[ksk-change] Keeping two KSK keys long term

[Richard Lamb]

Mike-

 

Thank you very much for this.  As clearly one of those experts, I appreciate
the time (and patience) you have taken in an attempt to educate me.  I will
need read through this a few times more to get the full effect but I think I
get the overall logic and agree.   For some things the devil IS in the
details and cannot be explained in a one-liner.  I particularly like the
scheme described in (2).  As we all know no system is perfect and it was
with this in mind that we made sure that the system we use now for root ksk
management was not cast in stone.  We have thought about many improvements
and implemented some minor ones suggested by the TCRs but an in depth view
like yours is, well, refreshing.  

 

Thank you,

-Rick

 

 

 

 

From: ksk-rollover-bounces at icann.org [mailto:ksk-rollover-bounces at icann.org]
On Behalf Of Michael StJohns
Sent: Thursday, October 02, 2014 9:49 AM
To: ksk-rollover at icann.org
Subject: Re: [ksk-change] Keeping two KSK keys long term

 

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/2239401f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5456 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20141002/2239401f/smime-0001.p7s>