This section is a general introduction to code signing. Later, we will discuss Microsoft's technology, called Authenticode, which helps developers to easily sign their code.
One of the larger questions facing the software industry is this: How can users trust code that is published on the Internet? Currently, most Web pages contain only static information, but soon they will be filled with controls and applications that are downloaded and run locally, on the user's computer.
Packaged software uses branding and trusted sales outlets to assure users of its integrity, but these are not available when code is transmitted on the Internet. Additionally, there is no guarantee that the code hasn't been altered while being downloaded. Browsers typically exhibit a warning message explaining the possible dangers of downloading data, but do nothing to actually see whether the code is what it claims to be. A more active approach must be taken to make the Internet a reliable medium for distributing software.
There are two issues that must be addressed:
Microsoft's solution to these issues is Authenticode coupled with an infrastructure of trusted entities. We will discuss the infrastructure later in this document, when we explain certification authorities. Authenticode, which is based on industry standards, allows developers to include information about themselves and their code with their programs through the use of digital signatures.
You use digital signatures when you have data you want to distribute, and you want to assure the recipients that it does indeed come from you. Signing data does not alter it. It simply generates a digital signature string you can bundle with the data.
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. (These are called a key pair.) The private key is known only to its owner, while a 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 reasonably be 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 long documents. To save time, digital signature protocols use a cryptographic digest, which is a one-way hash of the document. The hashed document is signed instead of the document itself. Both the hashing and digital signature algorithms are agreed upon beforehand. Here is a summary of the process:
If the signed hash matches the recipient's hash, the signature is valid and the code is intact.
When code is associated with a publisher's unique signature, distributing software on the Internet is no longer an anonymous activity. Digital signatures assure accountability, just as a manufacturer's brand name does on packaged software. If an organization or individual wants to use the Internet to distribute software, they should be willing to take responsibility for that software. This approach is based on the premise that accountability is a deterrent to the distribution of harmful code.
Public keys, because they are public, are vulnerable to attack. In particular, an unscrupulous individual may want to substitute one public key for another.
For example, if Microsoft wants to send an encrypted message to Bob, an independent developer, it goes to the public-key database and gets Bob's public key. Unfortunately, Bob has a rival named Trent. Trent is not only a rival, but a sneak as well. He has substituted his own key for Bob's in the public-key database. Microsoft encrypts a message in Trent's key and sends it to Bob. Trent intercepts the message, decrypts it, and reads it. Finally, he re-encrypts it with Bob's key and sends it on to Bob. Neither Bob nor Microsoft know what has happened.
Public-key certificates are used to prevent this situation. A certificate is someone's public key, signed by a trustworthy person or organization. If Bob has a certificate in the database, it contains much more than his public key. It contains information about Bob, such as his name and address, and it is signed by some entity Microsoft trusts.
Trustworthy persons or organizations are called certification authorities (CAs). Certificates are verified through a hierarchy of these CAs. Each certificate is linked to the certificate of the CA that signed it. By following this hierarchy, or verification path, to a known, trusted CA, you can be assured that a certificate is valid. An example of this is illustrated in the following diagram.
Sample Certification Hierarchy
In this example, Netwerks's certificate is certified by CA1 while Bob's is certified by CA3. Netwerks knows CA1's public key. CA2 has a certificate signed by CA1, so Netwerks can verify the CA2 certificate. The root also has a certificate signed by CA1. CA3 (Bob's CA) has a certificate signed by the root. By moving up the verification chain to a common point (in this case, the root), Netwerks can verify Bob's certificate.
Certification authorities have two main duties:
Other duties may include:
Local Registration Agencies
Companies that don't want to take on all the responsibilities associated with being a CA can become a local registration agency (LRA). The LRA views enrollment requests, verifies evidence, and passes on the approved request to the signing CA. The relationship between a CA and an LRA can vary depending on their arrangement, which is specified in a contract.
A possible LRA would be a university acting on behalf of its students. Any university could verify whether a student is actually enrolled and, consequently, could easily approve certificate requests.
Umbrella Organization
It is important that the software industry endorse both the policies that allow CAs to participate, and the criteria that define a responsible commercial or individual software publisher. To ensure this industry cooperation, Microsoft is working to establish an umbrella organization. Over time it is expected that a consortium of industry partners and certificate authorities or an industry organization similar to the Software Publishers Association or the World Wide Web Consortium will fill this role.
To obtain a certificate from a CA, a software publisher must meet the criteria for either a commercial or an individual publishing certificate, and submit these credentials to either a CA or an LRA. The criteria we will discuss are those proposed by Microsoft. Please note that standards bodies such as the World Wide Web Consortium are reviewing them and they are subject to change. We will then describe the overall process of obtaining a certificate for code signing.
Applicants for a commercial software publishing certificate must meet the following criteria:
Two immediate questions are how do large software publishers determine who should apply for certificates and who should sign code? The answer depends on how the software publisher wants to control distribution of software on the Internet.
In a centralized approach, where the company wants total control of what code is published, there may be only one certificate, and strict guidelines for releasing code through one source. Other software publishers may allow each division, or even smaller groups or individuals within the company, to sign their own code using the corporate name. The point is that the software publisher must decide who can apply for a certificate and sign code and who takes responsibility for any code signed using certificates that bear the corporate name.
Using the Dun & Bradstreet rating as a criterion draws a line between "commercial" and "individual" developers. The intended distinction is between commercial persons or entities (that is, sole proprietors, partnerships, corporations, or other organizations that develops software as a business) and non-commercial persons or entities (that is, individuals or nonprofit corporations).
Applicants for an individual software publishing certificate must meet the following criteria:
The value of an individual software publishing certificate is in the information it provides to users so they can decide whether or not to download the code. Knowing who authored the code, and that the bits have not been altered from the time the code was signed to the present, is reassuring information. Additionally, a browser could provide links to a publisher's Web pages so the user can obtain detailed information about the signed code, the author, and the certificate authority. After learning about this code and the author, the user may decide to run the code, or all future code, coming from this particular individual.
The process of applying for certification is summarized in the following diagram.
These are the steps to apply for and grant a certificate:
1. Apply for a software publishing certificate
In this diagram, a software publisher's request for certification is sent to the local registration agency. (In a simpler model, it is sent to the CA.) It is expected that CAs and LRAs will have Web sites that step the applicant through the application process. Applicants will be able to look at the entire policy and practices statements of the CA or LRA. The utilities an applicant needs to generate signatures, such as Microsoft's Authenticode, should also be available.
The applicant must generate a key pair using either hardware or software encryption technology. The public key is sent to the LRA during the application process. For individuals, all of the necessary information can be transferred on-line. For commercial publishers, because of the identity requirements, proof of identification must be sent by mail or courier.
2. Verify the applicant's credentials
Depending on the contract between the CA and the LRA, these companies will examine the evidence to verify an applicant's credentials. To do this, they may employ external contractors such Dun & Bradstreet.
3. Generate and issue the software publisher X.509 certificate
After the CA has decided that the applicant meets the policy criteria, it generates a Software Publisher Certificate (SPC) that conforms to the industry standard X.509 certificate format with Version 3 extensions. This certificate, which is distributed in the digital signature for the software, identifies the publisher, contains the publisher's public key, and is used to verify that the file has not been modified since it was signed. It is stored by the CA for reference and a copy is returned to the applicant via electronic mail.
The publisher should review the contents of the certificate and verify that the public key works with the private key. After accepting the certificate, the publisher should include a copy in all published software signed with the private key.
Commercial developers can expect a response to their application in less than two weeks. While there is no limit to the number of certificates commercial software publishers can obtain, it is up to the publisher to determine who gets a certificate, and how code is signed and distributed.
4. Distribute signed software
The publisher can now begin signing and distributing software on the Internet. Publishers use utility programs to sign the software they intend to publish. The utility programs use the private key to generate a digital signature on a digest of the binary file and create a signature file containing a PKCS #7 signed-data object. (For more information about PKCS #7, see the RSA specification listed in the "Suggested Reading" section of this document.) The PKCS #7 signed-data object also contains a copy of the X.509 software publisher certificate. For portable executable (PE) image format files, the PKCS #7 signature file contents are stored in the binary file itself, in an additional section.