Re: Is this the first ever practically-deployed use of a threshold scheme?
On 2 aug 2010, at 16.51, Jeffrey Schiller wrote: Does the root KSK exist in a form that doesn't require the HSM to re-join, or more to the point if the manufacturer of the HSM fails, is it possible to re-join the key and load it into a different vendor's HSM? With the assistance of the vendor (or their employees), it would be possible to reassemble the storage master key (SMK) by combining 5 of 7 key shares, then decrypting the key backup. There is nothing in the HSM units itself that is needed for a key restore. In other words, is the value that is split the raw key, or is it in some proprietary format or encrypted in some vendor internal key? The value that is split is the SMK, used to encrypt the actual key. The actual key is not split and, once in production, is never to be transported outside the ICANN Key Management Facility. Back in the day we used an RSA SafeKeyper to store the IPRA key (there is a bit of history, we even had a key ceremony with Vint Cerf in attendance). This was the early to mid '90s. Aha, that's why Vint was so on top of things during the East Coast key ceremony :-) The SafeKeyper had an internal tamper key that was used to encrypt all exported backups (in addition to the threshold secrets required). If the box failed, you could order one with the same internal tamper key. However you could not obtain the tamper key and you therefore could not choose to switch HSM vendors. In this case, the SMK == the tamper key. jakob - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 2 aug 2010, at 08.30, Peter Gutmann wrote: For the case of DNSSEC, what would happen if the key was lost? There'd be a bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but it's not like commercial PKI with certs with 40-year lifetimes hardcoded into every browser on the planet is it? Presumably there's some mechanism for getting the root (pubic) key distributed to existing implementations, could this be used to roll over the root or is it still a manual config process for each server/resolver? How *is* the bootstrap actually done, presumably you need to go from no certs in resolvers to certs in resolvers through some mechanism. Initial bootstrap is done by - distribution of the key by ICANN (via http://data.iana.org/root-anchors/) - distribution of the key by the vendors themselves Authentication of the root key can be achieved as part of the the distribution mechanisms above, or by transitive trust through people who attended the key generation ceremony. We've already seen public attestations from participants (e.g., [1], [2] and [3]). Key rollovers are performed as specified in RFC 5011, i.e. a new key is authenticated by the current key. This does of course not work when the existing private key material is inaccessible (on form of lost). It could work if the key is lost by compromise, but one has to take into consideration how the key was compromised in such cases (key misuse, crypto analysis, etc). For the generic end user, I would expect vendors to ship the root key as part of their software and keep the key up to date using their normal software update scheme. jakob [1] http://www.kirei.se/en/2010/06/20/root-ksk/ [2] http://www.trend-watcher.org/archives/dnssec-root-key-declaration/ [3] http://www.ask-mrdns.com/2010/07/root-dnssec-key-attestation/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 31 jul 2010, at 08.44, 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? The DNS root key is stored in HSMs. The key backups (maintained by ICANN) are encrypted with a storage master key (SMK), created inside the HSM and then split among 7 people (aka Recovery Key Share Holders). To recover the SMK in case of all 4 HSMs going bad, 5 of 7 key shares are required. (https://www.iana.org/dnssec/icann-dps.txt section 5.2.4) According to the FIPS 140-2 Security Policy of the HSM, an AEP Keyper, the M-of-N key split is done using a La Grange interpolating Polynomial. I'd be happy to answer any additional questions, jakob (part of the team who designed and implemented this) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
On 16 jul 2010, at 19.59, Thierry Moreau wrote: With what was called DURZ (Deliberately Unvalidatable Root Zone), you, security experts, has been trained to accept signature validation failures as false alarms by experts from reputable institutions. Thierry, do you know of anyone that configured the DURZ DNSKEY and accepted the signature validation failure resulting because of this? We had good (documented) reasons for deploying the DURZ as we did, the deployment was successful and it is now all water under the bridge. Adding FUD at this time does not help. Auditing details are not yet public. Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything missing, please let me know. I am wondering specifically about the protections of the private key material between the first key ceremony and the second one. I didn't investigate these details since ICANN was in charge and promised full transparency. Moreover, my critiques were kind of counterproductive in face of the seemingly overwhelming confidence in advice from the Verisign experts. In the worse scenario, we would already have a KSK signature key on which a suspected breach qualification would be attached. The key material was couriered between the Key Management Facilities by ICANN staff members. I'd be happy to make sure you get answers to any questions you may have regarding this handling. Is there an emergency KSK rollover strategy? Yes, please read the DPS - https://www.iana.org/dnssec/icann-dps.txt. jakob (member of the Root DNSSEC Design Team) -- Jakob Schlyter Kirei AB - http://www.kirei.se/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
