Re: [Pki-devel] lightweight sub-CAs; updated design

On Fri, Oct 17, 2014 at 10:04:32AM -0700, Christina Fu wrote: > sorry I missed a few folks in my reply ... > > On 10/17/2014 10:01 AM, Christina Fu wrote: >> Hi Fraser, >> >> This response is for the "Key generation and storage" part of the design. >> >> First of all, Dogtag does provide symkey retrieval via a JNI package which >> provides interface to NSS called "symkey". There had been talks of >> merging symkey functionalities into JSS (which is also a JNI package that >> provides interface to NSS) in the future. >> >> In fact, for years, Dogtag has been doing what's similar to what Petr^2 >> Spacek described with DNSSEC, the wrapping/unwrapping of keys on both NSS >> softtoken as well as supported HSMs for distribution without ever >> disclosing any private keys in memory. >> This is the most basic requirement for Common Criteria for RHCS. >> This is just to assure you that whatever you need, it's most likely >> already there and more. >> >> BTW, I'm not familiar with "SoftHSM". The name itself sounds like an >> oxymoron, but we don't have to get into that ;-). >> >> As far as HSMs go, once keys are generated, you are not going to be able >> to export any private keys out of it unless they are temporary and >> non-sensitive keys, which should not be the case for CA signing keys. >> In practice, since HSMs are expensive, people use net HSM so servers can >> share the same hardware unit as long as they are within the same secured >> network, which means that you don't have to try to distribute the certs >> and keys, as long as you have the right permission/privileges and enough >> info to access such network shared HSM. >> In cases when sharing of an HSM is not possible, HSM vendors provide >> assistance to "copy" keys from one HSM to another. When our customers run >> into that, we ask our customers to contact their vendor(s). >> In some situations, process can be taken to generate keys on soft token in >> a secure and isolated location and manually import to individual HSMs. >> What you do not want to do, is to put your CA signing keys anywhere other >> than an isolated backup facility or in the token itself, no matter how >> many times you wrap it. Ciphers get cracked every few years, and when >> your CA private keys are compromised, the consequences are insurmountable. >> You might ask, why then KRA keeps the wrapped user private keys on the >> ldap server for archival/recovery? The answer is very simple. Those are >> user keys. It would be bad if they are compromised, but not as bad or >> widespread. Also, those user private keys are wrapped with individual >> session keys (every key is different), unlike what DNSSEC is doing with >> one single "master key", if I read it correctly (I apologize I did not >> have time to look into DNSSEC at all). >> Anyway, Dogtag has a long history of serving facilities that require high >> security, so that's why it is what it is today. >> >> Hope this helps. >> Christina >> >> Christina, thanks for your detailed reply. OK, so if wrapped private keys in LDAP is unacceptable, what are the other options. I will just enumerate some ideas below; we can start discussion of these alternatives or maybe they will spark other ideas. - Push private keys directly to clones. The database contains the list of clones (cn=<host>,cn=CAList,ou=Security Domain,<basedn>) and their SecureAdminPort. Could we have an API for sending the private keys to each clone, where the keys would only be present on the wire in a secure channel, once for each clone? Drawbacks: additional logic needed to handle situations where a clone is offline at sub-CA creation time. - Pull private keys directly from generating clone to other clones. In a way, this is the dual of the previous suggestion. Clones can notice when a new sub-CA has been created in the database. The entry can contain a reference to the clone that created it, and other clones can contact that clone and request the private key over a secure channel. Drawbacks: additional logic needed to handle situations where the generating clone is offline; additional failure modes (e.g. if no clone with keys is online). - Do not automatically distribute private keys to clones. Focus effort on a good UX for administrators to distribute keys to clones. Drawbacks: seems to violate an important requirements - namely, that sub-CAs be ready to use across clones automatically (no administrator action required). I have ignored the HSM dimension above because it seems that customers using HSM are in one of two situations: 1) customer has a net-HSM used by all clones, so the key distribution problem doesn't exist, or 2) we cannot get the keys out therefore cannot distribute them. I'm not sure where pki-symkey fits into all of this. I had a quick look at the code but couldn't make much sense of it. Where should I look for examples of its intended use and capabilities, or to whom should I talk? Thanks all for your time and ongoing patience as I work out the design for this important feature.

Fraser >> On 10/16/2014 12:05 AM, Fraser Tweedale wrote: >>> On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote: >>>> On 15.10.2014 14:48, Simo Sorce wrote: >>>>> On Wed, 15 Oct 2014 17:48:35 +1000 >>>>> Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote: >>>>> >>>>>> On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote: >>>>>>> On Wed, 2014-10-15 at 01:15 -0400, Ade Lee wrote: >>>>>>>> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Just landed a big update to the lightweight sub-CAs design >>>>>>>>> proposal: http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>>>>>>>> >>>>>>>>> I plan to start the implementing next week. Aside from general >>>>>>>>> design review, specific things I need input on are: >>>>>>>>> >>>>>>>>> 1) >>>>>>>>> >>>>>>>>> How to propagate newly-generated sub-CA private keys to clones >>>>>>>>> in an automated way, and how to store them. >>>>>>>>> >>>>>>>> I'll comment about that in the IPA thread. I had thought that the >>>>>>>> keys etc. would reside in the primary CA certdb. >>>>>>>> >>>>>>> Actually, I'll respond here because the IPA thread has moved >>>>>>> slightly away from this. In the IPA thread, there is discussion of >>>>>>> storing the keys in ldap encrypted by some master key - which >>>>>>> presumably would be stored in the certdb. >>>>>>> >>>>>>> Decrypting the signing key and keeping it in memory is absolutely a >>>>>>> no-no. The CA signing key material should only be present in the >>>>>>> HSM/softoken - and should never be exposed unencryted outside the >>>>>>> token. All crypto operations must be done there. That most likely >>>>>>> means storing the data in the NSS certdb. >>>>>>> >>>>>> The design of key distribution could follow the DNSSEC design; see >>>>>> Petr Spacek's comments in this thread: >>>>>> https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html >>>>>> >>>>>> Presumably this design for key distribution has received some >>>>>> thorough attention. Perhaps some of the assumption for DNSSEC do >>>>>> not hold for Dogtag. I have copied Petr and Simo for their input. >>>>> We use a softHSM for the DNSSEC stuff (in theory can be replaced by a >>>>> hw HSM too), and keys are handed within it only. >>>> We are finishing DNSSEC right so I don't have time to study sub-CA >>>> design >>>> right now. For this reason I'm replying only with general statements: >>>> >>>> - SoftHSM can be used as generic purpose token with PKCS#11 interface. >>>> - It supports multiple "PKCS#11 slots" in single SoftHSM installation >>>> so >>>> data can be separated as necessary: Each "slot" stores data in separate >>>> directory (with potentially different filesystem permissions, PINs >>>> etc.) >>>> - Upstream is responsive and accepts patches with new features (i.e. >>>> unimplemented pieces of PKCS#11 standard) without problems. >>>> - SoftHSM v2 code could use some cleanup but it has clear design and >>>> structure and I don't see extensibility problems. >>>> - Storage & crypto backends have clearly defined API so it should be >>>> possible to implement own back-ends (LDAP & NSS, if necessary). >>>> >>>> Generally I don't see a reason why it couldn't not be used for as key >>>> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or >>>> even >>>> for clients (GNOME keyring backed with SSSD-SoftHSM tandem). >>>> >>>> -- >>>> Petr^2 Spacek >>> Thanks Simo and Petr for your input. >>> >>> After some more investigation it looks like all the crypto in >>> Dogtag, including for KRA etc, is performed within the >>> ``CryptoManager`` facility. With that in mind, I've got a more >>> concrete implementation proposal that also uses ``CryptoManager``. >>> If it proves insufficient I will embark on a more detailed analysis >>> of feasibility/implications of bringing SoftHSM as a Dogtag >>> dependency (and remain open to other key distribution ideas). >>> >>> One difference between the DNSSEC/SoftHSM design is that the master >>> key has to be unwrapped each time a sub-CA key needs to be >>> installed. This was because I couldn't see a way to store and >>> retrieve a specific SymmetricKey in CryptoManager/CryptoToken. If >>> there's a way to do this and I've just overlooked it, let me know. >>> But I don't think the security of the scheme is impacted ; it just >>> means that there's a bit of repeated work when we import sub-CA keys >> >from the database. >>> Direct link to key distribution implementation detail in the design >>> proposal: >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based... >>> >>> >>> Cheers, >>> >>> Fraser >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ >> Pki-devel mailing list >> Pki-devel(a)redhat.com >> https://www.redhat.com/mailman/listinfo/pki-devel > _______________________________________________ > Pki-devel mailing list > Pki-devel(a)redhat.com > https://www.redhat.com/mailman/listinfo/pki-devel _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel