<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/1/2014 11:49 PM, Richard Lamb
wrote:<br>
</div>
<blockquote
cite="mid:1f69100adec244c6a63594023d7dc4dc@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG"
type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<br>
Hi Rick - <br>
<br>
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.<br>
<br>
"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."<br>
<br>
<br>
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).<br>
<br>
<br>
(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. <br>
<br>
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*). <br>
<br>
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.<br>
<br>
(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: <br>
<br>
<ol>
<li>Each partial signer has a smart card (miniHSM?) with a
specific key pair where the public key is known to the HSM. <br>
</li>
<li> 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.</li>
<li>Each partial signer "signs" the object to be signed using its
own key pair and publishes the result to a publicly available
webpage.</li>
<li>ICANN, on the date of the signing ceremony:</li>
<ul>
<li>Verifies each signature from (3) external to the HSM and <br>
</li>
<li>randomly selects K (where K is the minimum necessary
signers) step (3) signed objects<br>
</li>
<li>Feeds the step (3) signed objects into the HSM where each is
independently verified</li>
<li>When the HSM verifies K signed objects, it produces its own
signature over the "object to be signed" and emits it.</li>
</ul>
<li>ICANN publishes the new signed DNSKEY RRSet.</li>
</ol>
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.<br>
<br>
An even more comprehensive change would be something like "Practical
Threshold Signatures, Victor Shoup (<a class="moz-txt-link-abbreviated" href="mailto:sho@zurich.ibm.com">sho@zurich.ibm.com</a>), 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.<br>
<br>
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). <br>
<br>
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. <br>
<br>
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).<br>
<br>
Mike<br>
<br>
<br>
</body>
</html>