Der ADK-GAU
Diese Darstellung erhebt nicht den Anspruch auf Vollständigkeit
Am 23.08.2000 erreichte mich eine E-Mail von Ralf Senderek, in der er mich auf seine Untersuchung
KEY-EXPERIMENTS - How PGP Deals With Manipulated Keys - An Experimental Approach by Ralf Senderekhinwies.
Abstract
Different versions of PGP show considerably different reactions when being confronted with public keys which have been subsequently manipulated. Especially a subsequent contamination of a public key with another person's key will not be noticed and rejected if you use newer versions of PGP, but will be used to produce encrypted messages which can be read in plaintext by everyone who has the secret key corresponding to the key which was smuggled into the original one. This manipulation will not be detected when using some newer versions of PGP and will not be noticed until users are going to have a detailed look at the bytes of the manipulated keys. This study helps to understand this threat, to find out experimentally how a specific version of PGP reacts, and to avoid being cheated with manipulated keys.
Einen Tag später verbreiteten sich die Ergebnisse seiner
Untersuchung per Postings ins Usenet und E-Mails auf Mailing-Listen
über die ganze Welt.
Führende Kryptografen wie Bruce Schneier und Ross Anderson
meldeten sich zu Wort, das CERT® gab das Advisory CA-2000-18
"PGP
May Encrypt Data With Unauthorized ADKs" heraus und
auf der bekannten Website Slashdot,
der PGP-Users
Mailingliste und in der Usegroup alt.security.pgp
entbrannten lange Diskussionen über die Folgen und Ursachen
der Ergebnisse von Sendereks Untersuchung, die ich an dieser
Stelle als ADK-GAU bezeichnen möchte, den die Ergebnisse stellten
sich als das größte und schwerwiegendste Sicherheitsloch in
der Geschichte von PGP heraus.
Ausgehend von meinen CMRK Testschlüsseln, die ich 1997 erstellt
und zum Download zur Verfügung gestellt hatte, damit sich
alle PGP Anwender selbst einen Eindruck von der ADK-Funktion
verschaffen konnten, hatte Ralf Senderek eigene Untersuchungen
angestellt, um herauszufinden, wo sich der ADK-Key befindet
und wie die Drittkeyverschlüsselung per ADK genau funktioniert.
Ausschlaggebend waren seine Bedenken gegenüber der ADK-Funktion,
die seit Beginn ihrer Einführung von vielen Kryptografen,
Privacy-Aktivisten und auch mir geteilt wurden und das Faktum,
dass keine wissenschaftliche Aufarbeitung des gesamten Komplexes
existierte:
Genauere Untersuchungen zur ADK-Funktion gab es nicht, nur
die Stellen im Sourcecode von PGP, die für den CMRK/ADK verantwortlich
sind, waren bekannt und einige Beschreibungen (wie hier in
dieser Anleitung) waren publiziert. In der Internetgemeinde
spukten seit Jahren Verdächtigungen und Vermutungen herum,
Spekulationen und Halbwissen vereinigten sich.
Während seiner Untersuchung stellte Ralf Senderek fest,
dass der ADK nicht, wie vermutet, Bestandteil des eigentlichen
Keys ist, sondern in der Signatur eines Keys im V.4 Format
sitzt.
Er hatte meine CMRK-Keys und Keys, die er selbst erstellt
hatte mit Hilfe eines selbst entwickelten Key-Editors und
dem Verschlüsselungsprogramm GnuPG
[Befehl "gpg --list--packets Key" ] analysiert.
Dabei rückten die Unterschiede im Schlüssel- und Signaturformat
zwischen den V.3-Keys der alten PGP 2.6.3 und den V.4-Keys
der neuen PGP 5-6 Versionen in das Zentrum seiner Aufmerksamkeit.
Er stellte fest, dass Keys im Schlüssel- und Signaturbestandteil
aus einzelnen Unterpaketen bestanden, die zur Aufnahme aller
Bestandteile eines Keys und seiner Signatur dienten.
Bei V.4-Keys im Gegensatz zu V.3-Keys besteht der Signaturbestandteil
aus mehreren Unterpaketen, insgesamt kann sowohl der Schlüssel-
als auch der Signaturbestandteil um zusätzliche Unterpkate
erweitert werden.
Während der Untersuchung der Unterpakete identifizierte er
das ARR Feld und den ADK-Key in einem Unterpaket der Signatur
des V.4-Keys, in der die Informationen zum zu verwendenden
ADK-Key und der Session-Key, zusätzlich mit dem ADK-Key verschlüsselt,
abgelegt war.
Er musste auch feststellen, dass ein Teil der Signatur mit mehreren
Unterpaketen durch einen Hash der Selbst-Signatur dieses Teils wie
auch aller enthaltenen Unterpakete vor Manipulationen geschützt
wurde, während ein weiterer Teil mit mehreren Unterpaketen durch
keinen Hash geschützt wird, also immer "offen" liegt.
Während also eine Veränderung des ersten Teils zu einer korrupten
Signatur führen würde, wäre eine Einbringung oder Abänderung
von Informationen im zweiten Teil möglich, ohne das die Signatur
und damit die Validität des Keys korrumpiert wäre.
Die nicht gehashten und geschützten Unterpakte basieren auf
dem OpenPGP Standard, wurden aber von PGP fehlerhaft implementiert,
GnuPG besipielsweise ignoriert falsche ADK's in nicht gehashten
Unterpakten.
Es stellt sich allerdings die Frage, ob solche Unterpakettypen
überhaupt sinnvoll sind.
Im OpenPGP Standard heisst es dazu:
5.2.3. Version 4 Signature Packet Format
[...]
The data being signed is hashed, and then the signature data from the
version number through the hashed subpacket data (inclusive) is
hashed. The resulting hash value is what is signed. The left 16 bits
of the hash are included in the signature packet to provide a quick
test to reject some invalid signatures.
There are two fields consisting of signature subpackets. The first
field is hashed with the rest of the signature data, while the second
is unhashed. The second set of subpackets is not cryptographically
protected by the signature and should include only advisory
information.
[...]
A subpacket may be found either in the hashed or unhashed subpacket
sections of a signature. If a subpacket is not hashed, then the
information in it cannot be considered definitive because it is not
part of the signature proper.
Schematische Abbildung des ADK-Sicherheitslochs [CERT]

Davon ausgehend, führte Senderek an den von ihm erstellten Keys Manipulationen in den Signaturen durch, die zu folgenden Ergebnissen führten:
- ein V.3 RSA-Key kann in einen V.4 RSA-Key umgewandelt und mit ADK-Keys versehen werden, führt dabei aber zu einer vollständigen Veränderung der Informationen über Key-ID, User-ID und Fingerprint, also zu einem "neuen" Key, der sich vom ursprünglichen V.3 Key unterscheidet
- bei einem V.4 DH-Key ohne ADK kann in den ungehashten,
bzw. ungeschützen Teil der Signatur ein neuer ADK verankert
werden, ohne die Signatur, bzw. die Validität des Keys zu
korrumpieren.
Ein manipulierter V.4 Key verändert sich aber in der Bytegrösse aufgrund der Aufnahme des ADK-Keys. - bei einem V.4 DH-Key mit ADK, der sich mit Wissen des
Anwenders im gehashten, bzw. geschützten Teil der Signatur
befindet, kann dieser ADK in den ungeschützten Teil verschoben
und durch einen neuen ADK ersetzt werden, bzw. kann zum
bestehenden ADK ein zusätzlicher ADK in dem ungeschützten
Teil der Signatur eingebracht werden, ohne das die Signatur,
bzw. die Validität des Keys korrumpiert wird.
Ein manipulierter V.4 Key verändert sich aber in der Bytegrösse aufgrund der Aufnahme des ADK-Keys.
Am 24.08.2000 teilte der Kryptologe Ross Anderson von der University
of Cambridge mit, dass es einem seiner Studenten, Steve Early,
gelungen sei, die betreffende Stelle im Source Code in einer
PGP 6.5.1i-beta2 zu identifizieren.
Er schreibt:
Ralf Senderek has found a horrendous bug in PGP versions 5 and 6. It's of scientific interest because it spectacularly confirms a prediction made by a number of us in the paper on `The Risks of Key Recovery, Key Escrow, and Trusted Third-Party Encryption' that key escrow would make it much more difficult than people thought to build secure systems.
He's written a paper on his work and it's at
http://senderek.de/security/key-experiments.html
Since NAI joined the Key Recovery Alliance, PGP has supported "Additional Decryption Keys" which can be added to a public key. The sender will then encrypt the session key to these as well as to your main public key. The bug is that some versions of PGP respond to ADK subpackets in the non-signed part of the public key data structure. The effect is that GCHQ [Anmerkung: Government Communications Headquarters, britischer Geheimdienst] can create a tampered version of your PGP public key containing a public key whose corresponding private key is also known to themselves, and circulate it. People who encrypt traffic to you will encrypt it to them too.
The problem won't go away until all vulnerable versions of PGP are retired, since it's the sender who is responsible for encrypting to the ADKs, not the recipient.
In the meantime there might be a nasty denial-of-service attack in which bad guys upload tampered versions of everybody's public keys to all the public keyrings.
Ross
PS: my student Steve Early has trawled the PGP-6.5.1i-beta2 source code and found the bug:
In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions: one called ringKeyFindSubpacket(), which finds a subpacket from a self-signature packet, and ringKeyAdditionalRecipientRequestKey(), which uses ringKeyFindSubpacket() to search for ADK subpackets. ringKeyFindSubpacket() is declared as follows: PGPByte const * ringKeyFindSubpacket (RingObject *obj, RingSet const *set, int subpacktype, unsigned nth, PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation, unsigned *pmatches, PGPError *error); In particular, the "phashed" parameter is used to return whether the subpacket was in the hashed region. Now, looking at the call in ringKeyAdditionalRecipientRequestKey() I see this: krpdata = ringKeyFindSubpacket (obj, set, SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, &krdatalen, &critical, NULL, NULL, &matches, error); ...the "phashed" value isn't checked (or even asked for)!Fixing the bug, and generating BIG WARNINGS when ADKs are found in the non-hashed area, should be trivial.
Das heisst, ein V.4 DH-Key, der mit PGP 5.5 - 6.5.X erstellt wurde,
kann nachträglich ohne Wissen des Anwenders mit ADK-Keys gespickt
werden, an die Daten zusätzlich zum Keybesitzer mitverschlüsselt
und natürlich von den ADK-Keybesitzern auch entschlüsselt werden,
sofern sich auch der ADK-Key im Public Keyring des Opfers befindet,
was bei unbedarften PGP Anwendern und angesichts der Automatisierungsfunktionen
zur Keyverwaltung nicht auszuschliessen ist.
Ein mit PGP 2.6.3 oder PGP 6.5.X erstellter RSA-Key liegt
im V.3 Format vor und kann nur durch Umwandlung in einen V.4
RSA-Key und Veränderung aller Keyidentifizierungsinformationen
mit ADK-Keys gespickt werden.
Was als zusätzliche und kontrollierbare, wenn auch zweifelhafte,
Funktion gedacht war, entpuppte sich als echtes Back-Door.
Wie oben gesagt, entspannten sich lebhafte Diskussionen in
allen Bereichen des Internets, während die herkömmlichen Medien,
Webforen, News-Letter und News-Ticker zuerst keinerlei Notiz
nahmen. Einige User begannen ihre PGP-Keys zurückzuziehen,
waren also per PGP nicht mehr erreichbar, andere stellten
erste Forderungskataloge und Erklärungsaufforderungen an NAI
auf und erklärten ihren Umstieg auf PGP 2.6.3 und GnuPG, andere
weiderum frischten alte Verschwörungstheorien auf, die Verquickungen
zwischen NAI/PGP und den amerikanischen Geheimdiensten NSA
und FBI zum Inhalt hatten, einzelne User begannen, die Experimente
von Senderek mit dessen breitsgestellten Keymaterial nachzuvollziehen.
Alle erwarteten die ersten Reaktionen von NAI und Phil Zimmermann.
Die folgte auch dann am Abend des 24.08.2000 in Form einer Erklärung von Phil Zimmermann auf der PGP.com Website als Antwort auf ein Bulletin, dass die CERT Organisation mittlerweile zum ADK-GAU herausgegeben hatte und einer Erklärung von Will Price, dem Director of Engineering von PGP Security, Inc. auf der PGP-Users Mailingliste am 25.08.2000:
Phil Zimmermann:
Date: Thu, 24 Aug 2000 19:02:19 -0700
To: CERT Coordination Center <cert@cert.org>
From: Philip Zimmermann <prz@pgp.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We at NAI/PGP Security regret this important bug in the ADK feature
that has been described on various Internet postings today (Thursday
24 Aug). We were made aware of this bug in PGP early this morning.
We are responding as fast as we can, and expect to have new 6.5.x
releases out to fix this bug late Thursday evening. The MIT web
site should have a new PGP 6.5.x freeware release early Friday, and
the NAI/PGP web site should have patches out for the commercial
releases at about the same time. As of this afternoon (Thursday),
the PGP key server at PGP already filters out keys with the bogus
ADK packets. We expect to have fixes available for the other key
servers that run our software by tomorrow. We have also alerted
the other vendors that make PGP key server software to the problem,
and expect Highware/Veridis in Belgium to have their key servers
filtering keys the same way by Friday.
The fixes that we are releasing for the PGP client software
filters out the offending ADK packets. We already warn the users
whenever they are about to use an ADK, even in the normal case.
We will have new information as soon as it becomes available at
http://www.pgp.com.
Philip Zimmermann
prz@pgp.com
19:00 PDT Thursday 24 Aug 2000
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0 (Build 200 Beta)
iQA/AwUBOaXThGPLaR3669X8EQKfGACfagps8ZHCba21eOjoxRUb07Z59dkAoKRg
vaKciU0kcW1l1i+eBS18aQNU
=zoga
-----END PGP SIGNATURE-----
Wie aus der Information von Phil Zimmermann, die PGP Keyserver bei PGP.com würden nach manipulierten Keys mit ADK gescannt werden, hervorgeht, sind auch die PGP Keyserver betroffen, d. h. manipulierte V.4 PGP-Keys konnten die ursprünglich hochgeladenen PGP-Keys ersetzen, ein weiterer schwerwiegender Bestandteil des ADK-GAU's, denn über die Keyserver werden die meisten Keys unter den PGP Anwendern verbreitet.
Will Price:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A quick update on the status of things.
For the latest information, we have a well-marked link for this on
the front page of www.pgp.com. Currently this will take you to:
http://www.pgp.com/other/advisories/adk.asp
That page will also link you to the CERT advisory. There is much more
we plan to say and do, and we are putting together an advisory to
cover the details people are asking about. However, we're juggling
this at the same time as we're trying to build a large number of
releases for all of you. Needless to say, there are a lot of people
here burning the midnight oil.
I would like to add that there have been innumerable false
conclusions and hypotheses which have led to people misunderstanding
this issue entirely in the messages I have read in this group and
others so far. We can't take the time to respond to all of these
individually right now, but hope to cover the issues which have been
raised in the advisory. After that is released, I and other team
members as usual should be available here to answer any further
questions.
Thanks for your patience!
- -- Will
Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP
iQA/AwUBOaZu/ay7FkvPc+xMEQJ8DgCfRJjFtbiuzHW4fODEviUikixyyLgAoJIm
ur0xipL0uGXFtee3/edyjE7i
=Ni2T
-----END PGP SIGNATURE-----
Am 26.08.2000, zwei Tage nach Bekanntwerden des ADK-GAU's,
veröffentlichte NAI als erste Massnahme die PGP Freewareversion
6.5.8 für Windows und Macintosh, UNIX basierte Betriebssystem
blieben aussen vor, alte PGP-Versionen der betroffenen Reihe
5.5.X bis 6.5.2 ebenso.
Am 27.08.2000 folgten Patches für die kommerziellen Versionen
PGP 6.5.3 (Windows) und 6.5.2 (Macintosh) Desktop Security
& Personal Privacy und die Veröffentlichung eines Reparaturtolls
namens PGPrepair, mit dem Public Keyrings und Keyserver Keyringe
auf manipulierte Keys gescannt und ADK's in den ungeschützten
Teilen der Signatur entfernt werden können. Am Mittag des
27.08 veröffentlichte NAI die kommerziellen PGP 6.5.8 Versionen
Desktop Security & Personal Privacy.
Bemerkung
Man muss PGP.com zugute halten, aufgrund des ADK-GAU's sehr
schnell reagiert und die Windows & MaC PGP Anwenderschaft
sehr schnell mit Patches und gefixten Versionen versorgt zu
haben.
Auch die Informierung über die Website von PGP.com und auf
der PGP-Users Mailingliste ist PGP.com zugute zu halten.
Was ich vermisst habe, war die Einbeziehung der englisch-
und deutschsprachigen Newsgroups und fehlende Information
auf der NAI Website.
Sowohl die Patches, als auch die neuen Vollversionen sollen das ADK-Sicherheitsloch beheben. Die ADK-Funktion als solche bleibt erhalten.
Am 26.08.2000 teilte der PGP User Michel Bouissou in alt.security.pgp
seine ersten Erfahrungen mit der PGP Version 6.5.8 mit, die
er mit dem manipulierten Testkey B1 aus dem Keyset von Ralf
Senderek konfrontierte.
Seine Ergebnisse:
- die Version zeigt einen manipulierten Key als normalen, validen Key ohne jeden ADK an
- der ADK-Key wird bei der Verschlüsselung nicht benutzt
- die Version zeigt keinerlei Hinweise oder Warnungen an, dass der Key manipuliert wurde, bzw. einen falschen ADK enthält
Kurz zusammengefasst kann man zur Version 6.5.8 sagen, dass
PGP den ADK-Key zwar nicht benutzt, aber keine Warnung oder
Information anzeigt.
Allerdings wird bei dem Import die Signatur entfernt,
woran ein manipulierter Public Key erkennbar ist.
Key-Server
Am Montag, den 28.08.2000 teilte Teun Nijssen von der Universität Tilburg/Niederlande, der die zwei Keyserver von SURFnet administriert, auf der PGP-Users Mailingliste mit, er habe bei einem Check der 1.3 GB grossen Keyringe mit PGPrepair keine einzige ATTACK oder WARNING Meldung erhalten, also keinen manipulierten Key gefunden, der auf dem ADK-Sicherheitsloch basiert:
Message-Id: <200008281300.e7SD0M502111@mailone.kub.nl>
From: "teun, Tilburg University" <Teun.Nijssen@kub.nl>
Organization: Tilburg University
To: pgp-users@cryptorights.org
Date: Mon, 28 Aug 2000 14:59:56 +0200
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: [PGP-USERS] CERT statement on ADK bug, etc........
In-reply-to: <20000828073722.A18834@cp5340>
X-mailer: Pegasus Mail for Win32 (v3.01d)
Sender: pgp-users-admin-human@cryptorights.org
Reply-To: pgp-users@cryptorights.org
Tony,
/Will Price published the availability of the PGPRepair utility on this
/list yesterday. You can verify/ensure the integrity of the keys on your
/keyring at any time. I did so within minutes of receiving the message
/announcing the PGPrepair utility.
I was less fast: it takes a couple of hours to retrieve 1.3 GB each from the
two keyservers that SURFnet runs.
Anyway, I found zero pgprepair 'ATTACK' or 'WARNING' reports in both servers.
And, being a ten year member of the kernel of CERT-NL, I would like to express
that I think that NAI is handling this issue quite well. I have seen many
vulnerabilities through the years. Many of them are at the core of security
and although I like the idea of bug free software, it appears I live in a
different world: Kerberos, SSH, Netscape, IE, Lotus Notes, you name it....
cheers,
teun
Dazu noch die Mail von Randy Harmon
von PGP.com, gepostet am 30.08.2000:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We at PGP Security have been working with Teun at Surfnet on this
topic. By scanning his Horowitz and PGP Certificate Server
databases, he has verified that there are currently no instances of
keys which would trigger the vulnerability in PGP client software.
We have also provided a preliminary patch so that his PGP Certificate
Server now rejects incoming self-sigs containing such unhashed ADK
subpackets.
We have offered both to Highware and to Marc Horowitz help in any way
we can so that a new version of OpenKeyServer and pksd (respectively)
can be produced to address the issue in those software packages.
In the meantime, if keyserver managers wish, they can perform a
periodic key dump and run the 'pgprepair' tool available from
http://www.pgp.com/other/advisories/adk.asp. This may help identify
occurences of the problem as quickly as possible.
Randy
- --------
Randy Harmon
Administrator, certserver.pgp.com
Engineer, PGP Keyserver
PGP KeyID: 0x5cb7b7f2a0aa5c1e
> -----Original Message-----
> From: Michael Helm [mailto:helm@fionn.es.net]
> Sent: Wednesday, August 30, 2000 12:53 PM
> Cc: pgp-keyserver-folk@flame.org
> Subject: Re: pgp vulnerability -- possible key server impact
>
>
> How are Horowitz keyserver managers dealing with the
> ADK pollution problem?
>
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3
iQA/AwUBOa2F2ly3t/KgqlweEQJV3gCfZroAg+31N9xTzXFGZH5SKKRpiCQAoKQ4
w9sf2hcpWESWVVm+R1t9jpHv
=xSxx
-----END PGP SIGNATURE-----
Die Konsequenzen des ADK-GAU's
Allgemein- das Vorliegen des Quellcodes eines Programmes (also auch
von PGP 5/6) garantiert nicht von vorne herein dessen Integrität
und Sicherheit.
Das jetzige ADK-Sicherheitsloch besteht seit Einführung von ADK, also seit mehreren Jahren!
Anmerkung: Das hat schon das Sicherheitsloch von PGPdisk 1.0 gezeigt. - Eine vollständige, kontrollierte und unbahängige Überprüfung
des Quellcodes auf Sicherheitslöcher und Auswirkungen des
Programmcodes seitens anerkannter Kryptografen muss Voraussetzung
einer Veröffentlichung sein.
Da dies kosten- und zeitintesnsiv ist, sollten Softwarehersteller u. U. eine Analyse im eigenen Interesse und zum Vorteil ihrer Kunden finanzieren - PGP 6 muss um nachvollziehbare und strenge Sicherheitsroutinen ergänzt werden, die mögliche Manipulationen in weitestgehendem Umfang ausschliessen
- NAI muss die Ursachen und die Auswirkungen des ADK-GAU's vollständig dokumentieren, ebenso zukünftige Entwicklungen und Programme im Kryptografiebereich
- NAI muss PGP vollständig dem OpenPGP
Standard RFC-2440 unterordnen, bzw. diesem Standard
entsprechen und Versionen anbieten, die vollständig ohne
ADK, bzw. Mechanismen sind, die Key Escrow Effekte haben.
In Beziehung zum ADK-GAU muss sich das Key-Format ändern.
- Revocation aller mit PGP 5/6 erzeugten DH-Keys, Neuerstellung von RSA-Keys mit PGP 2.6.3 IN oder PGP 6.5.8
- Benutzung von PGP 2.6.3 oder eines anderen, sicheren Verschlüsselungsverfahren,
bis alle nötigen Konsequenzen gezogen und die wichtigsten
Forderungen erfüllt wurden.
Inwieweit das erreicht ist, muss jeder für sich selbst entscheiden. - Jede Mitwirkung an Key Escrow Konzepten ist aus meiner Sicht für einen Anbieter von Kryptografie indiskutabel
- gedenkt NAI/PGP.com für alle Versionen der Reihe 5.5 bis 6.5.2 Patches herauszugeben.
- besitzen die neuen PGP Versionen weiterhin das unsignierte Unterpaket, bzw. sind weitere Bestandteile/Unterpakete von V.4 PGP-Keys ungeschützt und nicht vor Manipulationen sicher.
- entfernen gefixte Keyserver nur einen "falschen" ADK oder das gesamte unsignierte Unterpaket
- gedenkt NAI/PGP.com das Format der V.4 Keys zu ändern (Anlehnung an OpenPGP, bzw. GnuPG)
Im Anschluss dokumentiere ich die Erklärung und den Forderungskatalog
PGP ADK Bug: What we expect from N.A.I.
Message-ID: <8oam4g$om$1@cristal.i-quake.com>die Michel Bouissou am 27.08.2000 in alt.security.pgp veröffentlichte und denen ich mich anschliesse:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The disastrous ADK bug recently discovered by Ralf Senderek in
versions 5.x and 6.x of PGP has greatly compromised the trust that
all of us crypto and privacy activists had in N.A.I. PGP.
In this message, I express not only my personal opinion, but as well
the opinion of several crypto and privacy activists, long-time PGP
supporters in France.
This bug is the most serious and threatening one ever discovered in
PGP since its beginning.
Although N.A.I. quickly reacted to this bug by scanning and fixing
their keyservers, publishing a new PGP 6.5.8 version supposed to be
immune to the bug within 48 hours after its discovery, and also
released a PGPrepair program which is supposed to clean forged public
keys from keyrings, this still is far from enough.
(We write "supposed" not because we distrust the efforts made by
N.A.I., but because we estimate that these solutions cannot have been
tested enough in this short timeframe to put full confidence into
them).
We received information from N.A.I. stating that these
countermeasures were the first steps taken in emergency, and we
acknowledge that they shown quick and reactive and there was not much
more that they could have done in such a short timeframe.
We understand from N.A.I. employees statement that more comprehensive
and definitive solutions are yet to come and are looking forward for
these solutions.
Yet, we regret that N.A.I. and / or Phil Zimmermann didn't release so
far clearer explanations about what they thought of this bug and its
cause and consequences on a technical standpoint.
The fact that this bug can allow messages to be encrypted to somebody
(attacker) different than the intended message recipients makes it
one of the most disastrous things that can happen to a public-key
cryptosystem.
This bug being related to the "ADK / ARR" feature in PGP makes the
issue still hotter, as this ADK feature has been contested and
disapproved from the beginning by the vast majority of PGP
supporters, as well as a number of crypto specialists.
In any case, this "ADK / ARR" feature is a very sensible thing, as
incoporating such features in a cryptosystem creates one possible
weakness and attack path. Ralf's discovery recently proved we were
right being worried about it.
This ADK system being so sensible, we would have expected N.A.I. to
have put the highest care in implementing, testing, securing and
documenting it. Unfortunately, Ralf's work and our own tests proved
this wasn't the case.
=> The bug exists, can easily be exploited. This has been largely
debated these last days.
=> The "warning" messages do not behave as one would expect by
reading the manuals and options explanations.
=> The whole ADK concept and implementation is not explained nor
discussed in the PGP Freeware manual, maintaining ignorance and
confusion about sensible things which should be made very clear.
All this proves that this wasn't properly done, and, quoting Ralf
Senderek last public note:
<<<<<
>This is not a bug, this is a scandal, because NAI put ADKs into PGP
>without caring about simple manipulations. Obviously there has
>never been a well thought-out security strategy and most of the
>relevant information the public got from NAI concerning ADKs was
>completely untrue as my
>experiments reveal.
>>>>>
We regret to say that we must share and approve Ralf point of view
about this.
This weakness discovered in the v4 signature mechanism rises the
issues of possible other weaknesses that might have been introduced
in PGP when PGP5 was released, because it proves that things which
should have been carefully checked and designed were not. And such a
weakness stayed unnoticed for several years.
In light of this, we must acknowledge that Ralf Senderek advice to
trust only PGP 2.6.x version makes sense.
Seing that, and seing that several small but very visible bugs have
remained in the PGG G.U.I for a very long time (such as a bug in the
display of the main PGPkeys window, bug in the display of Keyserver
search results...) we really have to worry about the overall quality
and security of the PGP products.
Consequently, we suggest that:
- - N.A.I. should put the core of PGPFreeware under GNU/GPL licence.
This would probably have no or little impact on the ability of N.A.I.
to keep producing and selling commercial PGP versions and related
security services, and would help much in restoring confidence.
- - N.A.I. should start cooperating, and not competing, with current
PGP-compatible cryptosystems developments such as GnuPG.
- - N.A.I. should urgently have the current PGP versions and key
formats reviewed by independant competent, and well-known
cryptographers, and should ask them to publish an independant audit
report about their findings.
- - N.A.I. should communicate very clearly about the ADK issue, and the
possible consequences of the existence of a non-hashed area in the v4
signature format. Although details about this signature format may be
buried somewhere in a technical RFC or the like, N.A.I. should
publicly discuss this signature format and the reason why such
non-hashed areas were put into it.
- - N.A.I. should try its best to explain how this bug can have been
introduced unnoticed in PGP, and why the implementation of the ADK
feature has not been accompanied with security controls that meet the
quality standards expected for such a life-critical software.
- - N.A.I. should take appropriate measures to really kick this problem
off. If this means having to abandon the current DH/DSS keys or
signature format and developing a new, more robust format, this
should be undertaken according to indenpendant and competent
cryptographers advice.
- - N.A.I. should stop bundling PGP with other "security" features such
as a VPN or firewall or intrusion detector that have nothing to do
with the PGP core. PGP is PGP and can maybe be accompanied by
PGPdisk. The rest has nothing to do with PGP and could be sold by
N.A.I. in different, separated software packages if they want. The
more unnecessary and bulky things are included with PGP, the bigger
PGP grows, the harder it becomes to review and control, and higher
becomes the risk that security-threatening bugs remain unnoticed.
- - N.A.I. should integrate into the next PGP releases an option to
globally desactivate ADK encryption, even if this means refusing to
encrypt anything to a recipient key which has an attached ADK.
- - And we wish that N.A.I. should release a freeware PGP version which
is completely ADK-free.
Should N.A.I. choose to follow some of these advices, this would
greatly help in restoring confidence that has much suffered from this
regrettable event.
Should N.A.I. choose to ignore these comments, this would surely lead
many people to distrust the PGP software and move on to new systems
such as GnuPG, which many of us are already seriously considering.
michel@bouissou.net
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
Comment: Corrigez le bug PGP ADK. Installez PGP 6.5.8 ou plus recent.
iQA/AwUBOajNvY7YarFcK+6PEQIsfgCeItaFxuENITYwHyarFt6h3oX4dwwAn305
MezqixhI0VhEObdogHcJU3rO
=Jkhe
-----END PGP SIGNATURE-----
Am 29.08.2000 stellte Phil Zimmermann anlässlich des ADK-GAU´s noch einmal seine Sicht des ADK-GAU's dar:
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 our only 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.
[...]
In der Hoffnung, dass dies die erste und letzte "GAU" Seite ist.