Code Signing

Providing Accountability for Software on the Internet

April 1996

Microsoft and many independent software vendors (ISVs) are proposing a new standard that uses digital signatures to provide shrink-wrap-like accountability for interactive code downloaded from the Internet. This is an open standard, it will be used to sign all forms of executable code, and is designed to run on all platforms.

Code signing, in a nutshell

When a user purchases a software product from the local store, the product is associated with trust and accountability because it has the ISV's logo on the shrink-wrapped box. The logo implies trust and reputation, and the shrink-wrap denotes that the code has not been modified since it left the ISV's hands. In short, the user trusts that the code is safe, has been tested, and contains no viruses or malicious functionality.

The code found on the Internet is largely anonymous. Users who download the code take two major risks:

When users download executable code today, a dialog box pops up and warns them that they are about to execute code from the Internet. If the user decides to download, he or she takes on a certain amount of risk. All ActiveX™ Controls, Java applications, executables, and dynamic-link libraries (DLLs) face this problem today. This risk prohibits some users and corporations from using code downloaded from the Internet, and will hinder the industry's effort to provide interactive solutions on the Internet.

Digital signatures provide a solution to that problem. In a nutshell, here's how digital signatures work: An ISV who develops an executable for distribution over the Internet works with a third party known as a certificate authority (CA) to obtain a digital certificate. The digital certificate is used to sign all of the ISV's executables. After the ISV has tested the executable, just before distribution, the ISV signs the code. Signing the code involves these steps:

The ISV then distributes the code. When a user downloads the code from the Internet, the browser or client-side application uses a Win32® function called WinVerifyTrust. This function call extracts the signature block, validates the certificate, and uses the ISV's public key (verified by the CA) to decrypt the digest. It then rehashes the executable with the same hash function (indicated in the signature block) to create a second digest. If the hashes do not match, the code has either been modified (indication of a virus) or the keys are not a matched pair (further indication that the code has been tampered with). After the signature is checked, the following may happen, depending on the options selected by the user:

The result is trusted code, and a user who is better informed to make a decision about the software he or she is downloading.

Note: Private and public keys are a matched set of keys created by the ISV and used for encryption and decryption of the digest into the signature block. The ISV 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 ISV. It is verified as part of the certification process by the CA and distributed to the public in the signature block.

For more information on code signing, please see the Web pages below:

Proposal:

Specs: FAQ: Presentation:Press releases:If you need more information or have specific questions you'd like us to answer, please send e-mail to safecode@microsoft.com.

© 1996 Microsoft Corporation