PGP's Vulnerabilities Reveal the Truth about Security

  • Bruce Schneier
  • InternetWeek
  • February 12, 2001

Reports that PGP, a standard used to encrypt e-mail, is broken are greatly exaggerated. Although a recent criminal investigation has led some to conclude that flaws in the PGP protocol helped the FBI nab its suspect, the truth is that no one has broken the cryptographic algorithms that protect PGP traffic. And no one has discovered a software flaw in the PGP program that would allow someone to read PGP- encrypted traffic. All that happened was that someone installed a keyboard sniffer on a computer, letting that someone eavesdrop on every keystroke the user made. The sniffer let the eavesdropper pick up the PGP passphrase and the text of a victim's messages as he typed.

In this incident, the victim was an alleged mobster, Nicodemo S. Scarfo, who was using PGP to encrypt his e-mail messages. The eavesdropper was the FBI, who ran a black-bag operation against Scarfo and installed the keyboard sniffer. While it may sound like a great plot for a detective story, the principles surrounding this case could have profound effects on IT managers.

There are many constitutional issues here. The FBI did obtain a warrant, but it is unclear if the warrant allowed this sort of surveillance. Scarfo's attorney certainly doesn't think so, and many civil rights groups agree. Lots of people are watching this case, which may force the courts to sort out some of these complicated issues.

My interest is more in the technical issues. The story graphically illustrates an important lesson of computer and network security: It's only as secure as the weakest link. PGP provides just one piece of the e-mail security chain. It protects messages in transit from the sender to the recipient. It protects against eavesdropping and impersonation. PGP does not protect either endpoint. In addition to keyboard sniffers, which can capture text and passphrases, PGP is vulnerable in other ways as well. For example, Trojan horses and viruses can send signed PGP traffic in the computer user's name. A clever attacker can even find printed copies of PGP-encrypted e-mail in the trash.

I am concerned that many cryptographers-I have been as guilty as everyone else-have lulled people into a false sense of security. We toss about phrases like "2,048-bit RSA" and "trillions of years to break," and we believe them. We're defending ourselves by planting a huge stake in the ground, instead of by building a wall, and hoping the attacker will take only the path that runs into the stake. We can argue about whether the stake should be a mile or a mile and a half tall, but the reality is that a smart attacker will simply go around the stake.

To be sure, cryptography is a good stake. It blocks the narrow gap where the attacker could easily pass through, protecting against non- invasive attacks. Attackers can still "go around" the stake, such as by breaking into Scarfo's home and installing the keyboard sniffer. Many attackers are not motivated enough-or even capable of doing so.

The moral here is that security only has real meaning in context. Network managers often think of security as a magic dust that they can sprinkle over their networks. Add a firewall here, encryption there, maybe a dash of PKI, and they're "secure." The reality is much more complicated. Security is a process, and cryptography and hardware are only part of that process. IT managers need to be constantly vigilant. There are no magic bullets or easy answers.

The issue is best summarized in a recent Philadelphia Inquirer story: "Manno [Scarfo's attorney] would not discuss what his client was storing on the encrypted program but said Scarfo was using software known as PGP. 'It stands for Pretty Good Privacy,' the lawyer said with a chuckle."

That chuckle might raise the hackles of your average cipherpunk, but you have to admit, his sarcasm wasn't off base.

Categories: Computer and Information Security

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Resilient Systems, Inc.