Created: August 9, 1996
Revised: February 17, 1997
Microsoft Corporation
What is Authenticode?
As a Microsoft Internet Explorer End User, How Do I Use Authenticode?
As a Developer, How Do I Sign My Code?
How Does Authenticode Work with Other Technologies?
What Are the Elements of Microsoft Code Signing?
As a Developer, What Are Some Technical Points to Keep in Mind When Signing Code?
Support for Authenticode™ technology through Microsoft® Internet Explorer 3.0 lets end users identify who published a software component and verify that no one tampered with it before downloading it from the Internet. Authenticode assures end users before they download signed code from the Internet of the identity of the software publisher and that the code has not been altered after the signature was applied—an approach that is more secure than the use of holograms and shrink-wrap used in retail stores today. While physical packaging can be counterfeited or tampered with, Authenticode lets users know when code has been tampered with.
While not guaranteeing bug-free code, Authenticode technology is designed to identify the publisher of the code and to assure end users that software has not been tampered with before or during the download process.
The security methods used to support this proposal rely on tested and proven technology. Authenticode is based upon specifications that have been used successfully in the industry for some time, including PKCS #7 (encrypted key specification), PKCS #10 (certificate request formats), X.509 (certificate specification), and SHA and MD5 hash algorithms.
The most comprehensive source of information about Authenticode technology can be found on the Microsoft Security Advisor site at http://www.microsoft.com/security/. The Authenticode section of this site outlines the code signing program and code signing procedures for developers. Other sources of information include:
Display of this software publisher certificate means that end users can identify who published this piece of software and know that it has not been altered or tampered with since it left the software publisher. Given this information and assurance, end users can decide whether or not they want to download this software from the Internet.
Internet Explorer 3.0 allows end users a broad range of options for using Authenticode. End users can decide how Internet Explorer should treat potentially unsafe code—that is, code that doesn't have a valid software publisher's certificate associated with it—by clicking Options from the View menu, clicking the Security tab, and then setting the Active content safety levels.
The default setting of "high" means that Internet Explorer will not allow end users to download potentially unsafe code, but does give end users the option of downloading software components that have a valid signature. It is highly recommended that users keep their safety settings at "high." However, if expert users feel safe visiting their favorite Web sites or are in a corporate environment that is not connected to the Internet, they might switch this safety level to "medium," so that Internet Explorer will notify them of potentially unsafe code, but let them download it nevertheless. At a safety setting of "none," Internet Explorer will not notify users of potentially unsafe code; this setting is not recommended under any circumstances.
This is a decision that should be based on the end user's own judgment. For instance, if the end user has downloaded software from a particular site before and believes that this software can be trusted not to have been tampered with or to behave maliciously, then the end user may decide to download code that has not been signed—that is, code that does not have a valid certificate associated with it. On the other hand, if the end user knows nothing about the software or the site from which it originated, the end user may choose not to download this piece of software.
Again, this decision relies on the end user's own judgment; however, the certificate provides end users with the data they need to make a more informed decision about this piece of software. If the end user has a great deal of trust in a particular software publisher, then the end user may decide to automatically download any software from this publisher through the settings provided in the Authenticode Security Technology dialog box. (On the View menu, click Options, click the Security tab, and then click Publishers . . .)
Personal, site, and publisher certificates are all used to prove identity over the Internet; however, these certificates are used within different contexts. Your personal certificate identifies you to Web sites and allows you to access secured content over the Internet. A site certificate assures you of a Web site's identity and is used for secure communications between you and the Web site. A software publisher certificate, as mentioned previously, identifies the publisher of a piece of software and ensures that the software hasn't been tampered with after it has left the software publisher.
Before downloading a signed piece of software, Microsoft Internet Explorer identifies the issuer of the software publisher certificate as a certificate authority for either individual or commercial publishers. Internet Explorer 3.01 further differentiates individual and commercial software publishers through the graphical presentation of the certificate to the end user in the Authenticode Security Technology dialog box.
Using the Internet Explorer Administration Kit, an administrator can preconfigure Internet Explorer safety settings, thereby setting the default manner in which Internet Explorer treats potentially unsafe code, e.g. code that does not have a valid software publisher certificate associated with it. In addition, through this Administration Kit, the administrator can control which Options settings the user can change. Hence, the administrator can prevent unsigned software from being downloaded to end users PCs.
These certificates are obtained from one of two sources: a certificate authority (CA) such as VeriSign or GTE can provide certificates, or a privately controlled certificate server can issue certificates as well.
VeriSign is now providing Digital IDs for use with Authenticode. GTE software publisher certificates will be available soon after the release of Internet Explorer 3.0. Please see "Digital Certificates for Authenticode" at http://www.microsoft.com/workshop/prog/security/authcode/certs.htm for more information regarding certificate authorities and getting your certificate.
VeriSign currently offers two types of software publisher Digital IDs: individual (Class 2) and commercial (Class 3). Please see the VeriSign FAQ page (http://digitalid.verisign.com/id_faqs.htm) for more information about these certificates.
International commercial software publishers can obtain a Digital ID for Commercial Software Publishers (Class 3) from VeriSign if they have a Dun & Bradstreet number or written proof of company registration.
Microsoft is working with VeriSign and other CAs to provide software certificate services for individual software publishers outside of the United States and Canada. At this time, these certificate services are not available. However, for the latest international availability of VeriSign Digital IDs for Individual Software Publishers, please see http://digitalid.verisign.com/.
To issue a commercial software publisher certificate, VeriSign must be able to authenticate the identity of the person and organization applying for the certificate. The most convenient method for a software publisher to establish organizational identity is to submit a D-U-N-S number from Dun & Bradstreet during the enrollment process.
If a software publisher does not have a D-U-N-S number, they can obtain one from a local Dun & Bradstreet service center quickly and at low cost. For more information about Dun & Bradstreet and getting a D-U-N-S number, please see the Dun & Bradstreet Web site at http://www.dnb.com/.
To ensure the commercial viability of a software publisher, Microsoft has arranged for VeriSign to check a company's D&B Financial Stress Rating as part of its authentication process. If a company's financial stress rating is 1, 2, or 3 (on a 5-point scale with 1 representing the lowest level of risk), the VeriSign Commercial Software Publisher (Class 3) Digital ID will indicate that the company has met Microsoft's criteria for identification as a commercial software publisher. If the company's rating is 4 or 5, VeriSign will undertake additional checking to determine whether the company meets commercial software publisher criteria. If no financial stress rating exists for a company, the Commercial Software Publisher (Class 3) Digital ID will indicate that.
In the event that a software publisher cannot get a D-U-N-S number, they can submit articles of incorporation to VeriSign (translated into English).
After software publishers enroll for their certificates, they can expect that their certificates will be issued within three to five business days.
Available through VeriSign, a Digital ID for commercial software publishers (Class 3) is priced at $400 per year. The price of a Digital ID for individual software publishers (Class 2) is $20 per year.
An individual certificate's cost will depend upon the pricing structure and policy of the issuing authority. If using an internal certificate server, the cost of the certificate will be determined by the company policy for departmental charge backs. If the certificate is obtained by a private party from a certificate authority (CA) (for example, VeriSign), the price will depend upon the type of the certificate and the pricing established by the CA.
End users can obtain code-signing certificates, but the same certificates cannot be used for both code signing and secure connections to Web servers. Software publisher certificates require additional criteria, such as a pledge attesting that the applicant will not sign code that is malicious. Initially, software publisher certificates need to be part of a specific certificate trust hierarchy that Windows® recognizes. See the Microsoft Security Advisor page "Proposal for Authenticating Code Via the Internet" (http://www.microsoft.com/security/tech/authcode/authcode-f.htm) for details on the corporate and individual policies.
Tools for signing code are available in the ActiveX SDK (MSDN Library, SDK Documentation). Developers can find these tools in the \bin directory after installing the ActiveX SDK.
In addition, developers can use Internet Explorer version 3.0 to test Authenticode. All Microsoft development tools will soon support Authenticode. Microsoft is also working with other tools vendors to ensure that they receive all of the specifications and assistance they need to implement code signatures.
Private and public keys are a matched set of keys created by the software publisher and used for encryption and decryption of the digest into the signature block. The software publisher uses the private key to encrypt the digest into the signature block. This key is never exposed to an outside party. The software publisher also creates the public key. It is verified as part of the certification process by the CA and distributed to the public in the signature block.
The keys are generated at the time the certificate is requested from a Certificate Authority. They are generated on your own PC, and your private key is never sent to the Certificate Authority or any other party.
Signing code is a very quick process and needs to be done only once, just before distribution. Software publishers can step through the code-signing process easily within a few minutes.
Microsoft Internet Explorer 3.0 supports downloading signed code.
Yes. The specifications were designed to be portable to other platforms, and the technology is not specific to Win32® or other Microsoft executables. Microsoft will focus on making this solution available on the Windows 95 and Windows NT® platforms first, and then Windows 3.1. Microsoft is committed to ensuring that this technology is implemented on the UNIX and Macintosh® platforms.
No. Authenticode technology produces a signature independent of any file format. Internet Explorer 3.0 supports Authenticode signatures for Win32 executables in addition to Java applets in .class file or .cab file format and ActiveX controls. Additional formats such as documents that contain macros and Macintosh operating system executables will be supported in future products.
Authenticode was not designed to provide copy protection for software. Rather, it was designed to ensure the source and integrity of software. Microsoft has not announced any plans to use digital signature technology to provide copy-protection capabilities.
Microsoft currently has the most secure sandbox available today in Internet Explorer 3.0 and will continue to add rich capabilities to it.
Code signing, as implemented through Authenticode, and the Java sandbox approach are complementary rather than competitive because they solve different parts of the security problem.
Microsoft currently has the most secure sandbox available today in Internet Explorer 3.0 and will continue to add rich capabilities to it. However, as published reports in the last six months have shown, sandboxing by itself is inadequate to offer a satisfactory level of security. Further, it is unlikely that sandboxing will ever be able to offer a rich enough set of capabilities for many applications. For that reason, Microsoft offers Authenticode as an additional level of security. Authenticode provides users with accountability because it positively identifies the publisher of a piece of code.
These two security methods augment each other. Some code will run fine within our robust sandbox, but signed code can be run with a higher degree of assurance, whether inside the sandbox or out. Users want their browsers to support both capabilities, and that is why Microsoft is shipping both in Internet Explorer.
Code signing is also an industry-wide initiative. In fact, Netscape and JavaSoft have publicly announced their intention to support it and the World Wide Web Consortium is currently discussing a Microsoft code-signing submission.
We had not considered signing Hypertext Markup Language (HTML) code or a whole page as a feature for the first release. However, software publisher and page authors have told us that this is a very compelling feature. It presents some unique problems, but we are investigating the possibilities and discussing potential solutions with vendors of authoring tools. We haven't made any announcements yet.
No. However, both Netscape and JavaSoft have publicly announced their intent to support code signing in future products.
A CA is a third party trusted by the industry, akin to a notary who handles electronic IDs. CAs provide the following types of services:
Anyone can be a CA or a sub-CA, if they are willing to provide these services. An example of a CA and sub-CA relationship is as follows: VeriSign may be a root CA providing full CA services. A university may want to provide certificates for all of the students in its master's program. The university may be in a good position to authenticate the identity of its students and may be willing to collect and track the necessary paperwork, but may not want to handle liability issues. Thus, the university might want to pass on the liability issues to a root CA such as VeriSign or GTE.
After developing and testing its code, a software publisher signs its code. For signing, the code is run through a one-way hash function that produces a fixed-length "digest." The digest is then encrypted with the software publisher's private key and combined into a signature block with the name of the hash algorithm and certificate (which holds the name of the publisher, the public key, name of the CA's certificate, and so on). This signature block is then inserted back into the portable-executable (PE) file format under a reserved section, and the code is distributed over the Internet.
When the user downloads the code, the downloading application calls the WinVerifyTrust API. The system extracts the signature, determines the CA who authenticated the certificate, and obtains the software publisher's public key distributed by that CA. The system then uses the public key to decrypt the digest. It runs the specified hash on the code again, creating a new digest. If the code has not been modified since it was signed, the new digest should match the old one. If the two digests don't match, either the code was modified, or the public and private keys aren't a matched pair. In either case, the code becomes suspect and the user is warned.
Microsoft proposes two sets of policies: commercial (corporate) and individual. Details of both policies are provided in "Proposal for Authenticating Code Via the Internet" on the Microsoft Security Advisor site (http://www.microsoft.com/security/tech/authcode/authcode-f.htm). To summarize:
These policies allow differentiation between commercial and individual software publishers, while enabling both types of publishers to sign their code. By knowing that a software publisher is a commercial entity, an end user may decide to trust that publisher's code differently than that of a hobbyist.
That being said, we consider individual contributions to the Internet very valuable if the Internet is to evolve beyond a platform used only for browsing content. There is nothing that prevents an individual certificate holder from upgrading his or her certificate to a commercial level. There is the hurdle of cost, but these are for services necessary to implement the open standard successfully.
Dun & Bradstreet ratings are extremely easy to get. If a software publisher has released a financial statement or paid taxes, it probably has a Dun & Bradstreet rating. If the publisher does not have a Dun & Bradstreet rating, it's very easy to request one. Another advantage of Dun & Bradstreet ratings is that they are also used internationally, whereas social security numbers are not.
One of the services that the CA provides is to maintain a list of revoked keys. If someone steals a software publisher's key, the publisher can get its certificate revoked and get a new certificate with a new set of keys immediately by contacting its CA. Users can refresh their list of public keys on a periodic basis. The size of the revoked certificate list should be very small (like a stolen credit card list, but even smaller). When the user tries to download code signed under the software publisher's old certificate, the user is warned that the certificate has been revoked. When the software publisher gets a new certificate and a new set of keys, the publisher will have to refresh the installed base with a new release of software signed with the new certificate. The publisher will then have to refresh its customer base with its newly signed controls. (This is similar to a recall of software, except publishers are spared the expense of cleaning the channel of bad disks.)
The act of signing code does not imply liability—it only provides identification of the software publisher and assurance that the code has not been tampered with since it left the publisher's hands. However, federal law does prohibit the intentional distribution of malicious code.
Exporting signed code is not a problem, as software publishers encrypt only a small digest or hash of their code. The export laws treat digital signatures as a special case. There are no export controls on the encryption of message digests, so software publishers can use a strong RSA public key for these digests.
The expiration of certificates provides an added measure of security. (For example, if a university certifies all of its students with digital IDs, it could set each ID to expire when the student leaves the university.) Code that is signed with an expired certificate is invalid. When the certificate expires, the software publisher will need to resign its code and post new versions of this code. In the future, when an Internet time stamp is available, software publishers will be able to sign code with a time stamp to prove that the certificate was valid at the time the code was signed; then the signed code will remain valid even after the certificate expires.
With Authenticode technology, software publishers can currently sign 32-bit .exe files (PE files), .cab files, .ocx files, and .class files.
Test certificates can be generated with the MakeCert utility. For certificates generated by MakeCert to be recognized, it is necessary to run (double-click) the wvtston.reg file. Running wvtstoff.reg can back out registry entries created with wvtston.reg. These .reg files are shipped with the MakeCert tool in the ActiveX SDK.
You must request all types of certificates on the same machine from which you apply for the certificate. However, after you have downloaded the software publisher certificate from the certificate authority, you can transport your certificate between machines. To do so, you must transport the matching private key (.pvk file) and certificate (.spc file) together.
Note Test certificates generated with MakeCert may not be portable if the private key was generated in the registry. The private key is generated in the registry by default unless you specify the -k option to request a private key.
When applying for a software publisher certificate, you are asked to provide a floppy disk on which to store your private key. After the certificate authority (CA) has processed your application, the CA notifies you to pick up your certificate. The private key and certificate are a matched pair and must be used together to sign code.
The lack of reserved space in the .cab file for the certificate usually causes this error. If you are using a .ddf file to build your .cab, include the line:
.ReservePerCabinetSize=6144.
If you are using cabarc, include the -s parameter as follows:
cabarc -s 6144.
If Internet Explorer's safety level setting is "medium" or "high," a Potential Safety Violation message box appears when the page contains active content that is not verifiably safe to display. Internet Explorer either refuses to display the control or provides an option to download and use the control. There are two ways to resolve this issue.
The first option is for control developers to register their controls as implementing the "safe for scripting" component category. When Internet Explorer encounters an <OBJECT> tag, it uses the Component Categories Manager to determine whether the specified CLASSID is safe for scripting. For one method of marking Microsoft Foundation Class Library (MFC) controls "safe," see "How To Mark MFC Controls Safe for Scripting/Initialization" in the Visual C++ documentation (MSDN Library, Knowledge Base). See "Signing and Marking ActiveX Controls" (MSDN Library, Technical Articles) for more information on marking your control safe for scripting.
Important Note Please do not mark controls "safe" if they are not.
The second option is for control developers to implement the IObjectSafety interface. More information about the first and second options can be found in "Marking a Control as Safe" in the ActiveX SDK documentation (MSDN Library, SDK Documentation).