Slashdot Mirror
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?"
Post-it notes all the way baby!
"" How about taking the safety labels off everything, and let the stupidity-problem solve itself? """
It's called the Release Manager.
There are so-called secret-sharing systems, which allow you to distribute a secret (such as a private key) over some number of people such that a specified number of people (the threshold) must work together to recover the secret.
This way, you can avoid a single person being able to sign, while at the same time making sure that no single person is critical for the signing.
Micros~1.
They invented code signing after all....
put the signing certs on pin protected smart cards. Then ship the cards to the people you want to have be able to sign. Ship the pin to unlock the card by a different method.
Lasers Controlled Games!
An organisation such as the EFF or the like, should have such a key escrow service ;)
Any technology distinguishable from magic, is insufficiently advanced.
Share split the key among a number of trusted project leaders, and require over half but not all of them to restore the key. Maybe give the project manager more than one share, but ensure that s/he doesn't have enough shares to make them essential - that way you don't need any escrow, if someone goes AWOL you can recombine the rest of your shares and then split it again without them. That's probably the best way to do things. However, I think having a single person sign the build is probably "good enough" unless it's an extremely sensitive application.
I am trolling
You'd prefer multiple points of failure? :-)
In all seriousness, a single point of failure means you only have to worry about one person's key being comprimised. On the other hand, multiple developers available to sign something means multiple points that could have the key stolen.
A backup is a good idea - escrow of some sort, but having multiple devs sign sounds like a bad idea IMHO.
In high assurance scenarios like commercial CA operations private-keys are never controlled by an individual. Typically an N of M scheme is used to activate crypto-hardware.
There as been some interesting work done demonstrating the generation of partial signatures using partial keys - this probably meeds one of your needs. Each of the trusted core of developers gets part of the private-key and uses that to sign part of the release, all the signature parts are assembled and voila you're done. Key recovery works well here as each key part can be encrypted and backed up elsewhere (USB token somewhere else). This may be way overkill for your needs.
Why not just use an OTS code signing certificate and use the Mozilla or Java or OpenSSL tools to manage signing? If you lose the key you can just get a (free) replacement. This way your key chains up to a well known root that ships with FF, Java, Opera etc. Also if you find your key has been compromised for whatever reason, CRLs or OCSP will be available to prevent use of the compromised key by whomever it is you want to defend against.
I've almost finished programming it with some neat defense technology, to deal with hackers that try to break into it, or child pedos that think it's a seven year old boy and want to play.
Now, I'm going to give it some ability to review the source code for our missile-launching satellites and robotic defense schematics.
BTW you'll find this funny: it's already smart enough to complain about the name I gave it. Although personally, I think SkyNet is a great name.
Certainly the risks are higher, in open source development, of people bailing out of the effort. But pretty much any organization of any size engaged in such projects ("closed" or otherwise) has issues like this.
I've run into problems with departing web admins and SSL cert renewals, domain management absent the original admin/tech contacts, or just simple stuff like having to crack ZIP files because the project manager has gone on to greener pastures. So far I have yet to beat the paper backup in the company management's private safe, with the In Case Of Death, Open Me label on it. For multi-developer projects, there's usually a central figure - sort of an Alpha Dog - no matter how peer-ish the project is supposed to be.
Don't disappoint your bird dog. Go to the range.
...isn't it about time we shelved that idiotic phrase "best practices"? Can't you just ask for the best way, or the best method? People are using "best practices" for everything from EMail management to installing a new kitchen sink. It's hokey and pretentious, and I'll be really glad if I never see it again.
Okay, I feel better now. Thank you.
P.S. My karma is right on the edge, so if you mod me down I'll probably lose all my bonuses and everything.
It's the land of the brave, and the home of the free
Where the less you know, the better off you'll be.
Three people can keep a secret, if two of them are dead.
Why not use Shamir secret sharing 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).
Why doesn't the package builder sign the package with his personal key? This has the additional advantage that you can trace problems to individuals and/or broken keys. The core group of developers should cross-sign all of their public keys; they can then sign the keys of the people that are allowed to make "official" distributions. From then on it is just a matter of key management: distribute the "trusted" public keys and revoke keys when people leave the project.
extern warranty;
main()
{
(void)warranty;
}
I'd have to say that you're over-thinking this. I doubt you need digital signatures at all.
First, should there be any questions at all, well--Use The Source, Luke! You've got it, so examine it and compile it yourself. That's one of the big selling points of open source, no?
For binary releases, just do it the OpenBSD way. Official releases are created and hosted on trusted servers, along with the hashes. A bunch of mirror sites copy the releases and the hashes. (And, there're these nifty CDs that come pre-packaged with the release and the hashes.)
Anybody who has any questions can verify the hashes on their own copies in any number of ways. You could get the hash off the trusted site, several of the mirrors, etc. You could email somebody you trust, asking them to confirm them. You could even use a telephone or meet in person.
Belive me, if there's any hanky-panky going on, it'll show up real quick. All sorts of people will raise a ruckus.
So, the end result is that you get secure code that everybody trusts and you don't have to muck around with digital signatures, secret sharing, and all that.
Don't get me worng--all those things have their places. Distributing free software just ain't one of them.
Cheers,
b&
All but God can prove this sentence true.
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:
- 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.
- 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 (he has some recent work too). Tal Rabin has done some good work, as has Markus Stadler. Recent work by Stanislaw Jarecki has caught my eye.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
CODEX 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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No need for shared secrets, no need for a "master" key of any kind.
Anyone in the world. Their reputation is what's on the line, not the project's reputation.As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
So to sign, requires cooperation of k1 developers, and 1 smart card.
Code signing is a mechanism for proving "who" is endorsing that code as something you can trust. Your problem is defining "who" and that's not really a technical problem.
If somebody forks you, you shouldn't sign their code. Not because it's bad, but because you can't vouch for it. THEY should sign their code.
Letting somebody else have the key to sign code is endorsing that your good name should go on ANYTHING that they decide to put out. Certainly, a project above a certain size with a community of maintainers should distribute this responsibility.
If I had a small project, I would make sure the key was left to somebody in my will (and I'd probably leave it with some close friends) - hopefully it'd get to somebody who'd be nominated to takeover the probject - because if I die presumeably I'm less worried about someone pretending to be me. This is a form of key escrow, but it's not a very arbitrary one.
For a larger project, it must be almost the highest level of trust, and it doubtless has to be learned. Those levels of trust would go something like:
bank accounts & corp documents
CVS log modification (auditability erasing)
code signing
CVS commit (but at least you can track it after the fact)
fast-track patch submission
anyone (normal patch submission)
These levels are a pyramid; fewer people should be trusted at each level - and fewer people are needed.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot