 | ||
|
| ||
| ||
|
| ||
Microsoft Corporation
Updated: February 17, 1997
Questions
What is Authenticode?
What is Authenticode?
Is Authenticode technology really secure?
Where should I look for information about
Microsoft Authenticode technology?
As an Internet Explorer end user, how do I use Authenticode?
When I download a piece of software over the
Internet, Microsoft Internet Explorer 3.0 shows me a
"certificate." What does this certificate mean?
What options do I have in using Authenticode
with Internet Explorer 3.0?
If Internet Explorer 3.0 tells me that a piece
of software has not been signed, should I download it
anyway?
Should I trust and download a piece of
software, just because its been signed?
Does a personal certificate or a site
certificate have anything to do with a software publisher
certificate?
How can I tell the difference between an
Individual publisher and a Commercial publisher when
Internet Explorer presents me with a software
publisher’s certificate?
How can Authenticode be used within a
corporate scenario?
As a developer, how do I sign my code?
How do I get a software publisher certificate
for use with Authenticode?
For what type of Digital ID should I
apply?
I am a developer outside of the United
States and Canada. How can I get a software publisher
certificate?
What are the criteria for obtaining a
commercial software publisher certificate?
How long does it take to get a
certificate?
How much does certification cost?
I heard that VeriSign is offering digital
certificates for end users. Will people be able to use
those to sign code?
Where do I get the tools for signing my
code?
What are public and private keys?
How do I get my public and private keys?
How long does it take to sign code?
When can I start testing signed code?
How does Authenticode work with other technologies?
Is Authenticode a cross-platform
solution?
Is Authenticode an ActiveX only
technology?
Does Authenticode provide copy-protection of
my software?
Does Microsoft support the Sandbox model?
With Authenticode, is Microsoft competing
against the Java sandbox model?
Can I use Authenticode to sign my Web
page?
Does Netscape Navigator check for signed
code?
What are the elements of Microsoft code signing?
What is a certificate authority (CA)?
Tell me how code signing works
What are the policies regarding commercial
and individual software publishers?
Why do we need two sets of policies?
Why use a Dun & Bradstreet rating rather
than something like a social security number?
What if someone steals my key and starts
distributing bad code with it?
What exactly is my liability when I sign
code?
What encryption algorithms are you using?
What about exporting these?
What happens when my certificate expires?
As a developer, what are some technical points to keep in mind when signing code?
What types of code can I sign?
Why don't I see my MakeCert-generated test
certificate?
Do I have to request, retrieve, and sign my
code on the same machine?
I generated my private key already. Where is
my software publisher certificate?
Code signing fails with error 80004005 when
signing a .cab file. What causes this?
I signed my code but I still get the message,
"This page contains an ActiveX control with data that is
not known to be safe," or, "This page contains both scripts
and a control that are not known to be safe for scripts to
use."
Support for Authenticode™ 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 the identity of the software publisher and that the applet 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 is our Authenticode page. This site outlines the
code signing program and code signing procedures for
developers. Specifically, please reference Signing Code with
Microsoft's Authenticode if you are looking for
detailed information on signing your code. You can also
check out the
VeriSign code signing FAQ .
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. Through the Active content safety levels found under the Security tab in the Options menu, end users can decide how Internet Explorer should treat potentially unsafe code — that is, code that doesn't have a valid software publisher certificate associated with it.
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, e.g. 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.
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 private or paid-for 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 pre-configure 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 IDsSM for use with Authenticode. GTE software publisher certificates will be available soon after the release of Internet Explorer 3.0. Please see http://www.microsoft.com/workshop/security/authcode/cer ts.asp for more information regarding certificate authorities and getting your certificate.
VeriSign currently offers two types of software publisher
Digital IDSMs: individual (Class 2) and
commercial (Class 3). Please see
http://digitalid.verisign.com/ask_veri.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 D&B service center quickly
and at low cost. For more information about D&B and getting
a D-U-N-S number, please see
http://www.dnb.com/dunsno/dunsno.htm .
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 Proposal for Authenticating Code Via the Internet for details on the corporate and individual policies.
Tools for signing code are available in the ActiveX SDK. 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 get 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 public key is also created by the software publisher. 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 Windows 95 and Windows NT first, then Windows 3.1. Microsoft is committed to ensuring that this technology is implemented on UNIX and the Macintosh platforms.
No. Authenticode technology produces a signature independent of any file format. Internet Explorer 3.0 supports Authenticode signatures for Win32 executable in addition to Java applets in .class file or CAB file format and ActiveX controls. Additional formats such as documents that contain macros and MacOS 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, since 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 currencurrently discussing a Microsoft code-signing submission.
We had not considered signing 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 masters 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 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, which is also available on this Web site. To summarize:
The commercial policy requires software publishers to
provide proof of identity, take a pledge that their
intention is not to distribute malicious code, and have a Dun
& Bradstreet (D&B) rating. http://www.dnb.com/dunsno/dunsno.htm
provides
more information about getting a Dun & Bradstreet
rating online. Using some form of hardware to maintain
their private key is highly recommended.
The individual policy requires individuals to provide proof of identity (but to a lesser degree than the commercial policy), take the pledge, and promise to take reasonable steps to keep their private key secure (this does not require hardware).
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 (D&B) ratings are extremely easy to get. If a software publisher has released a financial statement or paid taxes, it probably has a D&B rating. If the publisher does not have a D&B rating, it's very easy to request one. Another advantage of D&B 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 that 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 apprears 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 MFC controls
"safe," see Q161873 - How To Mark MFC Controls Safe for
Scripting/Initialization . See
Signing and Marking ActiveX Controls 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 the Safety API Reference in the ActiveX SDK documentation.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top