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