Some time ago I read the canonical answer of our ursine overlord concerning CAs and their private (root) keys.

More recently I stumbled across the question on the question on how to manage code signing keys for iOS and android.

Basically as a follow-up I just had to ask myself:

How do large companies (like Apple, Microsoft, Google, Intel, ...) protect their valueable code-signing keys?

In particular this question can be broken down into: How do these companies ensure only valid builds get signed (i.e. access management) and what do they physically do the protect the private keys? In particular the comparison of the security measures root CAs use and that the companies use can be interesting.

This question is also motivated by my older "How do large companies protect their source code?", where I got interesting, unexpected answers such as "they just use private GitHub repositories". In particular one may suspect that the build machine just has a software key that signs all builds it produces and I hope to clarify this (among learning the actual protections).

As for "why" protecting the keys is important:

  • If Apple's keys would get lost (silently?) anybody could sign iOS or Mac OS X builds or Apps, which would undermine large portions of Apple's security measures.
  • If Microsoft's keys would get leaked, the same app fiasco as for Apple would hold and additionally attackers may be in a position to push malicious Windows updates to targeted machines.
  • If Intel's keys were leaked, it would be possible to sign Intel processor code updates and to sign arbitrary SGX software allowing deep implementation of malware in a target system that is impossible to get rid off without changing the hardware.
  • If Google's keys were leaked, one could arbitrarily fake Google apps (arguably the weakest attack scenario out of the given)

As usual, I don't want answers saying "it's illegal to steal / abuse such keys", as the law may not be an effective way to stop agencies that can just declare their law violation "top secret" or to stop criminals who don't care about the law anyways.

Further, I want to quickly clarify, why I rule out "revocation" as the solution: a) This is not always possible, especially for hardware manufacturers, if the public key is actually hard-coded (for security reasons) into the hardware. b) The damage to the image of the company would be gigantic if they would have to revoke a key. Thus, while revocation may work in some circumstances (for small app developers for example), it's not a good option for larger companies.

  • 2
    There derive a 'second generation' of keys from them that they actually use, and store the originals in a physical vault. – Jan Doggen Mar 7 '16 at 12:23
  • This may be relevant to at least part of your question... security.stackexchange.com/questions/67663/… – user1751825 Mar 7 '16 at 12:25
  • @JanDoggen, how do they derive a "second generation"? Does this mean they have always backup keys in their vaults? – SEJPM Mar 7 '16 at 12:37
  • 1
    Why do you think they do it differently than CAs? – Michael Mar 7 '16 at 13:24
  • @Michael, I do really hope they do it like CAs, but I don't know (that's why I'm asking, it's expensive and time intensive after all). I also expected software companies to have physically separate development networks and was proven wrong. – SEJPM Mar 7 '16 at 13:26

Lots of processes can be called "code signing", anything from publishing a tar file with a pgp-signed hash and up.

For the sort of large company you mention, ultimately HSMs (more than one, obviously, in case a data center is overtaken by zombies or something) are involved. The hard part is not where the actual keys are stored, but the entire Release Engineering process that guarantees that the shipped signed binaries really did come from the source code in the repositories.

It differs a lot. Some ways I've seen it are. Soft keys on development work stations, not so secure. Smart cards locked in safes, secure but cumbersome. Central code signing server, with hsm for private key protecting, pretty secure, and auditable.

CA/Browser forum, that creates specifications all public CAs have to abide to, have published guidelines for CAs issuing code signing certificates. It is a valuable resource in this context IMHO. https://cabforum.org/ev-code-signing-certificate-guidelines/ (I have no affiliation with this spec, but it is important for public code signing certificates)

Private key protection of the subscriber (code signing) key is not detailed, but described in section 10.3.2.

  • you really need to state your affiliation with a product if you're going to be mentioning one that you sell, otherwise you'll get flagged as spam. Better yet, no need to hawk your product here at all, it adds nothing to the answer. – AviD Apr 3 at 19:54
  • Thanks, I will be very careful in the future mentioning external resources. Perhaps guidelines could be made more clear on external resources at security.stackexchange.com/help/how-to answer? – primetomas Apr 5 at 5:34
  • 1
    Perhaps you should check out this meta thread which explains a bit about disclosing affiliation in answers. The gist of it is that you need to disclose affiliation in any answer not specifically about the product you develop. – forest Apr 5 at 5:40
  • @primetomasit already says everything here: security.stackexchange.com/help/promotion – AviD Apr 5 at 8:10

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.