|
Philip Zimmermann |
|
ADK bug in PGP19 Oct 2000 - For a signed version of this announcement click here On Thursday 24 August, we found out that we had a security related bug in PGP, in the implementation of the Additional Decryption Key (ADK) feature. A German researcher, Ralf Senderek, had already published news of this bug on a web site. We mobilized quickly and released a fixed version of PGP within about 18 hours of hearing the news. The fix for the commercial version of PGP is available from http://www.pgp.com, and the fixed freeware PGP (version 6.5.8) is available from the MIT web site at http://web.mit.edu/network/pgp.html, or from http://www.pgpi.org. Of course, our subsequent releases of PGP (like 7.0) are also fixed. Some of the postings on the Internet about this subject have portrayed this bug as a back door in PGP. Let me assure you, it is nothing of the sort. It is a bug (and we have now fixed it). An especially embarrassing bug, because it is in a feature that some people have objected to even when everyone thought it was working correctly. The ADK feature was designed in 1997 to be a kinder, gentler alternative to key escrow for companies to use for employee's keys. I felt that key escrow was an especially bad idea, and came up with this alternative: Imagine that you published your public key with a little yellow Post-it note (digitally signed by you) attached to it, asking users who want to encrypt with your public key to encrypt the message with another key as well. That means the note asks users to encrypt the message with two keys instead of one -- the intended recipient's key, and an additional key chosen by the recipient, identified on the little Post-it note. It is a request from the recipient that the sender of a message may choose to comply with, or choose to ignore. The sender is free to encrypt the message with one key, or both keys. If he chooses to comply with the recipient's wishes and use the ADK, either the intended recipient or the ADK may decrypt the message. This satisfied a major requirement from our corporate customers for a mechanism of handling what happens when an employee is not available to decrypt the file, perhaps because he's on vacation, or died in a plane crash, or simply forgot his pass phrase. It is so much better than key escrow because it requires the consent of both the sender and receiver to use the feature. It is highly visible to the sender, and asks his consent before proceeding with the encryption. We could not sell PGP without this feature. Most freeware users didn't need this feature, so we did not make the freeware version of PGP capable of generating ADKs on their keys. You have to buy the commercial version to generate keys with proper ADK packets attached to them. Since the freeware users don't pay the salaries of our engineers, and the commercial users do, we had to add this feature to PGP to meet an absolute requirement of most of our paying customers. It seems the most militant critics of the ADK feature are also the ones who don't want to pay for PGP. Somebody has to pay the engineers so that we can keep developing PGP and give it away for free to these critics. The recipient has to make a digital signature on the little yellow Post-it note, giving his consent to having an ADK associated with his key. And therein lies the bug. The bug in PGP versions 5.5 through 6.5.3 is that PGP does not always properly check to see if the ADK is signed before using it, if the little Post-it note that references the ADK is improperly formatted in a particular way. This means someone could attach an unauthorized ADK to your key, and possibly fool an inattentive message sender into using it. It would not be an easy scam to pull off, because chances are, the sender does not have the bogus ADK on his keyring, and even if he goes through the extra trouble to get it from a server, the bogus ADK is probably not going to be signed by a Certificate Authority trusted by the sender, so PGP will object to him using that ADK to encrypt the message. This is a daring attack, an attack that has a very high probability of being detected. Then, even if all those problems are somehow overcome, the attacker still has to intercept the encrypted email on its way to the intended recipient. Intelligence agencies are good at intercepting email traffic, but they would never be foolish enough to try a daring attack. That might be why we found absolutely no bogus ADK packets when we scanned all the public keys on the public key servers after the bug was reported, even after nearly three years of deployment of this bug. If this were a back door, it would be a particularly stupid design for a back door. Anyway, did I mention that we fixed the bug? We also fixed it on the key servers so that the key servers would reject (and delete) bogus ADKs before anyone had a chance to use them, even if they did not yet have the new fixed version of PGP. The fixed version of PGP deletes bogus ADKs wherever it finds them. It does not simply avoid using the bogus ADKs, it actually deletes them from the key. They are gone. Ironically, our most cynical critics objected to this way of fixing the bug, accusing us of "covering up" the bogus ADKs because they could not see them anymore (maybe they did not realize the bogus ADKs were actually gone). Sigh. Some people are impossible to please. We also made a change to the freeware version of PGP 7.0 to make it impossible for the user to turn off warnings about the presence of an ADK on a key before using it. If you intend to use ADKs a lot and want to be able to turn off these warnings via the preferences panel, you must buy the commercial version of PGP. Senderek's report suggested that the same bug also affects other kinds of attributes you attach to your key, including the designated revoker feature in PGP. We fixed these problems at the same time, in the same way. Although these variations on the bug were less serious than the ADK bug (and did not involve such a controversial feature), they would have allowed unauthorized designated revokers to be added to your key, which could potentially open the door to a denial of service attack by allowing someone to revoke your key. In fact, while we were examining the source code to fix the designated revoker feature, we discovered another bug relating to designated revokers and fixed that too. That bug allowed invalid designated revoker signatures to be accepted under some circumstances. This in no way could have hurt the security of PGP messages, but could have allowed valid keys to appear revoked. We also fixed the key servers to filter out all of these problems for everyone's keys. When we added the ADK feature in 1997, many critics charged that this would pave the way for government law enforcement or intelligence agencies to exploit the ADK feature to spy on ordinary citizens. In fact, this has not happened. After many years of struggle, we have won the crypto debate in the US (and France, and a growing list of other countries in Europe), and the US export controls were relaxed completely in January 2000. After nearly three years of deployment, the ADK feature has had absolutely zero impact on the state of government surveillance in the US, and around the world. The predictions were wrong. At the same time, the commercial acceptance of PGP (in part because of the addition of the ADK feature) has propagated PGP more widely in the politically powerful computer industry, which I suspect has in some way contributed to pressure on the government to relax the export controls in this election year. One annoying thing I've seen in some of these press reports on the web is that adding this ADK feature had something to do with the Key Recovery Alliance (KRA), an industry group formed in the 1990s to put key recovery features in crypto products, mostly to allow those products to get export licenses from the US government. Let me assure you all that the KRA has nothing to do with us adding this feature to PGP. I had this ADK feature added to PGP in late 1997, before Network Associates acquired PGP Inc. We added it because it was a good feature to solve specific data recovery problems that corporations had, problems I have described above. It had nothing to do with export licenses. We avoided the export controls by publishing PGP source code in printed books and legally exporting the books (which were not subject to export controls) to Europe, where they were scanned in via OCR and compiled back into working software again and sold on CDROMs all over the world. A neat trick, don't you think? It worked beautifully, and there was no need for us to compromise PGP's cryptographic integrity to allow it to be exported. Anyway, later Network Associates acquired PGP Inc, and I made them drop out of the KRA as soon as they did. A few months later, NAI acquired another company (TIS), which was a member of the KRA, and thereby became a member again by default. Their membership was up for renewal, and I asked them not to renew, and they again complied with my request. Today it appears the KRA no longer exists, now that the export controls are gone. No one made any deals with the government. There is no conspiracy here. There are still no back doors in PGP. We still publish the PGP source code for peer review, because we want people to help us find the bugs. Most other software companies don't do that. Their software is as big and complex as ours, so they probably have as many (if not more) bugs, but you don't hear about them as much because the source code is not published for peer review. PGP started out as a human rights project, and today is used by every human rights organization in the world. Our engineers stay with the PGP team because they feel that they are working on something important for the world. It's a thankless job for most of them, especially with all this criticism from conspiracy theorists who imagine we've sold out to the government. Why do people have to assume the worst motives? If NAI tried to put a back door in PGP, all the engineers on the PGP team would quit in a highly visible protest, and I would be talking to the press about it. There is no way that I would let this happen, and NAI has shown no interest in putting a back door in PGP. Philip Zimmermann |