¶ºÒõ¹Ý

Convenient, easy to access, inexpensive way to comply with new CA/B Forum changes for code signing private keys.

As companies struggle to ensure compliance with new (as of June 1) CA/Browser (CA/B) Forum requirements that all code signing private keys be stored in FIPS 140-2 compliant hardware, ¶ºÒõ¹Ý announced a new capability called ¶ºÒõ¹Ý KeyLocker to address these compliance requirements.

Why this industry requirement is long overdue

Over the past several decades, there have been countless incidents where a software developer has stored private code signing keys in insecure locations. A notable example occurred with the Taiwanese computer manufacturerÌýÌýIn this example, private code signing keys were stored on web servers. Hackers breached the webservers, found the code signing credentials, added malware to legitimate Asus driver updates, signed them and in hours, Asus was pushing out infected updates to thousands in their unknowing customer base.

Asus isn’t alone. Nvidia and GitHub are a few more notable examples. Most recently, there was an incident with ÌýIf one searches the dark web, it is easy to find, for a price, malware kits along with stolen code signing credentials.

Why does this happen so frequently?

Developers are creatures of habit and convenience. They are driven by market pressures to produce new product capabilities faster than ever. They utilize processes and tools — such as DevOps, continuous integration and continuous deployment (CI/CD) and cloud native infrastructure — which heavily rely on automation. In addition, security often isn’t their primary focus. These factors often can lead to shortcuts — that is, code signing private keys being stored where they are convenient but not secure.

This means these keys may end up on the servers (on-prem and in the cloud) they use to build their applications. Or their laptops. Or, as was the case of Asus, on the web servers that were used to push out final updates to customers.

New CA/B Forum requirements to address these types of breaches

The Code Signing Working Group of the CA/B Forum passed a ballot to strengthen the requirements surrounding private keys used for code signing. Over the course of a year, the participants of the Code Signing Working Group hashed out the details of CSC-13: Update to Subscriber Key Protection Requirements to meaningfully raise the bar for security while carefully weighing the burden that new requirements may pose.ÌýThese changes are now effective.

How to become compliant

If you’re a large enterprise organization, you’re likely already using a hardware security module (HSM) to securely store your private keys or using a secure code signing solution, such as ¶ºÒõ¹Ý^® Software Trust Manager.Ìý¶ºÒõ¹Ý Software Trust Manager not only secures keys in a FIPS 140-2 compliant way, but also allows organizations to establish access policies to further protect the use of keys even in highly automated processes like DevOps.

Physical hardware tokens, such as those sold by ¶ºÒõ¹Ý, remain an option as well. But the drawback of using a hardware token is that it is hard to use them in build and signing processes that are fully automated, such as those used in DevOps.

This new CA/B requirement may be particularly challenging for small software development teams without access to an on-prem HSM or for those that don’t use an enterprise secure code signing solution, like ¶ºÒõ¹Ý Software Trust Manager. For these types of customers, we now offer ¶ºÒõ¹Ý KeyLocker, an option available to those that purchase code signing certificates from ¶ºÒõ¹Ý CertCentral.

For those that do not have access to an HSM or a secure code signing solution, and purchase code signing certificates from ¶ºÒõ¹Ý CertCentral, you now have a new CA/B Forum compliant option. This solution is called ¶ºÒõ¹Ý KeyLocker.

¶ºÒõ¹Ý KeyLocker

¶ºÒõ¹Ý KeyLocker delivers strong key protection for Organization Validated (OV) and Extended Validation (EV) code signing private keys in a cloud delivered service that meets CA/B Forum requirements. KeyLocker provides secure key storage, key generation and signing without the constraints of a physical token.

In contrast to hardware tokens, KeyLocker does not require shipping nor incur the delays and inconveniences associated with the order and delivery of physical devices. There are no risks of lost or stolen tokens. Signing can take place at any time, from any location and can be readily integrated into automated CI/CD pipelines.

KeyLocker may be purchased along with a code signing certificate in making cloud-delivered signing with strong key protection easy to obtain, easy to set up, and easy to use. KeyLocker offers a seamless way for IT administrators and developers to comply with the CA/B Forum requirements for code signing key protection.

For organizations with large and distributed software teams and/or those that develop mission/safety/business-critical software, secured private key storage – such as that provided by KeyLockerÌý– is one step towards software supply chain security, but alone doesn’t support all the of the recommended security precautions for code signing. For example, security measures such as code signing policy enforcement, centralized enterprise management, role-based access to keys, key rotation, fine grain security and access controls, and irrefutable record of code signing activities are available in ¶ºÒõ¹Ý Software Trust Manager.

For more information about ¶ºÒõ¹Ý KeyLocker, download the datasheet.