Re: Is this the first ever practically-deployed use of a threshold scheme?
On Sun, Aug 1, 2010 at 7:10 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: ...does anyone know of any significant use [of split keys] by J.Random luser? I'm interested in this from a usability point of view. Maybe not J.Random but J.Corporate... A few jobs ago back in the late '90s, I worked for Network Associates which had bought PGP (the company). We instituted the use of PGP (the technology) corporate-wide for email and encrypted disk volumes. PGP allows for enforceable key recovery - corporate clients demanded it. Our corporate key recovery key was split into, I think, 5 parts with 3 parts required for key recovery. The parts were held by various corporate executive/officer types. The PGP product mostly hid from the end user the fact that every PGP-encrypted thing had an encrypted private key along with it (you could poke around and see the key recovery blob if you really wanted to). I don't know what the key recovery UI looked like. As a corollary, has anyone gone through the process of recovering a key from shares held by different parties...? It just so happens, I lost my PGP private key a year or two into this (failed to copy it when transferring to a new desktop). We had well documented procedures for key recovery. I never got my key or data back. I was never informed why. Perhaps the seldom used key recovery software had bugs and wouldn't work for my key, or we couldn't get the required big wigs into one room, or, probably most likely, at least three big wigs lost their shares. Michael Heyman - 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?
There is more than the UI at stake here, i.e. the basic functionality of the scheme. Say you distribute shares in a 4 out of 7 scheme (ABCDEF) and share A is published on the web. How do you recover from the remaining 3 out of 6 scheme into a 4 out of 6 scheme without having a key ceremony? In an ad-hoc multi-party scheme, you request 4 of the remaining compliant parties to destroy key material allowing them to participate in a group with the traitor A, but no other key material. No system UI, but admittedly a coordination nightmare! If the system is built to allow resharing then this is no problem. Resharing from a t-out-of-n scheme to an r-out-of-m scheme works as follows: If the secret s is shared using the (otherwise random) polynomial f of degree t then a share consists of (i,f(i)). To reshare, at least t or the original shareholders issue shares of f(i) in an r-out-of-m manner, i.e. take a polynomial gi of degree r and compute m shares (i,j,gi(j)). When these are distributed to the new users, the new users should end up with matching j's. The old shares (i,f(i)) are deleted. Each of the m new users now has t shares (i1,j,gi1(j)), (i2,j,gi2(j)), ... ,(it,j,git(j)). This information can be combined into a single share (j,G(j)) of s by using the Lagrange coefficients of the first scheme. All of this can be decorated with zero knowledge proofs to prove correctness of the shares etc. Note that there is no interaction of the t shareholders and everthing can be done remotely. In the scenario that one share A is published it's enough to have t-1 users help in the resharing since every new user can use the public information. On the other hand that's a mess to program, so it's more resonable to ask t of the remaining shareholders to help. Doesn't sound like a coordination nightmare to me. For all this in a more general setting see e.g. Redistributing Secret Shares to New Access Structures and Its Applications by Yvo Desmedt and Sushil Jajodia (1997) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.3353 Does this answer the question? Tanja - 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?
Tanja Lange wrote: There is more than the UI at stake here, i.e. the basic functionality of the scheme. Say you distribute shares in a 4 out of 7 scheme (ABCDEF) and share A is published on the web. How do you recover from the remaining 3 out of 6 scheme into a 4 out of 6 scheme without having a key ceremony? In an ad-hoc multi-party scheme, you request 4 of the remaining compliant parties to destroy key material allowing them to participate in a group with the traitor A, but no other key material. No system UI, but admittedly a coordination nightmare! If the system is built to allow resharing then this is no problem. Resharing from a t-out-of-n scheme to an r-out-of-m scheme works as follows: If the secret s is shared using the (otherwise random) polynomial f of degree t then a share consists of (i,f(i)). To reshare, at least t or the original shareholders issue shares of f(i) in an r-out-of-m manner, i.e. take a polynomial gi of degree r and compute m shares (i,j,gi(j)). When these are distributed to the new users, the new users should end up with matching j's. The old shares (i,f(i)) are deleted. Each of the m new users now has t shares (i1,j,gi1(j)), (i2,j,gi2(j)), ... ,(it,j,git(j)). This information can be combined into a single share (j,G(j)) of s by using the Lagrange coefficients of the first scheme. All of this can be decorated with zero knowledge proofs to prove correctness of the shares etc. Note that there is no interaction of the t shareholders and everthing can be done remotely. In the scenario that one share A is published it's enough to have t-1 users help in the resharing since every new user can use the public information. On the other hand that's a mess to program, so it's more resonable to ask t of the remaining shareholders to help. Doesn't sound like a coordination nightmare to me. For all this in a more general setting see e.g. Redistributing Secret Shares to New Access Structures and Its Applications by Yvo Desmedt and Sushil Jajodia (1997) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.45.3353 Does this answer the question? Yes, or at least it gives a good sense that these issues has been dealt with in the cryptographic literature. It seems to fulfill the operational requirements (obviously when a good faith participant receives new shares from a remote party, a trust relationship is needed, but that is a given irrespective of the underlying crypto). Thanks a lot for your answer! Regards, -- - Thierry Moreau Tanja - 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 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?
Peter Gutmann wrote: That's a good start, but it gets a bit more complicated than that in practice because you've got multiple components, and a basic red light/green light system doesn't really provide enough feedback on what's going on. What you'd need in practice is (at least) some sort of counter to indicate how many shares are still outstanding to recreate the secret (We still need two more shares, I guess we'll have to call Bob in from Bratislava after all). Also the UI for recreating shares if one gets lost gets tricky, depending on how much metadata you can assume if a share is lost (e.g. We've lost share 5 of 7 vs. We've lost one of the seven shares), and suddenly you get a bit beyond what the UI of an HSM is capable of dealing with. There is more than the UI at stake here, i.e. the basic functionality of the scheme. Say you distribute shares in a 4 out of 7 scheme (ABCDEF) and share A is published on the web. How do you recover from the remaining 3 out of 6 scheme into a 4 out of 6 scheme without having a key ceremony? In an ad-hoc multi-party scheme, you request 4 of the remaining compliant parties to destroy key material allowing them to participate in a group with the traitor A, but no other key material. No system UI, but admittedly a coordination nightmare! -- - Thierry Moreau With a two-share XOR it's much simpler, two red LEDs that turn green when the share is added, and you're done. One share is denoted 'A' and the other is denoted 'B', that should be enough for the shareholder to remember. If you really wanted to be rigorous about this you could apply the same sort of analysis that was used for weak/stronglinks and unique signal generators to see where your possible failure points lie. I'm not sure if anyone's ever done this [0], or whether it's just build in enough redundancy that we should be OK. Peter. [0] OK, I can imagine scenarios where it's quite probably been done, but anyone involved in the work is unlikely to be allowed to talk about it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - 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?
Jonathan Katz wrote: On Sat, 31 Jul 2010, Jakob Schlyter wrote: 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) This is just Shamir secret sharing, not real threshold cryptography. (In a threshold cryptosystem, the shares would be used in a protocol to perform the desired cryptographic operation [e.g., signing] without ever reconstructing the real secret.) Has real threshold cryptography never been used anywhere? CertCo (RIP) built a Certification Authority software product that used real threshold cryptography. Key shares for a k of n scheme (where k and n were chosen at key split time) were stored in hardware crypto tokens, and signatures were generated by having k tokens generate partial signatures and then combining them into a regular RSA sig. The system was deployed as the SET root CA for some time; we did try to sell it as a regular software product, but (corporate) political issues made that somewhat challenging. I honestly don't remember whether it was deployed by anyone else for anything other than SET, but it may be that one of the (many) other CertCo alumni on this list might. The original CertCo CA software used pretty simple threshold crypto (I can provide paper refs for the particular schemes we used if anyone really wants them), but by the time I left we had worked on verifiable schemes (where you can verify the partial sigs independently), proactivization (re-sharing to change k or n, or remove bad players), and so on. The deployed system did not implement distributed key generation, which had just appeared in the literature at that time -- the key was generated on one token, and then split; the key generation token was then intended to be destroyed. Although the system was designed to be used in a globally distributed fashion, with automated systems for sending work (things to sign) to sites holding key shares (where each signing request was signed by an RA to authorize it), and then collecting and recombining the partial sigs, it turned out to be way too hard to use that way. I don't know if it was ever deployed in a truly geographically distributed configuration, rather than having all the shares (except for backups) kept at one site. (And as a result, I started working on usability of security :-). Shortly after the last CertCo CA, Victor Shoup published a new threshold RSA scheme that made them much simpler to incorporate into deployable systems; building a system that uses real threshold crypto would be pretty easy these days if one wanted to. If nothing else, it's a great example for cryptographers of how small changes in the algebraic formulation of something can have large impact on how easy it is to build into systems. --Diana Smetters - 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?
Peter Gutmann wrote: Thierry Moreau thierry.mor...@connotech.com writes: With the next key generation for DNS root KSK signature key, ICANN may have an opportunity to improve their procedure. What they do will really depend on what their threat model is. I suspect that in this case their single biggest threat was lack of display of sufficient due diligence, thus all the security calisthenics (remember the 1990s Clipper key escrow procedures, which involved things like having keys generated on a laptop in a vault with the laptop optionally being destroyed afterwards, just another type of security theatre to reassure users). Compare that with the former mechanism for backing up the Thawte root key, which was to keep it on a floppy disk in Mark Shuttleworth's sock drawer because no-one would ever look for it there. Another example of this is the transport of an 1894-S dime (worth just under 2 million dollars) across the US, which was achieved by having someone dress in somewhat grubby clothes and fly across the country in cattle class with the slabbed coin in his pocket, because no-one would imagine that some random passenger on a random flight would be carrying a ~$2M coin. So as this becomes more and more routine I suspect the accompanying calisthenics will become less impressive. (What would you do with the DNSSEC root key if you had it? There are many vastly easier attack vectors to exploit than trying to use it, and even if you did go to the effort of employing it, it'd be obvious what was going on as soon as you used it and your fake signed data started appearing, c.f. the recent Realtek and JMicron key issues. So the only real threat from its loss seems to be acute embarassment for the people involved, thus the due-diligence exercise). I fully agree with the general ideas above with one very tiny exception explained in the next paragraph. The DNSSEC root key ceremonies remains nonetheless an opportunity to review the practical implementation details. The exception lies in a section of a paranoia scale where few organizations would position themselves. So let me explain it with an enemy of the USG, e.g. the DNS resolver support unit in a *.mil.cc organization. Once their user base rely on DNSSEC for traffic encryption keys, they become vulnerable to spoofed DNS data responses. I leave it as an exercise to write the protocol details of an hypothetical attack given that Captain Pueblo in unito-223.naval.mil.cc routinely relies on a web site secured by DNSSEC to get instructions about where to sail his war ship on June 23, 2035 (using the unrealistic assumption that Pueblo's validating resolver uses only the official DNS root trust anchor). Regards, Peter. -- - 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
Re: Is this the first ever practically-deployed use of a threshold scheme?
On Aug 1, 2010, at 7:10 AM, Peter Gutmann wrote: Thanks to all the folks who pointed out uses of m-of-n threshold schemes, however all of them have been for the protection of one-off, very high-value keys under highly controlled circumstances by trained personnel, does anyone know of any significant use by J.Random luser? I'm interested in this from a usability point of view. As a corollary, has anyone gone through the process of recovering a key from shares held by different parties at some time after the point at which they were created (e.g. six months later), the equivalent of running a restore from your backups at some point to make sure that you can actually recover your sysem from it? How did it go? It'll be interesting to see the responses, but ... in this particular case, we do actually have plenty of experience from physical applications. Vaults that can be opened only by multiple people each entering one part of the combination have been around for some time. For that matter, that requires mechanisms for having multiple people set their part of the combination. Even requirements for dual signatures on checks beyond a certain size are precedents. One could certainly screw up the design of a recovery system, but one would have to try. There really ought not be that much of difference between recovering from m pieces and recovering from one. Of course, one wonders how well even the simpler mechanisms work in practice. The obvious guess: At installations that actually exercise and test their recovery mechanisms regularly, they work. At installations that set up a recovery mechanism and then forget about it until a lightning strike takes out their KDC 5 years later ... well, I wouldn't place big bets on a successful recovery. This isn't really any different from other business continuity operations: Backup systems that are never exercised, redundant power systems that are simply kept in silent reserve for years ... none of these are likely to work when actually needed. -- Jerry Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com - 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?
Jerry Leichter leich...@lrw.com writes: One could certainly screw up the design of a recovery system, but one would have to try. There really ought not be that much of difference between recovering from m pieces and recovering from one. There's a *huge* difference, see my previous posting on this the last time the topic came up, http://www.mail-archive.com/cryptography@metzdowd.com/msg07671.html: the cognitive load imposed is just so high that most users can't cope with it, particularly since they're already walking on eggshells because they're working on hardware designed to fail closed (i.e. lock everything out) if you as much as look at it funny. The last time I went through this exercise for a high-value key, after quite some time going through the various implications, by unanimous agreement we went with lock an encrypted copy in two different safes (this was for an organisation with a lot of experience with physical security, and their threat assessment was that anyone who could compromise their physical security would do far more interesting things with the capability than stealing a key). 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. Peter. - 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 Aug 2, 2010, at 2:30 AM, Peter Gutmann wrote: Jerry Leichter leich...@lrw.com writes: One could certainly screw up the design of a recovery system, but one would have to try. There really ought not be that much of difference between recovering from m pieces and recovering from one. There's a *huge* difference, see my previous posting on this the last time the topic came up, http://www.mail-archive.com/cryptography@metzdowd.com/msg07671.html: the cognitive load imposed is just so high that most users can't cope with it, particularly since they're already walking on eggshells because they're working on hardware designed to fail closed (i.e. lock everythi ng out) if you as much as look at it funny Well ... we do have a history of producing horrible interfaces. Here's how I would do it: Key segments are stored on USB sticks. There's a spot on the device with m USB slots, two buttons, and red and green LED's. You put your USB keys into the slots and push the first button. If the red LED lights - you don't have enough sticks, or they aren't valid. If the green LED lights, you have a valid key. If the green LED lights, you push the second button (which is otherwise disabled), and the device loads your key. (The device could also create the USB sticks initially by having a save key setting - probably controlled by a key lock. Voting out and replacing a segment requires a bit more, but could be designed along similar lines.) You can use some kind of secure USB stick if you like. The content of a USB stick is standard - there has to be a file with a known name and some simple format, so it's easy to re-create a USB stick from a paper copy of the key. Since specialized hardware is expensive, you can approximate this process with software (assuming you get a competent designer). You can get by with only one USB slot, but given the tiny cost of USB hubs - I can buy a complete 10-port USB hub, power adapter included, shipped free, for less than $16 at mertiline.com, for example (and that's gross overkill) - it's probably worth it to give users a nice physical feel of inserting multiple keys into multiple locks. I just don't see the great cognitive load involved, if the problem is presented properly. -- Jerry - 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 7/31/2010 2:54 PM, Adam Shostack wrote: On Sat, Jul 31, 2010 at 06:44:12PM +1200, 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? | | (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). We had a 3 of 7 for the ZKS master keys back in the day. When we tested, we discovered that no one had written the secret-combining code, and so Ian Goldberg wrote some and posted it to usenix for backup. At RSA Security back in the early 2000s, I devised protection schemes, and wrote product code using 5 of 7 Shamir secret sharing for certain products. Peter Trei - 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?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK. I'm being a bit lazy but... I've read through the ceremony script and all that, but I have a simple question which the script documents didn't really answer: 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? 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? 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. 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. -Jeff - -- Jeffrey I. Schiller Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice j...@mit.edu http://jis.qyv.name -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMVtt98CBzV/QUlSsRAvCRAJ0esya4xAMEXsFOFUF0kcBaue40owCfRsjZ Ep+hF6LLzEcS+BDQYPvNbfg= =qzNb -END PGP SIGNATURE- - 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?
Jerry Leichter leich...@lrw.com writes: Here's how I would do it: Key segments are stored on USB sticks. There's a spot on the device with m USB slots, two buttons, and red and green LED's. You put your USB keys into the slots and push the first button. If the red LED lights - you don't have enough sticks, or they aren't valid. If the green LED lights, you have a valid key. If the green LED lights, you push the second button (which is otherwise disabled), and the device loads your key. That's a good start, but it gets a bit more complicated than that in practice because you've got multiple components, and a basic red light/green light system doesn't really provide enough feedback on what's going on. What you'd need in practice is (at least) some sort of counter to indicate how many shares are still outstanding to recreate the secret (We still need two more shares, I guess we'll have to call Bob in from Bratislava after all). Also the UI for recreating shares if one gets lost gets tricky, depending on how much metadata you can assume if a share is lost (e.g. We've lost share 5 of 7 vs. We've lost one of the seven shares), and suddenly you get a bit beyond what the UI of an HSM is capable of dealing with. With a two-share XOR it's much simpler, two red LEDs that turn green when the share is added, and you're done. One share is denoted 'A' and the other is denoted 'B', that should be enough for the shareholder to remember. If you really wanted to be rigorous about this you could apply the same sort of analysis that was used for weak/stronglinks and unique signal generators to see where your possible failure points lie. I'm not sure if anyone's ever done this [0], or whether it's just build in enough redundancy that we should be OK. Peter. [0] OK, I can imagine scenarios where it's quite probably been done, but anyone involved in the work is unlikely to be allowed to talk about it. - 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?
(In a threshold cryptosystem, the shares would be used in a protocol to perform the desired cryptographic operation [e.g., signing] without ever reconstructing the real secret.) Has real threshold cryptography never been used anywhere? Yes, the root key for the SET consortium was done this way. The technology was developed by Banker's Trust Electronic Commerce, which was spun off into a company called CertCo. They also had a method of re-splitting a key; think of a trade group that votes out one of the members without that entity's consent. The code to do all that was on the HSM cards. Both techniques are patented. CertCo failed and I don't know who ended up with the IP. (As a souvenir from the wind-down, I have a co-branded CertCo/Chrysalis HSM. :) /r$ -- STSM, WebSphere Appliance Architect https://www.ibm.com/developerworks/mydeveloperworks/blogs/soma/ - 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?
Thierry Moreau thierry.mor...@connotech.com writes: With the next key generation for DNS root KSK signature key, ICANN may have an opportunity to improve their procedure. What they do will really depend on what their threat model is. I suspect that in this case their single biggest threat was lack of display of sufficient due diligence, thus all the security calisthenics (remember the 1990s Clipper key escrow procedures, which involved things like having keys generated on a laptop in a vault with the laptop optionally being destroyed afterwards, just another type of security theatre to reassure users). Compare that with the former mechanism for backing up the Thawte root key, which was to keep it on a floppy disk in Mark Shuttleworth's sock drawer because no-one would ever look for it there. Another example of this is the transport of an 1894-S dime (worth just under 2 million dollars) across the US, which was achieved by having someone dress in somewhat grubby clothes and fly across the country in cattle class with the slabbed coin in his pocket, because no-one would imagine that some random passenger on a random flight would be carrying a ~$2M coin. So as this becomes more and more routine I suspect the accompanying calisthenics will become less impressive. (What would you do with the DNSSEC root key if you had it? There are many vastly easier attack vectors to exploit than trying to use it, and even if you did go to the effort of employing it, it'd be obvious what was going on as soon as you used it and your fake signed data started appearing, c.f. the recent Realtek and JMicron key issues. So the only real threat from its loss seems to be acute embarassment for the people involved, thus the due-diligence exercise). Peter. - 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
