Jakob Schlyter wrote:
On 1 aug 2010, at 16.43, Thierry Moreau wrote:
Technically, the USG requested FIPS-140-2 level 4 HSM technology for the DNS
root signing gear. This implies a single source, with a very inflexible user
interface (no special personalization of the HSM for the DNSSEC project). The
threshold scheme was present in the vendor offering but there was no documented
use of it (it may have been used internally by some organizations that would
have taken seriously the dual control principle but who knows).
I'm not sure what you mean with "no documented use of it" and I'm not sure why
there is a need to add any FUD on this matter. If you have any questions or doubt
regarding the m-of-n implementation and its use, I'm sure we can get the appropriate
answers from the vendor.
I was referring to "documented use of it" *before* the ICANN work on DNS
root signature. I am sorry if you understood differently.
I don't know whether a number-theoretic foundation lies behind the threshold
scheme. In any event, the crypto value protected by the scheme is the long term
(intergity-)encryption key for the HSM configuration file, which includes the
DNSSEC KSK private key.
The storage master key (SMK) used for key backup is protected by a 5 of 7
scheme. The activation key for the HSM key material (aka AAK) is protected by
a 3 of 7 scheme. This is all documented in the DPS.
I am quite sure the activation keys are outside the scope of attention
by Peter. Activation keys relate to a very different set of threats and
vulnerabilities.
The detailed usage (the HSM is FIPS-approved, the usage is outside of compliance scope)
is also documented (as usual you have to infer the operating principles from a plethora
of minute details and meaningless acronyms). I made a critique of it on this list
recently. Outside of this critique is the (inconsequential) fact that they seem to use
"1234" as the PIN for the smart cards (I got this fact from a glimpse at the
real-time video of the key ceremony).
There is no PIN for the SMK shares. The is a PIN for the AAK share, but as we
have other security controls to manage the risks that the PIN would mitigate
(remembering that the PIN itself introduces some issues as well), we choose to
not use it (or rather; use a fixed, known PIN).
Thanks for the clarification. Indeed, the choice not to use it (and not
to apply PIN protection to the SMK shares by design) follows a logical
set of usage assumptions.
One is the backup for long-term recovery capability. They rely on 5-of-7
custodians spread across a few continents (ICANN needs to look like an
international organization).
The other purpose was transient, for the duplication of signature capability from the "East
coast facility" to the "West coast facility". In that case, they use something like
2-of-3 (or 2-of-4) but they shipped the key share media (smart cards) and the HSM configuration
file (yes, it *WAS* encrypted!! ) by means not subject to the same control/audit scrutiny as the
rest of the procedure.
The above is actually the same very SMK, but the 2nd copy of the SMK shares
(the one used for transporting the key material from the east to the west
coast) was destroyed as part of the ceremony at the west coast (where the key
from the east coast where restored). The 2nd copy of the SMK was generated
using a 2 of 4 scheme.
If it leaked in transit, the destruction (electronic erasure followed by
actual shredding of smart cards) is pointless. Otherwise, we seem to
agree on the basic facts.
The couriered key material was indeed under the same control/audit scrutiny as
the rest of the procedures, is was documented both in writing and by video.
Anyone in doubt of what happened, how data was transported and what controls
were in place to detect tampering and/or other threats, are more than welcome
to contact me and I will try to answer any questions.
The very "couriered key material" was indeed created and used under
these controls. My attention is focused on the courier *OPERATION* itself.
The offer to answer questions triggered a private e-mail to Jakob (but
no genuine question). If anything new comes from this exchange, I will
try to report to this same mailing list.
With the next key generation for DNS root KSK signature key, ICANN may have an
opportunity to improve their procedure. However, at this point the project will
be the focus of less attention, and the institutional commitment may not be as
strong as it was for the first key generation.
We'd be happy to learn from your experience in this matter and will listen
carefully to any feedback from the community. But before submitting comments, I
do urge people to review the key ceremonies that took place on the east and
west coast (audit material is available online at
http://data.iana.org/ksk-ceremony/).
Understood.
jakob
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
