[ksk-change] Keeping two KSK keys long term

[Michael StJohns]

On 10/1/2014 11:49 PM, Richard Lamb wrote:
> Security level/controls for all key material must be equal or better.
> That's why we don't have a second backup key since the storage of the
> additional key would incur the high costs of ensuring it to was equally
> secured in a separate facility (5-6 tiers etc...).  But of course I am just
> parroting what I learned from the experts on the cc line.  If the community
> says they don't care, well.....
>
> -Rick
>
>
>
>

Hi Rick -

This one is going to be long winded and slightly pedantic - details are 
important.  It's a general follow up to your email and to the others on 
this thread.

"Security level/controls for all key material must be equal or better."  
As stated, this has a number of issues.    I'm going to restate this in 
a slightly different way:  "Cryptographic material (keys, hardware 
security modules, crypto ignition keys, backup material) must be 
protected in a manner to provide at least the minimum desired level of 
assurance for the system.  This does not mean that all cryptographic 
material must be protected equally, but that, taken as a whole, the 
protections applied to each component enable at least that minimum level 
of assurance for the system as a whole."


There are two items of assurance that you have to address, and each has 
its own set of concerns:  1) Sufficient cryptographic material has to be 
available to complete a desired cryptographic operation when necessary; 
(e.g. assurance against loss); 2) Sufficient protections need to be in 
place to prevent the completion of the cryptographic operation unless 
the policy requirements are met (assurance against compromise - includes 
both using the HSM out of policy, and extracting key material from 
within any policy wrapper).


(1) is generally addressed through redundancy and backups.  You provide 
sufficient copies of the material to reduce the chance of a complete 
loss of the material is less than your assurance threshold.  That can be 
done through split key (threshold) paper systems, smart cards, backup 
HSMs etc.  The hard part with (1) is preventing (1) from causing issues 
with (2).  But that's not actually hard if you look at the math rather 
than the hardware.

There used to be a device called a STU III - secure telephone unit. It 
was certified to encrypt voice up to the US Top Secret level. The 
interesting thing about the device was that it was unclassified when 
separated from its crypto ignition key.  The STU III and the CIK each 
had part of the key material necessary to enable secure communications 
and policy required nothing more than the operator carry the CIK with 
him when the STU III wasn't in use to make both pieces unclassified.  
(This by the way drove the crypto custodians bonkers as this was 
*something new*).

The point is that if its impossible to get enough of the parts of the 
private key together without someone finding out about it, then the 
protections on each share of the key do not need to be at the same level 
as the key when its assembled. Using more of the math based approaches 
(in addition to hardware based approaches) for key protection should be 
considered the next go round.

(2) Is slightly more interesting.  One of the discussion points on an 
earlier thread was the issue of getting N people to show up every so 
often to do a key ceremony.  Looking at this, I understand this is good 
theater, but maybe not a sustainable operational model.  How about instead:

 1. Each partial signer has a smart card (miniHSM?) with a specific key
    pair where the public key is known to the HSM.
 2.   ICANN publishes (a week before the due date) a draft "object to be
    signed" - basically the new DNSKEY RRSet with all the right times
    and keys.
 3. Each partial signer "signs" the object to be signed using its own
    key pair and publishes the result to a publicly available webpage.
 4. ICANN, on the date of the signing ceremony:
      * Verifies each signature from (3) external to the HSM and
      * randomly selects K (where K is the minimum necessary signers) 
        step (3) signed objects
      * Feeds the step (3) signed objects into the HSM where each is
        independently verified
      * When the HSM verifies K signed objects, it produces its own
        signature over the "object to be signed" and emits it.
 5. ICANN publishes the new signed DNSKEY RRSet.

This requires a change to the policy engine of the HSM obviously (e.g. 
PKCS11 isn't sufficient), but means that you can securely sign the root 
with remote actions in a publicly verifiable manner.  It also means that 
you can increase the number of possible partial signers (with the 
resultant broader community participation) with minimal cost.  Note that 
you still need some sort of ceremony to generate new keys.

An even more comprehensive change would be something like "Practical 
Threshold Signatures, Victor Shoup (sho at zurich.ibm.com), IBM Research 
Paper RZ3121, 4/30/99" where there is no central HSM, but where the 
partial signatures are done remotely and then assembled into a full 
signature by anyone who wanted to do so.  I built DNSSEC signing code 
for this that works quite nicely That paper applies to RSA, but there 
are similar (not equivalent) schemes for EC.

There are a number of ways to enhance this using cryptographic 
techniques combined with hardware policy enforcement to minimize the 
chance of even one of the remote private keys being compromised (e.g. 
2of2 or 2of3 secret sharing of the partial signer's private key with 
reassembly only for signing).

I said earlier that it's a numbers game and if - mathematically - you 
need N pieces  to do the crypto operation, preventing an attacker from 
getting N-1 is a win.  If there are K total elements, then you also need 
to ensure that no more than K-N elements are irrevocably lost.

Going back to the original comment that not all cryptographic material 
requires the same level of protection.  Consider a two key trust anchor 
set for the root.  One key is used fairly regularly, the second is the 
back up.  3 parts of the backup key pair resides in a PCIe HSM card 
locked in a safe deposit box near the ICANN facility, three parts on a 
second PCIe HSM at the back up facility, part of the key pair is on a 
smart card in Paris, part on a smart card in London and part on a smart 
card in ??.   Also, none of those smart cards actually give you 
credentials to enable the HSM - those are held by other people. The 
backup system requires a 4 of 6 key recovery (an HSM plus one smart 
card).    The cost for the PCIe HSMs is ~$5k, but even if they're stolen 
they're useless without one of the 3 smart cards, and without the 
operational credentials for the HSM.  The smart cards on the other hand 
are mathematically useless without the data in the HSM.  The cost for 
doing the separation of operational key from backup key becomes the cost 
of two safe deposit boxes, 2 PCIe HSMs and 3 smart cards being carried 
around in wallets. (Or maybe 6 - the 4 of 6 for HSM A may not be the 
same split of 4 of 6 keys for HSM B).

Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141002/431e32cc/attachment.html>