Download Microsoft Word (.DOC) format of this document (zipped, 31.3K).Revision 1.1
April 1996
Microsoft Corporation
Download Microsoft Word (.DOC) format of this document (zipped, 31.3K).
Problem Statement
Approach
Program Overview
Certificate Authority Infrastructure
Application Process
Costs
User Experience
Implementation Information
Flexibility and Future Extensions
Feedback
One of the larger questions facing the software industry over the next few years is how end users and corporations will "trust" code downloaded from the Internet. Unlike store-bought software, there is no shrink-wrap packaging or brand recognition, so the user is not able to discern who authored and published the code, or whether the code has been altered en route through the Internet to the client system. Currently, most Web pages contain static information, but in the near future these pages will be filled with controls and applications that will be downloaded and run locally. When users download now, they are greeted with an ominous dialog that warns of the consequences of running the code, but also lets them do so if they choose. There is much room for improvement.
The code signing program puts in place the infrastructure and mechanisms based on cryptographic public and private key technology using X.509 certificates and PKCS #7 industry standards to allow end users and corporations to develop some measure of "trust" in code downloaded from the Internet. End-users should always be given options on handling the code, but with code signing they are able to identify and obtain information about the software publisher, and be reassured that the integrity of the software has been maintained from vendor to client. It is a goal of the entire computer industry to prevent the distribution of software viruses and other malicious activities. To achieve this, the code signing program employs digital signatures.
Using a digital signature does not prevent bugs in code, nor does it constitute anti-virus medicine, but it can set up an environment in which users can trust the software publishers and individual developers who produce signed code. The approach here is accountability--to cease having publication of software on the Internet be an anonymous activity. If an organization or individual wants to use the public Internet to publish software, they should be willing to take public responsibility for the code they author and publish. If the code proves to have errors or even malicious faults, these organizations and individuals should be willing to answer for them just as they would take credit for good code. This approach is founded on the idea that accountability is an effective deterrent to the distribution of harmful code.
Two other important goals of this code signing program are to build an open industry standard, and to make the standard work across all platforms. Microsoft is actively pursuing the participation of other influential software industry members and standards bodies to develop facets of this code signing program into a standard. Specifically, the criteria for what constitutes a responsible software publisher, and the format of the digital certificates and signatures (which use standard X.509 and PKCS #7 formats) are the areas which will greatly benefit the software industry if they become standardized. To help achieve the cross-platform goal, Microsoft will publish specifications that allow other platform vendors to implement the program.
The code signing program is defined to meet the following goals:
An important element of this program is the set of policies governing what defines a responsible software publisher. What criteria need to be met by software so that programs made available by those groups via the Internet are viewed to be as safe as shrink-wrapped software in any computer store?
This proposal outlines two separate sets of criteria for commercial and individual developers. Currently, corporations in the business of developing software, regardless of their size, have the incentive to employ good quality-assurance practices because they are answerable to their customers. They risk reputation and future business--the bottom line--when their reputation is tarnished. End users understand this reasoning and expect quality products from corporate publishers, as evidenced by their willingness to buy and use shrink-wrapped software. Publishers classified as "individual" software publishers have similar goals; however, their economies of scale and means require a different approach. And while the distinction and resulting "commercial" and "individual" categories are necessary, the apparent disadvantage of this distinction boils down to the need for businesses and end users to make their own decisions on how they utilize these categories of signed code in their environments. The platform implementation will distinguish between these categories of signed code and allow these businesses and end users to make decisions.
Applicants for the Commercial Software Publishing Certificate must meet the following criteria for code signing privileges:
In utilizing the D&B rating as a requirement, the distinction has been drawn between "commercial" and "individual" developers. The intended distinction is between commercial persons or entities (such as a sole proprietor, partnership, corporation or other organization that develops software as a business) and non-commercial persons or entities (such as individuals or nonprofit corporations). The other requirements firmly establish identity, and ensure that corporations use a relatively secure method of storing their private key.
Applicants for the Individual Software Publishing Certificate must meet the following criteria for code signing privileges:
![[AUT2091B 7490 bytes ]](/workshop/prog/signcode/AUT2091B.GIF)
Figure 1. Certificate Authority infrastructure
Certificate authorities (CAs) publish policies and act to grant code signing authority (certificates) based on meeting criteria established in the policy. Other CA duties include managing certificates (enrollment, renewal, and revocation), storing root keys, verifying evidence submitted by applicants, providing tools for enrollment, and accepting the liability associated with handling these items. CAs are an important element of this program as they ensure that all software publishers are working according to the same set of rules.
The figure above illustrates the CA hierarchy that is expected to develop over time, including the possibility of branding by well-established organizations that want to get into the CA or registration agency business. It is expected that more CAs and local registration agencies will get into the business as other opportunities in the area of digital signatures emerge.
Companies not wanting to take on the tasks associated with being a CA may become local registration agencies (LRAs). The LRA views enrollment requests, verifies evidence, and passes on the approved request to the signing CA. The CA and the LRA may vary on the terms of their arrangement, which is structured in a contract.
A good example of this is a university acting as an LRA on behalf of its students. Any university could easily verify whether a student was enrolled in the university and consequently easily approve certificate requests.
It is important that the software industry endorse both the policies that allow CAs to participate, and the criteria that define a responsible commercial and individual software publisher. To handle these tasks, 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 like the Software Publishers Association (SPA) or World Wide Web Consortium (W3C) will fill this role.
![[AUT2091C 2781 bytes ]](/workshop/prog/signcode/AUT2091C.GIF)
Figure 2. Steps in the application process
1. Publisher applies for a software publishing certificate
In the diagram above, a software publisher's application request is sent to the local registration agency, which in a simpler model could be the CA. It is expected that CAs and LRAs will have Web sites that step through the appropriate application process for an individual or commercial software publishing certificate. Applicants will be able to look at the entire policy and practices statements of the CA/LRA, which should include the base elements of the code signing policies of this program. The application process requires that the applicant generate a private/public key pair using either hardware or software encryption technology. The applicant's public key is sent to the CA in the application process. In the case of applying for an individual software publishing certificate, all of the information can be transferred online, but because of the identity requirements of the commercial policy, proof of identification must be sent through mail or courier.
2. CA verifies the applicant's credentials
Based on the contract between the CA and the LRA these companies will examine the evidence to validate that the applicant meets the criteria. In performing this task they may employ external contractors such D&B and TRW.
3. CA generates and issues the software publisher X.509 certificate
After the CA has decided that the applicant meets the policy criteria, they generate a software publisher certificate containing the applicant's public key. The certificate issued by the CA is an industry standard X.509 certificate format with version 3 extensions that identify the use for software publishing. The certificate is stored by the CA for reference and a copy is returned to the applicant using electronic mail. The publisher should review the contents of the certificate and verify that the public key matches their private signing key. After accepting the certificate, the publisher includes a copy of the certificate in all published software signed with the private key. At this point, the publisher may begin signing and safely distributing software on the Internet. In the case of the individual developer the entire application process should take less than an hour and be accomplished online, while for the commercial developer it should take less than two weeks. For commercial software publishers there is no limit to the number of certificates they can obtain, but it is up to the publisher to determine who gets a certificate, and how code is signed and distributed.
4. Publisher verifies the certificate contents and begin signing software
Publishers use utility programs to sign software they intend to publish on the Internet. The utility programs use the private signing key to generate a digital signature on the binary image and create a signature file containing PKCS #7 signed data. The PKCS #7 signed data also contains a copy of the X.509 software publisher certificate. For PE image-format files, the PKCS #7 signature file contents are stored in the binary file itself, in an additional section of the image file.
The private signing key is held by the corporation or individual and kept secret. The development platform should include tools that work in conjunction with encryption software or hardware to actually sign the code. The software publisher certificate identifies the publisher and is distributed in the digital signature for the software. The certificate contains the public key of the publisher and is used to verify that the image has not been modified since it was signed.
The expected cost of the commercial software publishing license is $400-$500 for a year. After one year the certificate may be renewed annually for about three-quarters the amount. The expected cost of the individual software publishing license is $20/year. A certificate allows the software publisher to sign an unlimited number of code modules. Additional costs for commercial developers will be incurred for the hardware device to generate and store keys, which range from about $200 for a PCMCIA Crypto token device to $12,000 for a BBN SafeKeyper. The more expensive devices offer the more secure methods of private key storage.
For corporations not wanting to invest in hardware there will most likely be signing agencies that allow them to outsource this capability. This may be a viable alternative for companies that will not be producing and distributing large amounts of code on the Internet.
The initial Win32® implementation will give users choices of how to handle the categories of signed code. For a typical browser application that may download code, the user will be able to run signed code with or without UI intervention. In the case where UI intervention is desired, signed code will display the name of the software, the "identity" of the publisher, and the issuing certificate authority. The user will be allowed to view detailed information about the publisher and the certificate authority and subsequently choose to run this category of signed code without UI intervention.
The following two specifications on code signing were distributed at the Microsoft Professional Developers Conference (March 1996) and are now available in draft form on this Web site:
There is considerable flexibility within the architecture for operating system-specific details. For example, while Microsoft expects to hard-code trust of the top of the CA hierarchy into its first products utilizing this code signing model, the architecture doesn't require this approach. The architecture is a cross-platform solution. End users or system administrators could be given considerable control over which software vendors and individual developers they wish to trust and which they choose not to trust.
Also, although it is important to establish an industry accepted policy to which software companies will be held accountable, it is expected that additional, more specific policies will be added to these basic code signing policies in the future. For example, a Big Eight accounting firm may wish to establish a "Platinum" policy directly related to the Accounting Package software rating. This rating might then be used within the accounting industry to indicate that software packages under this policy are guaranteed to meet certain industry accepted guidelines, or, in the lingo of accountants, "generally accepted accounting practices."
Because this is a proposal, it is intended to elicit feedback concerning the goals, approach, accompanying infrastructure, and implementation of the code signing program. Our goal is to gain industry endorsement and participation in this program. The alias safecode@microsoft.com has been set up to provide an avenue for feedback on the proposal, and to allow Microsoft to respond to your comments.
Return to the Code Signing home page