Code Signing is a cryptographic process to digitally sign executables and scripts. The signature confirms the software author or publisher’s identity, and provides integrity by guarantying the software has not been altered since it was signed. The goal is to help the end user make the correct yes or no decision.
Certification authorities (CAs) have been providing code signing certificates since the late nineties. The CAs have individually created their own processes and standards for verification, issuance and management of code signing certificates. 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. The issue is due to two problems: 1) dishonest authors or publishers request a code signing certificate and 2) honest authors and publishers have their private signing key compromised. These two problems were the catalysts for a project between the CAs and application software suppliers (including Microsoft) to develop the new standard, Minimum Requirements for the Issuance and Management of Publicly Trusted Code Signing Certificates. Through development, the draft standards were made available for public review. The result is a publication which all CAs in the Microsoft Trusted Root Certificates must adhere to by February 1, 2017 if they issue code signing certificates. Identity Verification Verification of organizations 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. The CA 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. Publisher 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. Moving Forward 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.