Deploying Authenticode with Cryptographic Hardware for Secure Software Publishing

  • Article

Authors: Monica Ene-Pietrosanu , Kelvin Yiu (Microsoft Corporation)
Antony Crossman, Alan Lewis, Daniel Murton (nCipher)

Abstract

This paper describes the role of Microsoft Authenticode code-signing and time-stamping in establishing user trust in code that is published online. It provides an overview of the Authenticode code-signing and time-stamping process and examines the role of public key cryptography in proving the identity of the code publisher and proving that code has not been tampered with since original publication. The paper looks at the importance of protecting the credentials that underpin Authenticode and the role of cryptographic hardware in securing digital keys and certificates.   

On This Page

Introduction
Authenticode Overview
Protecting Signing Credentials
Time Is Key
Authenticode and nCipher
Summary
Acknowledgements
Related Links

Introduction

The ability of users to trust code that is published on the Internet is a major challenge facing the software industry. Similarly, large organizations deploying line of business applications such as enterprise resource planning (ERP) systems must decide what software to trust. Packaged software has traditionally relied upon branding and trusted sales outlets to assure users of the legitimacy and integrity of the software. This is not available when code is transmitted across the Internet. Building trust requires a reliable mechanism by which users can verify the identity of a code publisher and verify that the code has not been changed since its publication date.

Malicious code in the form of viruses, worms, and Trojans is now a serious threat that impacts every computer user, whether network-connected or not. Recent reports indicate that, in the United States alone, the effect of malicious code costs industry and consumers between $427M and $522M in 2004.1

Because software on the Internet is not labelled or "shrink-wrapped", end users cannot be sure who published a particular piece of software. It is also difficult to identify whether a piece of code has been tampered with. As a result, end users assume a certain amount of risk when downloading Java applets, plug-ins, Microsoft ActiveX controls, and other executables over the Internet.

Microsoft Authenticode is a technology that can significantly reduce the level of risk and minimize user exposure to malicious code. It identifies the publisher of signed software and verifies that it has not been tampered with before users download software to their PCs. As a result, end users can make a more informed decision as to whether to download code.

Authenticode operates in conjunction with trusted entities, such as the platform, application, and public key infrastructure (PKI). At the heart of this trust, it relies on digital certificates certified by a trusted certificate authority (CA) and digital signature techniques to deliver two critical benefits.

  1. Strong authentication of the publisher of the code.

  2. A cryptographic seal, a ’hash’, which mathematically identifies the content of the document so that even the smallest change to the code will invalidate the signature—thus making the code tamper-evident.  

These techniques are underpinned by the use of one or more private keys to sign and time-stamp the published software. The protection of private keys is essential in securing any PKI application, including Authenticode. If the secrecy of these keys were to be compromised, they could be used to fraudulently sign software that can then masquerade as the legitimate application.

Protecting keys within Hardware Security Modules (HSM) provides physical and logical barriers to attack that do not exist with a software-only security solution. The keys never exist in an unencrypted form outside the HSM and all operations with the keys occur within the HSM. Authenticode code-signing keys are bound to a digital certificate that identifies the publisher. Time-stamping is an essential component of the Authenticode code-signing process. It establishes that the code-signing took place at a specific point in time, specifically during the period for which the signing certificate was valid, thus extending the validity of the code past its certificate expiration date. However, such a time-stamp will only have value if it can be tied to a recognized source of time and if the time values are protected from manipulation when in transit from a recognized time authority or when applied to the signed code.

This paper presents an overview of Authenticode, examines some of the cryptographic techniques that underpin the solution, and looks at the role of cryptographic hardware in providing a robust platform for trusted code.

Authenticode Overview

To establish trust in software, it is vital that the following problems are addressed.

  • Authenticity—so that the user can verify the identity of the publisher of the code.

  • Integrity—so that the user can verify that the code has not been changed since its publication date.

Authenticode allows developers to include with their programs information about themselves and their code with their programs through the use of digital signatures. It enables identification of the publisher of signed software and verification that the software has not been tampered with before end users download the code. As a result, end users can make a more informed decision about whether code is safe to download.

An example of Authenticode use is found in Microsoft Internet Explorer. By default, it will not permit unsigned ActiveX code, or signed ActiveX code that has been tampered with, to be downloaded. Before signed ActiveX code is downloaded, the publisher’s certificate is displayed in a dialog box, and the user must click to accept and complete the download based on the information presented. The following figure illustrates the Authenticode dialog box in Microsoft Windows XP SP2.

security dialog

Windows Software Restrictions Policies provide another example of the use of Authenticode in Windows XP and Windows Server 2003. In this scenario, a group policy can be set by the administrator that only permits code signed with specific certificates to load and execute across the enterprise, thereby minimizing the organizational risk of exposure to malicious code.

Authenticode makes use of cryptographic techniques to verify identity. It combines digital signatures with an infrastructure of trusted entities that includes Certification Authorities (CAs), to assure recipients that data does indeed come from the stated publisher. Signing code does not alter it; it simply generates a digital signature string that can be bundled with the code.

It is important to understand that while Authenticode enables a strong identity/trust model for end users, it does not guarantee bug-free code.

Digital signatures are created using a public-key signature algorithm such as the RSA public-key cipher. A public-key algorithm actually uses two different keys—the public key and the private key (called a key pair). The private key is known only to its owner, while the public key can be available to anyone. Public-key algorithms are designed so that if one key is used for encryption, the other is necessary for decryption. Furthermore, the decryption key cannot be reasonably calculated from the encryption key. In digital signatures, the private key generates the signature and the corresponding public key validates it.

In practice, public-key algorithms are often too inefficient for signing large files. To save time, digital signature protocols use a cryptographic digest, which is a one-way hash of the file. The hash is signed instead of the file itself. Both the hashing and digital signature algorithms are agreed upon beforehand.

The following summarizes the process.

  1. A one-way hash of the file is produced.

  2. The hash is encrypted with the private key, thereby signing the file.

  3. The file and the signed hash are transmitted.

  4. The recipient produces a one-way hash of the file.

  5. Using the digital signature algorithm, the recipient decrypts the signed hash with the sender's public key.

If the signed hash matches the recipient's hash, the signature is valid and the file is intact.

Using Authenticode, the publisher signs the code, tagging it with a digital certificate that verifies the identity of the publisher and also provides the recipient of the code with the ability to verify the integrity of the code. A certificate is a set of data that identifies the software publisher [in the way that a Secure Sockets Layer (SSL) Certificate identifies a Web site]. It is issued by a CA only after that authority has verified the software publisher’s identity. The certificate data includes the publisher’s public cryptographic key. The certificate is typically part of a chain of such certificates, ultimately referenced to a well-known CA such as VeriSign or GeoTrust. When the code is distributed across the Internet, the end user can, before downloading the code, review the authenticity of the code-signing certificate. A well-designed application will construct a chain of certificates up to a trusted root CA. Code is executed only if the identity of the publisher can be validated, and after user consent.

Digital certificates have a finite life span. Upon expiration of the code-signing certificate, the user platform may prevent code from executing. To prevent a platform denying code execution because of this reason, a time-stamp is used by the publisher to fix or notarize a valid code certificate signature to a specific moment in time.

  • This ensures the long-term validity of a code-signing certificate by verifying that the executable file was signed when a valid code certificate was in place.

  • This does not permit the use of an expired certificate to sign code.

  • This permits a CA to revoke a code-signing certificate without affecting the files it signed before the key was compromised. In the same way that the code-signing certificate is part of a chain of certificates, the associated time-stamp certificate is also chained to a trusted CA permitting the recipient to easily verify the authenticity of the time-stamp.

The following is an example of how the time-stamp is secured.

  1. The hash of the publisher signature is sent to the Time-Stamp Authority (TSA).

  2. The TSA then generates a second digital signature using the TSA certificate and private key.

  3. Authenticode then stores the time-stamp signature in the signed file.

When software (code) is associated with a publisher's unique signature, distributing software on the Internet is no longer an anonymous activity. Digital signatures help to ensure accountability, just as a manufacturer's brand name does on packaged software. Organizations or individuals who use the Internet to distribute software have a responsibility to ensure the authenticity and integrity of their software. Authenticode provides a means to verify the status of downloaded code. This accountability helps users to make better decisions about what software to run.

The Difference Between Authenticode and Strong Names

A strong name is a unique identifier for code that is based on public key cryptography that does not require PKI infrastructure. Since no CA has validated the code publisher’s identity, it is not possible for most users to make a trust decision based on the strong name alone. With Authenticode, the publisher identity has been verified by a CA and certified using an X.509 certificate. As long as the user trusts the CA that issued the certificate, the user can be assured of the origin of the code.

Protecting Signing Credentials

Authenticode relies on proven cryptographic techniques and the use of one or more private keys to sign and time-stamp the published software. It is important to maintain the confidentiality of these keys. Should they be compromised, they can be fraudulently used to sign malicious code, which, to an end user, would appear to be legitimate, endorsed by a valid digital signature. It can result in the delivery of code containing a Trojan or virus, resulting in significant disruption—including legal and financial loss. Therefore, the cryptographic keys that are at the heart of the Authenticode process must be well-protected.

Access to digital keys may be controlled by either hardware or software. With software protection, the keys reside in memory within the server that is responsible for the Authenticode process, where they are more susceptible to malicious attack and may be stolen.

It is a recommended security best practice to store keys within the confines of a hardware security module. When access controls are enforced in hardware, distinct physical and logical barriers are erected to protect the keys. The keys are protected with an HSM, which is a physically separate device connected to the server, internally or externally. The HSM contains physically separate and protected memory in which the keys reside. The keys never exist in an unencrypted form outside the HSM and all cryptographic operations take place within the HSM. The keys are therefore resistant to attack.

Hardware-based cryptography protects the private keys by only exposing them as plaintext within the secure confines of a tamper-resistant HSM. Cryptographic keys are best protected from misuse by using a Federal Information Processing Standard (FIPS) 140-2 Level 3–validated module. An HSM should support the following security features.

  • All cryptographic functions should take place within a FIPS 140–validated HSM.

  • Critical private and secret cryptographic keys should never appear in plaintext outside the boundary of the cryptographic module.

  • Multi-factor authentication should be used. This typically uses threshold sets of smart cards, where 'k of n' cards must be presented to enable a particular feature or to authorize a specific function, together with individual pass phrases for each card.

  • Responsibility should be split so that authorization for specific tasks can be shared between multiple security officers, avoiding an over reliance on a single individual.

  • Separation of roles should be used to ensure that administration and operational functions are split, avoiding a reliance on a single 'super-user' with excessive access rights.

  • Private keys should be secured and backed up using standard IT practices and policy. During the back up process, keys must never be exposed as plaintext outside of the HSM.

  • Disaster recovery should be in place so keys can be recovered easily and securely by initializing a new HSM should an existing module be damaged or stolen.

Time Is Key

Even the strongest cryptographic keys are theoretically capable of being compromised given sufficient time and effort. Hence, it is a standard security best practice to ensure that all certificates, including those used for code-signing, has a finite lifetime, typically a year or so. At the end of this period, the software must be re-signed with a new key (with associated certificate) to ensure its continuing trustworthiness. As most software is designed to have a lifetime considerably greater than this period, it creates a problem and an associated cost when the certificate expires. The existing software will not be verified and therefore may fail to execute within the customer’s environment.

Authenticode solves this problem through the use of timestamping which binds a time-value to the signed software and then signing this again with another (time-stamp) private key. This establishes that the signing action took place at a specific point in time and during the period for which the code-signing certificate was valid. A time-stamp signature can be verified at any point beyond the time of signing, permitting the customer’s software to execute, even though the associated code-signing certificate may have expired. In addition, if a code-signing key had been compromised and the corresponding certificate had been revoked, a time-stamp could be used to establish if the signing took place before or after the certificate was revoked. Thus, time-stamping allows a software publisher to avoid the costs and issues associated with re-signing and re-issuing software, ensuring published software can be validated indefinitely.

Given the potential value of code, it is important that organizations implement an Authenticode process that has a reliable time infrastructure. In practice, this means that they must be able to access their chosen time source whenever required. They must also be satisfied that sufficient security controls are in place to maintain the integrity of the time values from original source to the point at which a time-stamp is applied. Typically risk assessment will determine whether an organization chooses to access a third-party TSA, or whether time-stamp control is retained in-house.

To obtain the maximum value of the Authenticode time-stamping process, a number of important requirements should apply.

The first requirement is that the time used must reference a standard agreed definition of time, which has the same meaning anywhere in the world. A common time standard enables verification of a time-stamp against a standard time, and that there is agreement within some defined tolerance when comparing times.

The development of the railways in the late 19th century required a means of time synchronization at different localities. The standard system of time zones was invented in 1878 with all time within a zone being set to the same value, based on Greenwich Mean Time (GMT). With the advent of atomic clocks in the 1960s, a new definition of time was established based on the atomic periodicity of radiation in a Cesium-133 atom. This International Atomic Time (TAI) standard is based on an averaging of the measurements from many atomic clocks sited at National Measurement Institutes (NMIs) around the world and is the basis for Coordinated Universal Time (UTC), the modern successor to GMT. Basing time-stamps on UTC provides a common, standard reference point for establishing the long-term validity of the Authenticode signing process.

The second requirement is that the time value must be delivered from the NMI to the point at which the time-stamp is being applied in a manner that ensures its integrity and allows its relationship to UTC to be proven.

A number of mechanisms are used for the dissemination of time. A popular method is for a computer to acquire time from a network or peer machine using the Network Time Protocol (NTP). An NTP server installed at an NMI can provide UTC to distant computers over the Internet. However, Internet addresses are easy to forge and remote users cannot be certain of the authenticity of the NTP server to which they are connected. Even when server authenticity can be established, there is no way for a software publisher to assure a customer that the time used was indeed UTC. The time-stamp will contain no record of where the time came from or how it relates to UTC.

Similar problems occur using other time synchronization techniques such as direct dial-up of a time server over a modem or acquisition of time from the Global Positioning System (GPS) satellite network. All these transport mechanisms suffer the same inherent weaknesses—poor security during transmission and lack of a strong credential for binding to an official UTC source. A mechanism that addresses these weaknesses is required to ensure the value and integrity of UTC within a time-stamp. In particular, any transport mechanism needs to incorporate mutual authentication of the end points and encryption of the transported UTC values between end points. This ensures the secure delivery of time to the point of use. Additionally, some form of certification is required that proves the UTC received at the point of use is from an official NMI.

The final requirement is that the process of applying time and its binding to the software must occur within an environment that is secure from fraudulent manipulation.

This implies that both the keys and the software that implements the time-stamping process itself must be afforded strong protection. Executing the code and storing the keys in a hardware device that is physically separated from the main server and provides additional levels of tamper protection is recommended as a best practice.

Authenticode and nCipher

nCipher hardware provides a trusted system for protecting the credentials of the software publisher used by Authenticode during code publication. These credentials comprise the code-signing key, the TSA key, the Time Attributes, and the respective certificates.

  • nCipher’s nShield or netHSM can be used to secure the code-signing key within an industry standard FIPS 140-2 Level 3–validated HSM. Managing these keys in hardware removes them from vulnerable servers, protecting them from key-finding attacks.

  • The nCipher DSE 200 provides a secure Authenticode time-stamp service, protecting the TSA key, the TSA Certificate, and the Time Attribute Certificate (TAC) that attests to the calibration of time within the DSE 200. These credentials are protected within the confines of a FIPS 140-2 Level 3 HSM.

nShield and netHSM Hardware Security Modules

nCipher’s range of HSMs protects cryptographic keys in a highly secure hardware environment, enabling them to be effectively managed and safely stored. The modules are certified to FIPS 140-2 Level 3. (FIPS 140-2 is an established standard for the validation of cryptographic modules published by the National Institute of Standards and Technology (NIST).) The FIPS 140-2 certification is especially relevant in the US federal government and financial markets where security policies frequently mandate FIPS-certified products. For more information about FIPS 140-2, see the NIST Web site at https://csrc.nist.gov/cryptval/140-2.htm. This includes the nCipher NIST-approved evaluations. Both the nShield and netHSM support nCipher’s Secure Execution Engine (SEE) technology allowing the HSM to manage and execute application-level software within its protected cryptographic boundary.

The nShield and netHSM modules both support the Microsoft Cryptographic API (CryptoAPI) to provide cryptographic services to applications like Authenticode.

DSE 200

The DSE 200 is fundamental to an Authenticode implementation by removing the traditional reliance on the system clock, which is vulnerable to tampering. The DSE 200 provides an accurate and verifiable time-stamp, produced within the tamper-resistant boundary of the nCipher DSE 200 appliance. The DSE 200 is designed to operate with independently provided calibration and audit services. These services offer traceable and secure links to official UTC sources, such as the source maintained by NIST. Once calibrated via an authenticated secure network connection, the DSE 200 is ready to provide time-stamps to Authenticode-compliant requests.

The DSE 200 uses a secure transport protocol, incorporating mutual authentication, to establish a secure link to a clock at an NMI. The cryptographic keys used in this authentication process are secured in a FIPS 140-2 Level 3 HSM, ensuring that time values cannot be compromised in transit.

The transport protocol also incorporates an automatic process for auditing and calibration to synchronize time. At the end of the process, the NMI-secure clock issues the DSE 200 with a signed certificate (TAC) attesting to the calibration and traceability of the time. This certificate establishes the trustworthiness of the time value that will be used in the time-stamp, by certifying its relationship to UTC. This certificate is in turn embedded within the time-stamp ensuring that a software publisher’s customer can audit the pedigree of the time value.

authen01.gif

Summary

Creating user trust in code published over the Internet demands two elements of proof.

  • That the publisher is who they say they are.

  • That the software has not been altered since publication.

Authenticode provides mechanisms to identify the publisher of signed software and to verify the integrity of the software before users download it to their PCs. Authenticode relies upon public key technology to sign and time-stamp code prior to publication. In turn, trusted code relies upon a sufficient level of protection being given to the underlying credentials, the keys and certificates, behind Authenticode.

The combination of Microsoft Authenticode with nCipher cryptographic hardware provides a code-publishing solution that delivers strong authentication of the publisher to end users and provides assurance of the integrity of code.

Authenticode’s support for nCipher’s hardware delivers the following security enhancements.

  • Publishers’ private signing keys and associated certificates are protected within industry-standard hardware security modules.

  • Code-signing and time-stamping operations are performed within a certified FIPS 140-2 Level 3–validated cryptographic boundary.

  • Calibration is certified to a recognized UTC source.

  • UTC from a National Measurement Institute is securely delivered to a dedicated time-stamping appliance.

Acknowledgements

David Cross, Tom Albertson, David Kennedy - Microsoft Corporation

Richard Moulds - nCipher

See the following resources for further information.

For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at https://www.microsoft.com/windowsserver2003

For the latest information about Microsoft Windows PKI, see the Windows 2003 Public Key Infrastructure Web site at https://www.microsoft.com/PKI * *

1 Source mi2g quoted in eweek, December 6, 2004.