Last month, the Certificate Authority Security Council (CASC) officially announced their new minimum requirements for publicly-trusted Code Signing Certificates, which marks the first time Certificate Authorities (CAs) will have a set of standardized issuance and management policies designed specifically for Code Signing. You can read the full requirements in this document: Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates.

The requirements go into great detail about CA policies, covering topics such as certificate contents, revocation and status checking, verification practices, and many more. While CAs have been busy working behind the scenes to comply with all of these, you may be wondering what the changes mean for you. Let’s take a look at how some of the new requirements will affect the people actually using the certificates to sign code.

Private Keys Need to be Stored on Cryptographic Hardware

According to the CASC, one of the leading causes of Code Signing attacks is key compromise. That is, a malicious party gains access to the private key of a legitimate, “good” publisher and uses it to sign a malicious file, making it look trustworthy and increasing the chances it will be downloaded. Storing the keys on secure cryptographic hardware, such as a USB token or Hardware Security Module (HSM), significantly decreases the chance of key compromise compared to storing the keys locally (the most common method prior to the new requirements).

We’ve been recommending stronger private key protection for a while now and it’s been a requirement for Extended Validation (EV) Code Signing Certificates since they were introduced in 2014. Under the new guidelines, Code Signing Certificates must be stored on hardware such as a thumb drive, SD card, or FIPS 140-2 compliant USB token. Consistent with GlobalSign's commitment to provide secure Code Signing Certificates with strong assurance, all Code Signing orders after January 30, 2017 will include a FIPS 140-2 compliant USB token to store the certificate and protect the private key.

Standardized and Strict Identity Verification

The other leading cause of Code Signing attacks, according to the CASC, is issuing certificates to malicious publishers, who then use the certificate to sign viruses or malware. To prevent this, the new requirements outline specific precautions CAs must take before issuing, including:

• Strict identity verification about the publisher, including legal identity, address, data of formation and more
• Cross-checking against lists of suspected or known malware publishers, producers and distributors
• Maintaining and cross-referencing an internal list of certificates that were revoked because they were used to sign suspect code and certificate requests that were previously rejected by the CA

Many CAs already abide by most of these processes, but standardizing makes it harder for a bad publisher to shop around for a CA with weaker vetting procedures if they get rejected by someone else.

Reporting and Responding to Certificate Misuse or Suspect Code

In addition to trying to prevent the certificates from being issued in the first place, the new requirements also dictate that CAs operate a “Certificate Problem Reporting” system, by which third parties (e.g. anti-malware organizations, relying parties, software suppliers) can report, “suspected Private Key Compromise, Certificate misuse, Certificates used to sign Suspect Code, Takeover Attacks, or other types of possible fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”

CAs are then held to very strict standards regarding how to respond to these reported problems. For example, they must begin investigating within 24 hours and maintain 24x7 communication about any incidents. There are also strict guidelines and timelines regarding revocation, in the event malware or other abuse is suspected.

You can report a problem to GlobalSign here.

The new reporting systems mean even if a malicious publisher happens to pass through the verification process, their certificate can promptly be reported, investigated and revoked.

All CAs Must Offer Timestamping

Another new requirement that may be of interest to developers is that all CAs must now operate a RFC-3161-compliant Timestamp Authority (TSA) that is available for all Code Signing customers. This means a trusted timestamp can be included with each signature. (Note: GlobalSign has always provided timestamping for Code Signing customers.)

The main benefit of this is that the signature will not expire when the certificate does, which is what would normally happen without the timestamp. Instead, signatures can stay valid for the lifetime of the timestamp certificate, which can be as long as 135 months, as specified by the requirements.

Another scenario that benefits from timestamping is the event of a key compromise and subsequent certificate revocation. For example, if your key was used to sign legitimate code, but then later was compromised and used to sign malicious code, you could set the revocation date to be between the two events. This way, your legitimate code would continue to be trusted, but the malicious code would not.

A Safer Future for Code Signing

The new standards and requirements are an essential step toward cutting down on Code Signing attacks. Microsoft is the first applications software vendor to adopt the guidelines and will start enforcing them February 1, 2017. All GlobalSign Code Signing Certificates will be in compliance with the new requirements before then.

If you have questions about any of the changes, please don’t hesitate to contact us. We also recommend this white paper from the CASC for more details on code signing standards and best practices: Code Signing White Paper: What It Is, Best Practices, and Why It’s Important.