EV Code Signing certificates are based on the Extended Validation (EV) Code Signing Certificates guidelines developed by the CA/Browser Forum. The guidelines combined the EV standard for validation with specific code signing components such as protecting private keys with hardware and providing time-stamp services.
The demand for EV Code Signing certificates is growing thanks to the recent release of Windows 10. By October 29th, 2015 (90 days after release) all drivers provided to Microsoft must be submitted with a signature from an EV Code Signing certificate. Microsoft will trust the submission as the EV Code Signing certificate will prove that the publisher’s identity has been determined and the certificate issuance authorized.
EV Code Signing certificates are similar to standard Code Signing certificates, but have some distinct advantages:
- Standard Based – EV Code Signing certificates are issued based on an industry standard with input from public certification authorities (CAs) and browser vendors.
- Rigorous EV Validation – Code publishers that want to use an EV Code Signing certificate have to meet the EV verification and authentication requirements. Rigorous EV validation means EV Code Signing certificates are less likely to be issued to an attacker.
- Private Key Size Minimum – EV Code Signing certificates must have a minimum key size of 2048-bit RSA. This key size is recommended for signing through 2030.
- Private Key Protection – EV Code Signing certificate private keys must be generated and managed in a hardware security module (HSM). Most CAs which issue EV Code Signing certificates will recommend an HSM which meets the minimum of FIPS 140-2 Level 2. The advantages of HSM protection is it keeps the keys from copied and distributed, and requires two-factor authentication for signature.
- SHA-2 Certificate Hashing – EV Code Signing certificates are hashed using the SHA-2 hash algorithm which mitigates attacks such as hash collision, preimage and second-preimage.
- Revocation – The CAs have standardized reasons as to why they must revoke an EV Code Signing certificate. In addition, Microsoft will monitor for harmful signed code. As such, Microsoft can also require a certificate to be revoked to mitigate malware.
- Revocation Longevity – In the event that an EV Code Signing certificate gets revoked, the CA must provide the revocation status for a minimum of 20 years. A long period revocation status will prevent signed malware from being used in the future.
- Time-stamp Authority – CAs which issue EV Code Signing certificates must also provide a time-stamp authority (TSA) which meets RFC 3161. The TSA will allow the publisher to time-stamp the signatures of their code. The time-stamp can be used to support the longevity of the code in the event that the EV Code Signing certificate is revoked after signature.
- Application Reputation – Publishers can develop application reputation to reduce dialogue boxes with Windows using SmartScreen Filter. Code signed with an EV Code Signing certificate will immediately establish reputation.
- Security of Windows 10 – 90 days after the release of Windows 10, Microsoft will require both kernel mode and user mode drivers be signed using an EV Code Signing certificate. This will help mitigate signed malware for future deployments of Windows.
As we move forward, Publishers should consider the following when developing Windows drivers:
- Obtain an EV Code Signing certificate for signing Windows 10 drivers. The EV Code Signing certificate can also be used to support driver signing for Vista, Windows 7, Windows 8 and Windows 8.1.
- Obtain an account through the Windows Hardware Developer Center Dashboard Portal.
- Submit all signed drivers through the Windows portal. The portal will sign the drivers the right way to ensure they work for Vista, Windows 7, Windows 8 and Windows 8.1.
Learn more about by downloading our “Code Signing: Why Devolpers Need to Digitally Sign Code and Applications” whitepaper.