Tag: Code Signing certificates

What is Code signing?

In the recent past, many technology firms are being targeted by hackers to tamper and corrupt the source code. These attacks heavily impact brand reputation and also leads to huge losses for firms victimized. To tackle this scenario, Code Signing technique can be used for safe guarding the code integrity and to provide authenticity of the author to the end user by providing digital signatures. Code Signing provides secure and trusted distribution of software preventing tampering, corruption and forgery. Code signing improves end-user confidence in software/code integrity and sender authenticity.

To explore the “Top 5 benefits of Code Signing“, please go through the blog article: www.encryptionconsulting.com/code-signing-top-5-benefits

Code Signing Architecture:

Code Signing Architecture provides a detailed explanation on how the Code Signing process works along with its components. Mentioned below are the four important differentiating components in the Code Signing Architecture.

• Code Signing System (CSS)
• Certificate Authority (CA)
• Time Stamp Authority (TSA)
• Verifier

These four components together will achieve the full cycle completion of the code signing process. Each component has a defined working process which is discussed in detailed below.

Code Signing System (CSS):

The Code Signing System (CSS) is the first and important component of Code Signing Architecture. Code signing system signs the submitted code using digital signature and authenticates the author. The digital signature is generated by CSS using private signing key and certificates. It is highly important to secure the private signing key and certificate from misuse and unauthorized access.

Certificate Authority (CA):

Developers or Source issuing code should use certificates from authentic certificate authorities (CA) as the certificate enables the process of authenticating the source. Certificates issued by authentic certificate authorities must comply with standard certificate policies such as NIST Interagency Report 7924 which specifies requirements to be followed by CAs while issuing certificates. Also, the developer requesting the certificate from authentic CAs has to provide supporting validation documents which would be verified before providing certificates. CA would follow guidelines mandated by standard agencies such as CA security council, CA/Browser Forum etc.

Time Stamp Authority (TSA)

An optional but important component in Code Signing Architecture is Time Stamp Authority (TSA). Time stamping preserves the source time when the code was signed and allows software to be accepted by the OS and other client device platforms even after the certificate expires. Signed software is validated with the source time when the certificate was signed rather than the current time. Hence, it is always advisable to use Time stamping technique while performing code signing. Digital signature signed code is sent to TSA for time stamping. TSA applies its own signature along with the valid source time stamp. TSA is independent from Code Signing System and synchronizes its clock with an authoritative time source.

Verifiers

End user using the code digitally signed by the publisher first initiates the process of verifying the signature. In general, verifiers are used to perform this step of validating the signatures and time stamp (if any). Verifiers leverage trust anchors to validate the signature on the signed code. Trust anchors are usually public keys of root certificate authorities (CA) installed securely on the verifying platform. In general, root CAs use standard architecture such as X.509 standard. If your organization is looking for implementation of Code signing, please consult info@encryptionconsulting.com for further information

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.