The Need for Meaningful Trust

What's to stop someone from creating a fraudulent key purporting to belong to a developer, posting it to pgp.mit.edu (a popular keyserver), and then replacing both a software package by that developer and its detached signature file with bogus versions that match each other? Nothing. But like Tripwire, PGP doesn't prevent file-tampering; it just alerts us to it.

Ideally, if both a package and its accompanying signature are swapped or tampered with, one of the following will occur:

• When you try to verify the signature, GnuPG will warn you that the signature was created by a different key than the one (on your public keyring) that you've used to verify other software from the same source.
• If you don't have a previous copy of the signer's public key, you'll notice the key ID on the signature doesn't match the key ID on the developer's web site or in e-mail the developer has sent to public forums (yes, it can take a couple of web searches to verify this).
• Somebody else will notice the discrepancy and you'll hear about it, and/or the matter will be dealt with even before you try to verify the signature yourself.
• Unfortunately, it's very easy to imagine none of the above happening. It's depressingly possible, likely even, that after such a hack the following would occur: a number of users would download the Trojan, most of whom wouldn't even bother to verify the signature, and would go ahead and install the Trojan. Furthermore, many, if not most of those who would verify the signature, would download the key referenced in the signature, verify that the (bogus) key did create the signature and that the signature matches the (Trojaned) package, and go ahead and install the Trojan.

Luckily, it only takes one person with a legitimate copy of the signer's real key to notice such a discrepancy and sound the alarm, hopefully soon enough to prevent the Trojan from being downloaded and installed by less-vigilant users. But the real lesson here is twofold: it is extremely important that as many people as possible routinely use GnuPG to check the signatures of software packages and that people must take any necessary additional steps to determine whether such signatures were created by a legitimate key.

In my humble opinion, this scenario also illustrates the questionable value of hosting a software package, its detached signature and the signer's public key all on the same site. Entire sites are as likely to be compromised as individual pieces thereof.

One final example of the pitfalls of assumed trust: remember back in March when Microsoft announced that two Microsoft digital certificates on VeriSign's certificate authority (keyserver) were in fact forgeries? (Microsoft uses its own implementation of digital signatures to validate Microsoft software packages and updates, one that is functionally equivalent to GnuPG and PGP.)

Had someone used those bogus certificates to sign, for example a Trojaned version of Internet Explorer, and had they managed to place their Trojan on a Microsoft web server, users installing the Trojan would have seen a pop-up window informing them that since the digital certificate used to sign the software checked out with VeriSign, that the software was perfectly safe.

This is what happens when people, especially key/certificate-authorities like VeriSign, get sloppy about the keys they trust and even vouch for. By the way, Microsoft made its announcement almost three months after the bogus certificates had been published. Check signatures, and don't automatically take every key you encounter at face value.