Feeling Insecure?

Code signing is a means for software developers can use a unique “certificate” as a digital signature to verify their identities to the users of their programs. The idea is that when installing the software you can evaluate whether or not to complete the install based on whether or not you trust the  publisher. Sounds like a good idea, and it is.  Code signing is certainly a valuable security feature, but it’s important for users and publishers  to understand its uses and its limitations. In this article, we’ll take a look at how code signing works and how best to use it.

So, what IS Code Signing?

Wouldn’t it be great if buyers of users could know, before they install software programs whether the code is trustworthy?  That’s what code signing is designed to do. The first step is to have a positive ID on the author or publisher. If it’s being distributed by a company that you know and trust from previous purchases, most likely you’ll allow it. If not, because it’s a company you’ve never heard of – or even worse, if it’s being distributed anonymously – you’ll definitely think twice before installing it.

Code signing is a means of assuring you of the origin of the code, and prevents unscrupulous developers from distributing bogus software in someone else’s name ( a common way hacker’s use to distribute malicious programs and virus-loaded applications on the Web).  In knowing the identity of the publisher, code signing can protect the code from secondary hacks (if the code is changed, the digital signature will be invalidated). So, code signing provides two elementary security protections:

  • Verifying the author (Developer or Company)
  • Ensuring the Code is as it was when it was released and not tampered with.

How does it work?

Your written signature is used on legal documents because each person’s signature is unique. 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. Using the personal signature analogy, think of the trusted third-party like a Notary Public. They go to some trouble to verify that you are who you say you are before they let you sign important documents. 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 never be shared with anyone, ever. The public key is submitted to the CA with the certificate request.

When the certificate is issued, the developer uses the private key paired 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.

Let’s walk through what happens when a developer signs the code:

  1. The code is put through a one-way “hash” function. This creates a “digest” of fixed length. The code is analyzed and a unique signature is established.
  2. The developer’s private key is used to encrypt this digest.
  3. The digest is combined with the certificate and hash algorithm to create a signature block. This is entirely unique and essentially impossible to replicate.
  4. The signature block is inserted into the portable executable file. It can’t be separated now without the tampering becoming obvious.

What happens at the other end (on the computer that downloads the signed code)? Here’s the process:

  1. The certificate is examined.
  2. The developer’s public key is obtained from the CA.
  3. The digest is then decrypted with the public key.
  4. The same hash algorithm that was used to create the digest is run on the code again, to create a second digest.
  5. 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 (let’s just  call them CAs) issue different classes of code-signing certificates, depending on whether the publisher is an individual software developer or an end-user or a commercial software company. The certificate will indicate whether it is commercial or individual. Commercial publishers must submit a Dun & Bradstreet number, Articles of Incorporation, that sort of thing. They also agree not to distribute malicious code. They also must pay considerably more (about $395 a year for a commercial certificate from Verisign). Individuals also have to sign the pledge and prove their identities, but the identity verification process isn’t as detailed.

One reason Dun & Bradstreet numbers (DUNs) are used as identifiers is because they are used internationally, unlike a Social Security Numbers.

Certificates will 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 is not in force, the user will be warned on screen during the installation process. If something like that were to happen, the CA can issue a new certificate to the developer, who will then need to sign the code with the new private key. In the same  way, users are warned if the publisher’s certificate has expired.

Microsoft Authenticode

Authenticode is Microsoft’s code-signing technology. Microsoft built this into their operating systems and Internet Explorer. Authenticode certificates can be issued by Verisign and Thawte (among other public certification authorities) or by a private certification authority. Authenticode can be used for signing cab files, .ocx files, ActiveX controls, Java .class files,  and all Win32 executables (PE files).

When a user downloads a program, an Authenticode dialog box provides identification of the Publisher,  the CA that issued the certificate and date the code was last signed. The user can then select whether to install the software or not. The user has the option to  check a box to always trust software from this publisher, so they don’t have to go through the process with every update. Conversely, security enhancements provided by Windows XP service pack 1 and later versions, 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 Example 1).

Example 1

Clicking the link to the publisher’s name (in this example, Microsoft Corporation) lets the person installing the software evaluate properties of the digital signature, including:

  • Publisher name
  • E-mail address (if available)
  • Date and time the code was signed
  • Countersignatures

The Digital Signature Details box is shown in Example 2.

Example 2

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 Example 3.

Example 3

This information includes:

  • Version number
  • Serial number
  • Signature algorithm
  • Issuer
  • Date issued (“valid from”)
  • Expiration date (“valid to”)
  • Subject
  • 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

If you wanted to do a little investigation before you complete the installation you could the  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.

What Code Signing Can (and  Can’t) Do

Code signing is an indispensible  part of your security plan if your users download and install active content or  programs. It provides you with ability to identify the publisher and  have confidence that the code hasn’t been hacked after it was signed.

BUT…it’s not 100% guaranteed that the software is error or bug free! It is still up to you to determine the trustworthiness of a particular publisher.

For the Control Freak in You

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.

In a nutshell

Code signing technology is used by most  Windows users and administrators, though many don’t understand its significance or how it all works. Code signing is an authentication mechanism for software publishers that is based on digital signatures backed by digital certificates. Signed code isn’t always reliable code, but a digital signature does provide some accountability – something that is often missing in an environment of openly, and sometimes anonymously distributed software.