Protect Your Private Keys: Three Easy Steps for Safe Code-Signing

December 19, 2013 by Bruce Morton     No Comments

A recent article by the Microsoft malware protection center, “Be a real security pro – Keep your private keys private,” reminded me of some best practices.

lockThere are far too many cases of illegitimate code being signed by a stolen private key for legitimately signed code-signing certificates. In these cases, the owners of the private keys have not secured the keys.The problem with code-signing is that many developers may need to sign their code.

If there is no controlled signing process, then the signing private key, password and code-signing certificate are readily distributed among developers. The thinking? “Since more than one developer is using the private key, let’s make the password simple, so that everyone remembers it.”

With this process, there is no control on how the private key and password are protected. This makes the challenge of accessing these items even easier. When managing code-signing private keys, the following is recommended:

  • Minimize Access to Private Keys — Computers with private keys should have minimal external connections. Minimize the number of users who have access to the private keys.
  • Use Physical Security to Protect Keys — Protect private keys with cryptographic hardware products that meet the minimum of FIPS 140-2 Level 2 certified. Cryptographic hardware does not allow export of the private key to software where it could be attacked.
  • Test-Signing versus Release-Signing — Test-signing certificates require less protection than production code-signing certificates. Test-signing certificates can be self-signed or come from an internal test CA. Establish a separate test code-signing infrastructure to test-sign prerelease builds of their software. Test certificates must chain to a completely different root certificate than the root certificate that is used to sign publicly released products. This precaution helps ensure that test certificates are trusted only within the intended test environment.

If you’re interested in more information, Microsoft provides an extensive set of best practices to support code-signing.

About

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.

Add to the Conversation