The Certificate Authority Security Council has released new Minimum Requirements for Code Signing for use by all CAs (Certificate Authorities). This represents the first-ever standard for code-signing, and the advocacy group hopes the guidelines will improve web security by making it easier to verify software authenticity.
The new Minimum Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates outlines specific steps CAs and individual software companies must perform to ensure code-signing certificates are not abused. It addresses "user concerns about the trustworthiness of signed objects and accurately identifying the software publisher," the working group wrote in the requirements document.
While the requirements are intended primarily for CAs that can issue code-signing certificates (including root CAs publicly trusted for code signing and all other CAs part of the root CA's validation path), software companies and developers have to comply with some of the requirements if they are going to work with a standards-compliant CA. Not meeting those requirements can mean a code-signing certificate will not be issued, or an existing one will be revoked.
Code signing refers to using certificates to digitally sign executables and scripts in order to verify the author's identity and, more importantly, that the code has not been altered or corrupted since it was signed. Several attack campaigns have stolen legitimate code-signing certificates to sign malware, making it possible for the malicious code to bypass security defenses. There are 25 million pieces of malware enabled by code-signing certificates, and stolen code-signing digital certificates are sold everyday on underground markets for more than $1,000 each, said Kevin Bocek, vice president or security strategy and threat intelligence at Venafi. "Code signing is critical to every mobile device and computer we touch," Bocek said.
Microsoft has already adopted the minimum requirements and will require all CAs issuing code-signing certificates for the Windows platform to adopt the minimum requirements starting Feb. 1, 2017.
Because CAs have different rules for how they issue and revoke code signing certificates, both developers and cybercriminals could game the system, Bocek said. Without any standards in place, it was possible to get accepted one CA even after already being rejected by a different CA. The variance made it difficult to know which code-signing certificate could be trusted. With the guidance, each CA has some leeway in developing its own process for how to issue and revoke certificates, but the underlying requirements are the same from CA to CA.
Along with providing all the information necessary for the CA to verify the identity of the software company (or developer) in order to issue the certificate or sign the code object, organizations are responsible for making sure the private key is generated, stored, and used in a secure environment with controls to prevent the keys from being stolen or misused. The CA has to provide guidance on how to protect the keys, but it's up to the organization do it in a way that matches the guidelines:
- Protecting the private keys: Organizations have to use either a trusted platform module to generate and secure key pairs, a FIPS-140-Level-2 Hardware Security Module or equivalent (such as Common Criteria EAL 4+), or another type of hardware storage token, such as a USB key or a SD card. The tokens have to be kept physically separate from the device hosting the code-signing function until the moment it is actually needed for a signing session.
- Securing the code signing computer: The computer used for signing cannot be used for web browsing, and it must be periodically scanned by regularly updated security software for possible infections.
- Picking a trusted third-party: Organizations that use a third-party signing service to sign objects with their private keys should make sure the signing service has enabled multi-factor authentication to access and authorize code signing. If the service doesn't, it's not compliant with the new requirements and should be a serious warning flag.
- Transporting the key securely: If the CA or the signing service is generating the private key on behalf of the organization, the private keys may be transported outside of the secure infrastructure. In those cases, the key must either be transported "in hardware with an activation that is equivalent to 128 bits of encryption, or encrypt the Private Key with at least 128 bits of encryption strength," according to the standard. That could mean using a 128-bit AES key to wrap the private key, or storing the key in a PKCS 12 file encrypted with a randomly generated password "of more than 16 characters containing uppercase letters, lowercase letters, numbers, and symbols."
- Using strong keys: The CA will not issue the code-signing certificate if the requested Public Key does not meet modern security requirements or if it has a known weak Private Key (such as a Debian weak key).
The CA will have to spell out all of the new requirements in the subscriber agreement, and it has to keep complete records to show both the organization and the CA is following the rules. Under the agreement, the organization cannot request a code-signing certificate if the public key in the certificate is -- or will be -- used with a non-code signing certificate. The organization also has to commit to protecting against the theft or misuse of the private key, and to immediately request the CA to revoke the certificate if the private key is compromised or used to sign malicious code.
If the private key is compromised due to an attack, the CA doesn't have to issue a new or replacement certificate until it is satisfied the organization has improved its security protections.
"Documentation of a Takeover Attack may include a police report (validated by the CA) or public news report that admits that the attack took place. The Subscriber must provide a report from an auditor with IT and security training or a CISA that provides information on how the Subscriber was storing and using Private keys and how the intended solution for better security meets the guidelines for improved security," the standard says.
Currently, if the CA rejects the request for a new or replacement certificate, the organization can apply with another CA. However, if the second CA is following the new requirements, then it will be checking "at least one database containing information about known or suspected producers, publishers, or distributors of Suspect Code, as identified or indicated by an Anti-Malware Organization and any database of deceptive names" before issuing a certificate. If the second CA sees that the organization has been implicated in signing bad code, then the idea is that it will also push back and reject the application, just like the first CA.
"The CA must not issue new certificates to organizations that have been the victim of two Takeover Attacks or where the CA is aware the organization is not storing the private keys correctly," the standard says.
The standard also has other requirements about the CA setting up a Timestamp Authority and how the timestamp certificates should be used, such as letting code signatures to stay valid for the length of the period of the timestamp certificate.
The standard was released by the Code Signing Working Group, part of the CA/Browser Forum, which is a voluntary group of CAs, browser makers, and software vendors that use X.509 v.3 digital certificates in their applications. The Code Signing Working Group consists of Comodo, DigiCert, Entrust, GlobalSign, Izenpe, Microsoft, Symantec, SSC, and WoSign. The China-based WoSign is the same CA that was recently marked as untrusted by Mozilla, Apple, and Google for multiple problems in how SSL certificates were issued.
"The CA Security Council guidance on code signing is long overdue," Bocek said. "New methods of certificates to detect fraud and misuse such as Certificate Reputation will also see increased adoption as misuse of code signing certificates gets more and more attention."
The requirements have not been adopted by the CA/Browser Forum, but will instead be improved and maintained by the CA Security Council.