Fwd: [Opendnssec-user] SoftHSMv2: key extraction

[Rick van Rein]

Hi Petr,

I have to be bold I fear…

> You can read about the basic idea here:
> https://www.redhat.com/archives/freeipa-devel/2014-April/msg00565.html

You are proposing to drag around the private keys between pieces of software, in a format encrypted to an externally generated, symmetric master key that is known to multiple pieces of infrastructure.  That ranks as… functional thinking, but rather poor security practice.

> (Discussion continues in next months, I'm sorry for mailman inability to create direct links across months.)

Quickly browsing through the responses, there has only been discussion about directory formatting issues, but there are no security-minded responses.

> Any comments on it are more than welcome!

To be honest, I am shocked — this is a *very* weak design from a security perspective.  What you are doing undermines the concept of PKCS #11 completely, and it is *much* weaker than a SoftHSM-based implementation.

The thing is, even with SoftHSM you have good control over where your private key material is copied to; think non-swappable memory, think avoidance of static bits burning into DRAM cells through ion displacement; I don’t know how far SoftHSMv2 goes, but at least it is in a position to care.  The PKCS #11 API is the way to access private keys through using them, and anything that comes out of a signing operation is safe to publish.  An HSM strongly limits the places where the (wrapped) private key is stored temporarily or for a long time, while you are proposing to drag the private key material through all sorts of functional / technical / networking tools, a lot of which has not been vetted for security like an HSM is.  SoftHSMv2, is designed by knowledgeable cryptographers and should be considered a superb manner of key management relative to your own coding, unless you and all coders in the wrapped-private-key path also happen to be such knowledgeable cryptographers.

The use of a master key, which I presume is used to decode the private key, is an even clearer misuse of PKCS #11; not only are you not using its private key encapsulation, you are even decrypting it outside of any HSM (“professional key management”) engine.  You are effectively reducing PKCS #11 to a software library, indeed pretty much like an OpenSSL library that loads private keys into the rich / complex / dangerous functionality of an application, decrypts them for use in what may or may not be rock-solid signing code.  You are basically saying that you don’t want or need PKCS #11 and that you would rather not have to deal with it at all, because it is obstructing you and its security model is not of interest to you.This means that your users wil not be able to upgrade from SoftHSMv2 to the higher level of security from a “real” HSM because you are bypassing it anyway.

This is indeed the type of problem in your architecture that I suspected from your question.

So, please don’t do it this way.

A much better way would be:

1. Distribute public key material through LDAP
2. Keep private keys behind PKCS #11
3. Access PKCS #11, possibly remotely, to create any signatures
4. Exercise strict access control over the HSM, and be very mindful about the PIN used to access it
5. If you must, encapsulate replication algorithms between HSM nodes into a small and very, very secure and very, very limited-task bit of code (PKCS #11 wrapper or SoftHSMv2 storage engine) and don’t treat it is a trivial bit of coding but as a security hazard

I apologise if I’ve been bold in the above; that must then have been my desire for clarity.  I hope that similar mistakes haven’t been made in other parts of FreeIPA?


Hopefully useful,

Cheers,

Rick van Rein
OpenFortress Digital signatures