In the recent past, many technology firms are being targeted by hackers to tamper and corrupt the source code. These attacks heavily impact brand reputation and also leads to huge losses for firms victimized. To tackle this scenario, Code Signing technique can be used for safe guarding the code integrity and to provide authenticity of the author to the end user by providing digital signatures. Code Signing provides secure and trusted distribution of software preventing tampering, corruption and forgery. Code signing improves end-user confidence in software/code integrity and sender authenticity.
Code Signing Architecture provides a detailed explanation on how the Code Signing process works along with its components. Mentioned below are the four important differentiating components in the Code Signing Architecture.
These four components together will achieve the full cycle completion of the code signing process. Each component has a defined working process which is discussed in detailed below.
Code Signing System (CSS):
The Code Signing System (CSS) is the first and important component of Code Signing Architecture. Code signing system signs the submitted code using digital signature and authenticates the author. The digital signature is generated by CSS using private signing key and certificates. It is highly important to secure the private signing key and certificate from misuse and unauthorized access.
Certificate Authority (CA):
Developers or Source issuing code should use certificates from authentic certificate authorities (CA) as the certificate enables the process of authenticating the source. Certificates issued by authentic certificate authorities must comply with standard certificate policies such as NIST Interagency Report 7924 which specifies requirements to be followed by CAs while issuing certificates. Also, the developer requesting the certificate from authentic CAs has to provide supporting validation documents which would be verified before providing certificates. CA would follow guidelines mandated by standard agencies such as CA security council, CA/Browser Forum etc.
Time Stamp Authority (TSA)
An optional but important component in Code Signing Architecture is Time Stamp Authority (TSA). Time stamping preserves the source time when the code was signed and allows software to be accepted by the OS and other client device platforms even after the certificate expires. Signed software is validated with the source time when the certificate was signed rather than the current time. Hence, it is always advisable to use Time stamping technique while performing code signing. Digital signature signed code is sent to TSA for time stamping. TSA applies its own signature along with the valid source time stamp. TSA is independent from Code Signing System and synchronizes its clock with an authoritative time source.
End user using the code digitally signed by the publisher first initiates the process of verifying the signature. In general, verifiers are used to perform this step of validating the signatures and time stamp (if any). Verifiers leverage trust anchors to validate the signature on the signed code. Trust anchors are usually public keys of root certificate authorities (CA) installed securely on the verifying platform. In general, root CAs use standard architecture such as X.509 standard. If your organization is looking for implementation of Code signing, please consult firstname.lastname@example.org for further information
Every organization is expected to benefit a lot through code signing and this very reason makes this technology critical. One has to keep in mind the best practices to be followed while implementing code signing. Because when there is a breach of private keys of your company due to poorly implemented infrastructure, it not only impacts the customers but also the trust they have on your brand and its products.
Let’s take a look into the most critical best practices your company has to follow while implementing code signing technology:
Code Signing: Best Practices :
Separation of environments: Test signing and Release signingOne of the important code signing best practice is to set up a parallel environment for code signing infrastructure to sign test code with an internal test root Certificate Authority (CA). Internal test root CA would provide test certificates for signing the code. This benefits the firm in two ways, first benefit is limiting the exposure of actual private keys and code signing mechanisms to close group of users/developers and the other benefit is to opportunity to test the signed code for functionality bugs and vulnerabilities.
Test signing can be done in two ways:
Test Certificate Signing Authority
Mid-size to small sized organizations can use self-signing certificates for the test code sign process. This might involve some effort to make the certificates trusted as, by default, it won’t be trusted. In general, one can obtain these certificates through free tools without using any public key infrastructure (PKI). Organizations with complex and huge size test environment can use internal test CA for generating test certificates for the code signing process.
Either your firm uses self-signed certificates or internal test CA, always ensure that code signing process and root certificates are separated between test and production environment.
Restricted access to Private keys through physical securitySystems with private keys have to have minimal access. As the saying goes, the most secure computer would be the one with minimum external connections. Hence, minimize the number of personnel having access to system with private keys used for code signing process.
Physical security is equally important for securing the sensitive data. In spite of all the virtual measures taken, if there is an employee or contractor who gains unwanted access can be a high threat. Physical measures such as cameras, fingerprint access, security guards etc. can be utilized for providing physical security.
Cryptographic hardware protection modules (HSMs)Cryptographic hardware protection modules restrict the export of private keys from these devices. Cryptographic modules are tamper proof and secure for storing keys that are used to sign digital certificates. There are three important types of cryptographic devices used for securing keys:
In general, HSMs are preferred over other devices as the security standards are relatively higher. Ensure that all the devices used are compliant with FIPS 140 level 2 certified.
Timestamp process: Public or PrivateTime stamping process helps in verifying the authenticity of the publisher after the expiry of certificate. Public time stamping authority can be used for cost benefit but it is always suggested to use internal timestamp authority to avoid public network access.
Timestamp certificates can be issued for a maximum time period of 135 months. Strict measures has to be taken while you expose code signing process during external/public time stamping.
Scan the code for viruses Code signing process helps in authenticating the code alone and cannot secure the code. Hence, it is always suggested to perform virus and malware scans before publishing the code and signing with digital certificates. Using virus/malware scan improves the quality of code as well.
If you are a CISO or holding an equivalent position for any organization, one of the biggest nightmares would be failure of line of defense for data security. One such important module relevant to data protection is “Code Signing”. Organizations have to be aware of threats posed to Code signing process and implement reasonable recommendations for tackling the issues.
According to a study conducted by Venafi, it is understood that out of 320 participants from USA, Europe and Canada more than 28% implement a defined code signing policy for protecting certificates used for signing code. There are high chances of forging and stealing of certificates by cyber hackers when proper policies are not enforced for code signing.
Let’s discuss few scenarios of threat landscape for “Code Signing” when appropriate code signing policy is not in place.
Potential Threats to Code Signing
Theft/Loss of Private Signing KeysPrivate signing keys have to be protected with utmost care. Many incidents are reported regularly due to theft of private signing keys. Cyber criminals with access to these signing keys might masquerade malware/malicious code as an authentic code or software. These incidents would cause huge financial loss as well as brand reputation loss. A single compromised private key can cause devastation to the entire firm’s business.
Real world incidents due to theft of private signing keys caused lot of damage for the affected firms. Governments also are affected by the loss of private keys and one of the classic examples is the attack on Malaysian Government during November 2011 where legitimate certificates stolen were used to sign malware.
Compromised Certificate AuthorityDirect attack launched on certificate authority (CA) issuing code signing certificates can cause severe damage to the firm using the certificates. Hence, it is always advisable to ensure the best practices are followed by CAs issuing certificates. Cyber attack incidents on CAs can even lead to the bankruptcy of the firm issuing certificates.
One such incident happened to a Dutch certificate authority – DigiNotar in 2011. Certificate Authority was compromised by hackers and issued fake certificates for many reputed websites which eventually resulted in bankruptcy of DigiNotar.
Best practice is to perform assessment on the vetting processes used by Certificate authority and data security measures in place before choosing the CA.
Use of insecure cryptography governance controls:Usage of weak and insecure cryptographic algorithms for code signing process would create vulnerabilities which can lead to cyber attacks such as brute force attack to hack keys used for code signing. Poor governance controls can cause intrusions into development and production systems. These security lapses can cause malicious code to be signed and authenticated.
CISOs should consider implementing proper governance controls to create secure environment. Also, performing appropriate assessment of code signing processes would avoid any unprecedented breach.
Venafi research survey on Code signing best practices and processes followed across US, Canada and Europe showed an astonishing picture about code signing landscape. More than 50% of the respondents across US, Canada and Europe either do not have code signing processes defined or implementing informal process with inconsistency. This is a huge alarming concern for CISOs.
35% of the respondents do not have clear owner for managing code signing private keys. In many cases, either development team or information security or both are managing private keys used for code signing.
It is the responsibility of CISOs to consider hiring an in-house team or a consulting firm who possess expertise in cryptography and code signing processes for better and secure implementation of “Code Signing”.
If your organization is looking for assessment and/or implementation of Code signing, please consult email@example.com for further information
Code Signing is the process of applying a digital signature to a software program intended for distribution over the internet. Code signing helps to verify that the software is authentic i.e. from the original developer, and also helps to validate that the code has not been tampered with by an attacker while in transit e.g. by the insertion of malicious code or malware. The digital signature used for code signing is contained in a digital certificate called the code signing certificate.
Code Signing Certificates
Like any other digital certificate, code signing certificates are based on the X.509 standard and also need to be signed by a trusted third party such as a Certificate Authority (CA). However, code signing certificates cannot be used interchangeably with other certificates such as SSL certificates. The main reason for this is that as per the X.509 specification, any digital certificate contains a “Key Usage” field, which indicates the intended use of the certificate and is filled in at the time the certificate is generated. Additional information regarding the use of the certificate can also be contained in the “Extended Key Usage” extension. The X.509 specification mandates that a certificate cannot be used other than for it’s intended purpose. For example, an SSL certificate has the key usage field set to “Digital Signature” whereas a code signing certificate has the key usage field set to “Code Signing”.
While X.509 provides the specification for the certificate format, the technology implementations to generating certificates will vary by vendor. For example, Authenticode is code signing technology from Microsoft that helps developers sign applications for the Windows operating system. Authenticode certificates are used to sign files with extensions such as .exe, .dll, .ocx, .cab, and .xpi. Similarly, Apple code signing certificates are used to sign applications for iOS, Java code signing certificates are used to sign .jar files for the Java Runtime Environment (JRE), and Adobe AIR certificates are used to sign .air or .airi files.
The process of obtaining a code signing certificate is similar to other digital certificates. Any organization that wishes to publish software for distribution over the internet applies for a code signing certificate with a CA, submitting their public key and other organization information. Note that the public-private keypair needs to be separately generated, like in the case of any digital certificate. The CA validates the developer (organization) applying for the certificate, signs the certificate as proof of validation, and issues the same to the developer or software publisher. The certificate that the CA issues includes information such as the publisher identity, the public key of the publisher, the certificate validity period, the digital signature of the CA, and other details.
Types of code signing certificates
Self-signed certificates: It is possible for software publishers to generate their own self-signed certificates. In such cases however, the signature verification process during software installation will generate a warning that the software was created by an unknown publisher. Self-signed certificates could be used for testing and local development of software, before it is made generally available for public distribution. However, self-signed certificates should not be used for production software being distributed to end users.
For public software distribution, CA issued certificates are the best option. There are two types of CA-issued code signing certificates based on the type of validation.
Standard Validation Certificates: This is the default type of code signing certificate and involves basic validations of the publisher or developer by the CA. To be issued a standard code signing certificate, software publishers need to meet some basic requirements such as minimum key length, maximum validity period, and time stamping for digital signatures.
Extended Validation (EV) Certificates: EV code signing certificates involve the highest levels of validations and vetting of the software publisher by the CA and are usually issued on a hardware token for additional levels of security. To be issued an EV certificate, apart from the basic requirements of standard certificates, software publishers also need to conform to much more stringent requirements – for example maintaining private keys in a Hardware Security Module (HSM) that is compliant with FIPS (Federal Information Processing Standards) 140 Level-2 or equivalent.
Certificate Expiry and Time Stamping
Like any digital certificate, code signing certificates also expire at the end of their validity period. On expiry, the signature will not be validated, and the software may cease to install or execute properly, although nothing is wrong with the software itself. This issue is addressed by the process of time stamping, in which a time stamp is applied to the code at the time of signing the file. This is usually done through another trusted third party called a Time Stamp Authority (TSA), to prove the validity and authenticity of the time stamp. The presence of a time stamp ensures that the software continues to run even though the code signing certificate has expired, giving the publisher time to renew the certificate.
We have seen in earlier articles that the strength of Public Key Infrastructure (PKI) systems depends on how the private keys are managed and secured. If the private key for any digital certificate is compromised, the certificate needs to be invalidated, or revoked by the CA which issued the certificate. Certificate revocation is critical in the event of a breach: it ensures that end users are alerted that the certificate can no longer be trusted, discouraging the download, installation and further usage of the software. Certificate revocation is done by including the revoked certificate in a Certificate Revocation List (CRL), or by updating the certificate status using the Online Certificate Status Protocol (OCSP). Further details about CRLs and OCSP will be covered in a later article.
Code signing is the process of applying a digital signature to any software program that is intended for release and distribution to another party or user, with two key objectives. One is to prove the authenticity and ownership of the software. The second is to prove the integrity of the software i.e. prove that the software has not been tampered with, for example by the insertion of any malicious code. Code signing applies to any type of software: executables, archives, drivers, firmware, libraries, packages, patches, and updates. An introduction to code signing has been provided in earlier articles on this blog. In this article, we look at some of the business benefits of signing code.
Reduction in financial risk
As per recent research, the average cost of a malware attack is around $2.6 million1 and this poses a big financial risk to any organization. One of the root causes for malware is when software is installed without verifying whether the software is authentic and without confirming who is the owner of the software. Another source of malware attacks could be when attackers tamper with software from a source that the customer trusts and insert malicious code inside that software. Code signing addresses both these problems.
One point to note is that while code signing is necessary, it is not sufficient to prevent malware – for example, if the keys used for code signing certificates are themselves compromised. Management of keys therefore is an equally important area of focus and will be covered in a separate article.
Improved brand and reputation
Apart from the financial impact, a malware attack also results in a reputation impact, rapidly damaging organization credibility and raising questions about the security practices of any company. Code signing provides a “digital shrink wrap” seal to your software – it confirms software authenticity to your customer and warns the customer if the seal has been tampered with. For example, even if a single bit in the software is modified, the hash used to sign the software will not match with the hash for the downloaded software – warning the customer not to install the software and thereby preventing a breach. The net effect is to improve your company’s brand and reputation in the eyes of your customers.
Increase in customer trust
Without code signing, security warnings and alerts are shown to the user by the browser and operating system – introducing an element of doubt into the user’s mind and a subsequent loss of customer trust in the software. Customer trust can be further eroded by a malware attack, especially if the root cause analysis points to the lack of code signing being one of the reasons for the attack. Signing code is a great way of building customer confidence and trust by conveying to customers that the organization is doing whatever is possible to ensure the security and integrity of the software it is distributing.
Increasing the distribution reach and install base for your software
Online distribution of the software is becoming de-facto today considering the speed to market, reduced costs, scale, and efficiency advantages over traditional software distribution channels such as retail stores or software CDs shipped to customers. Code signing is a must for online distribution. For example, third party software publishing platforms increasingly require applications (both desktop as well as mobile) to be signed before agreeing to publish them.
Even if you are able to reach a large number of users, without code signing, the warnings shown during download and install of unsigned software are often enough to discourage the user from proceeding with the download and install. In fact, the overall trend is for operating systems to make it increasingly difficult for users to install unsigned software by asking users to go through multiple manual steps and override default security settings. In enterprises, unsigned software can often make it to the “blacklist” or list of software prohibited by the IT team from being downloaded and installed. Code signing can address these issues, help software publishers reach a larger audience, and increase the overall download rates and install base for software. 1As per a study from Accenture and Ponemon institutehttps://www.helpnetsecurity.com/2019/03/07/cyberattack-cost-2018/
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:
Code Ownership: Proving that the software code being downloaded and installed is from the original, authentic owner.
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.
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.
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.
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.
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.
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.
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.
Code signing solution is a process to confirm the authenticity and originality of digital information especially a software code and assuring that this digital information is valid and additionally establishes the legitimacy of the author. It also provides assurance that this piece of digital information has not changed or revoked after it has been signed by the validity of signature.
Whenever we download a program or software, and we see a pop saying “Are you sure you want to run this?” or when we install a software and try to run then you get asked “Do you want to allow the following program to make changes to this computer” then that means code signing in action. And if the program downloaded or installed has not been code signed then we can see a small warning sign stating the same that it has not been code signed.
Why Code Sign Solution?
Code Signing Solution plays an important role as it can enable identification of a legitimate software v/s a malware or a rogue code. In technical terms, code signing creates a hash of the code and encrypts it with a private key adding its signature. During executing this signature is validated and if the hash match it gives assurance that the code has not been modified. It also establishes assurance that the code is issued from a legitimate author that it is claiming to be once it has been digitally signed.
Risks associated with Code Signing Solution:
Few challenges come along with code signing like any other development process. Code signing is only effective if the associated software is secured. Below are the few risks associated,
Stolen, corrupted or misused keys.
When access is granted to an unauthorized user in the system using malicious signature certificates, then that is going to hamper the code signing process.
Unsecured CA private keys would also lead to comprising the code signing system.
Establishing trust in the unauthorized certificates issued by would lead to the malfunction of the system.
The signing of unauthorized code.
Code signing can get hampered in an insecure cryptography system.
Best Practices for Code Signing Solution:
Establishing a high state of security on Private Keys – using HSMs or in a purpose-built environment.
Keeping track of Private Keys and Code Signing events – Maintaining and providing visibility access about who signed what and when.
Managing the assignment and revocation of publishers – Ensuring the access of Private Keys to only the authorized users.
Auditing Capability – Gives accountability and forensic insights on code signing activities.
It is of great importance if policies and procedures are reviewed before the signing of code as it would lead the development process to be more trustworthy and healthy.
Developing a strongly secured cryptography system will have no risk impact on the code signing process.