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

On Mon, 2014-10-20 at 08:01 -0400, Dmitri Pal wrote: > On 10/20/2014 12:18 AM, Fraser Tweedale wrote: >> 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. The feature that Christina is probably referring to was a mechanism I put in place a little while back to distribute a shared symmetric key from the TKS to the TPS during installation. I am also wary about storing wrapped CA signing keys in LDAP. These aren't just the keys for a user, but rather CA signing keys -- literally the keys to the kingdom (or at least little fiefdom). Now, I still think though that it is possible to possible to transport the subCA keys between clones safely. Here is one suggestion: 1. We create a new service on the CA for the distribution of subCA signing keys. This service may be disabled by a configuration setting on the CA. Whether it should be disabled by default is open to debate. 2. SubCA detects (through ldap) that a subCA has been added. It sends a request for the CA signing key, including the identifier for the subCA and half of a session key (wrapped with the subsystem public key). Recall that the subsystem key is shared between clones and is the key used to inter-communicate between dogtag subsystems. 3. The service on the master CA generates the other half of a session key and wraps that with the subsystem public key. It also sends back the subCA signing key wrapped with the complete session key. There are lots of variations of the above, but they all rely on the fact that the master and clones share the same subsystem cert - which was originally transported to the clone manually via p12 file. The subsystem certificate is stored in the same cert DB as the signing cert, so if it is compromised, most likely the CA signing cert is compromised too. > I think the best would be to have manual distribution of the keys > assumed by default but have a way for admin to specify that he is OK > with replicating keys via LDAP in a wrapped blob. > Not all environments are the same. In many cases wrapped keys in LDAP > would be good enough but in some they would not so to fail safe the > manual option should be default. > Given that these are CA signing keys - even if the subdomain is smaller - I'd rather err on the side of caution and use a mechanism similar to the above. > 2c. > >> 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&lt;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 _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel