Code Signing Certificates

Introduction

Code Signing is the process of applying a digital signature to a software program intended for distribution over the internet. Code signing helps to verify that the software is authentic i.e. from the original developer, and also helps to validate that the code has not been tampered with by an attacker while in transit e.g. by the insertion of malicious code or malware. The digital signature used for code signing is contained in a digital certificate called the code signing certificate.

Code Signing Certificates

Like any other digital certificate, code signing certificates are based on the X.509 standard and also need to be signed by a trusted third party such as a Certificate Authority (CA). However, code signing certificates cannot be used interchangeably with other certificates such as SSL certificates. The main reason for this is that as per the X.509 specification, any digital certificate contains a “Key Usage” field, which indicates the intended use of the certificate and is filled in at the time the certificate is generated. Additional information regarding the use of the certificate can also be contained in the “Extended Key Usage” extension. The X.509 specification mandates that a certificate cannot be used other than for it’s intended purpose. For example, an SSL certificate has the key usage field set to “Digital Signature” whereas a code signing certificate has the key usage field set to “Code Signing”.

While X.509 provides the specification for the certificate format, the technology implementations to generating certificates will vary by vendor. For example, Authenticode is code signing technology from Microsoft that helps developers sign applications for the Windows operating system. Authenticode certificates are used to sign files with extensions such as .exe, .dll, .ocx, .cab, and .xpi. Similarly, Apple code signing certificates are used to sign applications for iOS, Java code signing certificates are used to sign .jar files for the Java Runtime Environment (JRE), and Adobe AIR certificates are used to sign .air or .airi files.

The process of obtaining a code signing certificate is similar to other digital certificates. Any organization that wishes to publish software for distribution over the internet applies for a code signing certificate with a CA, submitting their public key and other organization information. Note that the public-private keypair needs to be separately generated, like in the case of any digital certificate. The CA validates the developer (organization) applying for the certificate, signs the certificate as proof of validation, and issues the same to the developer or software publisher. The certificate that the CA issues includes information such as the publisher identity, the public key of the publisher, the certificate validity period, the digital signature of the CA, and other details.

Types of code signing certificates

Self-signed certificates:
It is possible for software publishers to generate their own self-signed certificates. In such cases however, the signature verification process during software installation will generate a warning that the software was created by an unknown publisher. Self-signed certificates could be used for testing and local development of software, before it is made generally available for public distribution. However, self-signed certificates should not be used for production software being distributed to end users.

For public software distribution, CA issued certificates are the best option. There are two types of CA-issued code signing certificates based on the type of validation.

Standard Validation Certificates:
This is the default type of code signing certificate and involves basic validations of the publisher or developer by the CA. To be issued a standard code signing certificate, software publishers need to meet some basic requirements such as minimum key length, maximum validity period, and time stamping for digital signatures.

Extended Validation (EV) Certificates:
EV code signing certificates involve the highest levels of validations and vetting of the software publisher by the CA and are usually issued on a hardware token for additional levels of security. To be issued an EV certificate, apart from the basic requirements of standard certificates, software publishers also need to conform to much more stringent requirements – for example maintaining private keys in a Hardware Security Module (HSM) that is compliant with FIPS (Federal Information Processing Standards) 140 Level-2 or equivalent.

Certificate Expiry and Time Stamping

Like any digital certificate, code signing certificates also expire at the end of their validity period. On expiry, the signature will not be validated, and the software may cease to install or execute properly, although nothing is wrong with the software itself. This issue is addressed by the process of time stamping, in which a time stamp is applied to the code at the time of signing the file. This is usually done through another trusted third party called a Time Stamp Authority (TSA), to prove the validity and authenticity of the time stamp. The presence of a time stamp ensures that the software continues to run even though the code signing certificate has expired, giving the publisher time to renew the certificate.

Certificate Revocation

We have seen in earlier articles that the strength of Public Key Infrastructure (PKI) systems depends on how the private keys are managed and secured. If the private key for any digital certificate is compromised, the certificate needs to be invalidated, or revoked by the CA which issued the certificate. Certificate revocation is critical in the event of a breach: it ensures that end users are alerted that the certificate can no longer be trusted, discouraging the download, installation and further usage of the software. Certificate revocation is done by including the revoked certificate in a Certificate Revocation List (CRL), or by updating the certificate status using the Online Certificate Status Protocol (OCSP). Further details about CRLs and OCSP will be covered in a later article.