DEUTSCHE PGP ANLEITUNG

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 Senderek
hinwies.

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:

  1. die Version zeigt einen manipulierten Key als normalen, validen Key ohne jeden ADK an
  2. der ADK-Key wird bei der Verschlüsselung nicht benutzt
  3. 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.
Persönlich-Praktisch
  • 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
Ungeklärte Fragen
  1. gedenkt NAI/PGP.com für alle Versionen der Reihe 5.5 bis 6.5.2 Patches herauszugeben.
  2. 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.
  3. entfernen gefixte Keyserver nur einen "falschen" ADK oder das gesamte unsignierte Unterpaket
  4. 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.