[openssl-dev] Using openssl with a remote private key

[Douglas E Engert]

On 3/17/2015 10:44 AM, Tigran Gyonjyan (BLOOMBERG/ 731 LEX) wrote:
> Hi there!
>
> Recently I had to work on an openssl project where due to security requirements I had to place the private key for the server certificate on another machine. In order to be able to make openssl ignore
> the fake private key in the certificate I had to "hack" some data structures to delegate the handshake decrypt to the remote machine so that the handshake could succeed.

Introducing another machine, will introduce addition trust issues, as to why the
"server" trusts the "other machine" holding the private key, how does the "other machine" trust the "server" and trust
the network connections between the two machines.
If not done correctly, the "other machine" could be attacked to decrypt requests from a man-in-the-middle
pretending to be the "server".

(The certificate contains the public key, the private key is not part of the certificate.)

>
> I was wondering if this capability to delegate the decrypt function can be useful enough to incorporate into the official version.
> In cases when the client and the server are located on user's machine it is a risk to keep the private key on that machine.

As pointed out in other replies, PKCS#11 and openssl_engine could be used. If used with a
smart card, the smart card could be on the "other machine". The PKCS#11 implementation
could be using PCSC to talk to the smart card, which can be used across a network. For example remote desktop, rdesktop or RDP
can transport the smart card APDUs across the network.

This is usually used by a user with a smart card at a remote terminal, and the trust model
is different then in your case of a "server" to the "other machine".

>
> Let me know if there is a better solution for this problem.
>
> Cheers,
> Tigran
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>