ENGINE API and a compromised client or server

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

ENGINE API and a compromised client or server

Chris Gray-4
Hi all,

On a project I am working on we are wrestling with the problem of
preventing discovery of the private key, in a consumer device. I have been
advocating the use of the ENGINE API as a general model which can be used
to provide the best isolation possible on the customer's chosen hardware:
 * at a minimum no direct accessibility of the private key file (or
dedicated flash region) from the internet-facing process;
 * better still if internet-facing process runs in an LXC (esp. if
unprivileged);
 * ideally of course true SHM ($$$);
without needing to maintain multiple codebases.

Some colleagues have expressed concern that API methods such as
RSA_(public,private]_[en,de]crypt could be used by a compromised
client/server to launch a chosen-plaintext attack. (For the record we are
also using ECDSA, so this question is not purely RSA-specific). I am not
unduly worried about the _public_ functions because we should be able to
insist that a decent padding algorithm is used and then we are pretty
safe, right? I am more nervous about RSA_public_encrypt, which I think is
needed by TLS and which only seems to support RSA_PKCS1_PADDING (not
good). Is this a feasible attack vector?

Note that we are not only talking about servers here, rather we currently
have only one internet-facing server (HTTPS) and a growing number of
XXX-over-TLS clients, so if anything these are a greater source of
concern.

Any pointers are very welcome!

Chris Gray


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users