Code signing is a critical way to ensure privacy and security online. In today’s digital world, authenticity, trust, and integrity are key factors. People download apps and software every day, including mobile apps, operating systems, software updates on personal devices. However, with the high rates of phishing malware attacks, users’ data could be compromised.
This is where code signing makes a difference.
Publishers and developers add digital signatures to their applications and software to increase user trust and security to verify that the included code has not been tampered with and is safe for use.
According to the NIST (National Institute of Standards and Technology), Code signing allows developers to distribute and update software securely and automatically, preventing tampering and forgery.
Signing your code as a publisher helps:
- Validate your organization’s identity, ensuring users the software is from a trusted vendor.
- Improve user experience by building trust since users can verify the app is authentic.
- Minimize software security risks by preventing third parties from tampering with the code.
This article describes recommendations when applying code signing. It features architectural solutions that publishers must consider.
1. Secure Your Private Keys
There have been reports of high-profile cyber-attacks using malware signed with legitimate code signing certificates. Experts believe the code signature breach could result from the certificate owners’ inability to secure their private keys.
One of the ways to secure your code signing is to protect private keys with cryptographic hardware products. Keys stored in software on a general-purpose computer are easily exposed to compromise.
Cryptographic hardware is more secure. It is best to keep private keys in tamper-proof, cryptographic hardware devices to make them less vulnerable to compromise. It prevents the export of the private key to software where attackers can access it. In addition, it prevents theft of the key since the physical device it’s stored in is protected.
Common types of cryptographic devices used include:
- Hardware security modules.
- Smart cards.
- Smart card-like devices such as USB tokens.
If you have to export private keys, it’s best to protect the cryptographic hardware with a randomly generated password. Ensure the password is at least 16 characters, including numbers, lowercase letters, uppercase letters, and special symbols.
2. Isolate Private Keys from External Networks
Once you have completed the code signing process, move the private keys of all developers’ servers and computers. It’s advisable to store your private key in an encrypted, secure, and centralized location. Most importantly, the systems with genuine code signing certificates must have the least connection to the outside world.
Ensure you isolate it from external networks as well as from production environments. Carefully monitor it to prevent anything that can threaten its integrity. Instead, protect such systems using the principle of least privilege, multi-factor authentication for access. Block all networks except the most necessary network ports for installing updates and running an updated antivirus scanner.
3. Time-stamp Code
Though an optional part of code signing, time stamping is a process that allows the software to verify the validity of a code signing signature – even after a code signing certificate expires.
Whenever any user runs the signed software’s executable on a machine or system, the user’s operating system verifies its digital signature. The client’s computer will verify the signature based on the time it was digitally signed instead of the system’s current time when the user executed it.
4. Differentiate Between Test-signing and Release-signing
Test-signing private keys and certificates do not require as much security as release-signing private keys and certificates. Firms use release signing certificates to sign production codes shipped to end-users across the globe. As such, it requires stricter security than a test signing certificate. Establishing a separate test code signing infrastructure for pre-release software builds is advisable.
The test certificate should be chained to an entirely different root certificate then the root you use to sign publicly released products. This precaution helps ensure you test certificates only within the intended test environment. You should also provide test-signing certificates that can be self-signed or come from an internal test CA.
5. Do not Overuse Any One Key
In cases where you find security flaws, prompt a User Access Control dialogue box. This will appear when a user installs the code. You can achieve this by revoking the code signing key so a revoke prompt will occur.
If you issue the code with security flaws before the good code, revoking the certificate will also harm the good code. It’s best to change keys and certificates often to avoid conflict. In sum, it’s best to distribute risk with multiple certifications.
It’s also best to revoke compromised certificates. Report signed malware or key compromise to your certification authority. Compromised keys may also require you to revoke the code signing certificate.
Since the human factor is involved with handling private keys, code signing may be susceptible to compromise, tampering, misuse, or malicious intent. These security considerations can help improve security for your code signing.