Code Signing – A Manager’s Guide

How did code signing become important?

Let’s look at three interesting trends that have emerged in software development over the last decade.

One is that the number of companies that develop and release software has increased enormously. A key trigger for this has been the smartphone revolution and the associated need for companies to have their own mobile apps for their customers, as well as employees.

The second trend is that the primary means to distribute software, as well as the related patches and upgrades, has ubiquitously now become the internet. The advantages of using online software distribution, versus traditional methods such as CDs (Compact Discs) are significant: large scale, near instant software distribution at extremely low costs.

The third trend is the number of Independent Software Vendors (ISVs) who are primarily in the business of building software applications, has grown steadily over the years, with some research reports indicating a ten-fold growth over the last decade.

These trends explain how online software distribution has become the preferred method for companies developing and selling software. But does this method and its convenience-benefit also introduce business risk?

How does a user know whether the software being downloaded is from the original author (and not an impersonator)? How does the user know that the software has not been tampered with, and some malicious code inserted into the software? Code Signing provides the answer to these questions, by helping companies secure the software they release.

Apart from software developers and enterprise security specialists, it is critical for project managers, product managers, engineering managers and even senior management to be familiar with code signing. The reason is simple. Code Signing is an excellent safeguard against malware attacks. And malware is the most expensive type of attack on any enterprise: the average cost of a malware attack, as per a recent research report from IBM security, is $239 million which is 60 times more than the average cost of a data breach!

How code signing works?

The “code” in code signing can mean executables, archives, drivers, firmware, libraries, packages and essentially any software that is intended for release and distribution to another party or user.

To understand how code signing works, it is important to have a basic understanding of Public Key Infrastructure (PKI). As defined in earlier articles on this blog, PKI is a set of roles, policies, hardware, software and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. It is also important to understand the two primary objectives of code signing:

1. Code Ownership: Proving that the software code being downloaded and installed is from the original, authentic owner.
2. Code Integrity: Proving that the code has not been tampered with or changed in any way, e.g. with some malicious code (malware) being inserted in it.

The process of code signing involves four main steps which are described below.

1. Key Generation: The basic requirement for code signing is to have a private key and the corresponding public key available. The public and private key pair can be generated using a (trusted) third party tool or software. A detailed explanation of key generation is out of scope of this article.
2. Code Signing Certificate: You then need to apply for a code signing certificate with a Certificate Authority (CA), which is a trusted entity that issues digital certificates. The application needs to include your public key along with other organization identity details. Some of the well-known CAs include Verisign, Digicert, Symantec, GoDaddy, Comodo, Let’s Encrypt, and GlobalSign. The certificate that the CA issues includes information such as your (organization) identity, your public key, the certificate validity period, the digital signature of the CA, and other details.
3. Hashing: The next step is hashing your code. Hashing is a one-way process where data of any size and type can be converted, through a mathematical algorithm, to fixed size data. The algorithm is called a hash function and its output i.e. the fixed size data is called a hash value or hash. The hash value is totally different from the original data and the original data cannot be deduced from the hash.
4. Signing: The hash value of the software is then encrypted or “signed” using the private key. The encrypted hash, along with the code signing certificate, is added to the software package that is now ready to be shipped or distributed.The reason why the hash value is signed, and not the original software, is that the hash is a small amount of data (typically up to 512 bits) which can be encrypted very quickly, whereas the original software might be very large and might take a long time to encrypt. Also, there is no real need to encrypt the software code itself: the beauty of hashing is that if the original software code is modified even by a single bit, the hash value produced by the hash function is totally different.

Best Practices for Code Signing

We suggest the following practices for a secure Code Signing process: 

1. Storing the private keys in HSM

   The Hardware Security Module (HSM) doesn’t allow the export of private cryptographic keys to software, as that will make these keys vulnerable to attacks. After the CAB Forum’s June 2023 requirement, we highly recommend using a FIPS 140-2 Level 2 (or higher) certified HSMs for Code Signing.

2. Limiting private Key access

   We highly suggest allowing only minimal connections to client systems with the private keys. Limiting key access to limited users will resolve a lot of inconspicuous user activity.

3. Code should always be Time-Stamped

   Time stamping is a good way to track when code has been signed and helps check the validity period of the signature. It also allows the code to be verified after the certificate used for signing has expired or been revoked.

4. Avoid overusing one key

   Organizations sometimes use the same key to sign code across multiple product lines and businesses. This isn’t a good approach. If that key gets compromised, all the releases signed by that key will be at risk. A good practice would be to rotate your keys as frequently as possible.

5. Create transparency and centralize the management

   Generally, organizations manage certificates and keys manually. But this isn’t a good approach as manual processes neither provide complete visibility nor centralized control over keys. Applying various policies on the keys and regulating those is difficult without a centralized management system.

What happens when the software is downloaded?

At the receiver side, the browser being used to download the software first checks that the certificate in the code being downloaded is authentic and from a trustworthy CA. This is possible since the public keys of most of the well-known CAs are already pre-installed with most browsers and operating systems.

If the certificate is not authenticated, the browser will alert you and depending on browser security settings, may or may not allow the download. If the user ignores this warning, and attempts to install the software, the operating system will issue an alert indicating that the software publisher could not be verified and effectively discourages the user from installing the software. This addresses the first objective of code signing i.e. establishing code ownership.

If the certificate is authenticated, the public key is extracted from the certificate and used to decrypt the encrypted hash available in the package. Next the actual downloaded software (minus the certificate and hash) is hashed again using the same hash function. This hash value is compared with the decrypted hash value. If they match, the software has not been altered. If an attacker has changed the software (e.g. by adding some malware) then the hashes will not match, the operating system will throw an alert and refuse to install the software. This addresses the second objective i.e. ensuring code integrity.

Code Signing for Software Supply Chain Security

When a private key is compromised, the certificate loses its trust, destroying the authenticity and integrity of the software signed by this code-signing certificate. Code-signing practices ensure secure product development, production, and deployment. The best practices for protecting the Software Supply Chain with secure code-signing are: 

1. Authenticate code before signing and releasing

   Organizations should use streamlined code signing processes, such as CI/CD pipelines and approval processes, to prevent malicious code from being signed. After signing, the code or artifact should be authenticated and verified before being released to the users. Organizations should also maintain logs of all the code-signing processes for auditing later.

2. Revoke compromised certificates

   To ensure code safety, revocation should be followed. Certificates that have been compromised should be revoked by the Certificate Authority; this way, the corrupted or compromised certificates cannot be used for code-signing activities. 

Code Signing in Cloud-Native Environments 

Code Signing is very important in deployments in cloud-native applications or DevOps. Before distributing software to users, we can sign and verify software types such as container images, application binaries, etc. In cloud-native environments, code signing is integrated with CI/CD pipelines to maintain the trust and authenticity of the software. By including code signing in cloud-native environments, organizations can prevent the risk of tampering with code that makes it malicious for distribution. 

Summary

Today code signing is an essential part of the software development lifecycle. Without code signing, enterprises risk losing users and face enormous financial and reputation risks in case of malware attacks. It is therefore critical for software line managers as well as senior management to understand code signing and its importance to their organizations.