2017 Brings New Code Signing Standards that Aim to Stop Bad Actors


Application code signed with certificates has become ubiquitous among application developers, thanks to Certificate Authorities (CAs) seeking to bring integrity to applications. Simply put, code backed by a certificate is supposed to guarantee the software has not been altered since it was signed.

However, bad actors have usurped the validity of signed code by compromising the private keys behind those certificates or by falsifying information to request a valid certificate. Either way, that spells big trouble for those looking to avoid malicious code or other nefarious activities caused by what was thought to be a legitimate piece of application code.

In other words, malicious code can now enter an enterprise by masquerading as legitimate, safe code, creating a significant problem that digitally signed code was designed to prevent. What’s more, those bits of digitally signed code is growing exponentially, backed by Ponemon Institute research that shows 58% of security teams need to better secure their keys and certificates.

With the realization that code-signing certificate misuse is on the rise, organizations including Certificate Authorities (CAs) and application software suppliers (most notably, Microsoft) came together to develop a new standard, which goes into effect February 1, 2017. The new standard, which is defined as the Minimum Requirements for the Issuance and Management of Publicly Trusted Code Signing Certificates, requires that all CAs in the Microsoft Trusted Root Certificates must be adhered to, if they issue code signing certificates.

CA Security Council member, Bruce Morton, explains “Minimum Requirements for Code Signing will increase Internet security by setting a new bar to prevent private keys from being compromised. The requirements will also provide a better mechanism to have code signing certificates revoked limiting the proliferation of malware.” The result will benefit application software suppliers, online businesses, and of course, software users globally.

Morton, who is also Director, Certificate Technology and Standards at Entrust Datacard, adds “The major problem with code signing is attackers can sign malware with a valid code signing certificate which is trusted because the code can be authenticated.” Morton added “The issue is due to two problems. The first of which is when dishonest authors or publishers, request a code signing certificate. The second being when honest authors and publishers have their private signing key compromised.”

Morton also explained how the new standards address those issues, as well as others, by placing more emphasis on the critical elements that surround the validation of code signing, including:

  • Identity Verification: Verification of an organization’s identity has taken advantage of the CA/Browser Forum Baseline Requirements, which has been proven to be reliable since implementation in 2012. Vetting of individuals includes review of government-issued photo ID or having the certificate request signed using a personnel certificate which has been validated using accepted validation processes. The applicant’s identity validation process must use a high-risk request process. The CAs are to check databases of known or suspected producers, publishers or distributors of suspect code that have been developed by anti-malware organizations and application software providers. CAs must also maintain and check an internal database that lists revoked certificates used to sign suspect code and previously rejected certificate requests.
  • Key Compromise: Key compromise has been addressed by first setting a minimum key size to: 2048-bit RSA or to ECC curves NIST P-256, P-384 and P-521. The maximum validity period for a code signing certificate will be 39 months with the goal of changing the key with every certificate renewal. Private keys must now be protected on hardware or kept in a device separate from the host of the signing function. Hardware encryption can be done in a FIPS 140-2 Level 2 certified hardware security module or Common Criteria equivalent, or on a trusted platform module (TPM). Hardware encryption is mandatory if the publisher has a history with takeover attacks. That is, if the publisher’s key has been compromised by means of fraud, theft, malicious or illegal conduct, then the key must be encrypted. A method for the publisher to mitigate key compromise is to use a signing service. In this case, a signing authority will generate and manage the signing key, typically in a hardware security module. Publishers requesting to sign code must have multi-factor authentication. The result is the keys are kept protected and are not available to be shared in the publisher’s environment.
  • Certificate Revocation: In the event of suspect code being signed, the code signing certificate will have to be revoked. The publisher may find out that their key has been compromised and will directly request revocation. In other cases, other parties such as an application software supplier may find signed malware. In this case, the software supplier can contact the CA directly and request the certificate to be revoked. The standard provides procedures for investigation and CA response times. Revocation information must be provided by OCSP and may also be provided by CRL. OCSP responses must be updated at least every four days and the response must expire within 10 days.
  • Time-stamping: CAs are required to provide a Time-Stamp Authority (TSA). Time-stamping code signing signatures provide the exact time of signing. At the time the code signing software is performing the signature, it will send a token to the TSA. The TSA will add a time-stamp, hash and sign with its private key. The time-stamp signature can be validated with the time-stamp certificate and the signing time will be known. A great advantage of using time-stamps is gained during code signing certificate revocation. For instance, the code signing keys may have been used to sign valid code, then were used to sign malware. The code signing certificate must be revoked to remove trust from the signed malware. But what about the valid code? The standard allows the publisher to choose a revocation date enabling the publisher to choose a revocation date after the valid code was signed and before the malware was signed. All code time-stamped before the revocation date would be trusted, but not the code that followed the date. In addition, the code signature would be valid until the time-stamp certificate has expired. The new stand provides requirements for time-stamp CAs, time-stamp certificates and TSAs. Included in these requirements is a maximum validity period of 135 months for time-stamps. This should allow code signing signatures to remain valid for more than 10 years.

The requirements outlined above should go a long way towards preventing malicious code from benefiting by usurping CA requirements, and should bring a quick end to falsely signed code.