Is this the first ever practically-deployed use of a threshold scheme?

[Jakob Schlyter]

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 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.


> 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).


> 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.

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.


> 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/).


	jakob

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com