22.1 Why Code Signing?

only for RuBoard - do not distribute or recompile

Walk into a computer store and buy a copy of Microsoft Windows, and you can be pretty sure the box contains a genuine CD-ROM with a computer operating system written by the Redmond software giant. The program, after all, comes shrinkwrapped in a box, with a difficult-to-forge security hologram seal. Inside the box is a CD-ROM that may include its own hologram. You have great confidence that your CD-ROM or floppy disks have the same program as every other CD-ROM or floppy disk sold in every other Windows box. Presumably, the software was checked at the factory, so you have every reason to believe that you've got a legitimate and unaltered copy.

The same can't be said for software downloaded over the Internet. When Microsoft released its 1,264,640-byte Service Pack 1 for Windows 95, the only way to be sure that you had a legitimate and unaltered copy was to download it directly from Microsoft's web site and then hope the file wasn't accidentally or intentionally corrupted either on Microsoft's site or while it was being downloaded.

What's worse, if you wanted to save yourself some time by copying Service Pack 1 from a friend, there was no way that you could inspect the file and know whether it was good or not: your friend's copy might have been corrupted on his hard disk, or it might have been infected with a virus, or it might not even be the right program. How do you know if it is a true copy, other than trusting your friend at his word?

With Microsoft Windows 95 Service Pack 1, there was no way to electronically certify the contents of code downloaded over the Internet. But starting with Internet Explorer 3.0, Windows users were given a powerful system for trusting the authenticity of their software: digital signatures for executable programs. Called Authenticode, the Microsoft digital signature system is specifically designed to allow users to verify that downloaded programs are authentic and unmodified.

22.1.1 Code Signing in Theory

Code signing was supposed to bring the assurance of shrink-wrapped software to the world of software that's distributed electronically. It does this by adding two things to an executable:

A digital signature that signs the executable with a secret key.
A digital certificate that contains the corresponding public key, the name of the person or organization to whom that key belongs, and a digital signature signed by a recognized certification authority.

These are shown in Figure 22-1.

Figure 22-1. A piece of signed code, showing the code's digital signature and the corresponding digital certificate.

To work, code signing presupposes the existence of a working public key infrastructure. Otherwise, there is no way to tell whose signature is on a piece of signed code. Code signing also requires that those individuals and organizations that hold secret keys protect them properly. Otherwise, there is no way to know if a signature was written by an authorized individual or by a malicious attacker who obtained a copy of another's secret key.^[1]

^[1] We'll also assume that the algorithms used are strong, that the key is big enough and sufficiently random, and the overall software infrastructure was coded and protected properly. There are many more assumptions, but these should illustrate the point at some level, you need to trust a lot of things that can go wrong. The reputation and competence of the parties involved help you gain confidence in the structure, or contribute to a lack of confidence.

Microsoft's Authenticode system is used most often with VeriSign's public key infrastructure, although any certification authority key that is approved for code signing and that is in the Internet Explorer key store can be used for verifying Authenticode signatures.

To be useful, the signatures must be verified. Internet Explorer will analyze code after it is downloaded to determine if a signature is or is not present. Later versions of Windows, including Windows 2000, ME, and XP take Authenticode one step further and use it for signing critical parts of the Windows operating system. These signatures are verified every time the Windows operating system starts up. In this way, code signing can detect malicious attempts to modify code, accidental modifications that might result from operating system errors or hardware failure, and unauthorized modification attempts by the user. Thus, code signing can dramatically boost the reliability of today's computer systems by allowing us to detect modifications in programs before those programs are run.

Code signing has also been proposed as a way of creating accountability for people who write programs and distribute them on the Internet. The idea is that Internet users should be taught not to run programs that are unsigned.^[2] Then, if a malicious program is distributed on the Internet, it will be a simple matter to find out who distributed the program and punish them. By establishing significant penalties for people who distribute malicious programs, as well as a reliable technique for tracking those authors, it is thought that the incidence of such programs will be greatly diminished.

^[2] If public education fails, system software can always be modified so that unsigned programs cannot run.

22.1.2 Code Signing Today

There are several code signing systems in use today:

Authenticode, which is Microsoft's system for signing CAB, CAT, CTL, DLL, EXE, and OCX files
Microsoft Office 2000 and VBA Signing, which allows software publishers to digitally sign Microsoft Office Macros and Visual Basic for Applications objects
Netscape Object Signing, which can be used to digitally sign Java Archive ( JAR) files, Netscape plug-ins, Java programs, and JavaScript programs
Macromedia Shockwave digital signatures (requires Director 8 Shockwave Studio or Macromedia Flash)
Marimba Castanet, which supports code signing for certification information distributed over a Castanet Channel
Sun Java SDK, which supports its own code signing model

22.1.3 Code Signing and Legal Restrictions on Cryptography

In contrast to other encryption technologies, there are no significant legal restrictions on code signing technology. This is because signing does not embed secret messages in the signed documents and because the patents that once covered public key cryptography have now expired.

Beware the Zipper!

The need for code signing was conclusively demonstrated in 1995 and 1996, when a program called PKZIP30B.EXE was reportedly uploaded to many software libraries on the Internet. The program appeared to be the 3.0 beta release of PKZIP, a popular disk compression program. But when unsuspecting users downloaded the program and tried to run it, the rogue program actually erased the user's hard disk. That didn't do wonders for the reputation of PKWare, PKZIP's creator.

Digital signatures could have prevented this mishap. If PKWare had previously adopted a policy of signing their programs with the company's digital signature, then bad hackers could never have created the PKZIP30B.EXE file and credibly passed it off as being the creation of PKWare. That's because the rogue hackers who distributed the PKZIP30B.EXE program couldn't have signed it with PKWare's digital signature.

Of course, PKWare would have to have put in place a policy of signing their programs with their secret key and making sure that the company's public key was in wide distribution. They would also have had to make sure that there was a simple-to-use verification program that was widely available.

How could PKWare have done this? It would have been tough. The company could have created a PGP key, distributed it, and used that key to sign new versions of its program. But how could anybody have trusted the key? Or the company could have built its own public key and the verification program in previous versions of PKZIP. The program could have been equipped with a "verify and upgrade" command that would inspect the digital signature of a proposed patch or upgrade, make sure that it matched, and then perform the necessary upgrade. Not only would this have thwarted the malicious hackers, it would have also assured the company's customers that the upgrades they got from friends were true and unadulterated.

Today such bootstrapping is no longer necessary. Companies can simply obtain a software publisher's certificate from a recognized certification authority and use it to sign the programs that they distribute. Of course, since most users will happily run code that is unsigned, it is not clear that code signing ultimately increases the security of a desktop computer system.

only for RuBoard - do not distribute or recompile