Code signing
Code signing is the process of digitally signing and to confirm the software author and guarantee that the code has not been altered or corrupted since it was signed. The process employs the use of a cryptographic hash to validate authenticity and integrity.
Code signing can provide several valuable features. The most common use of code signing is to provide security when deploying; in some programming languages, it can also be used to help prevent namespace conflicts. Almost every code signing implementation will provide some sort of digital signature mechanism to verify the identity of the author or build system, and a checksum to verify that the object has not been modified. It can also be used to provide versioning information about an object or to store other meta data about an object.
The efficacy of code signing as an authentication mechanism for software depends on the security of underpinning signing keys. As with other technologies, the integrity of the system relies on publishers securing their private keys against unauthorized access. Keys stored in software on general-purpose computers are susceptible to compromise. Therefore, it is more secure, and best practice, to store keys in secure, tamper-proof, cryptographic hardware devices known as hardware security modules or .
Contents
Providing security
Many code signing implementations will provide a way to sign the code using a system involving a pair of keys, one public and one private, similar to the process employed by or . For example, in the case of .NET, the developer uses a private key to sign their libraries or executables each time they build. This key will be unique to a developer or group or sometimes per application or object. The developer can either generate this key on their own or obtain one from a trusted (CA).
Code signing is particularly valuable in distributed environments, where the source of a given piece of code may not be immediately evident – for example , controls and other active web and browser scripting code. Another important usage is to safely provide updates and patches to existing software. , , and most provide updates using code signing to ensure that it is not possible for others to maliciously distribute code via the patch system. It allows the receiving operating system to verify that the update is legitimate, even if the update was delivered by third parties or physical media (disks).
Code signing is used on Windows and Mac OS X to authenticate software on , ensuring that the software has not been maliciously tampered with by a third-party distributor or download site. This form of code signing is not used on Linux because of that platform’s decentralized nature, the being the predominant mode of distribution for all forms of software (not just updates and patches), as well as the open source model allowing direct inspection of the source code if desired.
Trusted identification using a certificate authority (CA)
The used to authenticate the code signature should be traceable back to a trusted root authority CA, preferably using a secure (PKI). This does not ensure that the code itself can be trusted, only that it comes from the stated source (or more explicitly, from a particular private key). A CA provides a root trust level and is able to assign trust to others by proxy. If a user trusts a CA, then the user can presumably trust the legitimacy of code that is signed with a key generated by that CA or one of its proxies. Many operating systems and frameworks contain built-in trust for one or more existing CAs (such as , , /, , TC TrustCenter, , and ). It is also commonplace for large organizations to implement a private CA, internal to the organization, which provides the same features as public CAs, but it is only trusted within the organization.
Alternative to CAs
The other model is where developers can choose to provide their own self-generated key. In this scenario, the user would normally have to obtain the public key in some fashion directly from the developer to verify the object is from them for the first time. Many code signing systems will store the public key inside the signature. Some software frameworks and OSs that check the code’s signature before executing will allow you to choose to trust that developer from that point on after the first run. An application developer can provide a similar system by including the public keys with the installer. The key can then be used to ensure that any subsequent objects that need to run, such as upgrades, plugins, or another application, are all verified as coming from that same developer.
Time-stamping
Time-stamping was designed to circumvent the trust warning that will appear in the case of an expired certificate. In effect, time-stamping extends the code trust beyond the validity period of a certificate.
In the event that a certificate has to be revoked due to a compromise, a specific date and time of the compromising event will become part of the revocation record. In this case, time-stamping helps establish whether the code was signed before or after the certificate was compromised.
It is also important to note that code signing does not protect the end user from any malicious activity or unintentional software bugs by the software author – it merely ensures that the software has not been modified by anyone other than the author.
Implementations
IBM’s has had PKI signing of code from Release 1, and both client and server software have execution control lists to control what levels of access to data, environment and file system are permitted for given users. Individual design elements, including active items such as scripts, actions and agents, are always signed using the editor’s ID file, which includes both the editor’s and the domain’s public keys. Core templates such as the mail template are signed with a dedicated ID held by the Lotus template development team.
Microsoft implements a form of code signing (based on Authenticode) provided for Microsoft tested drivers. Since drivers run in the kernel, they can destabilize the system or open the system to security holes. For this reason, Microsoft tests drivers submitted to its . After the driver has passed, Microsoft signs that version of the driver as being safe. On 32-bit systems only, installing drivers that are not validated with Microsoft is possible after accepting to allow the installation in a prompt warning the user that the code is unsigned. For .NET (managed) code, there is an additional mechanism called that uses Public/Private keys and SHA-1 hash as opposed to certificates. However, Microsoft discourages reliance on Strong Name Signing as a replacement for Authenticode.
Unsigned code in gaming and consumer devices
In the context of consumer devices such as , unsigned code is often used to refer to an application which has not been signed with the normally required for software to be accepted and executed. Most console games have to be signed with a secret key designed by the console maker or the game will not load on the console. There are several methods to get unsigned code to execute which include software , the use of a , a technique known as the or running a .
It may not initially seem obvious why simply copying a signed application onto another DVD does not allow it to boot. On the , the reason for this is that the Xbox executable file (XBE) contains a media-type flag, which specifies the type of media that the XBE is bootable from. On nearly all Xbox software, this is set such that the executable will only boot from factory produced discs so simply copying the executable to burnable media is enough to stop the execution of the software.
However, since the executable is signed, simply changing the value of the flag is not possible as this alters the signature of the executable causing it to fail validation when checked.
Proliferation of connected devices
The growing Internet of Things (IoT) is giving code signing critical new importance. As more and more sensors and devices are connected to close network ecosystems, certificate issuance mechanisms have been extended beyond identifying people to identifying machines. Device credentialing enables control over the manufacturing process of high technology products and protects against unauthorized production of counterfeits. Together with code signing, the technology ensures physical authenticity and the authenticity and integrity of the code they possess at the time of manufacture through the use of a digital birth certificate, or during subsequent upgrades through code validation any time during the product lifecycle. This is creating a new dimension for code signing, and elevating the security awareness and need to maintain private signing keys secured within a dedicated protected environment to establish a root of trust for the entire system. Given the prevalence of malware and Advanced Persistent Threats (APTs), many software vendors, providers of online services, enterprise IT organizations and manufacturers of high-technology IoT devices are under pressure to increase the security of their high technology manufacturing and code signing process.