Here's my scenario in detail: We have 3 parties: (V) Vendor of intellectual property (U) User of intellectual property (may not see the IP, but use it with some tools and see the output) (T) Tool provider (may decipher the IP and use it, but not show it to (U)) According to IEEE-1735 we do the following: The (V) creates a session key and encrypts it's intellectual property using AES-256. Then he encrypts the session key using RSA-4096 and the public key of (T). So (T) should be able to decipher the session key and thus the IP. Now (T) burns his private key into his tool to his customer (U) to use all IP that some vendor (V) encrypted for the use with (T)'s tools. The critical scenario is the following: Assume (U) is the bad guy, who is interested in the intellectual property. He could replace the openssl shared libs to intercept the call to |AES_set_encrypt_key(..)| and steal the session key. With this key he and everyone he shares the key with can decipher the IP of (V). Now my company is (T) and we don't want to leak (V)'s session key. You may assume that our binary is protected state of the art agains debugger attacks and stuff. So the only question is if the shared openssl library makes the tool more vulnerable? Thanks in advance, Mirko Am 20.06.2016 um 18:04 schrieb Michael Wojcik: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Mirko Fit >> Sent: Monday, June 20, 2016 09:36 >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] openssl shared libs >> >> I meant the easy way of replacing a shared lib (no need to be root): >> > LD_LIBRARY_PATH=/path/to/modified/shared/lib:$LD_LIBRARY_PATH >> > my_tool > What's the attack tree look like for this case, under your threat model? > > Here you're talking about users running "my_tool" and subverting their own security. They already could run my_tool under a debugger and intercept keys and so on. And what "passwords" (per your initial email) are being handled by my_tool that the user doesn't know about? Are they hard-coded in the my_tool binary? > > That said, there *are* possible attacks here. For example, an attacker might use social engineering to get a user to run my_tool with subverted shared libraries; essentially that's a side-loading attack. But it needn't be the OpenSSL libraries, because once the application is running malicious code, all bets are off. (Subverting OpenSSL would be convenient for stealing TLS credentials, but it's not necessary.) Or an attacker might gain access to a user account and set LD_LIBRARY_PATH, LD_PRELOAD, etc in the user's environment and wait for the user to run my_tool. > > But these considerations don't suffice to create a coherent security policy. You need a threat model so that you can evaluate the economics. What are the vulnerabilities under your model created by dynamic loading, and what do they cost? What are the vulnerabilities created by static linking (Ken Goldman rightly mentions the difficulty of picking up security updates, for example), and what do they cost? > > If you don't have the resources to create a proper threat model and produce usable cost estimates, then you have to use heuristics. And the heuristic most widely followed in this case is "link the OpenSSL shared objects". > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160623/b4740cf1/attachment-0001.html>
