[Freeipa-devel] SoftHSMv2: key extraction (originally to OpenDNSSEC-user)

[Simo Sorce]

----- Original Message -----
> 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,

To be honest, no, this is not very useful, let me bold, and I am not being defensive here.

You have not thought at all about the environment in which all this stuff is running, and
what is the aim is here.

There are certainly some compromises here, the compromise is between security and something
practical. Now that doesn't mean we can't change something, and we welcome thoughtful input.

Distribution of keys is a fundamental part of the design, it is clearly not as secure as a
HSM can be by keeping the private key always in hardware, but a single point of failure is
not useful in our model.

We want to architect things so that each server can use an HSM in order to deal with
the individual server keys, that is something we need to explore, and is in our pipeline,
and not just for DNSSEC. But the server keys only wrap distributed master keys that other
software will use. In some cases they can be feed back in to softHSM for sure, and we should
make it possible for the system to work that way in the long term.

so feedback in that direction will certainly help.
Thank you.

Simo.



-- 
Simo Sorce * Red Hat, Inc. * New York