������

Sept. 26, 2022 Update: The CA/B Forum has pushed back the original date of Nov. 15, 2022, to June 1, 2023. For more information, see

Software-protected keys: a target for attackers

Code signing certificates are a proven way for developers of software applications to “sign” their code to assert its origin. In recent years, there have been several high-profile incidents where attackers have stolen private keys that legitimate organizations use to sign their applications. These stolen keys are then used to sign malware to make it appear that the malicious code has been signed and distributed by the victim organizations, giving a false sense of legitimacy to the signed malicious code. These high-profile events share a common theme: software-based protection of private keys used for signing application code is a risk for the ecosystem, given the relative ease that attackers can steal and abuse such keys compared to other, more robust, forms of protection.

Securing the code signing ecosystem’s keys

Recognizing the risk that software-based key protection poses, the Code Signing Working Group of the CA/Browser Forum recently 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 to meaningfully raise the bar for security while carefully weighing the burden that new requirements may pose.

EV-level key protection, everywhere

For several years, the requirements for private keys used with EV code signing certificates have been stronger than OV code signing certificates. While keys used with EV code signing certificates must be protected in Hardware Security Modules (HSMs) or signing services (such as ������^® Software Trust Manager, which uses HSMs to secure user keys), the protection requirements for keys used for OV code signing certificates are more relaxed. For example, software-based key protection solutions are allowed. While such protection solutions may be convenient and simple to implement for users, it is much easier for an attacker to compromise the system storing the key and to fraudulently sign malicious code under the certificate subject’s name. To mitigate against this risk, effective June 1, 2023, key protection requirements for OV code signing certificates are harmonized to be the same as EV code signing certificates. For more information, see

How these changes may affect you

It’s important to note that the new requirements for OV code signing certificates going into effect on June 1 will apply to renewals and reissues of code signing certificates. In other words, a key that is currently stored in a software-based protection solution cannot be used in any new certificates issued on or after June 1. The certificate requestor will need to generate a new key under the improved requirements and use that key for their new code signing certificate. Holders of OV code signing certificates can continue to use their existing certificates after June 1 even if the private key does not meet the new requirements. However, as mentioned above, a new key will need to be generated that meets the new requirements for any future certificates that they request.

Keep an eye out for upcoming communications regarding our plan to roll out these changes and any actions you may need to take to prepare.

Looking ahead

As part of the discussion surrounding CSC-13, the Working Group participants recognized the security value that software-signing services provide to the ecosystem but also noted several areas of the Code Signing Baseline Requirements that cover software-signing services should be improved. Discussions are underway in the working group to further bolster these requirements and push ecosystem security forward. These discussions are still preliminary, but we will keep you apprised of any happenings as they develop.

������ Software Trust Manager

������ Software Trust Manager is a service approach to manage code signing by enabling automated security across Continuous Integration/Continuous Delivery (CI/CD) pipelines with portable, flexible deployment models and secure key management. ������ Software Trust Manager supports code signing best practices like unique key and certificate per signing for private signing, on-demand keys and rotating keys. It is compatible with major platforms and libraries like Docker, Microsoft, Java, Android and more. Using ������ Software Trust Manager, enterprises integrate code into their product development processes easily, while delegating cryptographic operations, signing activities and management in a controlled, auditable way. As a part of ������ ONE®, ������ Software Trust Manager offers a quick deployment of high volumes of certificates within minutes, plus the flexibility to deploy on-premises, in-country or in the cloud.

������ Software Trust Manager inherently only supports workflows aligned with current compliance requirements, and it supports key generation and protection so that you can be assured it always remains complaint, regardless of future policy changes. With these changes to code signing certificate management, it may be time to consider a modern managed signing service. See the ������ Software Trust Manager page for more information.