Managing Code Signing Digital IDs for Open Source?

Saqib Ali asks: "What are the best practices for managing Code Signing Digital IDs for Open Source projects, where the developers are dispersed throughout the globe? For our project there is NO central office, where we can secure the private key for the Code Signing Digital ID. Who should have the possession of the private key? Multiple people, or just the project manager? What Key Escrow (recovery) techniques can be used, in case the private key holder is not available? Who should be allowed to digitally sign the build? Currently one person handles the signing responsibility, but I think that is surely a single point of failure. Any thoughts/ideas?"

RM

[Anonymous Coward]

It's called the Release Manager.

Shamir Secret Share

[cheesedog]

Why not use Shamir secret sharing [harvard.edu] to hold onto the private key? You can choose N people to hold pieces of the private key and choose K = N such that [any] K individuals can reconstruct the secret (but not any less than K).

Secret Sharing and Verifiable Secret Sharing

[HidingMyName]

Key escrow/recovery schemes where there is a sort of "backdoor" built in to allow for key recovery via trusted third parties fell out of favor in the late 1990's, as can be seen at: in this paper [cdt.org].

My research is currently looking into approaches to related areas (as a user, not necessarily as a cryptographer), you may wish to look into "secret sharing", where given a secret (e.g. a private key), a set of participants, and what the literature calls an access structure which is a collection of subsets of participants that you wish to be able to easily recover the secret (called a qualified subset), establishes a two stage protocol:

1. Share - a trusted entity called the dealer takes the secret and encodes it into a set of shares, securely awarding each participant a unique share.
2. Reconstruct - some subset of the participants presents their shares, if the shares are valid and the subset is a qualified subset, the secret is recovered and securely distributed to that subset of participants, otherwise the secret should not be revealed.

Now, there are (t,n) theshold schemes where any subset of t or more participants where t is between 2 and n are qualified to recover the key otherwise they are not.

There are proactive variants that periodically recut the shares to prevent accumulated leaking of shares over time from forming a qualified subset.

Also there are verified secret sharing schemes which support a verify operation, where a share can be checked for correctness without trying to reconstruct the secret (so that bad dealers can be caught and that at reconstruct time invalid shares can be found prior to reconstruction).

Finally there are "cheating immune" schemes. A cheater is a participant who gives a bogus share at reconstruct time. If they know something about the reconstruction step and can assume the other participants are giving valid shares, some schemes may allow the cheaters to learn something about the secret. In cheating immune schemes, this is prevented.

Finally there are schemes that use verifiable threshold schemes and verifiable secret sharing for digital signatures.

If you are interested in some references, Doug Stinson's bibliography on Secret Sharing [uwaterloo.ca] (he has some recent work too). Tal Rabin has done some good work, as has Markus Stadler. Recent work by Stanislaw Jarecki [uci.edu] has caught my eye.

Keep a printout...

[davidwr]

In addition to everything else that's been suggestion, keep a digital and printed copy of important, long-lived items like keys someplace safe, like a safe deposit box, preferably one with multiple non-bank-controlled keys, two of which need to be used to open the box.

Found it!

[jd]

CODEX [umd.edu] is a package that seems to provide what you want. It took some digging, though. I'd add it to Freshmeat, but this looks too much like a one-off project, rather than something being sustained.

Distributed hardware threshold signature.

[CustomDesigned]

Share secret between m1 developers and m2 smart cards (like iButton/Java Ring). The signing key is shared between the smart cards, and one developer key. k1 of the m1 developers can reconstruct the developer key. The signing key is reconstructed with k = 2 from the developer key and any smart card key. It exists momentarily only inside the secure smart card memory, and signing takes place inside the smart card.

So to sign, requires cooperation of k1 developers, and 1 smart card.

Re:Found it!

[stoborrobots]

I'd add it to Freshmeat, but this looks too much like a one-off project, rather than something being sustained.

Maybe submit it to Unmaintained Free Software?
http://www.unmaintained-free-software.org/ [unmaintain...ftware.org]