[Dnssec-deployment] Root key rolling (was NIST guidance as to DNSSEC and others)

Michael StJohns mstjohns at comcast.net
Wed Feb 8 19:48:17 EST 2012

At 04:32 PM 2/8/2012, Joe Abley wrote:

>On 2012-02-08, at 16:24, Michael StJohns wrote:
>> Yup - I got this.  I will note that all of these are portable, and that the RKSHs are NOT stored at the KMF.  Per the DSP, section 4.1.6 appears to be controlling with respect to the storage of the encrypted backup KSK.
>It's DPS by the way (DNSSEC Policy and Practice Statement).


>>> Although this may not require making an exact copy of the KMF, it would require storing it in facilities with comparable security.
>> Not exactly. Unless I'm completely misunderstanding the DSP,  the encrypted KSK smart card needs to be stored in a facility that meets the requirements of 4.1.6  or 4.1.8.   (E.g. where do you currently store the off-site backups of the encrypted KSK?)   
>In the same safes that are used to store the HSM that is backed up onto those smart cards.

So in other words, no "off site backups".

>> RKSHs don't even require that much protection (section 5.2.4).  In fact, I can't see any requirement in the DSP or the related "trusted person" document that the RKSH smart cards be secured.
>The RKSHes are only used to recover from the situation where the HSMs containing the KSK at both locations all fail. This was considered a worthwhile risk to guard against since all HSMs run the same code, and originate from the same vendor. (There was only one HSM available at the time of deployment that met the requirements of NTIA/NIST).

I really don't understand why having only one vendor contributes to "worthwhile risk against failure" - but that's a side issue.  I'll be interested in seeing how you transition from the current HSM vendor to the next.

>> A live key on an HSM requires the protection level of the KSF.

Key signing facility I believe - someone else's term - apparently not in this thread.

>>  In my model, the back-up/next key is NOT an live key on an HSM unless and until it's time to place it into operation.  It may be generated on the HSM originally, but once the backups are taken, the key is removed from the HSM.  If its needed, the key backup restoration ritual is performed to place the "next key" into operation.
>Whether or not the standby key is stored on smart cards or an HSM seems like a minor detail, no?

Actually it is not a minor detail.  

A key on the HSM can be compromised:
  via compromise of the HSM hardware, 
  a fault in the HSM firmware
  by theft of the HSM along with the activation credentials, 
  by theft of the HSM master keys (not sure the HSM you're using has externalized master keys - so) and the encrypted back up material.

A key outside of the HSM can be compromised by:
  decrypting the backup
      which implies that you a) have a copy of the backup
      and b) have the key shares or
       c) have a way of breaking the encryption.

Both can be compromised by
   breaking the cryptographic mechanism (e.g. large prime factoring) if you can see the public key.

 From a math point of view, having both the HSMs and the backups in the same place is the worst case as you can do an attack on either branch of the attack tree, and if either is successful, the attacker wins.

>> You want to secure the key backup - but the level of security is that needed to make sure that 5 people with RKSHs and the key backup can't come together unless authorized.   A physical escrow location, or a trust facility or even an n of k safe should be sufficient with the appropriate procedures to detect theft or other loss of the material.
>Sure, but that's a different level of protection than is enjoyed by the active KSK.

Agreed, but the question is not "different" but "sufficient for the risk".

>The active KSK was generated in one KMF, transported (encrypted, on N of M smart cards) in tamper-evident bags to the other KMF, and stored on HSMs there before it ever went into production. The chain of custody of the key was verified during that generation and transport process.

Chain of custody is interesting, but ultimately not all that important.  The question you have to ask is "what does an attacker need to put a back up key into service?"   Given that we're mostly going to assume that - absent a break-through attack (better than brute force) on the encryption mechanism protecting the key - the encryption is sufficient, and that the proofs for Shamir's secret sharing indicate it's absolutely impossible to recover the encryption key absent 5 shares, the key question is what do we need to do to keep the 5 shares separate (which is the same question for the primary key) and separate from the encrypted key (which is defined for the primary key as "keep the encrypted key in the safe at the KSF until we need).  So the problem for a back up key is "what level of protection for the encrypted key is sufficient?"

Strangely enough, it may not even be as hard as that.  Take a 5 of 7 system.  Retain 2 of the shares at the primary KSF, retain 1 share at the secondary KSF.  Distribute the other 4 shares as usual.  To break the key, you need to a) get a copy of the encrypted key, b) break into at least one of the KSFs, c) assemble 3 or 4 of the other RKSH  participants.  The encrypted key is absolutely useless without the material at the KSF.  And the KSF material is absolutely useless without the encrypted key.

>At no time since the key has been considered in production have the private key materials (encrypted, stored on HSM or N of M smart cards, or in any other form) existed outside the KMF.

Except - as you note above - in encrypted form, during the courier operation to move them from generator to secondary.


I think what you're possibly missing is that the encrypted key - even as a bare object - is an opaque, useless blob without the intervention of the RKSH's.  I mostly wouldn't be scared with publishing the encrypted blob on a public web page - and indeed, it may be a good idea to do just that.  It may provide a canary in the form of white hat cryptographers using that blob as a target and reporting their results.

That said, keeping the encrypted key sequestered does probably add to the security of the system in a very small measure.


More information about the Dnssec-deployment mailing list