Code signing and the use of digital certificates are fundamental to the concept of trust in the modern technology world.
Specifically code signing, which is used to verify the identity of a program's developer and its origin. Like many X.509 certificates, code signing certificates come in standard and extended validation (EV) forms.
By code signing a program, developers are simply attaching their digital certificate. Code signing certificates use public key cryptography, the same technology used by other types of digital certificates. This approach can be used in operating systems of many types of platforms, from mobile to desktop. You can find them for Microsoft's Windows, Apple's Mac OS X, Linux, and even iOS and Android. They can even be found in IoT devices. Embedding these certificates into a program's source code is an important aspect of security and trust in any software development.
How to implement code signing
Achieving this requires a unique private key - one that is properly hashed so that the encryption/decryption handshake cannot be easily defeated. In public key cryptography, the combination of public and private keys is at the heart of the process, allowing communication without access.
After a new key pair is generated using a public key infrastructure (PKI), the public key is sent to a certificate authority (CA), which verifies the developer's identity and affixes its own public key to the code signing certificate. The certificate and code are sent back to the original developer who requested the certificate.
Now that developers have a code signing certificate and encryption key pair, they must hash the software's code before encrypting and signing it. Hashing is a program in which a hash function is used to convert code into an arbitrary fixed value. The output of the hash, called the digest, is then encrypted with the private key. Next, developers combine this digest with a code-signing certificate and a hash function to create something called a signature block, which basically combines all of the above items into a piece of code that can be easily inserted into software.
The importance of protection
The biggest problem with code signing is protecting the private code signing key associated with the certificate. If one key is compromised, the certificate loses trust and value, compromising the software you sign.
Many organizations protect themselves with security vaults and hardware security modules (HSMs) to increase the security of their private keys. Other organizations use Certificate Manager to automate and secure the lifecycle management of all code signing certificates. One example of this is the Sectigo certificate manager. Using a certificate manager can go a long way toward promoting the integrity of private keys and other cryptographic assets.
What does code signing prevent?
Simply put, code signing prevents malware and other malicious code from being introduced to an end user's system under the guise of benign files or events such as Windows updates. It does this by allowing users to verify that the file being downloaded is indeed from the originator and not a malicious actor. This reinforces the concept of trust within the system, allowing developers to assure end users who download software that the source can be trusted and is safe.
EV Code Signing Certificates provide additional security guarantees. They require keys to be stored in high-assurance hardware compliant with FIPS140-2 or above. There are USB tokens that fulfill this requirement and add another layer of protection via a PIN code. Alternatively, you can store the keys in your organization's hardware security module (HSM).
Research from Georgia Tech's Cyber Forensics Innovation Lab shows that the issuance and use of Extended Validation (EV) TLS/SSL certificates provides a 99.99% probability of protection against phishing attacks and abuse.
An easy way to protect your keys
There are many ways to protect code signing keys, including:
Separate your test and release signing keys
Test environments are messy and busy, but, since they are internal, test signing keys generally don't need to be as deeply protected as your release signing keys. In fact, many organizations use self-signed certificates or untrusted certificate authorities in test environments for this reason. Separating testing and release signing keys prevents developers from using one code signing key during the development phase and then releasing software with it. However, using separate test and release keys requires that any test installer be clearly marked to avoid it being pushed to customers.
Take Revocation Seriously
Revocation certificates are one of the most important parts of keeping track of your code signing keys. If vulnerabilities are discovered during the code signing process, or private keys are exposed, the keys and certificates associated with them need to be revoked and reissued to properly ensure trust in the system.
time is your friend
Code signing certificates expire just like other digital certificates. This doesn't mean that information signed with that certificate is invalid, but it does mean that when the system checks the code signature for comparison, it will recognize that it has expired and give the end user an error message. These alerts, which occur whenever the timestamp has expired, can be bypassed, but they damage the customer's reputation and trust in the brand. These expiration dates enforce the discipline of continuing to renew certificates, ensuring that certificates in released code are hashed using the latest cryptographic methods and have not been compromised through cryptographic vulnerabilities.
Best Practices for Code Signing
Code signing does not make software completely immune to misuse, tampering, or malicious intent. There is a large human element in the process of handling private keys. Code signing should be a collaborative responsibility between security and development teams to achieve a common goal and protect keys without disruption.
Following some industry-standard best practices can make this approach as effective as possible. Here are the top 10 code signing best practices recommended by Sectigo.
1. Secure your code with a code signing certificate
The most important recommendation is to use code signing certificates whenever possible. These certificates verify the origin and authenticity of the code to the end user and increase customers' confidence in their personal security. By properly signing your code, you can infuse your application or program with trust managed by a trusted public certificate authority. For added security, you can use EV code signing certificates.
2. Avoid developing bad habits
Proper use of certificates within your system is critical, but without enforcing behaviors to properly maintain and use them, anything else you do will be futile. Building a culture that understands the use and importance of digital certificates can only improve your organization overall.
3. Minimize access to private keys
Any good IT professional will put in as much access control as possible; this includes restricting access to private keys and underlying root certificates. You should allow very few people access to your organization's private keys, and those people should have a clear reason to need access. Establishing a role-based access (rbac) policy within your organization will help limit possible exposure.
4. Protect private keys with cryptographic hardware
Using encryption hardware allows you to protect your private keys with the latest encryption algorithms. This type of hardware should be at least FIPS 140 Level 2 certified. Products like hardware security modules (HSMs) will protect your private keys from falling into the wrong hands.
5. Timestamp the code
Time-stamping your code gives you an idea of when the code was written compared to the certificate it was written on. This allows it to be reconfirmed as legitimate once the certificate expires or is revoked. This is an important relationship to understand because as technology and encrypted threats evolve, current protections may be weakened or destroyed altogether.
6. The difference between test signing and release signing
As mentioned above, it is important to distinguish and understand the difference between test signing and release signing keys/certificates. Less security is required for test signing certificates and keys, which can be self-signed by a private internal test CA. They must also be concatenated with the root certificate of the release-signed product, and best practices include setting up entirely different code signing infrastructures for release and pre-release signing. This will enable you to set up proper access controls for your test environment and production code.
7. Verification code
Code signing doesn't specifically make sure the code is secure, it just says who wrote it. Therefore, code still needs to be fully certified before it can be released in good faith to the public. Doing this ensures that you don't accidentally spread incorrect or malicious code that could harm customers and damage your reputation. All certified code signing activity should be logged in case some type of investigation or incident response is required later.
8. Virus scan code
In addition to verifying that your code has not been modified, it is also important to scan it for viruses or other malicious code. Malicious code is often inadvertently inserted by developers who reuse or import existing code from external projects. It's much easier to catch and change bugs before the code is released.
9. Limit reuse of keys
Reusing your private key multiple times for code signing puts you at greater risk. If a key is compromised, all code signings to that date stamped with that key will be invalid and need to be renewed with new code signing certificates. Maintaining the habit of cycling through different keys and certificates will allow you to spread the risk and reduce the effort and impact of reissuing certificates.
10. Revoking a compromised certificate
Revocation is one of the most important tasks in keeping your code secure. Certificate authorities take revocation more seriously than anyone, which is why we recommend best practices like timestamping your code.
However, it is the development organization's responsibility to report any compromised code, keys, or certificates to your certificate authority so they can take appropriate action. CA will ask to revoke the code signing certificate if any possible problem arises. If you timestamp your code, only code with a revocation date after the event will be affected.