Peter Gutmann wrote:
Apparently the DNS root key is protected by what sounds like a five-of-seven
threshold scheme, but the description is a bit unclear. Does anyone know
more?
Dear Peter,
It's about time the PKI experts have a look at DNSSEC ...
Let me try to convey my understanding to you, but please forgive the
condensed language (I don't have time to make it self-explanatory).
Yes, the DNSSEC root KSK private signature key is protected with such a
technology.
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 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 request by the USG is documented among other root signing requirements.
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).
They used the threshold scheme for two purposes.
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.
My critique is this lack of control/audit scrutiny for one-time shipment
of crypto configuration material. Had ICANN published the *detailed*
procedure in draft form, I would have pointed out this to them in a
timely manner. In retrospect, their draft procedure document (which was
a summary) hinted to this critique, but formulating it at that point was
not on my plate: the Intaglio NIC key management organization does not
need this second purpose (it applies its solution equally to the first
purpose to the second purpose if it arises -- I presumed ICANN would
come up with the same idea in their detailed procedure).
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.
Hope it helps ...
Regards,
(Oh, and for people who want to quibble over "practically-deployed", I'm not
aware of any real usage of threshold schemes for anything, at best you have
combine-two-key-components (usually via XOR), but no serious use of real n-
of-m that I've heard of. Mind you, one single use doesn't necessarily count
as "practically deployed" either).
Peter (who has two more Perry-DoS-ing conversation-starter posts to make, but
will leave them for awhile now :-).
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [email protected]
--
- 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 [email protected]
