WHAT IS CODE SIGNING?
Code signing is the process of digitally signing executable files and scripts using a signing tool and a digital certificate. This process is based on a technology called public key infrastructure (PKI).
Signing code requires a dedicated signing tool such as Microsoft’s SignTool, Java’s Jarsigner, or even OpenSSL depending on the type of file to sign. The signature itself is a cryptographic operation that binds the content of the file to a digital certificate.
Code signing protects your company, partners, and end-users from software tampering when downloading executable program files — especially those from unsecured channels like the internet. As a code signing solutions provider, Entrust can help you implement efficient, high assurance code signing solutions that protect your business and your customers from attacks that forge or modify applications.
What is the Purpose of Digitally Signing Code?
There are two main reasons for digitally signing code:
- To provide users with the identity of the organization publishing the signed file
- To provide a means to verify the integrity of the file – that is to say, that it was not corrupted or maliciously altered since it was signed
What are Code Signing Certificates?
Code signing certificates are used by software developers to digitally sign applications, drivers, executables, and software programs. This verifies for end-users that the code has not been compromised or hacked by a third party. In order to bind public keys with their associated user (owner of the private key), public key infrastructures (PKIs) use digital certificates.
Code Signing Best Practices
Best practices for code signing certificates include:
- Control access to private keys
- Protect private keys with a FIPS-140-2 Level 3 Hardware Security Module (HSM)
- Time-stamp code
- Understand the difference between test-signing and release-signing
- Authenticate code to be signed
- Distribute the risk to multiple certificates
- Revoke compromised certificates
Entrust offers a full range of code signing certificates and a comprehensive method to manage them, including TLS/SSL certificates, secure email certificates, document signing certificates, and mobile device certificates.
How Does Code Signing Work?
To implement code signing, the software publisher needs to generate a private public key pair and submit the public key to a certificate authority, along with a request to issue a code signing certificate. The certificate authority verifies the identity of the software publisher and authenticates the publisher’s digitally signed certificate request. Once this vetting and key-verification process is successfully completed, the certificate authority bundles the identity of the publisher with the public key and signs the bundle. This creates the code signing certificate.
Learn more about implementing code signing in this white paper.
Methods for Digitally Signing
Various application platforms support code signing and provide different tools to perform the signing. Below is a list of the more common code signing types:
- Adobe AIR
- Apple Mac OS X Developer Library
- Firefox XPI
Steps for End-Users
There are five simple steps users should take to determine whether software can be trusted:
- Check to see if you were planning to install the software.
- Check the file name to see if it indicates the software you were planning to install. In the previous example, the user is installing Adobe Reader 10, which the name seems to indicate.
- Check the publisher’s name to see if it matches who you think wrote the software. This may be difficult as the software download site may be different than the publisher’s site.
- Check the code signing certificate to see if the publisher’s name is in the certificate.
- Check to see if the certificate was issued by a publicly trusted CA.
Code Signing Features
Organization validated (OV) certificates display the organization and location on the certificate. They do not support Windows kernel mode signing. Extended validation (EV) certificates display the jurisdiction and type of organization in addition to organization and location. EV certificates also facilitate Windows kernel mode signing for Vista, Windows 7, Windows 8, Windows 8.1, and Windows 10. Choosing the code signing certificate solution that is best for your organization’s needs is complicated, but Entrust is here to help.
Code Signing Solutions
Entrust’s portfolio of code signing solutions combines tamper-resistant nShield hardware security modules (HSMs) with the Code Signing Gateway solution from Entrust Professional Services. The Code Signing Gateway manages authorization workflow, accepts requests, notified approvers via email, manages time-outs, acknowledges approvals, logs activity, and delivers signed code to the staging area. The solution utilizes Entrust nShield HSMs and the root of trust—securing all signing keys in a FIPS 140-2 certified HSM. This prevents the potential loss of valuable signing keys—the keys to your code’s authenticity and integrity. This enables customers to sign their own software code. Features include:
- Microsoft smartscreen filter
- Third-party integrations
- Unlimited integrations
- Identified publisher status
- Warning box reduction
Entrust code signing solutions are backed by our extensive expertise in code signing best practices and standards of due care.
How does code signing provide the identity of the organization publishing the signed file?
A digital signature creates a cryptographic bond between a file and a digital certificate, the latter representing an organization. You can think of the certificate as a digitized rubber stamp; it contains details about the organization such as its legal name, email address, physical address, and country. Signing code therefore corresponds to applying a digital stamp to the code, which will display the organization’s details.
The details of a code signature can be checked each time the signed file is opened. In most cases, this is done automatically by operating systems, showing you the name of the organization contained in the certificate used for the signature.
Opening a digitally signed executable file on Microsoft Windows 10.
How does code signing provide a means to verify the integrity of the file?
Every code signature is created based on the content of the file. Without going into too much technical detail, a signing tool will calculate a condensed version of the file to sign – we call it a hash – and will sign this condensed version using the digital certificate provided. This signed hash is then embedded into the file in a place dedicated to hosting digital signatures.
Once you start distributing the signed file, operating systems and relevant applications will detect the presence of the signature. They will automatically calculate the hash of the file (without including the signed hash in the calculation) and compare it to the signed hash embedded in the file. If they are both the same, the verification passes. If the calculated hash is different than the signed hash, it fails. A failed verification means the content of the file has been modified after the signature was performed (as a result of an error or a malicious intent).
The reliability of this mechanism is based on the strength of the algorithm used to calculate the hash – the longer the hash, the better. One of the current standards used is SHA-256, an algorithm that produces 256-bit hashes.
What are the benefits of code signing?
There are several benefits of digitally signing code:
- You increase user confidence in your software. Signed code proves that the file not only belongs to the expected organization, but also guarantees that it hasn’t been tampered with (to inject malware, for example).
- You increase your reputation as a software developer. The more signed software you publish, the better your reputation will be. For example, Microsoft code signs their software to help ensure their customers are downloading the right files. Signed software is also helpful to antiviruses and malware detectors. If you sign your software, they’ll be able to flag suspicious, unsigned versions of your software.
- You avoid warnings and blocks from operating systems. They indeed expect all software publishers to sign their executable files. If you publish unsigned software and your users launch it, there’s a very good chance they will see a warning message from the operating system. MacOS is known for refusing to launch unsigned files, forcing the user to bypass security to proceed with the installation.
A warning message for unsigned software installation on Microsoft Windows 10.
A blocking message for unsigned software installation on MacOS.
For IoT devices using firmware, one of the best ways to ensure safe updates is to build your firmware with a requirement to only accept updated files that are signed using your internal (private) code signing certificates.
Read the white paper: The Importance of Code Signing
What is the difference between public code signing and private code signing?
Code signing certificates are issued by certification authorities (CAs), which are certificate-issuance engines. Most organizations own one or several “private” (internal) CA(s) and can issue all sorts of digital certificates, including code signing certificates. However, the signatures generated with these certificates are only trusted within the organization’s internal environment.
While this is perfect for many use cases involving internal applications and IoT, using a private CA doesn’t work when you plan to distribute your code outside of your environment, where your CA is not recognized.
Code signing certificates issued by publicly trusted CAs, such as Entrust’s, will generate signatures that will be recognized and trusted by all major operating systems and applications globally. Public CA organizations (also simply called public CAs) such as Entrust follow strict certificate issuance standards, must go through regular audits, and must apply to become trusted by each major operating system or application provider such as Microsoft, Apple, Google, or Mozilla.
When faced with signed code, operating systems and applications check the issuing CA of the certificate used for the signature. If the issuing CA is not in their “trust list” (also called root store), the signature won’t be trusted and the verification will fail. Hence the importance of getting publicly trusted code signing certificates when publishing software to the internet.
What is the difference between OV code signing and EV code signing?
While organizations are free to include any details they want in their private code signing certificates, public certificates must only contain information that has been thoroughly verified by the public CA before issuing the certificate.
A public CA can issue two categories of publicly trusted code signing certificates: OV and EV. These categories correspond to the level of verification of your organization that is performed by the public CA before issuing the certificate, and also the storage requirement for the certificate (specifically, for its private key).
- OV (Organization Validation): This is a standard validation method of an organization performed by CAs. It involves company checks (Does the company exist? Is it in good standing? Where is it located?) and a verification of the person requesting the certificate on behalf of the organization (Are they indeed an employee of the organization?).
- EV (Extended Validation): As the name suggests, this is an extended validation process that requires further verification of the organization details as well as the certificate requestor. The CA will require more information and more paperwork, and will proceed with one or several calls to the organization and the requestor before issuing the certificate. Secure storage is mandatory for EV code signing certificates, which means you will either need a secure USB token or a hardware security module (HSM) to store the certificate and its private key.
Entrust can supply USB tokens or nShield HSMs for all code signing orders, whether they are OV or EV certificates.
Learn more about code signing HSMs.
How does timestamping work with a code signing certificate?
In the context of a code signature, timestamping is the process of applying a digital timestamp, which includes the exact date and time, to a code signature.
Timestamping is a crucial yet often forgotten step of code signing. Signatures indeed have an expiration date, which corresponds to the expiration date of the code signing certificate used for the signature. An expired signature will lead to a failed verification when the signed code is launched, which would lead to warning messages and even code being prevented from running.
Private certificates can have a very long lifetime (10+ years) if needed, which is often enough because the signed code might no longer be used after such a long period. But public code signing certificates are currently valid for a maximum of three years, and there’s a very good chance your code will still be available by the end of this period. Timestamping a code signature will give it another 9-10 years of validity (depending on the validity period of the timestamping certificate used). And you can reapply a new timestamp when the current one is about to expire to further extend the validity of your code signature and avoid any warnings/blockings.
Timestamping is also useful in case you need to revoke your code signing certificate if it’s been compromised. Revocation can be backdated to the date and time you believe the certificate was compromised. If all your signatures have been timestamped, then only the signatures generated before the revocation date will remain valid. Any code signature without a timestamp will become invalid when the certificate is expired or revoked.
Timestamping can be done using private timestamping certificates from an internal CA. But for code that needs to be shared externally, you must use a public timestamping service, which will be recognized and trusted by all major operating systems and applications. Most if not all public CAs, including Entrust, offer a public timestamping service, available via a dedicated URL.