When it comes to your software code, what can you do to earn the trust of your users? For starters, write secure code. Make sure you use the best programming practices to save your users from XSS (cross-site scripting) attacks, SQL injections, etc.

What else can you do? Well, the first problem to be solved when your users see your software is – did it really come from you? This is what we will cover in this article. You can code sign your software. You can ensure code security by digitally signing your scripts and executable to confirm that you stand behind the code and that the software has not been modified or corrupted after your signature was stamped.

CAs (certificate authorities) are publicly trusted entities that bind your public key to your code signing certificate and confirm your identity. The users can use your certificate to establish software security by using the PKI (Public Key Infrastructure) to validate your code signature.  Web browsers and CAs have developed excellent standards that can be used to issue, manage, and verify code signing certificates. There are many code signing certificates available such as the cheap Code Signing Certificate that ensures that the code is authenticated. These standards make sure that the software is verified using well-established code signing specifications.

In this article, we will discuss the working of the code signing process and the use of best practices to sign your software.

Why should you sign your code?

Most devices ship with pre-loaded “out of the box” software, which is not enough for the lifetime of use. All PCs, mobile, and other computational devices need additional applications and patches to be frequently downloaded and installed. This puts the users in a precarious situation – should they trust the software security of the code they are about to get and run? How do they decide? How does the user agent, such as the browser, decide? Code signing is the solution.

You (the software publisher) can sign your code digitally to help your users verify if the code security can be trusted before they install and execute your software. A code signing certificate establishes your identity and verifies that the software has not been subjected to tampering after it was signed.

Generally speaking, unsigned software must not be trusted, since there is no proof of the origin or the integrity of the files being downloaded – this means that the users cannot hold the publisher liable for any errors, and the code integrity may have been compromised. Code that has been signed using a digital certificate issued by a trusted CA has a higher reliability than an unsigned one. With this information to back them up, the users can decide whether to trust the code and proceed with the installation of your software distribution.

How does code signing work?

Before a software publisher can sign their code, they need to acquire a code signing certificate their users can trust. To sign the software, you (the code publisher) must generate a pair of private/public keys. You then hand over the public key to the CA as part of your request to get a code signing certificate issued. The CA will verify the identity of the software publisher and authenticate the digitally signed request. Once this vetting process is completed and the key-verification succeeds, the CA will create and sign the code certificate, which includes your public key.

Now that you have your code signing certificate, you can use it to sign your software distribution. Various information pieces get added to the original software as part of the code signing process. This code signed bundle is used by your users to authenticate you and ensure that the code has not been altered since you distributed it.

This is how the entire code signing process works:

1. Create a hash of your code

  • A fixed length digest of the software to be distributed is created by using a hashing algorithm, since public-key algorithms are not efficient to sign large files.
  • This cryptographic hash is a unique representation of your code.
  • The only way to reproduce the hash is to start with the original file and use the same hashing algorithm to create the hash.

2. Sign this code hash using your private key

  • The signing algorithm works on the hash produced in the previous step using your private key as the input.
  • The CA’s and your (the software publisher) information is taken from the code signing certificate and made part of your signature.

3. The software to be published, your signature and the code signing certificate are bundled together

  • Since the users will need the public key to authenticate the code as part of the code verification process, your code signing certificate key is included in the bundle

That’s it. You can now distribute your software, which has been packaged in a form that your users can verify for authenticity.

How do the users verify code authenticity?

When the code is loaded by a user agent, it verifies the authenticity of the distribution using your bundled public key, code signature, and the software hash. If your signature is verified, the user agent decides that they can accept your software distribution to be valid. However, if the user agent is unable to establish the code authenticity, they will warn the user or reject the software package automatically, based on the way the user agent security has been set up.

This is how the signature verification works:

1. Hash verification

  • A hash is created by passing the original code to the hashing algorithm.
  • Your public key is extracted from the package and used to decrypt the code signature, thus revealing the hash that you had calculated while signing the software.
  • The user agent compares the two hashes. If the two match, it determines that the code has not been altered, and the signature is valid.

2. Code signing certificate verification

  • The user agent tests the code signing certificate to confirm that a trusted CA indeed issued it.
  • The validity of the code signing certificate is ensured by checking the expiry date.
  • The revocation lists are scanned to ensure that the code certificate is still valid.

Once the code signing certificate and the hash check out acceptable, the user agent declares that the software distribution is valid. The user is informed that it is safe to use, and the installation is allowed. However, if the user agent fails to establish code security, a warning is presented to the user.

What are the best practices for code signing?

The biggest challenge with any lock and key situation is losing your keys. Likewise, with code signing, you must protect the private keys that you use with your code signing certificate. If the key gets lost or stolen, your code certificate is no longer worthy. It loses its value and trust, even jeopardizing the distribution of the software you may have already signed. Here are a few best practices for code signing you should adhere to:

Limit access to your private keys

  • Minimize access to computers where you store your private keys
  • Limit the number of users who have access to your private keys
  • Deploy physical security to protect the assets where you hold your private keys

Store private keys on hardware products secured by cryptography

  • Cryptographic hardware prevents export of private keys to software, where it is more likely to be compromised
  • Use hardware products with the highest standards of cryptography (ideally certified FIPS 140 level 2 or higher)
  • Strive to go for more secure certificates (such as EV code signing certificates) that enforce the generation and storage of the private key in hardware

Do not release code with test-signed certificates

  • Test-signing code certificates are usually self-signed or drawn from a test CA
  • Test-signing code certificates and private keys have less security access controls than the production code signature ones.
  • Use a completely different root certificate chain for test certificates than the root certificate employed for signing publicly released software
  • Do not mix test code signing infrastructure with the one used for signing code released to the public

Authenticate the code signing process

  • All code that is signed must first be strongly authenticated as part of the prerelease process.
  • Prevent code signing of malicious and unapproved code by implementing a strict software submission and approval process.
  • All code signing activities must be logged for auditing and reporting purposes.

Check for viruses before code signing

  • Remember, code signing does not verify the quality or safety of your code – it just confirms your identity and ensures the code is not altered after you sign it.
  • Be extra careful when you incorporate code coming from other sources.
  • Implement processes to check the software for viruses, Trojan horses, and other malicious code before singing it for the release.

At last, code signing is a very effective way of securing your code for user trust. It works seamlessly on many platforms while providing assurances of origin and authenticity of a code. When you sign a code, please do not use internal or test certificates, which is not offered by a trusted Certificate Authority. Also, keeps the best code signing practices in mind when implementing your software release process.