What is Code Signing?
It would be great if users could know, before they install software programs and active content (such as ActiveX controls) whether the code is trustworthy – but how do you determine that? One way is to verify the identity of its author or publisher. If it’s being distributed by a company that you know and trust, you may want to allow it. If it’s distributed by a company that’s questionable or that you’ve never heard of – or even worse, if it’s being distributed anonymously – you probably want to think twice before installing it.
Code signing lets you know the origin of the code, and prevents a hacker from distributing “free software” in someone else’s name (for example, putting a malicious program or virus on a Web site for download and claiming that it’s a free tool from Microsoft). In addition to verifying the identity of the publisher, code signing can protect the code from tampering (if the code is changed, the digital signature is invalidated). Thus, code signing provides two security protections:
- Authentication of the author, publisher or distributor of the code
- Integrity of the code itself
How Code Signing Works
Code signing is based on the use of a digital signature, which is in turn is based on a digital certificate issued by a trusted third party (a certification authority) that has verified the identity of the software or content publisher. For example, Verisign and Thawte issue code signing digital IDs to software developers. When a developer enrolls for a digital ID, he is required to submit documentation of proof of identity. A public/private key pair is generated when the certificate is requested. The private key stays on the requester’s computer and is never sent to the CA. It should not be shared with anyone. The public key is submitted to the CA with the certificate request.
After the certificate is issued, the developer uses the private key associated with that public key to sign his code. When users download the signed code, they get a copy of the certificate verifying the identity of the author/publisher. The Web browser verifies the digital signature, and the user knows that the code did indeed come from that particular developer.
Here is exactly what happens when a developer signs the code:
- The code is put through a one-way hash function. This creates a “digest” of fixed length.
- The developer’s private key is used to encrypt this digest.
- The digest is combined with the certificate and hash algorithm to create a signature block.
- The signature block is inserted into the portable executable file.
What happens at the other end (on the computer that downloads the signed code)? Here’s the process:
- The certificate is examined and the developer’s public key is obtained from the CA.
- The digest is then decrypted with the public key.
- The same hash algorithm that was used to create the digest is run on the code again, to create a second digest.
- The second digest is compared to the original.
If the two digests match, you know that the public key is the one that matches the private key used to sign the code, and you know that the code hasn’t been changed since it was signed.
Certification authorities issue different classes of code-signing certificates, depending on whether the publisher is a commercial software company, an individual software developer or an end-user. The certificate will indicate whether it is commercial or individual. Commercial publishers must submit a Dun & Bradstreet number, Articles of Incorporation, etc. and sign a pledge not to distribute malicious code. They also must pay considerably more ($400 for a commercial certificate from Verisign at the time of this writing). Individuals also have to sign the pledge and prove their identities, but the identity verification process is less stringent.
One reason Dun & Bradstreet numbers (DUNs) are used as identifiers is because they are used internationally, unlike other identifying numbers such as Social Security Numbers (SSNs) and Employer Identification Numbers (EINs).
Certificates can be revoked if a publisher’s private key becomes compromised. When code is downloaded, the Certificate Revocation List (CRL) is checked and if the certificate has been revoked, the user is warned of this. The CA can issue a new certificate to the publisher, who will then need to sign the code with the new private key. Likewise, users are warned if the publisher’s certificate has expired.
Authenticode is Microsoft’s code-signing technology. Support is built into Microsoft operating systems and Internet Explorer. Authenticode certificates can be issued by Verisign and other public certification authorities or by a private certification authority. Authenticode can be used for signing Java .class files, .cab files, .ocx files, ActiveX controls and all Win32 executables (PE files).
When a user attempts to download software, the Authenticode dialog box provides information regarding the Publisher, CA that issued the certificate and date the code was signed. The user can then select whether to install the software or not. The user can also check a box to always trust software from this publisher, so as to not have to go through the process again. With the security enhancements provided by Windows XP service pack 1, another checkbox is added to the dialog box that allows users to never trust software from this publisher (the SP2 dialog box is shown in Figure A.
Clicking the link to the publisher’s name (in this case, Microsoft Corporation) lets the user examine the properties of the digital signature, including:
- Publisher name
- E-mail address (if available)
- Date and time the code was signed
The Digital Signature Details box is shown in Figure B.
The Advanced tab displays details about the signature, including the version number, issuer, serial number, digest and encryption algorithms, and authenticated and unauthenticated attributes.
Just click the View Certificate button on the General tab, then click the Details tab to view the certificate details, as shown in Figure C.
This information includes:
- Version number
- Serial number
- Signature algorithm
- Date issued (“valid from”)
- Expiration date (“valid to”)
- Public key information, including key length (for example, 2048 bits)
- CRL distribution point for accessing the CA’s revocation list
- Key usage information (in this case, digital signature)
- Thumbprint and thumbprint algorithm
- Extended error information
You can export the certificate by clicking the Copy to File button. This invokes the Certificate Export Wizard, which walks you through the steps of copying the certificate from the certificate store to your hard disk
Benefits and Limitations of Code Signing
Code signing technology is an important part of your security plan if your users download and install programs or active content. It provides you with verification of the identity of the publisher and confidence that the code hasn’t been tampered with after it was signed.
However, it’s important to remember that just because code is signed, that doesn’t ensure that it is safe (or free of bugs). It is up to you to determine the trustworthiness of a particular publisher.
Because you may not want to leave the decision up to users, you can use Software Restriction Policies to control what software can run, based on publisher certificates. To do so, you set up a certificate rule to allow or block content based on its signature.
You can also use the Trusted Publishers option of Software Restriction Policies to control which users are allowed to select trusted publishers, and to specify that CRL checks be done before a publisher is trusted. If you have the Trusted Publishers option enabled, ActiveX controls won’t run unless they are signed by publishers whose certificates have been added to the certificates store.
Although code signing technology is used by virtually all Windows users and administrators, many don’t understand its significance and how it works. Code signing is an authentication mechanism for software publishers that is based on digital signatures backed by digital certificates. Signed code isn’t necessarily safe code, but a digital signature does provide accountability – something that is often missing in a world of freely, and sometimes anonymously distributed software.