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-boun...@openssl.org] On Behalf
Of Mirko Fit
Sent: Monday, June 20, 2016 09:36
To: openssl-users@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".
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
