Philip Zimmermann's personal response to
the ADK bug, updated 20 October 2000
-----BEGIN
PGP SIGNED MESSAGE-----
Hash: SHA1
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. In which case, PGP will display the bad ADK
validity status to him before he can use 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. In both the commercial and freeware PGP 7.0, we also
made the warnings to the user far more explicit when encrypting
to a key with the ADK feature. 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
29 August 2000 (updated 20 October 2000)
prz@pgp.com
http://www.pgp.com/phil
This note
may be widely circulated.
-----BEGIN
PGP SIGNATURE-----
Version: PGP 7.0
iQA/AwUBOfCb5mPLaR3669X8EQJE6ACeMmGz9FvZi72VNU3XeZCa/MntiD0AoP5z
ih2AwBgKXqKzIsSROGNPYtiF =yq/N
-----END
PGP SIGNATURE-----
|