> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of Timo 
> Lange
> Sent: Monday, 11 January, 2021 10:56

> The root certificate, as well as the client private key is not available 
> inside
> the container, but stored in a HSM.
> For sure the private key may never leave the HSM

OK.

> and also the root certificate should not.

This doesn't make any sense. Certificates are not sensitive data, and it's 
inconvenient, if not impossible (depending on application software and HSM 
firmware) to split certificate chain validation across the host machine and the 
HSM.

Using the HSM as a certificate trust anchor *store* might make sense, depending 
on the use case. But the certificate would have to be extracted from the HSM by 
the application at runtime and made available to OpenSSL (or whatever's 
handling chain validation) so the peer's entity certificate can be verified.

> The application cannot directly interfere with the HSM through standardized 
> mechanisms
> as it is not accessible from inside the container.
> For doing so a proprietary interprocess-communication is required.

That certainly seems like unnecessary complexity, but I'll assume there's some 
valid justification for it.

> I assume I need to write a custom ENGINE, but failed with all my approaches.

You *could* write a custom engine, which you'd then have to rewrite as a custom 
provider when support for OpenSSL 1.1.1 ends and you need to move to OpenSSL 
3.0 or its successor.

However, you could also hide your IPC mechanism under a PKCS#11 implementation, 
and just use OpenSSL's PKCS#11 engine. PKCS#11 is the standard mechanism for 
talking to an HSM, and nothing says it can't involve IPC in the middle.

That is: OpenSSL -> pkcs11 engine -> your IPC client (written as a PKCS#11 
library) -> some communications channel -> your IPC server -> real PKCS#11 
library for your HSM. You could implement the IPC client and server using an 
open-source PKCS#11 shim such as pkcs11-helper. This area has been discussed 
recently on this list.

However, now you have the problem of securing the IPC channel. This is an 
architecture I'd be reluctant to endorse, given the complexity and attack 
surface.

--
Michael Wojcik

Reply via email to