Code Signing: Best Practices

Bruce Morton

The biggest issue with code signing is the protection of the private signing key associated with the code signing certificate. If the key gets compromised, then your certificate is worthless. A compromised key may also jeopardizethe software that you have already signed.

Here are some best practices for code signing:

1. Minimize access to private keys

  • Computers with keys should have minimal connections
  • Keep the minimum numbers of users who have key access
  • Use physical security to minimize access

2. Protect private keys with cryptographic hardware products

  • Keys should be protected on a minimum FIPS 140-2 Level 2 certified product
  • Cryptographic hardware does not allow export of the private key to software where it could be attacked

3. Time-stamp your code

  • Time-stamping allows your code to be verified after the certificate has expired or been revoked

4. Test-signing versus release-signing

  • Test-signing certificates require less access to 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

5. Authenticate code to be signed

  • Any code that is submitted for signing should be strongly authenticated, so you know that it permissible to sign
  • Implement a code signing submission and approval process to prevent the signing of unapproved or malicious code
  • Log all code signing activities for auditing purposes

6. Virus scan code before signing

  • Code signing does not confirm the safety or quality of the code; it confirms the publisher and whether or not the code has been changed
  • Virus-scanning will help to improve the quality of the released code

7. Minimize Use of Keys and Certificates

  • If code is found with a security flaw, then you might want create a trust dialogue when the code is installed in the future; this can be done by revoking the code signing certificate and a revoked prompt will occur
  • If the code with the security flaw was issued before more good code was issued, then revoking the certificate will impact the good code as well
  • Changing keys and certificates often will help to avoid this conflict

Microsoft has an extensive set of best practices, which can be found in this document.

This is the eight post in our code-signing. Check out the full list to read past entries.

Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

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.

1 Comment

Add to the Conversation