Slashdot Mirror

← Back to Stories (view on slashdot.org)

Managing Code Signing Digital IDs for Open Source?

Posted by Cliff on from the project-security dept.

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

103 comments

  1. Why ask? by hyfe · · Score: 4, Funny

    Post-it notes all the way baby!

    --
    "" How about taking the safety labels off everything, and let the stupidity-problem solve itself? """
  2. this should ne intresting by Amouth · · Score: 1

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

    --
    '...if only "Jumping to a Conclusion" was an event in the Olympics.'
  3. PGP signing? by Ranger · · Score: 0

    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 results at Google and take your pick.

    --
    "You'll get nothing, and you'll like it!"
    1. Re:PGP signing? by Malc · · Score: 1

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

    2. Re:PGP signing? by jrumney · · Score: 1

      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.

    3. Re:PGP signing? by Malc · · Score: 1

      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.

    4. Re:PGP signing? by Anonymous Coward · · Score: 0

      • wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww wwwW
  4. RM by Anonymous Coward · · Score: 2, Informative

    It's called the Release Manager.

  5. Just checksum by Anonymous Coward · · Score: 1, Insightful

    and be done.

    1. Re: Just checksum by Alwin+Henseler · · Score: 1
      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.

    2. Re: Just checksum by Craig+Davison · · Score: 1

      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.

      --
      Hands in my pocket
  6. If it's open source... by Marthisdil · · Score: 0

    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

  7. Sharing the public key by xmath · · Score: 5, Insightful

    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.

    1. Re:Sharing the public key by cpeikert · · Score: 4, Interesting

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

    2. Re:Sharing the public key by mhamrick · · Score: 1

      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.

    3. Re:Sharing the public key by jrockway · · Score: 1

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

      --
      My other car is first.
    4. Re:Sharing the public key by Darren+Winsper · · Score: 1

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

    5. Re:Sharing the public key by stonebeat.org · · Score: 1

      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.

      --


      Consensus is good, but informed dictatorship is better
    6. Re:Sharing the public key by Anonymous Coward · · Score: 0

      It was created as a way for you to know exactly who a piece of code came from

      Then it's still broken, because all it does is tell me that *someone* paid Microsoft $X for a signature. It doesn't tell me who actually wrote the code. (Because the entity who commissioned the signature is not guaranteed to be the entity who wrote the code.)

  8. Best Option? by 0kComputer · · Score: 1

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

    --
    Top 10 Reasons To Procrastinate
    10.
    1. Re:Best Option? by Zeebs · · Score: 1

      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.

      --

      Happy Noodle Boy says "F###ing doughnut! Mock me? You fried cyclops!!"
  9. I know who you can trust. by Anonymous Coward · · Score: 4, Funny

    Micros~1.

    They invented code signing after all....

  10. smart cards? by John+Harrison · · Score: 2, Interesting

    put the signing certs on pin protected smart cards. Then ship the cards to the people you want to have be able to sign. Ship the pin to unlock the card by a different method.

    --
    Lasers Controlled Games!
    1. Re:smart cards? by hedge_death_shootout · · Score: 1

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

  11. Start a "trust tree" by Anonymous Coward · · Score: 1, Interesting

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

    1. Re:Start a "trust tree" by Anonymous Coward · · Score: 0
      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.
  12. Interesting by Daath · · Score: 3, Interesting

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

    --
    Any technology distinguishable from magic, is insufficiently advanced.
    1. Re:Interesting by Anonymous Coward · · Score: 0
      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.

  13. Share split with a minimum number by m50d · · Score: 3, Insightful

    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
    1. Re:Share split with a minimum number by Anonymous Coward · · Score: 0

      So, kind of like Voltron?

  14. You'd prefer multiple? by Arakonfap · · Score: 2, Interesting

    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.

    1. Re:You'd prefer multiple? by stonebeat.org · · Score: 1

      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.

      --


      Consensus is good, but informed dictatorship is better
  15. Split secrets by lewis2 · · Score: 5, Insightful

    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.

    1. Re:Split secrets by Conare · · Score: 2, Insightful

      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.

      --
      Stop Continental Drift! Reunite Gondwanaland!
    2. Re:Split secrets by stonebeat.org · · Score: 1

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

      --


      Consensus is good, but informed dictatorship is better
    3. Re:Split secrets by lewis2 · · Score: 1

      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.

  16. Good use for AI by null+etc. · · Score: 2, Funny
    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.

    1. Re:Good use for AI by ggvaidya · · Score: 1

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

  17. Why is this presumed to be an Open Source issue? by ScentCone · · Score: 4, Insightful

    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.
  18. Never thought of this before? by wfberg · · Score: 0

    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?

    --
    SCO employee? Check out the bounty
  19. In Internet Explorer by Anonymous Coward · · Score: 0

    In Internet Explorer it already does all this automatically.

  20. Thoroughly off-topic, but... by BaudKarma · · Score: 2, Insightful

    ...isn't it about time we shelved that idiotic phrase "best practices"? Can't you just ask for the best way, or the best method? People are using "best practices" for everything from EMail management to installing a new kitchen sink. It's hokey and pretentious, and I'll be really glad if I never see it again.

    Okay, I feel better now. Thank you.

    P.S. My karma is right on the edge, so if you mod me down I'll probably lose all my bonuses and everything.

    --
    It's the land of the brave, and the home of the free
    Where the less you know, the better off you'll be.
    1. Re:Thoroughly off-topic, but... by hedge_death_shootout · · Score: 1

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

    2. Re:Thoroughly off-topic, but... by pommiekiwifruit · · Score: 1
      "Best practices" means someone is actually doing it now.

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

    3. Re:Thoroughly off-topic, but... by Mr.+Shiny+And+New · · Score: 1

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

  21. You know what they say by pHatidic · · Score: 3, Funny

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

    1. Re:You know what they say by caluml · · Score: 1

      Yo ho ho, and a bottle of rum!

      --
      Get your own free personal location tracker
    2. Re:You know what they say by Anonymous Coward · · Score: 0
      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!

  22. why? by Anonymous Coward · · Score: 0

    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?

  23. From the moderator... by Anonymous Coward · · Score: 0

    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.

  24. Don't dilute the trust. by metoc · · Score: 1

    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.

    1. Re:Don't dilute the trust. by Anonymous Coward · · Score: 0

      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.

  25. Keys? by Anonymous Coward · · Score: 0

    We dont need no stinking keys!

  26. Shamir Secret Share by cheesedog · · Score: 2, Informative

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

  27. To the gatekeeper, go the keys by Xeger · · Score: 1

    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.

  28. Actually I meant FSF, but EFF is just as good by Daath · · Score: 1

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

    --
    Any technology distinguishable from magic, is insufficiently advanced.
  29. Sourceforge... by Spy+der+Mann · · Score: 1

    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?

  30. One for each releaser. by coopseruantalon · · Score: 1

    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.

  31. Microsoft Passport? by team99parody · · Score: 1
    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.

    1. Re:Microsoft Passport? by hedge_death_shootout · · Score: 1

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

    2. Re:Microsoft Passport? by team99parody · · Score: 1

      Too bad it's not an effective means of karma whoring; since the theme for this troll account (Microsoft's team99 astroturfing campaign) is so ludicrous I can really only get Funny mods that don't help this account's Karma.

      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 as the Microsoft hired-trolls on the real Team99 retain theirs, so people can see what a joke both them and this account are.

      Thanks for your interest and comment, though. :) If only they'd give a fraction of a karma point for funnies, I think this account would have wonderful potential as a karma-whore-example account.

  32. personal reputation by MathFox · · Score: 2, Interesting

    Why doesn't the package builder sign the package with his personal key? This has the additional advantage that you can trace problems to individuals and/or broken keys. The core group of developers should cross-sign all of their public keys; they can then sign the keys of the people that are allowed to make "official" distributions. From then on it is just a matter of key management: distribute the "trusted" public keys and revoke keys when people leave the project.

    --
    extern warranty;
    main()
    {
    (void)warranty;
    }
  33. Don't make work for yourself by TrumpetPower! · · Score: 4, Insightful

    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&

    --
    All but God can prove this sentence true.
    1. Re:Don't make work for yourself by tepples · · Score: 1

      Official releases are created and hosted on trusted servers, along with the hashes.

      How do these trusted servers remain trusted?

    2. Re:Don't make work for yourself by Joff_NZ · · Score: 1

      Some opensource projects require that they be signed - one that comes to mind is the BouncyCastle Crypto API for Java - 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?

      --
      The revolution will not be televised. It won't be on a friggin blog either
    3. Re:Don't make work for yourself by cs · · Score: 2, 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.

      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.

      --
      Cameron Simpson, DoD#743 cs@cskk.id.au http://www.cskk.ezoshosting.com/cs/
  34. hm by savuporo · · Score: 1

    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.

    --
    http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org Errors found while checking this document as HTML5!
  35. Secret Sharing and Verifiable Secret Sharing by HidingMyName · · Score: 5, Informative
    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.

    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 (he has some recent work too). Tal Rabin has done some good work, as has Markus Stadler. Recent work by Stanislaw Jarecki has caught my eye.

  36. Why? by overshoot · · Score: 1
    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.

    --
    Lacking <sarcasm> tags, /. substitutes moderation as "Troll."
  37. remote server by net_phreak · · Score: 1

    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.

  38. I don't know the answer but .. by Anonymous Coward · · Score: 0

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

  39. Why just one key? by Timothy+Brownawell · · Score: 1
    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

  40. Debian by CarpetShark · · Score: 1

    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.

  41. Why are you doing code signing? by pjc50 · · Score: 1

    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.

  42. Keep a printout... by davidwr · · Score: 2, Informative

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

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  43. Found it! by jd · · Score: 2, Informative

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

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:Found it! by stoborrobots · · Score: 2, Informative

      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/

      --
      "Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
  44. Windows Drivers or the like by elo_sf · · Score: 1

    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.

  45. Just use personal keys by Sloppy · · Score: 2, Interesting
    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.
    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    1. Re:Just use personal keys by leuk_he · · Score: 1

      You got the mechanism right, it's all about trust. And the signing is nothing more than an advanced checksum. But the point is probably that they bought a key from thawte or verisign for $$$ so that users that download ther executable(with internet explorer) are assured they downloaded an unmodified executable.

      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 envelope (or a digital equivalent of this) to a second trusted person should do the trick. If you do not trust members of your project with this, (for forking or policy things), you should not trust them modifying the source and possibly releasing it. They have always the option of buying a new root certificate and make fork of the project.

  46. paranoia and FUD by Anonymous Coward · · Score: 0

    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.

  47. Key chains for better security by Anonymous Coward · · Score: 0

    Look at the way the author of PuTTY uses multiple keys for signing.

  48. Distributed hardware threshold signature. by CustomDesigned · · Score: 2, Informative
    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.

    1. Re:Distributed hardware threshold signature. by ccherlin · · Score: 1

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

    2. Re:Distributed hardware threshold signature. by CustomDesigned · · Score: 1
      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.

  49. An alternative approach by jd · · Score: 1

    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.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  50. One primary, many secondary by Rupan · · Score: 1

    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?

    --
    Ads? What ads?
  51. Mix up? by Hydrogen_NL · · Score: 1

    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.

  52. It's a social trust problem, not a technical one by arete · · Score: 2, Insightful

    Code signing is a mechanism for proving "who" is endorsing that code as something you can trust. Your problem is defining "who" and that's not really a technical problem.

    If somebody forks you, you shouldn't sign their code. Not because it's bad, but because you can't vouch for it. THEY should sign their code.

    Letting somebody else have the key to sign code is endorsing that your good name should go on ANYTHING that they decide to put out. Certainly, a project above a certain size with a community of maintainers should distribute this responsibility.

    If I had a small project, I would make sure the key was left to somebody in my will (and I'd probably leave it with some close friends) - hopefully it'd get to somebody who'd be nominated to takeover the probject - because if I die presumeably I'm less worried about someone pretending to be me. This is a form of key escrow, but it's not a very arbitrary one.

    For a larger project, it must be almost the highest level of trust, and it doubtless has to be learned. Those levels of trust would go something like:
    bank accounts & corp documents
    CVS log modification (auditability erasing)
    code signing
    CVS commit (but at least you can track it after the fact)
    fast-track patch submission
    anyone (normal patch submission)

    These levels are a pyramid; fewer people should be trusted at each level - and fewer people are needed.

    --
    Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
  53. Trust the PM, back up the key pair, jic. by myvirtualid · · 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 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.

    --
    I'm here EdgeKeep Inc.
  54. What are your signing semantics by mhamrick · · 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:

    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 jus

  55. Advanced security schemes by Tharkban · · Score: 1

    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?

    --
    Tharkban (It is a signature after all)
  56. Two signatures required for amounts over $5000 by rice_burners_suck · · Score: 1
    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.

  57. Re:K of N and don't forget the time-stamping by datapt · · Score: 1

    -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

  58. Mmmm security by Anonymous Coward · · Score: 0

    Just use ROT-13 encryption

  59. Missing the POINT! by Anonymous Coward · · Score: 0

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

  60. Personal keys vs. per organization keys by oglueck · · Score: 1

    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.

  61. So what? (was Missing the POINT!) by collinl · · Score: 1

    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

  62. If you think about it, there's no point to signing by pito · · Score: 1

    I've long objected to the idea that my users (BlogBridge http://www.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

  63. Huh? Why do you care? by hacksoncode · · Score: 1
    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.

  64. If it works, don't break it by Anonymous Coward · · Score: 0

    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.