11:18 p.m.
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> 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_implementation
>>
>>
>>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