Hi Petr and Rick,
actually PKCS#11 provides for a mechanism to wrap / unwrap keys for
export and import from and into key devices. You can wrap asymmetric
keys with symmetric keys and symmetric keys with asymmetric ones. Even
the formats and mechanism are well defined.
However, with SoftHSM you still deal with key material in software, aka
process memory of the CPU. The symmetric wrapping keys has no more
protection than the private key to the wrapped.
The weakness of the design is already to store keys in memory, even if
you use some kind of obfuscation or even employ a very skilled
cryptographer. Easiest attack is to copy the database with key material
and you're done - Keys copied and not even detected.
So security here comes from the assumption that the machine running
SoftHSM is well protected - an assumption that often might not hold true
(see the heartbleed bug).
We've implemented a similar key backup / restore mechanism in the
SmartCard-HSM, which is a hardware token storing private keys. In that
design the symmetric wrapping key is introduced into the SmartCard-HSM
as part of an organizational key management procedure using key shares
in an n-of-m threshold scheme [1]. Once that procedure is completed, the
SmartCard-HSM can be integrated into a cluster and keys can be shared
amongst them. Neither private signing keys nor the wrapping key are ever
exposed, you just have the ability to use the private key, export it in
wrapped form or import a wrapped key from some other SmartCard-HSM in
the cluster.
That way you can implement a scalable and redundant key management
scheme with minimal hardware cost. Unless you need more that 10 signing
operations per second, you should be fine with that setup.
Andreas
[1]
https://github.com/OpenSC/OpenSC/wiki/SmartCardHSM#using-key-backup-and-restore
Post by Rick van ReinHi Petr,
I have to be bold I fear?
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.
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
_______________________________________________
Opendnssec-user mailing list
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
--
--------- CardContact Software & System Consulting
|.##> <##.| Andreas Schwier
|# #| Sch?lerweg 38
|# #| 32429 Minden, Germany
|'##> <##'| Phone +49 571 56149
--------- http://www.cardcontact.de
http://www.tscons.de
http://www.openscdp.org