Overcoming Code Signing Roadblocks: Handling Non-Exportable Private Keys

Code Signing stands at a critical inflection point. While most security transformations evolve gradually, the Certificate Authority Browser Forum's (CAB Forum) recent mandate on non-exportable private keys for code signing certificates represents a seismic shift that's forcing organizations to fundamentally rethink their software delivery pipelines. As security leaders, we must ask ourselves: Are our current code signing practices ready for this new paradigm?

In the technical security industry, we're used to finding answers through collective wisdom - someone has usually encountered and solved our problem before. But what happens when you're the first one facing a new challenge?

Unlike the gradual evolution of technology and tools, changes in technical security can be sudden and dramatic, especially when driven by regulatory requirements. While most innovations unfold over time, regulatory deadlines create clear before-and-after moments that affect the entire industry simultaneously.

When there is a rule change, such as the CAB forum requirement to no longer make private keys exportable for code signing certificates, then whole processes are subject to change to accommodate the new rule.  And because this change happens on the same day for everyone, we might all be “the first one” all at the same time, because we all need to navigate this change to maintain compliance with CAB forum requirements.

For CAB forum’s requirements, we will need to understand the new rules cause breaks in existing use cases. One such use case is when a company is in possession of one code signing certificate that several software developers use to sign code, and the certificate is stored in each developer's browser.  It is key to understand that the initial code signing certificate had to have its private key exported for software developers to be able to load it into their browser in this use case.  The export of a code signing certificate’s private key is now prohibited for everyone who uses a publicly trusted code signing certificate to sign executables.

We can still crowdsource wisdom by recognizing that many in the industry face similar challenges and need practical solutions. However, it's crucial to understand your specific business requirements and processes when choosing the best way forward. Consider factors such as team size, security needs, budget, management preferences, portability needs, and ease of implementation.

One solution is for the company to procure an FIPS 140-2 Level 2 compliant Hardware Security Module (HSM), and store code signing certificates there for their software developers to invoke when they are signing packages with their provisioned credentials.  IdenTrust provides a code signing certificate that can be stored on the HSM and software developers would then invoke the public code signing certificate issued by IdenTrust that resides on the company HSM while signing their software packages.

An alternative solution which is also hardware-based , is to order publicly trusted code signing certificates on FIPS 140-2 level 2 compliant USB devices for each software developer. IdenTrust provides publicly trusted OV and EV code signing certificates, available on FIPS 140-2 Level 2 compliance USB hardware tokens shipped directly to the purchaser.  While there will be a workflow change where each software developer will invoke the certificate stored in the USB token when signing their software package, it is a scalable shift for those signing packages stored on their work machine. 

Ready to adapt your code signing practices to meet the new requirements? Contact us today to discuss your options and ensure your organization stays compliant and secure.