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 

Hopefully useful,


Rick van Rein
OpenFortress Digital signatures

Freeipa-devel mailing list

Reply via email to