Managing Code Signing Digital IDs for Open Source? 103
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?"
Why ask? (Score:5, Funny)
Microsoft Passport? (Score:1)
Somehow the Longhorn/Passport mechanism will handle all your secuirty needs by magic.
Re:Microsoft Passport? (Score:1)
Re:Microsoft Passport? (Score:1)
I might occasionally try to say something positive enough about Microsoft that it gets as many insigtfuls or informative's as it does Trolls, but I"m not holding my breath.
I think the best I can hope for is that I retain my +1 as a logged-in-user with thie Team99 parody at least as long
this should ne intresting (Score:1)
Re:PGP signing? (Score:2)
Re:PGP signing? (Score:2)
Re:PGP signing? (Score:2)
RM (Score:2, Informative)
Debian (Score:2)
I'm not sure how the Release Manager in Debian works, but a lot can probably be learned from Debian here. They (of course) have developers all over the globe, and they use a debian keyring for signing packages, as I understand it.
Since Debian is deliberately open and accountable in all aspects, you should be able to go back in their mailing lists and find the discussions that took place for different options etc.
Just checksum (Score:1, Insightful)
Re: Just checksum (Score:1)
In theory, somebody could cook up a modified file that gives the same hash. But modifying a file and still have multiple hash algorithms produce the same checksums, is very, very, much harder to do -- if not impossible.
Just post those hashes on trusted servers, and any file that matches both (or mor
Re: Just checksum (Score:2)
That's extremely unlikely, even with weak checksums. What you need to worry about is whether a server that will give you a fake binary will also give you a matching fake checksum.
Just post those hashes on trusted servers, and any file that matches both (or more) hashes must be your package.
By trust
Sharing the public key (Score:5, Insightful)
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.
Re:Sharing the public key (Score:5, Interesting)
Suppose it's time to sign a new build: then some parties reconstruct the secret key, and *poof* all of a sudden all the parties knows the secret key, and you're back to a single point (or even multiple points) of (security) failure.
What is needed is a threshold signature scheme (in which the key is never explicitly reconstructed). But I don't know of any free or even cheap implementations (they tend to complicated protocols).
Found it! (Score:3, Informative)
Re:Found it! (Score:3, Informative)
Maybe submit it to Unmaintained Free Software?
http://www.unmaintained-free-software.org/ [unmaintain...ftware.org]
Distributed hardware threshold signature. (Score:3, Informative)
So to sign, requires cooperation of k1 developers, and 1 smart card.
Re:Distributed hardware threshold signature. (Score:1)
Re:Distributed hardware threshold signature. (Score:2)
Basically, you need 1 of the n2 smart cards and k1 of the n1 developers to sign.
Re:Sharing the public key (Score:1)
If you publish the semantics that as long as your release signing key is signed by a "trusted key" and then make sure that individual release managers are somehow authenticated before their keys are signed, you should be okay, assuming your release managers practice good crypto hygeine.
Re:Sharing the public key (Score:2)
When everyone agrees build abc1337 is the release master, a hash should be created by each developer and then signed. That way you can use your gpg web of trust to verify the authenticity of the binary. You might not trust the Release Coordinator, but since three of your good friends were coders and signed it, you can trust the build. Code signing certificates were created my corporate entities like Microsoft to make open source look i
Re:Sharing the public key (Score:2)
That's a rather unfair statement. It was created as a way for you to know exactly who a piece of code came from, that's all. You can then decide whether to trust it or not. The problem arises because people started to assume signed code is safe to run just because it's signed.
Re:K of N and don't forget the time-stamping (Score:1)
Secret sharing schemes are available for code signing using either MS AuthentiCode, signtool, etc. The private key used to sign the code is stored in a hardware security module ensuring that the key is not exportable and used only within the module.
Some major software vendors use developer signatures as code source review and strip multiple user level signatures which contain certain attributes in the DN of the cert identify
Re:Sharing the public key (Score:2)
Best Option? (Score:1)
Re:Best Option? (Score:2)
I know who you can trust. (Score:4, Funny)
They invented code signing after all....
smart cards? (Score:3, Interesting)
Re:smart cards? (Score:1)
Start a "trust tree" (Score:1, Interesting)
Interesting (Score:4, Interesting)
Actually I meant FSF, but EFF is just as good (Score:2)
Share split with a minimum number (Score:4, Insightful)
You'd prefer multiple? (Score:3, Interesting)
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.
Re:You'd prefer multiple? (Score:2)
Split secrets (Score:5, Insightful)
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.
Re:Split secrets (Score:3, Insightful)
I may be misunderstanding you, but generally in digital signing, you don't recover the signing private key, because there is no point to it. Just issue a new one. Key Recovery is only useful for encryption purposes when there is data that is encrypted and will be lost unless you can recover the key. With digital si
Re:Split secrets (Score:2)
Re:Split secrets (Score:1)
Many of the commercial certificate authorities offer code-signing certificates for software management programs like Qualcomm's BREW, Microsoft Smartphone, Sun Java, Sun J2ME, SymbianMicrosoft ActiveX, etc. These are governed by the CA under either their policy or a policy specified by the platform vendor, or the carrier/operator.
If you are looking for tamperproofing and easy verification by end users there is no need to go for an expensive
Good use for AI (Score:3, Funny)
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.
Re:Good use for AI (Score:2)
If it knows what you're talkin about, that's okay, you've just accidently coded the second smartest computer of all time. Name it Deep Thought, and it'll be happy.
If it does not know about plum pudding, and/or shows any kind of anti-human sentiment (e.g has your pr0n collection recently been replaced by a set of skeletons?), please send us your name and address and we will try to help. Do not plug the computer into the internet, and do not let it play with anything which looks li
Why is this presumed to be an Open Source issue? (Score:5, Insightful)
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.
Never thought of this before? (Score:1)
Sourceforge... (Score:2)
Thoroughly off-topic, but... (Score:2, Insightful)
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.
Re:Thoroughly off-topic, but... (Score:1)
Re:Thoroughly off-topic, but... (Score:1)
"Best method" has not necessarily been proven in actual use.
Re:Thoroughly off-topic, but... (Score:2)
You know what they say (Score:4, Funny)
Re:You know what they say (Score:2)
Don't dilute the trust. (Score:2)
Having someone available to take over the duties of signing if the regular signer goes on vacation or leaves is a good idea.
The idea behind signing is that the receiver knows that the signed item can be trusted. Giving everyone a key justs dilutes the trust, so less is better. Keep the number of people with the key to a minimum.
Shamir Secret Share (Score:3, Informative)
To the gatekeeper, go the keys (Score:2)
In case of disaster (project manager disappears), you should escrow the private key using a secret-splitting scheme such that 51% or more of your developers can recover it.
One for each releaser. (Score:1)
For the major releases it would probably be sound to have a single key that the 10 must influential developers had acces to but only used in agrement with each other.
personal reputation (Score:3, Interesting)
Don't make work for yourself (Score:5, Insightful)
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&
Windows Drivers or the like (Score:1)
Re:Don't make work for yourself (Score:1)
Official releases are created and hosted on trusted servers, along with the hashes.
How do these trusted servers remain trusted?
Re:Don't make work for yourself (Score:2)
There's nothing stopping you from going through this process yourself, but it's apparently painful and long-winded.
BouncyCastle have done this, thus making it easy for the rest of us.
Perhaps the poster could ask them w
An alternative approach (Score:2)
Re:Don't make work for yourself (Score:2, Insightful)
I'd have to say you're underthinking this. Nobody has the time to source review every app and update of that app. Many lack the skills, and almosy everyone lacks sufficient attention span to ready and perfectly comprehend all the source code.
A great deal of stuff is done on trust, and
hm (Score:2)
The public needs only to know this one authority certificate, and validate the signature up to this one cert.
Secret Sharing and Verifiable Secret Sharing (Score:5, Informative)
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:
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.
Why? (Score:2)
If so, your problems go a lot deeper than key management.
remote server (Score:1)
Why just one key? (Score:1)
Tim
Why are you doing code signing? (Score:1)
Debian signs binary packages with the public key of the individual maintainer who made the upload. Those keys are then linked in a web of trust. There is also an archive key held by the release managers.
Keep a printout... (Score:2, Informative)
Just use personal keys (Score:3, Interesting)
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.Re:Just use personal keys (Score:2)
Now only one person got the "root certificate". I think that a second person who is thrusted better has thei key as well, in case this singe person gets hit by a bus. Sending the key in a closed enve
One primary, many secondary (Score:2)
Mix up? (Score:1)
It's a social trust problem, not a technical one (Score:3, Insightful)
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.
Trust the PM, back up the key pair, jic. (Score:1)
As noted, you can overthink this one to death. A simple recipe may address your needs:
1. The PM generates the key pair and obtains the certificate. The PM is steward of the key pair.
2. The PM performs all signing operations. They're the PM - trust them.
3. For backup purposes, you need multiple people to have access to the key pair in an emergency, e.g., PM hit by bus. Rent a safety deposit box and give the PM and two or three other senior individuals access authority. Perhaps require two or more signers
What are your signing semantics (Score:1)
Before all your project members start spinning PGP keys, you might what to ask yourself, "what do I hope to achieve by signing releases?" Digital signatures are used to prove two things:
Everything else is implied by policy and semantics . For reasons I'm unclear on, people frequently confuse signed code with trusted code. You can make signed
Advanced security schemes (Score:1)
Does anyone else think PGP only supports outdated techniques?
Two signatures required for amounts over $5000 (Score:2)
However, these private keys would not be usable by themselves: You would need several, but not all, of the private key holders to put their keys together in order to sign something. The algorithm would somehow need to account for the number of private keys and how many of them are needed to enable a working signing operation.
So, for example, your loosely-knit organization that is dispersed all arou
So what? (was Missing the POINT!) (Score:1)
Generally, one person controls the signing key(s), either directly, or via authority over those who do have access to the key.
What's so different about open source projects?
Only that there is not always an organisaiton to blame, sometimes it's an identified individual.
State that liability is accepted (or not) by the signing individual in the code package and documentation, and the problem is then on of recipient beware (I'm sure there is a cavea
Personal keys vs. per organization keys (Score:1)
At Apache Software Foundation (ASF) we use personal GPG keys. Of course that makes it a little tricky for the user, because he must know that the signer belongs to the organization. You should therefore clearly state
If you think about it, there's no point to signing (Score:1)
Not only is the question impossible to understand for normal people, it is also scary and confusing. And IMHO for those who THINK they understand the question, it creates a very false sense of security.
After all, unless your name is Bill Gates or Microsoft, how is the user to know whether Acme Corp from Denver Colorado are good guys or secretly malware developers? By signing the code w
Huh? Why do you care? (Score:2)
For corporations (and maybe the very largest of OSS foundations) there are valid reasons to care about these issues, because they have a name, and generally only 1 name, to protect. I just don't see what the point is for smaller OSS developers.
So what if the next version to come out is signed with a different key owned by a diff