You’ve probably noticed when surfing the web, some browsers show a special indicator like a green bar containing the company name, or in some instances, completely replacing the URL with the company name.
This is a result of Extended Validation (EV) certificates—a type of digital certificate that includes identity information of the entity who owns the certificate (in this case a website owner), issued by a Certificate Authority (CA) after extensive validation and rigorous vetting of the entity requesting the certificate.
Born out of a need to provide a high level of trust in the legitimacy of websites, EV certificates are also used today to enable trust in distributed code.
Let’s review a few concepts:
- Code signing is used for secure and trusted digital distribution of software. Code signing is simply a mechanism to validate the identity of the publisher of a program or software download and that it has not been corrupted and tampered with after it was signed by the publisher.
- When software developers want to sign their code, they need to generate a code signing public/private key pair. They then give the public key and the organization’s identity information to a trustworthy CA. The CA verifies the authenticity of identity information and then issues the code signing certificate to the developer.
- Developers use the private key—which must be kept highly protected—to sign code, while the associated certificate can be used by anyone receiving the code to validate the code source and integrity.
In this blog post, we’ll discuss the different validation levels of code signing certificates and focus on extended validation (EV) certificates, which provide the highest degree of validation, and when they are needed and how to address associated security requirements.
Code Signing Certificate Validation Levels
There are a few different kinds of code signing certificates with varying validation levels:
- Self-signed certificates – while externally distributed code is typically signed with certificates issued by a public CA, self-signed certificates can also be used for code signing. These certificates provide the lowest level of validation because they are issued by the organization using their internally managed CA, rather than by a trusted third party. Self-signed certificates may be appropriate for internal tracking and management of code developed within the organization. For example, certificates issued to each development team or individual developer may be used to sign pre-release code components, for internal tracking and analysis purposes.
- Organization Validated (OV) certificates – issued by a trusted public CA, following a basic registration and evaluation of the legitimacy of the requesting organization.
- Extended Validation (EV) certificates – issued by a public CA, following a rigorous validation of the requesting organization, as well as required proof of security measures to protect the certificate from compromise.
In general, code signing certificates with higher validation levels require more time and effort to obtain, and cost more to buy, manage and protect. Their key benefit is that they provide a greater degree of confidence and trust in the signed software, thus improving and simplifying the experience for the software’s consumers.
Brief History Background of EV Certificates
The concept and guidelines for EV certificates was developed by the CA/Browser Forum. The first version of the guidelines was ratified in 2007, with the purpose of enhancing web security through improved issuance and management of SSL/TLS certificates for website owners.
As described in the CA/Browser Forum EV Guidelines, “The primary purposes of Extended Validation Certificates are to: 1) identify the legal entity that controls a Web or service site, and 2) enable encrypted communications with that site. The secondary purposes include significantly enhancing cybersecurity by helping establish the legitimacy of an organization claiming to operate a Web site, and providing a vehicle that can be used to assist in addressing problems related to distributing malware, phishing, identity theft, and diverse forms of online fraud.”
In 2012, CA/Browser forum passed the first version of guidelines for EV certificates for code signing.
When should EV certificates be used for code signing?
EV certificates are typically used when:
- Using a high-end, secure and trusted signature is important to the organization – e.g. for brand reputation purposes.
- Signing Microsoft kernel mode driver packages – Everyone that develops drivers for Microsoft environments must use EV certificates (Microsoft mandates this for all platforms starting from Windows Vista).
- Signing applications for Windows desktop environments – when signed with an EV certificate, an application gets automatic reputation from Microsoft Smartscreen and thus does not get tagged as suspicious when downloaded. (In other cases, the user gets a pop-up with a warning message like the one below.)
Meeting the Key Protection Requirement
As a general rule, certificates are only good if their private keys are truly secure. If a code signing private key ends up in the wrong hands, bad actors can sign software as if they were the developer, and the public key will verify the (false) identity.
That being said, as mentioned above, EV certificates are harder to obtain than other certificates. They require rigorous proof of an organization’s identity and validity and added security measures to protect the certificates from compromise after they are issued. One of these measures is the requirement that keys be generated and stored in a FIPS 140-2 Level 2 or higher validated cryptographic module.
Signing Authorities shall protect private keys in a FIPS 140-2 level 2 (or equivalent) crypto module. Techniques that may be used to satisfy this requirement include:
a. Use of an HSM, verified by means of a manufacturer’s certificate;
b. A hardware crypto module provided by the CA;
c. Contractual terms in the subscriber agreement requiring the Subscriber to protect the private key to a standard equivalent to FIPS 140-2 and with compliance being confirmed by means of an audit.
The traditional options for meeting this key protection requirement include:
- Hardware Security Module (HSM) – a well-accepted and secure method of key protection, however it does pose usability and operational limitations – for more details see our previous blog post exploring varied secure code signing implementation approaches.
- Hardware crypto module (typically USB token or smartcard) delivered by the CA – again provide high security, but the need to wait until the hardware is physically delivered after purchasing the certificate means delays that may impact a company’s ability to release products and services, and administrative headache. Also, tokens held by employees are harder to manage, and may cause logistical challenges for example when an employee authorized to sign software leaves the organization.
A new option, a virtual Hardware Security Module (vHSM) answers the security requirement for EV certificates with a FIPS 140-2 level 2 validated, pure-software virtual HSM, without the need for hardware.
If your organization is considering code signing with EV certificates to meet security, operational, or UX needs, you are probably also considering how to address the EV certificate private key security requirement. In order to choose the best private key protection method, here a few questions you should ask:
- How many people need access to the private keys and where are they located? For example, one local team versus multiple globally disparate teams of signers.
- How often will you need to onboard new employees/revoke employees that have left?
- Are time lags due to the wait to receive cryptographic hardware from the CA impacting your ability to release code on time?