Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Managing Code Signing Digital IDs for Open Source?

Cliff posted more than 9 years ago | from the project-security dept.

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

cancel ×

103 comments

Sorry! There are no comments related to the filter you selected.

Why ask? (4, Funny)

hyfe (641811) | more than 9 years ago | (#12424663)

Post-it notes all the way baby!

Re:Why ask? (-1, Redundant)

Anonymous Coward | more than 9 years ago | (#12424759)

Feather and ink?

Keys? (0)

Anonymous Coward | more than 9 years ago | (#12424998)

We dont need no stinking keys!

Microsoft Passport? (1)

team99parody (880782) | more than 9 years ago | (#12425091)

Wasn't that supposed to be the end-all of trust & authentication systems?

Somehow the Longhorn/Passport mechanism will handle all your secuirty needs by magic.

Re:Microsoft Passport? (1)

hedge_death_shootout (681628) | more than 9 years ago | (#12425532)

Somebody please gilt frame parent as classic example of karma whoring.

this should ne intresting (1)

Amouth (879122) | more than 9 years ago | (#12424664)

not quite sure. .. never though about it.. but most groups i would think would have atleast one backup person for such a job

PGP signing? (0)

Ranger (1783) | more than 9 years ago | (#12424695)

I think some form of PGP signing would be a good idea. There is an open source PGP. You could probably use a similar process for signing that you do for signing other peoples keys. Level of trust, ect. See PGP [google.com] results at Google and take your pick.

Re:PGP signing? (1)

Malc (1751) | more than 9 years ago | (#12424732)

And per the story... who is responsible for looking after the private key? What do you do if that private key is lost? It's basically the same deal, although you're not involving a trusted CA and so some of the other issues go away (at the expense of it being less trustworthy).

Re:PGP signing? (1)

jrumney (197329) | more than 9 years ago | (#12424811)

PGP keys are free, unlike code-signing certificates from trusted CAs, so you can afford for each developer to have their own key, and if they are lost or fall into the wrong hands, then only that developer's key needs to be revoked and reissued, not the whole project's.

Re:PGP signing? (1)

Malc (1751) | more than 9 years ago | (#12424866)

How do you prove that something was signed using their key? You have to get their public key to check, so how do you manage that? The point of the CA certificates is that you're supposed to be able to verify that the it was signed by the person who says they signed it. Thus both systems have a management problem, and both systems fall down if the security of the certificate or public/private keys is compromised. Removing the CA just makes it easier and cheaper to sign something, but doesn't make it any easier to prove who signed it, especially for very large projects.

Re:PGP signing? (0)

Anonymous Coward | more than 9 years ago | (#12425034)

  • wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww wwwW

RM (2, Informative)

Anonymous Coward | more than 9 years ago | (#12424714)

It's called the Release Manager.

Debian (1)

CarpetShark (865376) | more than 9 years ago | (#12425563)

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 (1, Insightful)

Anonymous Coward | more than 9 years ago | (#12424718)

and be done.

Re: Just checksum (1)

Alwin Henseler (640539) | more than 9 years ago | (#12425871)

And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.

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 more) hashes must be your package.

Re: Just checksum (1)

Craig Davison (37723) | more than 9 years ago | (#12426182)

And since some older or less secure hashing algorithms might be fooled (modified file, same checksum), use multiple checksum methods. For example, provide both an MD5 and SHA-1 hash for each release package.

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 trusted you must mean SSL secured, like an https server. But then you have to store the private key somewhere (on the webserver, obviously, but someone needs to be responsible for it), and someone would have to contact a CA to get the keypair in the first place.

If it's open source... (1)

Marthisdil (606679) | more than 9 years ago | (#12424720)

Why bother having any code signing....just accept pgp signed code snippets for inclusion in the main repository of your application's codebase, and let the rest of the world submit and go through a verification process. It's not like you're sending bank secrets out :P

Sharing the public key (5, Insightful)

xmath (90486) | more than 9 years ago | (#12424721)

There are so-called secret-sharing [wikipedia.org] 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.

Re:Sharing the public key (4, Interesting)

cpeikert (9457) | more than 9 years ago | (#12424884)

Secret sharing is a good start, but it doesn't get you all the way there.

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! (2, Informative)

jd (1658) | more than 9 years ago | (#12425735)

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.

Re:Found it! (2, Informative)

stoborrobots (577882) | more than 9 years ago | (#12426652)

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]

Distributed hardware threshold signature. (2, Informative)

CustomDesigned (250089) | more than 9 years ago | (#12426178)

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:Distributed hardware threshold signature. (1)

ccherlin (190007) | more than 9 years ago | (#12430034)

And who has physical possession of the smart card? Back to square zero.

Re:Distributed hardware threshold signature. (1)

CustomDesigned (250089) | more than 9 years ago | (#12433060)

The description was admittedly brief, but read it again. There are multiple smart cards, any one of which can sign something. You could have one for each developer. Or one for each key developer.

Basically, you need 1 of the n2 smart cards and k1 of the n1 developers to sign.

Re:Sharing the public key (1)

mhamrick (513789) | more than 9 years ago | (#12425648)

Secret Sharing is appropriate for when you need to recover a secret or private key. It's not entirely clear that you need to always have recoverability of a key used to sign a release.

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 (1)

jrockway (229604) | more than 9 years ago | (#12426863)

This is a good idea, but I think it would be even simpler to do this:

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 insecure. In reality, anyone can get a code signing certificate; even malware developers. Using the existing web of trust is the way to go (and 100% Free!).

Re:Sharing the public key (1)

Darren Winsper (136155) | more than 9 years ago | (#12431126)

"Code signing certificates were created my corporate entities like Microsoft to make open source look insecure."
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 (1)

datapt (447252) | more than 9 years ago | (#12428762)

-Disclaimer- nCipher, my employer, offers these products so I am a bit biased ;)

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 identifying the developer as either security code review or senior enough developer to assert that code is secure and ready for release.

And once you do have an organizational signature on your code you need to time-stamp the code to validate the cert used for signing the code was valid at the time of the signature. Time-stamping is becoming more important as OS's and other hardening techniques are used to ensure that the code is valid and from a valid source. Ahh phishing

Re:Sharing the public key (1)

stonebeat.org (562495) | more than 9 years ago | (#12432183)

I am aware of the m of n concept. What i was looking for was some examples of pratical solution (commercial or opensource) that would work for our needs. we can not afford the verisign's key escrow service.

Best Option? (1)

0kComputer (872064) | more than 9 years ago | (#12424725)

Somtimes a single point of failure is the best option. Keep it simple (KISS). Just my 2 cents though.

Re:Best Option? (1)

Zeebs (577100) | more than 9 years ago | (#12424810)

I agree KISS, but single point of failure IS the problem in this case. So the problem as the solution doesn't make much sence.

I know who you can trust. (4, Funny)

Anonymous Coward | more than 9 years ago | (#12424745)

Micros~1.

They invented code signing after all....

smart cards? (2, Interesting)

John Harrison (223649) | more than 9 years ago | (#12424747)

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.

Re:smart cards? (1)

hedge_death_shootout (681628) | more than 9 years ago | (#12425561)

And then when they've done the build, shoot them in the back of the head. Clean, efficient, no loose ends.

Start a "trust tree" (1, Interesting)

Anonymous Coward | more than 9 years ago | (#12424750)

The signer of the build can be the "root" and just grow this tree to include all contributors.

Re:Start a "trust tree" (0)

Anonymous Coward | more than 9 years ago | (#12430851)

This is almost a good idea except:
  • They won't want to use a self-signed certificate because nobody else will recognise it;
  • So they will need to buy a certificate from a huckster like Verisign;
  • But they won't want to spend thousands on a certificate that can be used to sign new certificates;
  • So they will spend a few hundred (at most) on a code-signing certificate;
  • And won't be able to create a tree.

Interesting (3, Interesting)

Daath (225404) | more than 9 years ago | (#12424764)

An organisation such as the EFF or the like, should have such a key escrow service ;)

Actually I meant FSF, but EFF is just as good (1)

Daath (225404) | more than 9 years ago | (#12425041)

Actually I meant FSF, but EFF is just as good ;)

Re:Interesting (0)

Anonymous Coward | more than 9 years ago | (#12425179)

An organisation such as the EFF or the like, should have such a key escrow service ;)

Indeed, especially since you can have expiration dates for your X.509 certificates and the certificates can be revoked: one can require a valid CRL (Certificate Revocation List). One can do also more advanced stuff, like requiring one to have an at-most-one-hour-old message signed by the CA (Certification Authority) that just contains information whether one has had some critical certificate revocations.

Share split with a minimum number (3, Insightful)

m50d (797211) | more than 9 years ago | (#12424769)

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.

Re:Share split with a minimum number (0)

Anonymous Coward | more than 9 years ago | (#12424996)

So, kind of like Voltron?

You'd prefer multiple? (2, Interesting)

Arakonfap (454732) | more than 9 years ago | (#12424797)

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.

Re:You'd prefer multiple? (1)

stonebeat.org (562495) | more than 9 years ago | (#12432128)

for a OpenSource project relying on one person to be available everytime a new build needs to be rolled-out is not feasible. Even though the project member trust this person with the private key, we can not expect him to be around when we need the executable signed.

Split secrets (5, Insightful)

lewis2 (212695) | more than 9 years ago | (#12424807)

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.

Re:Split secrets (2, Insightful)

Conare (442798) | more than 9 years ago | (#12425567)

Good post! One nit pick - it's usually called M of N (just in case someone wants to google it). Also hardware scheme won't work for them here, due to the distribted nature of the organization.

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 signing, losing the private key (or compromising it) just means you can't use it to sign anymore. You can still validate signatures created with the compromised or lost private key using the public portion of it, which is usually included in the signed object itself. If you have an associated trusted time stamp that is, and the signature predates the compromise event.

I think the OTS code signing certificate is a good idea, and you could entrust the use of it (private key password) to a small group. if you do this, I would highly recommend that if someone that is trusted with the signing duties, or holds part of your multi-part key as detailed above, leaves your organization, that you revoke that certificate (or whatever PGP uses) and issue a new one. I would also recommend trusted timestamping if you are concerned about continuity of validations following a compromise.

Re:Split secrets (1)

stonebeat.org (562495) | more than 9 years ago | (#12432151)

What is an OTS code signing certificate?? BTW we are signing executable and not active X / applets.

Re:Split secrets (1)

lewis2 (212695) | more than 9 years ago | (#12432411)

OTS: off the shelf, meaning a typical one you'd find in a 'store."

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 certificate service, buy something cheap that comes with revocation services. Revocation services is critical if you are going to be sharing keys or having folks rotate in and out of authority (joining and leaving the release or development efforts) or if you are not confident that the place you store your keys could be compromised.

You should be able to get what you need for about 20 USD/year.

Good use for AI (2, Funny)

null etc. (524767) | more than 9 years ago | (#12424826)

Well, you should do what I'm doing. I'm in the same situation, and I've decided to program an Artificial Intelligence (AI) bot running on AIM (haha, get it?) to manage our keys.

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 (1)

ggvaidya (747058) | more than 9 years ago | (#12425593)

Ask it about plum pudding.

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 like liquid metal. you can threaten it with the name "John Connor" if it won't behave.

oh, and do not try to unplug it yourself IT WILL KILL YOU OUTRIGHT. oh, and if you live in california, you might also consider (crazy as it sounds) writing your governor. he'll know what to do.

sheesh, and they say television is not educational ...

Why is this presumed to be an Open Source issue? (4, Insightful)

ScentCone (795499) | more than 9 years ago | (#12424839)

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.

Never thought of this before? (0)

wfberg (24378) | more than 9 years ago | (#12424842)

What are the best practices for managing Websites 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 password for the downloads Website? Who should have the possession of the password? Multiple people, or just the project manager? What Password Escrow (recovery) techniques can be used, in case the password holder is not available? Who should be allowed to upload the build? Currently one person handles the uploads, but I think that is surely a single point of failure. Any thoughts/ideas?

Sourceforge... (1)

Spy der Mann (805235) | more than 9 years ago | (#12425043)

has an option where someone can take over a project if the owner doesn't appear for N months. Why not think of a similar scheme?

In Internet Explorer (0)

Anonymous Coward | more than 9 years ago | (#12424849)

In Internet Explorer it already does all this automatically.

Thoroughly off-topic, but... (2, Insightful)

BaudKarma (868193) | more than 9 years ago | (#12424865)

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

From the moderator... (0)

Anonymous Coward | more than 9 years ago | (#12424980)

Thoroughly off-topic, but 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.


I am sorry but SlashDot procedures and best practices require this posting to be modded down.

Bub-bye.

Re:Thoroughly off-topic, but... (1)

hedge_death_shootout (681628) | more than 9 years ago | (#12425614)

It may be pretentious, but it is a key requirement for deployment of solutions in the enterprise.

Re:Thoroughly off-topic, but... (1)

pommiekiwifruit (570416) | more than 9 years ago | (#12429929)

"Best practices" means someone is actually doing it now.

"Best method" has not necessarily been proven in actual use.

Re:Thoroughly off-topic, but... (1)

Mr. Shiny And New (525071) | more than 9 years ago | (#12430431)

In some industries "best practices" not only means someone is doing it now, but if you're not doing it you're negligent and liable to damages should any harm arise from your inferior practices. So I agree, in the computer industry we should refrain from using the term unless it truly is a "best practice". There are so many cases where there are multiple ways of accomplishing something and nobody can prove that one way is always better than an other, so in this case are there two different "best practices?" It's too grey. Call it "good practices" and nobody can complain. :)

You know what they say (3, Funny)

pHatidic (163975) | more than 9 years ago | (#12424869)

Three people can keep a secret, if two of them are dead.

Re:You know what they say (1)

caluml (551744) | more than 9 years ago | (#12425373)

Yo ho ho, and a bottle of rum!

Re:You know what they say (0)

Anonymous Coward | more than 9 years ago | (#12425416)

Thanks! That solved the problem nicely.

Now... to my next question: with these police guys that are hunting me down, what is the best practice open source way to, like, um, get rid of them? And no, I don't have enough ammo left right now, to use the previous method (plus there's also the issue of kevlar vests that would make this sub-optimal solution in any case).

Thanks in advance, and please post your solutions ASAP!

why? (0)

Anonymous Coward | more than 9 years ago | (#12424937)

Perhaps I'm missing something fundamental here, but why does more than one person need a copy of a given private key? As long as you have the public key, you can always verify the signature even if the private key is lost. If the previous owner of the private key left, wouldn't you want to generate a new private key anyway? Isn't it customary to assign private keys to individual people rather than groups or organizations?

Don't dilute the trust. (1)

metoc (224422) | more than 9 years ago | (#12424992)

Having a backup in case you loose the private key is a good idea.

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.

Re:Don't dilute the trust. (0)

Anonymous Coward | more than 9 years ago | (#12425937)

If you loose your private key, you don't need to worry about backups -- somebody somewhere will post it on their blog, and it's time to get yourself a new key. It is when you lose your key that you will find backups helpful.

Shamir Secret Share (2, Informative)

cheesedog (603990) | more than 9 years ago | (#12425031)

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).

To the gatekeeper, go the keys (1)

Xeger (20906) | more than 9 years ago | (#12425040)

Your project manager, or build engineer, or whoever is responsible for ensuring that a new build is "legitimate," should have sole possession of the private key used to sign the finished project.

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. (1)

coopseruantalon (835573) | more than 9 years ago | (#12425073)

Every developer should have his own key and release with it. Then he alone bears the responsibility and there is no trouble deciding who did what and all.

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 (2, Interesting)

MathFox (686808) | more than 9 years ago | (#12425114)

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.

Don't make work for yourself (4, Insightful)

TrumpetPower! (190615) | more than 9 years ago | (#12425150)

What are the best practices for managing Code Signing Digital IDs for Open Source projects

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 (1)

elo_sf (838722) | more than 9 years ago | (#12425909)

Just one thought, although presented as [source] code signing, perhaps this may have applicability in a system like Windows where code signing is used to allow the "object code" to run--or run without extra hassle.

Re:Don't make work for yourself (1)

tepples (727027) | more than 9 years ago | (#12426206)

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 (1)

Joff_NZ (309034) | more than 9 years ago | (#12426208)

Some opensource projects require that they be signed - one that comes to mind is the BouncyCastle Crypto API for Java [bouncycastle.org] - its got a BSD-style licence, but in order to use it in a JVM without hassle, then the .jar has to be signed with a key that has gone through some sort of process with Sun.

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 what they do?

An alternative approach (1)

jd (1658) | more than 9 years ago | (#12426247)

If the project manager for each project were to digitally sign off on their part if the project, and each archivist signed-off on their archives, etc, then each user could filter by who they personally trusted, you wouldn't need a "master" cert, nothing would need regenerating when someone left/joined, and there's be enough of an electronic paper trail to identify exactly where any problems lay.

Re:Don't make work for yourself (2, Insightful)

cs (15509) | more than 9 years ago | (#12427791)

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.

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 digital signatures at least tell the user that they are in fact placing their trust in who they think they're placing their trust. If the keys for signature are improperly managed then that confidence (that the people you trust are the authors) may not be maintained.

So if you're signing stuff, this is an important issue. Signing stuff lets users adopt a higher level trust method than "read the source". Overkill example: how recently have you read the entire Linux source code and verified it for correctness? (You must read it all, including the drivers, because everything runs with full privileges, and so a hack may be inserted in any code sequence that can run.)

Even small libraries are infeasible to personally verify if you're not intimate with the code. Therefore users must trust the authors for most things, and signatures are essential to being able to do so.

hm (1)

savuporo (658486) | more than 9 years ago | (#12425188)

Why not have one authority certificate for issuing further signing certificates to each release manager ?
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 (5, Informative)

HidingMyName (669183) | more than 9 years ago | (#12425309)

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.

Why? (1)

overshoot (39700) | more than 9 years ago | (#12425363)

Are we talking about "Code signing" in the sense of "here is a binary that some third party can trust you to use" sense? The Fritz Hollings/MPAA/Microsoft sense where any other compile of the same source code is useless?

If so, your problems go a lot deeper than key management.

remote server (1)

net_phreak (880947) | more than 9 years ago | (#12425396)

by using a single remote server whose key is distributed through a basic ssl connection with which you determine a new key between the two computers which are communicating. Distribute an algorithm which updates the remote server's key at a constant time period. This is how ATMs communicate with central computer servers.

I don't know the answer but .. (0)

Anonymous Coward | more than 9 years ago | (#12425462)

if somebody comes up with one, please, for the love of all things sacred, post it to gentoo-security.

Why just one key? (1)

Timothy Brownawell (627747) | more than 9 years ago | (#12425479)

Why not let several people sign it, with different keys? Then announce that it's only valid if signed by some number of that set of keys.

Tim

Why are you doing code signing? (1)

pjc50 (161200) | more than 9 years ago | (#12425635)

What security goal are you trying to achieve? What is an "official" package anyway? What happens is somebody wants to fork the code?

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... (2, Informative)

davidwr (791652) | more than 9 years ago | (#12425704)

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.

Just use personal keys (2, Interesting)

Sloppy (14984) | more than 9 years ago | (#12425961)

Why can't people just sign with their personal keys? And if another developer approves the same build, then it gets a second signature, and so on. The more signatures it has by people you trust, the more you trust it.

No need for shared secrets, no need for a "master" key of any kind.

Who should be allowed to digitally sign the build?
Anyone in the world. Their reputation is what's on the line, not the project's reputation.

paranoia and FUD (0)

Anonymous Coward | more than 9 years ago | (#12426037)

What we really need is to be less paranoid and chill out otherwise we are facing shorter lifespans because of anxiety and heart attacks. And this is not just a risk but guaranteed.

Key chains for better security (0)

Anonymous Coward | more than 9 years ago | (#12426161)

Look at the way the author of PuTTY uses multiple keys [greenend.org.uk] for signing.

One primary, many secondary (1)

Rupan (723469) | more than 9 years ago | (#12426300)

Does anyone remember the golden days of PGP? There were key signing events where a "trust" network was established. Could this not be applied to code signing? i.e. there is a single master key that is controlled by the lead developer that is used only to sign individual developer keys. The lead developer would have his own key as well -- like I said, the master key is *only* for signing. Then some sort of revision control system could verify the trust relationship of the developer's key versus the master key and allocate permission based on that.

This would also allow key revocation. I see this as a perfect solution; can anyone comment?

Mix up? (1)

Hydrogen_NL (699949) | more than 9 years ago | (#12426622)

Key escrow does not apply when it comes to signing, it only applies to encryption. You don't need a backup of signing keys, you just get new keys once the old keys are no longer available (check out the concepts behind digital signatures). You can have as many signing keys as you have developers, e.g.: - Code Signing 001 (for John) - Code Signing 002 (for Aziz) - Code Signing 003 (for Tsjang) - etc. If you are worried about theft and sabotage, like unauthorized people signing on your behalf, get decent key protection (a token around your neck at all time will do ;-) or just revoke any key that is lost or stolen, but beware, in that case you would have to make sure that the underlying security software used by end users to validate the code signature supports revocation. That's basically it.

It's a social trust problem, not a technical one (2, Insightful)

arete (170676) | more than 9 years ago | (#12426715)

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.

Trust the PM, back up the key pair, jic. (1)

myvirtualid (851756) | more than 9 years ago | (#12427026)

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 to access the box.

4. With one or more of those folks as witnesses, have the PM save the key pair like so:

4A. Export the key pair to your favourite protected format, e.g., PKCS#12 with 10000 rounds of hashing.

4B. Writes the protected key pair to a medium with decent shelf life, and stick that and the password in an envelope.

4C. Seal the envelope, sign and date the seal. (Helps detect tampering.)

5. Two of the individuals take the envelope and stick it in the safety deposit box.

In the event of an emergency, any two of the senior folks can get the key pair and give it to the new PM.

In the event of suspected misuse of the key pair by someone other than the PM, then the bank's safety deposit records at least let you know who cheated.

What are your signing semantics (1)

mhamrick (513789) | more than 9 years ago | (#12427076)

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:

  1. The key holder was in posession of the private key at the time the release was signed, and
  2. The key holder was in posession of a hash of the thing that got signed.

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 code trusted by promising to do things like check the code for correctness, verify that all the submitters to the project were upstanding people, and swear on a stack of holy books that you implement good security practices to protect the integrity of your source base. Establishing trust is a tricky proposal.

Applying crypto alone to solve trust issues is, in general, a bad idea. As fun as it is to spin PGP keys, read off key fingerprints over the phone, and so forth, it a hollow exercise unless you publish the meaning of the signature. For instance, many OS vendors and languages have the concept of signed code. Code signing has been hailed by some as the panacea for all our trust issues. Well guess what. Bad guys can sign code just as easily as good guys; the only thing that keeps your copy of Internet Explorer from being hijacked by roving gangs of underaged hax3n is the default settings for whose signing keys are considered trusted. And guess what? Thats something that's established by policy. And sometimes even this is not enough. In order to be enrolled for a code signing key, you usually have to jump through some adminsitrative hurtle like showing up at a notary public and proving you're not Kevin Mitnick and then faxing a notarized statement to an underpaid Verisign employee. Some manner of voodoo then occurs that results in a certification authority making a public statement about how good a guy you are. If you're a bad guy and you can convince a certifying authority that you're really a good guy, bingo! you now have trusted code running amuck in your cozy WinXP install.

But we all knew this was a problem and use Linux or FreeBSD or OpenBSD.

Okay... before I fall too far down the rabbit hole, let me try to make some constructive statements.

There are a couple of places where crypto is important to your project. The first is to authenticate submitters when they check in files to the CVS tree. SourceForge uses SSH to encrypt username / password pairs when it's time to log into their CVS repository. This is useful for keeping prying eyes from sniffing your submitter's passwords. I believe, but am not certain (and I hope someone can tell me I'm wrong here... I haven't checked anything INTO a SF project in a couple of years.) I believe that SF doesn not REQUIRE you to verify your identity or your machine's identity via crypto. You MAY do it, but I don't know if it's possible to require it.

This can be a problem if someone tries a man-in-the middle attack on you. Assuming your project is of a high level of sensitivity, someone might subvert your connection with the internet and pretend to be your CVS repository (e.g. - sourceforge.) If you're not using crypto to authenticate your repository's identity, the man-in-the-middle can pretend to be them to you and pretend to be you to them. Assuming the stars are aligned, they can watch as you key in your password and voila! they can pretend to be you.

But all is not lost. SF publishes their host keys. Through arcane modifications to files in your ~/.ssh or ~/.ssh2 directories, you can tell your client to barf if it detects MITM shenanigans. Assuming you do this BEFORE your submitters ever log in, you should have a modicum of security. If you do this AFTER your submitters login and select their passphrase, well...

You also have to hope that your submitters are trustworthy. Yeah, sure they're smart coders, but maybe they've just checked in some code that contains a hidden buffer overflow they intend to use sometime in the future? When Bill Gates and Steve "developers!" Ballmer talk trash about how open source is untrustworthy... this is where they're coming from. Their contention is that dutiful hard-working commercial "devs" in Redmond are all kinds more trustworthy than the unwashed masses who have not been subjected to an afternoon of logic puzzles and a free lunch. It's a great idea, it's just wrong. What is right is that if one of Chairman Bill's developers goes rogue, the FBI just has to put a perimeter around Redmond to track 'em down. The idea is that the threat of easy capture and the forensic value of checkin logs from America's favorite software house will keep the kids in line. Personally, I don't buy this argument, but it sorta flies with the business crowd. On the other hand, I don't think there are a lot of really smart guys in engineering at MS. There are also several flunkies. But I think the clever, darth sidious types are all in Marketing and Biz Dev.

Okay... so I've digressed again and this post is already about five times longer than I had hoped. Thank you for reading this far, let me try to add more value by dropping the microsoft jokes and get back to the question at hand.

Let's say that you're comfortable with the security precautions in place surrounding your code repository. You're convinced that sourceforge's web server that lists their public keys hasn't been compromized. Great. Let's talk about getting the code out to people that matter, the customer.

I think what you were really asking here is, "one or more of us has some code we built and tested on our machine, we would like to digitally sign it so everyone world-wide know's it's really the code that came from us." Okay, first things first, how do you manage multiple signers.

Someone recently mentioned the use of secret splitting. Wrong answer. You use this if you have a single private key you want everyone to use. My reccomendation is to have your benevolent dictator, your first amongst equals spin (generate) a master sort of public key. By all means use PGP or GPG. They're great bits of code. Then have all your releasers generate personal signing keys. I'm using the term "releaser" to mean anyone with authority to push out an official release. Your project might limit this to one person, or it might be multiple people. For your project it could be that all your submitters could be releasers, or maybe it's not. That's your decision. The key here is everyone who is trusted enough to "officially" release a build generates their own key pair.

They email you their public keys, along with a note kindly asking for you to sign their public key. Before you become a signing machine, think about whether or not you really trust these people. Okay... you're the trusting sort, good. You still have faith in humanity. You'll need it when you read about MSDRM and NGSCB over the next couple of years. D'oh! I said I wasn't going to make any Microsoft jokes! Sorry.

So where was I? Oh yeah... you have the public keys of the releasers. Now sign their public keys and put them on your web site somewhere that consumers of the releases can get at. And when I say "sign them," I mean sign them with the master key. Also... I wasn't explicit about this, generate a second, non-master key for your benevolent dictator if s/he is going to be producing releases.

Now that you're finished using the master key, copy it to a floppy and put the floppy in a tamper-evedent bag. Print out the BASE64 encoding of the private key and put it in a separate tamper-evedent bag. Put both bags deep in a cave guarded by the mythical three-nostralled "Head of Dobbs." Or just put it in a safe deposit box. Or put it somewhere safe in your house or your office or someplace you think it would be difficult for BAATHist operatives to get at. Just make sure you don't post it on the 'Net and don't publish the private key in a newspaper.

The key concept here is that the "master key" is used to "enroll" releasers. This is something you don't do very often, so you can safely store the master key offline until you need it again. If you're like me, however, you're likely to lose anything you don't use frequently, so we'll talk about this later.

At this point all the releasers have "release signing keys" that have been signed by the "master release key" and the public keys for all these keys have been published on your web site. It's time to sign a release!

After hours of toil, it's time for someone to sign the release. Maybe it's you, maybe it's someone else on the project team. The important part here is it should be someone that has a release signing key that's been signed by the master release key. (Note how I keep repeating this concept. That's because it's important.) You generate a tar.bz2 file with your code inside and then at least one of your releasers signs the compressed archive. That signature is saved in "detatched" mode in a file that's placed in the ftp directory next to the archive.

Hey... what do you mean "at least one" releaser signs the archive? Well... lets just say you just don't trust anyone. You're not sure your releasers are trustworthy. You might think that getting two releasers to sign the archive is a good idea. Keep in mind that all your releasers might be secret cabal members of the world anarchists association, so it doesn't really buy you anything in terms of trust moving forward. Hey, if two untrustworty rogues sign your code, it's no better than had it been signed by one. However... there's something we haven't talked about; due care of the releaser's signing keys.

So let's just imagine there's a really good reason a "bad guy" might want to put "bad" code in your project. Let's also imagine that all your releasers are as pure as is the winter snow, and you know they would never intentionally put bad code in your codebase, and you know they would never allow anyone else to do the same. But it's also possible they never learned good "operational security" (or OpSec as we used to call it back in the Regiment.)

Lets say one of your releasers was having just slightly too good a time at the last SchmooCon and let it slip with the fact that she's a releaser for your project. Three seats down at the bar is a "bad guy." Hearing this, he instantly goes on the offensive using his boyish good looks to gain the confidence of our trustworthy releaser. Several cosmopolitians later, our releaser doesn't notice he's shoulder-surfing her PGP passphrase. After the party her laptop is borrowed and her encrypted PGP key is extracted. Our ethically challenged Cassanova uses the shoulder-surfed password to recover the releaser's signing key and from the coffers of an enemy proclaim'd receives the golden earnest of our fault. Okay.. it's a little outlandish, but work with me here, I'm trying to have a little fun with the description. Just imagine that somehow, one of the releaser's keys is compromised.

This is a big deal. Remember that we sequestered the master key away. It should be a big deal to get that key back out to spin a new key for a releaser. Since it's such a big deal, releaser's keys have to have a relatively long lifetime. Because they have a long lifetime, they've been used a lot. If a bad guy gets access to your ftp site, and they have a releaser's key, they can go backwards in time and pull down all the previous releases of your project, insert vulnerabilities, sign them with the stolen key and re-upload them.

This is a key bit of knowledge to take away from this increasingly verbose exposition. When a key is compromised, all uses of that key from the past into the future are compromised as well. This is why there are such things as secure timestamping services and whatnot. If you're really, really paranoid, you can require two releasers sign a release. This supposedly doubles the effort required to create a real compromise. You have to steal two keys or in classic darth sidious fashion, subvert two releasers.

I know what you're thinking and the answer is "yes, it is possible to take things too far." But only you can decide what level of assurance you want in your team's processes.

Now it's time for someone to download your code. They get it off the FTP site (or the ever changing array of hosts sourceforge uses to mirror releases.) You should tell people somewhere in the documentation that they're supposed to download the detatched signature(s) and use PGP (or GPG or both) to verify the authenticity of the release.

Assuming that everything goes as planned, downloaders download your code, install it on their boxen, and the world is good. The code is SO good that Microsoft decides it want's to hire all your team members away from you. After they are firmly installed in the golden castle, never to be heard from again. It's time to pick some new releasers! But wait! Where did you put that master signing key?

Whatever could you have done to prevent this from happening? Yes, you've fallen victim to the most common problem with using PGP. Key atrophy. I've seen it several times. People get excited about using their key for the first couple of messages they send out, but then the novelty wears off when they realize they've got to keep re-entering their darn'd passphrase. They turn the "Always Encrypt" option off in their email client and promptly forget their passphrase or worse yet, forget where they put the backup disk with their PGP key. If this happens to your master key, you've got to do it all over again: generate the master key, sign your releasers signing keys, the works.

1st Person Key Escrow should help you take care of this problem. "Key Escrow?" you gasp. "What kind of Nazi are you?" Okay... don't panic. I'm talking about "1st person" escrow. Heck, let's just slap the person who called it "escrow' and call it "key backup." This is where you start dealing with key splitting and shares and all these things.

Most products (like PGP or GPG) that generate keys also have a way to export shares. The idea here is that you can split your private key into a number of shares and distribute them amongst a TRUSTED group. It's probably better if the share-holders don't know each other. As more than enough people on this thread have pointed out, if enough of them collude, they can recover the master key and generate their own releaser key. Horrors!

This leaves us with our final problem. Authenticating your releasers. Let's say I'm an evil, evil man hanging out on your project's dev list waiting for the opportunity to cause mischief. If I hear something like "okay, all releasers send me your public keys so I can sign them..." Well... guess what I'm going to do? I'm going to send you MY key and see if I can trick you into signing it. If I'm really good, or maybe I work with a trusted releaser, I'll spoof a message to you with my public key and the trusted releaser's email address, and then hope no one notices for a while.

This is the problem of authenticating in a vacuum. What you might want to do is have valid releasers phone you and read their PGP key fingerprint over the phone. Better yet, twist their arm and get them all to come to TOORCON. Then verify key fingerprints in person.

But you still have a little bit of a problem if you equate releaser's key with trust. It's entirely possible that you might be legitimately signing a legitimate key from an unstrustworthy person. Keep in mind that crypto can do nothing to prevent this and you'll probably be okay. What crypto can do, however, is verify that you're talking to the same untrustworthy scalliwag this week that you were talking to last week. That is, as long as their key has not been compromised.

Good luck.

it was colonel zeller who approached me first

In Soviet Russia... (-1)

mrt300 (580362) | more than 9 years ago | (#12427324)

...the key signs you! Sorry, it was too easy to pass up.

Advanced security schemes (1)

Tharkban (877186) | more than 9 years ago | (#12427925)

They have advanced secret sharing algorithms for that sort of thing. Something like k out of n people have to agree to sign it. I kind of doubt it'll play nicely with PGP though. Something really should be done about making such schemes more available.

Does anyone else think PGP only supports outdated techniques?

Two signatures required for amounts over $5000 (1)

rice_burners_suck (243660) | more than 9 years ago | (#12428552)

I think a new digital signing algorithm needs to be invented that has a public key and multiple private keys.

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 around the world might have ten different people who have these separate private keys. Suppose you decide that eight out of the ten people needs to include his portion in order for a signature to take place.

Such an algorithm would not necessarily be too difficult to create. Suppose you take the "normal" private/public key scheme and change it so that multiple private keys are created, each of which contains a portion of the complete private key. How much of the complete private key would depend on how many people need to sign; that is, the policy made up at the time the keys are created. The difficult part is making sure the algorithm remains one-way, and that no private key holder can deduce or compute the keys of the other private key holders.

Also, a software apparatus would need to be made which allows for distributed signing of a message without making the private key holders divulge their keys to each other. I'm a bit mixed on how this should be done.

Now suppose that something happens to one of the private key holders; the organization could decide to cancel those keys and generate new ones.

Mmmm security (0)

Anonymous Coward | more than 9 years ago | (#12429280)

Just use ROT-13 encryption

Missing the POINT! (0)

Anonymous Coward | more than 9 years ago | (#12429318)

You CANNOT implement an object code signing scheme for open source projects.

The whole point is that the user is free to change the sourcecode and re-build.

If you implement a system requiring object code signing you have just killed that.

You have turned open source into reviewable source.

1/2 - 3/4 of the freedom has just gone.

Or are we talking about code signing to certify to the USER (not the computer) that no third party has adulterated the code.

If its an certification of "goodness" to allow the RIAA/MPAA to be happy that the code will not steal, forget it. they won't be happy with anything as open as a normal computer. The whole information path from your HDD to your monitor must be locked down and not under your control.

These are seperate issues. You must first decide exactly what you are doing AND WHY before you start asking this question.

What is the goal of the code signing of which you speak?

Who is the CUSTOMER?

The computer user? the "industry"?

So what? (was Missing the POINT!) (1)

collinl (114075) | more than 9 years ago | (#12429873)

Why is any of this different to commercial softwar development"
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 caveat emptor-like term for this)
Lyal

Personal keys vs. per organization keys (1)

oglueck (235089) | more than 9 years ago | (#12429526)

I don't think it's a good idea to use a key issued to an organization in this case. If your organization does not have an office you will probably not be able to get a code signing cert from Thawte (or other CAs) stating your organization's name, anyway. You will fall back to GPG/PGP probably.

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 on your website and inside the downloaded package who signed it (one thing ASF still has to do right). You should also publish the fingerprints of those keys in the same easy-to-find place (keys that can not be verified are useless). On the other hand there is no problem when a developer leaves the project. There is no need to pass secrets around.

If you think about it, there's no point to signing (1)

pito (159507) | more than 9 years ago | (#12431179)

I've long objected to the idea that my users (BlogBridge http://www.blogbridge.com/ [blogbridge.com] ) are asked about certificates by Java.

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 with a valid certificate, all they are proving is that they have $300 or so and a valid post address. What kind of protection is that?

More on this: http://www.salas.com/weblogs/archives/000645.html [salas.com]

Huh? Why do you care? (1)

hacksoncode (239847) | more than 9 years ago | (#12433003)

Maybe I'm missing something here, but who cares if your key is lost or you drop out of the project? The person that takes it up can just get their own key and sign it with that.

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 different person than the last version? If it's OSS that could happen anyway due to a fork.

If you think that there are a bunch of people out there that have developed a huge level of trust in your open source project, you're deluding yourself. If you really think people will need to have some kind of statement to the effect that the new developer should now be trusted, just write up that statement and sign it with your key before you leave the project.

If you lose your key for some reason, have the CA revoke it and give you a new one... Sure, it's a pain, but not as much of a pain as most of the suggestions I've seen here.

If it works, don't break it (0)

Anonymous Coward | more than 9 years ago | (#12452016)

It sounds like you have a working protocol already. DON'T BREAK IT by trying to fix the wrong problem.

Yes, you can reduce the risk of "losing" the private key if you distribute multiple copies. On the other hand, that will INCREASE the risk of disclosure.

The right answer is to have a shared, reliable process for revoking and replacing the signing key. This addresses the problem of loss as well as disclosure.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?