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

Mon Oct 20 04:18:53 UTC 2014

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 at 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 at redhat.com
> >>https://www.redhat.com/mailman/listinfo/pki-devel
> >
> >_______________________________________________
> >Pki-devel mailing list
> >Pki-devel at redhat.com
> >https://www.redhat.com/mailman/listinfo/pki-devel
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel