Effective June 1, 2023, a significant change unfolded in the world of code signing certificates. Certificate Authorities (CA’s) took a decisive step by introducing a new requirement for customers seeking a Code Signing certificate. Requesters of code signing certificates now had to ensure that they either acquired the keys using a hardware crypto module token or provided verification to demonstrate that the private key associated with their Certificate Signing Request (CSR) was generated within a suitable Hardware Security Module (HSM). The purpose of this blog post is to explore the reasons behind these changes, acceptable methods of attestation, and how Keyfactor can offer support in navigating these new requirements.
Why is this happening?
As an organization, when you digitally sign an artifact like code, you’re affirming that it originates from your organization, and others can trust its authenticity and integrity. Considering the significance of this function, which other organizations and end users rely on to ensure they consume only legitimate content, the industry believes that additional protection is necessary to safeguard the sensitive private keys used during the signing process.
Bad actors often target these signing keys to distribute malware and other malicious content. Obtaining a signing key allows them to assume your organization’s identity, which can, unfortunately, go undetected. To mitigate this risk, the new requirement ensures that signing keys exist solely within appropriate hardware cryptographic modules, limiting adversaries’ ability to steal them. In cybersecurity, there is always a trade-off between usability and security, and in this case, the industry believes that the benefits of the additional protection outweigh the burden of changing how code signing keys are used.
What are acceptable methods of attestation?
For a comprehensive list and detailed information, please refer to the CAB Forum’s Code Signing Baseline Requirements document. To accommodate various circumstances, the CAB Forum members have included multiple options for attestation. Here are a few examples:
- The Certificate Authority (CA) provides a suitable Hardware Crypto Module with pre-generated Key Pairs, generated using the Hardware Crypto Module.
- The subscriber counter-signs certificate requests that can be verified using a manufacturer’s certificate, commonly known as key attestation. This indicates that the private key was generated in a non-exportable manner using a suitable Hardware Crypto Module.
- The subscriber provides a suitable report from a cloud-based key protection solution subscription and resources configuration, which protects the private key in a suitable Hardware Crypto Module.
In general, the most convenient option from a process standpoint is option 2. It involves using Public Key Infrastructure (PKI) to sign the CSR with a certificate that chains to the HSM manufacturer. This method allows for programmatically generating key attestation, which can be provided along with the CSR by the verified party to request certificate issuance. However, an agreed-upon standard for generating the attestation is required for this approach to scale across HSM manufacturers, CAs, and other entities. Efforts are underway with the IETF and other groups to establish this standard, but it may take some time before it is fully implemented and supported by all parties.
Alternatively, for those wishing to generate their own private keys for code signing certificates, there are alternate methods available to meet the requirements. These include electronic or paper-based reporting, which offers verification and assurance that the private key was generated in a suitable HSM.
To delve deeper into the details and comprehensive guidelines, you can refer to the Code Signing Baseline Requirements outlined by the CAB Forum. You can access the document here: Baseline Requirements (Code Signing) – CAB Forum.
How can Keyfactor help?
Keyfactor can assist our Signum SaaS customers by generating reports confirming that signing keys generated through Signum are stored in compliant HSMs. As soon as a standard agreed upon by CA’s for HSM verifiable attestation is finalized, Keyfactor plans to implement that functionality within all our Signing products, including Signum and SignServer.
Conclusion
The recent changes implemented in code signing requirements aim to enhance the security and trustworthiness of software distribution. By mandating the use of hardware crypto modules and providing attestation, these requirements address user concerns and strengthen the integrity of signed objects. Stay tuned for more insights, guidance, and developments in code signing. Through these changes, we move towards cultivating a software ecosystem that is more secure, trustworthy, and dedicated to safeguarding the interests of organizations and end users alike.
