DEUTSCHE PGP ANLEITUNG

GAK, CMR, ARR, MRK, ADK und PGP

Abkürzung Übersetzung Bedeutung
GAK Government Access to Keys staatlicher Zugriff auf Public Keys
ARR Additional Recipient Record ein Feld in einem Public Key, in dem vermerkt wird, an welchen Dritten zusätzlich verschlüsselt wird
CMR Corporate/Company Message Recovery Wiederherstellung des Klartextes einer verschlüsselten Nachricht durch Firmen und Vereinigungen
CMRK Corporate/Company Message Recovery Key der Drittkey
MRK Message Recovery Key der Drittkey
ADK Additional Decryption Key der Drittkey

Mit PGP 5.0, im Jahr 1997 veröffentlicht, wurde eine neue Funktion eingeführt, die als CMR, "Corporate Message Recovery" bekannt wurde und eine breite Diskussion auslöste.
CMR beschreibt die Möglichkeit, Dateien oder Nachrichten, die von einer Person an eine zweite verschlüsselt werden, gleichzeitig für eine dritte Person zu verschlüsseln, die sie also auch wieder entschlüsseln kann.
Deshalb spricht man in diesem Zusammenhang auch von Drittkeyverschlüsselung.
PGP Inc. versuchte mit CMR den Marktanteil für PGP im Businessbereich zu erhöhen, denn die ADK-Funktion zielte vornehmlich auf den Einsatz von PGP in Unternehmen.
Zugleich fand in den USA eine von Geheimdiensten forcierte Diskussion um die Einführung von staatlich verordneten Key Escrow (Hinterlegen des Entschlüsselungskeys bei einer zentralen Stelle) und Key Recovery (Rückgewinnung des eigenen Entschlüsselungskeys durch Dritte) Verfahren statt, dem PGP Inc. und NAI nach eigener Aussage durch die ADK-Funktion den "Wind aus den Segeln nehmen" wollte.

Die ADK/CMRK Komponente ist nicht Bestandteil des OpenPGP Standards nach RFC 2440, auf den sich NAI bezieht.
Die OpenPGP Allianz bezeichnet in Abgrenzung zu OpenPGP "PGP als Implementation des OpenPGP Standards eines einzelnen Unternehmens".

Am 29.08.2000 stellte Phil Zimmermann anlässlich des ADK-GAU´s noch einmal seine Sicht der ADK-Funktion dar (Kommentare in schwarz):
[...]

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.


Das stimmt nicht: Mit dem PGPadmin Tool der PGP Businessvariante ist es möglich, die ADK-Verschlüsselung zwingend zu implementieren - in diesem Fall hat der Sender nicht die Wahl, nur an den Keybesitzer zu verschlüsseln.
Der Wunsch wird zum Zwang.
Je nach Konfiguration des Netzwerkes auf der Seite des Keybesitzers mit ADK-Public Key, werden ein- und ausgehende E-Mails ohne ADK's abgeblockt, so dass die "freie Wahl" auch dadurch verhindert werden kann.

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.

Es gibt auch andere Methoden und Lösungskonzepte, um Daten vor Verlust und Nichtzugriff in einem Unternehmen zu schützen.

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.

Das stimmt nicht: Ein ADK-Key ist für den Sender nur sichtbar, wenn in PGPkeys auch die ADK-Anzeige aktiviert ist, das ist standardmässig nicht der Fall.
Bei der Verschlüsselung wird der ADK-Key ohne Nachfrage in das Empfängerfenster übernommen. Ein Warnhinweis ergibt sich nur, wenn der ADK-Key nicht präsent ist.

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.

Aber sie können dazu gezwungen werden, Public Keys mit ADK's anderer Personen zu verwenden.

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.

Die kritischsten Positionen zu ADK stammen aus Reihen langjähriger PGP-Anwender, Privacy-Aktivisten und namhafter Kryptologen.

[...]

Faktisch bleibt die Wirkung dieselbe: Eine dritte Partei kann in die Lage versetzt werden, die verschlüsselte Kommunikation zwischen "Bob" und "Alice" mitzuverfolgen oder verschlüsselte Dateien von "Bob" zu öffnen.

Die Funktionsweise

Der Administrator, von NAI bezeichnenderweise als "Chief Security Officer" (CSO) bezeichnet, erzeugt mit Hilfe des PGPadmin Tools eine Clientversion von PGP, ausgehend von seiner PGP 6.X Desktop Security, die jeder Benutzer zu verwenden hat.
Während der Clienterzeugung kann der Administrator im Konfigurationsprozess bestimmte Präferenzen setzen:

  • Festlegung eines ADK für eingehende E-Mails
  • Festlegung eines ADK für ausgehende E-Mails
  • Erzwingung der Benutzung eines ADK für ausgehende und/oder eingehende E-Mails
  • Erzwingung von zusätzlichen ADKs (z. B. weiterer "Firmen")
  • Erzwingung einer bestimmten Länge und Qualität der Passphrase
  • Erzwingung einer bestimmten Keygrösse
  • Zwang aller Benutzer der Clientversion, den ADK bei der Erzeugung eigener Schlüssel zu signieren
  • Erzwingung eines bestimmten Kommentars im Nachrichtenheader
  • Ausgabe einer Warnung, wenn mit einem Public Key verschlüsselt wird, der nicht mit dem ADK signiert wurde
  • Verbot der Keyerzeugung
  • Verbot der RSA-Keyerzeugung
  • Verbot der konventionellen Verschlüsselung
  • Voreinstellung der Keys, die im Standardkeyring enthalten sind

Erhält ein Benutzer die Clientversion und erzeugt damit seine Public Keys, wird der Signatur ein CAF (Corporate Access Field), bzw. ARR (Additional Recipient Record) Bereich hinzugefügt.
Er enthält die Information, dass bei jeder Verschlüsselung sowohl mit dem Public Key des Empfängers, aber auch mit dem Firmen Public Key (CMRK/ADK) verschlüsselt werden "soll" oder "muss", bzw. bei jeder Verschlüsselung der Firmen Public Key (CMRK/ADK) verwendet wurde.

Das heisst, es gibt Public Keys, deren ADK's zwingend mitbenutzt werden müssen, wenn man mit diesem Public Key verschlüsselt. Der ADK kann nicht ausgeschlossen werden, bzw. gibt es in PGP keine Funktion, um den ADK zu deaktivieren, an den Empfänger kann nicht verschlüsselt werden, wenn der ADK im Pubring nicht vorhanden ist.
Mein CMR User Testkey ist ein "mandatory ADK Public Key".

Der genaue Ort des ARR Feldes wurde durch Ralf Senderek in seiner Untersuchung
KEY-EXPERIMENTS - How PGP Deals With Manipulated Keys - An Experimental Approach by Ralf Senderek
dokumentiert.
In seiner Untersuchung zeigt Senderek, dass der ADK in der Signatur eines Keys im V.4 Format sitzt. Der Key muss im V.4 Format sein, da nur dieses Keyformat zusätzliche Unterpakte in der Signatur eines Schlüssels bereitstellt, in denen Informationen zum zu verwendenden ADK-Key und zur Speicherung des Session-Keys, der zusätzlich mit dem ADK-Key verschlüsselt wird, abgelegt werden können.

Siehe auch Der ADK-GAU

Der Public Key des Benutzers wird so zum Träger des CMRK/ADK der Firma: Aufgrund der Zusatzverschlüsselung ist der Firmenzugriff auf den Session Key (und damit auf den Nachrichtentext) gewährleistet.

Man unterscheidet drei Arten von ADK´s:

  1. ADK´s für eingehende Dateien/Nachrichten
    wird der Public Key eines Benutzers von einer Person ausserhalb der Firma benutzt, wird nicht nur mit dessen Key verschlüsselt, sondern auch mit dem Drittkey. Diese Möglichkeit kann nur für DH/DSS Keys konfiguriert werden.

  2. ADK´s für ausgehende Dateien/Nachrichten
    verschlüsselt ein Benutzer in der Firma an einen anderen Benutzer in der Firma oder an eine Person ausserhalb der Firma, wird auch mit dem Drittkey verschlüsselt.
    Diese Möglichkeit kann für DH/DSS und RSA Keys konfiguriert werden.

  3. ADK´s dritter Firmen
    die Clienten werden so konfiguriert, dass der Benutzer mit einem Drittkey verschlüsseln muss, wenn er den Public Key mit ADK einer dritten Partei erhält und diesen zur Verschlüsselung benutzen will.

Deshalb ist es für eine Firma, die zwingende Drittkeyverschlüsselung für beide Kommunikationsrichtungen einsetzen will sinnvoll, nur DH/DSS Keys zuzulassen und die Clienten so zu konfigurieren, dass ADK-Verschlüsselung zwingend ist, die RSA-Keyerzeugung für den Benutzer nicht zu erlauben und die Möglichkeit der konventionellen Verschlüsselung für die Benutzer auszuschalten.

Um die Drittkeyverschlüsselung innerhalb eines geschlossenen Benutzerkreises wie einer Firma lückenlos zu überwachen, kommen in diesem Konstrukt noch drei weitere Komponenten hinzu:

  1. PGP Certificate Keyserver
    Um ADK-Keys zu verhindern, könnte ein Benutzer versuchen, mit einer unabhängigen PGP Version einen Public Key zu erzeugen und ihn in der Firma in Umlauf zu bringen. Um dies zu verhindern, richtet der Administrator einen Corporate Signing Key (CSK) ein, mit dem alle neuen Public Keys signiert sein müssen, bevor sie vom PGP Keyserver akzeptiert werden.
    Erzeugt ein Benutzer einen unabhängigen Key, der nicht den Sicherheitsrichtlinien (Policy) entspricht (weil ihm z.B. der ADK fehlt), wird die Signatur vom Keyserver versagt, der Public Key zurückgehalten und gerät nicht in Umlauf.
    Umgekehrt signieren alle ADK-Keys der Benutzer den CSK und werden wiederum vom CSK signiert. Der PGP Client kann so konfiguriert werden, dass eine Warnung an den Benutzer erfolgt, wenn an einen Key verschlüsselt wird, der nicht vom CSK signiert wurde und der PMA (siehe unten) kann so eingerichtet werden, dass Daten, die mit einem Public Key ohne CSK Signatur verschlüsselt wurden, abgeblockt und nicht weitergeleitet werden.

  2. Policy Management Agent for SMTP (PMA)
    Da mit Einsatz des PMA die Einhaltung der Sicherheitsrichtlinien (Policy) (auch der Drittverschlüsselung) durchgesetzt wird, wird der PMA in Gemeinschaft mit dem SMTP Server auch als "Policy Enforcer" bezeichnet.
    Der PMA arbeitet mit jedem SMTP Mailserver zusammen und führt folgende Kontrollfunktionen aus:

    • der ARR-Bereich wird überprüft, ob eine Drittkeyverschlüsselung vorliegt oder nicht. Fehlt die Drittkeyverschlüsselung, wird die Nachricht nicht versendet und an den Absender zurückgeschickt.
    • Nachrichten, die mit einem Public Key verschlüsselt oder mit einem Key signiert wurden, der nicht vom CSK signiert ist, werden abgeblockt.
    • Nachrichten, die konventionell verschlüsselt wurden, werden nicht versendet und an den Absender zurückgeschickt.
    • Nachrichten, die mit bestimmten Keys verschlüsselt wurden oder an bestimmte Adressen gehen sollen, die nicht zulässig sind, werden nicht versendet und an den Absender zurückgeschickt.

  3. Designated Revoker
    In der PGP Version 2.6.3 und PGP bis Version 5.5 kann nur der Besitzer des Public Keys diesen auch wieder zurückziehen, seit der Version PGP 6 gibt es eine weitere Person, bzw. dessen Key, der einen anderen Public Key zurückziehen und damit ungültig machen kann.
    Ein Designated Revoker ist ein weiterer Benutzer, der dazu ermächtigt ist, den eigenen Public Key zu widerrufen, bzw. auf dem Keyserver als zurückgezogen zu kennzeichnen.
    Der PGP Client kann vom Administartor so konfiguriert werden, dass für jeden Public Key, der mit der Clientversion erzeugt wurde, ein Revoker Key (z.B. der Key des CSO) vorhanden ist. Der Designated Revoker Key muss ein DH/DSS Key sein.
    Verstösst ein Benutzer gegen Policies oder verliert das Vertrauen der Firma, kann also eine dritte Person den Public Key des Benutzers widerrufen, so dass der Benutzer nicht mehr in der Lage ist, mit diesem Key verschlüsselte Nachrichten zu lesen.
    Weitere Infos und die Ergebnisse eines Tests zur Designated Revoker Funktion.

Zur Verdeutlichung kann man sich diese CMRK-Keys herunterladen und in den Pubring aufnehmen.
Der eine DH-Key von "CMR-User" stellt den User dar, der einen Public Key mit Drittverschlüsselung besitzt, der DH-Key von User "Little Brother" ist der Drittkey an den mitverschlüsselt wird.

Die Beschreibung der Drittkeyverschlüsselungs- und Kontrollfunktionen in PGP 5/6 legen die Vermutung nahe, dass die neuen DH/DSS-Keys nicht bloss deshalb eingeführt wurden, weil es sich um einen neuen Algorithmus handelt oder aufgrund lizenzrechtlicher Überlegungen (denn PGP 6.0 for Business Security unterstützt sehr wohl RSA), sondern auch, weil die DH/DSS Keyinfrastruktur innerhalb geschlossener Benutzergruppen vielfältigere Kontroll- und Zugriffsmöglichkeiten bietet.

Siehe auchPGP 5/6 Versionen

Schutzmöglichkeiten bei PGP 5/6

Generell sollten nur PGP Versionen ab 6.5.8 eingesetzt werden, die ADK/CMRK Keys im PGPkeys Fenster anzeigen kann und gegen den ADK-GAU gefixt ist.
Dazu ruft man PGPkeys auf und aktiviert im Menü View den Menüpunkt ADK.
Nicht-CMRK-Keys werden in der ADK Spalte mit grauen Buttons, CMRK-Keys mit einem roten Button markiert, so dass eine leichte Identifizierung von CMRK-Keys möglich ist. Leider wird der verantwortliche Drittkey nicht in gleicher Weise gekennzeichnet.
Um die ADK Anzeige zu optimieren, sollte man zuerst alle Anzeigeoptionen deaktivieren und dann reaktivieren, wobei die ADK Anzeige an erster Stelle aktiviert wird, so dass die ADK Anzeigespalte sofort hinter der Keys Spalte angefügt wird.
An einer weiteren Stelle fallen CMRK-Keys auch sofort auf:
Wird an einen CMRK-Key verschlüsselt, in dem der PGP Key des Empfängers in das Recipients Fenster gezogen wird, erscheint automatisch auch der Drittkey, an den mitverschlüsselt wird. Ist der Drittkey im Pubring nicht vorhanden oder deaktiviert (disabled) worden, erscheint bei dem Versuch, an den CMRK-Key zu verschlüsseln die Warnmeldung:
The user XYZ has a missing Additional Decryption Key. Contact the owner of the key to obtain the Additional Decryption Key.
Ein weiteres, eindeutiges Indiz, dass ein CMRK-Key vorliegt.
In diesem Fall sollte man Kontakt mit dem E-Mailpartner aufnehmen, einen anderen E-Mailweg und einen anderen PGP-Key vereinbaren.

Der beste Weg, um ADK/CMRK zu entgehen besteht darin, NAI-PGP nicht einzusetzen, sondern GnuPG, PGP 2.6.3 IN, CKT-PGP.

Die gefährlichen Möglichkeiten

"Privacy" ist in einem geschlossenen Benutzerkreis, in dem PGP 5/6 eingesetzt wird, nicht existent.

Im Rahmen einer gesetzlichen Regelung zur Anwendung kryptografischer Verfahren (z. B. als Ergänzung zum TKG), wären Vorschriften denkbar, die Provider und Onlinedienste dazu verpflichten, den PGP SMTP Server (oder einen Server mit vergleichbarer Funktionalität) einzusetzen und von den Benutzern fordert, nur Public Keys mit CAF/ARR und staatlich/behördlicher CMR-Funktion einzusetzen.
Aus dem "Firmen"-Master-Key würde der Behörden-Master-Key, aus Corporate Message Recovery würde "Government Message Recovery", und aus dem Corporate Access Field würde ein "Law Enforcement Access Field" werden.
Wenn so der geschlossene Benutzerkreis einer Firma durch die Bürger eines Staates ersetzt würden, wäre der Begriff "Privacy" im Internet nicht mehr anwendbar, da der Staat zwar kein GAK ("Govermental Access to Keys") hätte, dafür aber ein GAM ("Governmental Access to Messages").

Wie der ADK-GAU gezeigt hat, ist mit der Implementierung von Key Escrow/Message Recovery Konzepten wie ADK immer die Gefahr verbunden, zusätzliche Back-Doors zu öffen.

Die Firma PGP.INC (jetzt Network Associates NAI, alias McAfee) hat Firmen, Ministerien, staatlichen Behörden und Diensten mit ihrem Produkt PGP 5/6 die technischen Möglichkeiten aufgezeigt und technischen Mittel in die Hand gelegt, um eine effektive und umfassende Überwachung des E-Mailverkehrs innerhalb eines begrenzten Raumes wie auch auf nationaler Ebene Wirklichkeit werden zu lassen und damit der ganzen Bewegung für sichere E-Mailverschlüsselung und das Recht auf Privacy schweren Schaden zugefügt.
Das hat mit den ursprünglichen Ideen und Idealen, die sich mit Pretty Good Privacy verbinden, nichts mehr zu tun.

 

NAI, TIS, PGP, KRA und Key Recovery

Anfang Dezember 1997 wurde PGP für 35 Millionen US Dollar an Network Associates (NAI) verkauft.
Zu diesem Zeitpunkt war NAI schon seit 1996 Mitglied in der Key Recovery Alliance - die ADK Funktion hatte Zimmermann aber bereits Mitte 1997 mit PGP 5.0 entwickelt und implementiert, also einige Monate vor dem Verkauf an NAI.

Die Key Recovery Alliance K R A

der im Oktober 1996 gegründete Unternehmensverband (zu dem z. B. AOL, Compaq, Apple, DSI, Entrust, Fujitsu, Hewlett-Packard, IBM, Mitsubishi, Motorola, NEC, Novell und VeriSign gehören) hat sich zum Ziel gesetzt, die Entwicklung, Implementation und den Aufbau einer globalen Infrastruktur von Technologien zu fördern, die es dritten Parteien ermöglicht, über Key Recovery (Möglichkeit einer dritten Partei den Secret Key wiederherzustellen) und Key Escrow (Hinterlegung des Secret Keys an zentraler Stelle) verschlüsselte Daten zu rekonstruieren.
Die KRA stimmt damit mit der Politik der US Regierung überein, den Export starker Kryptografie zu verbieten oder zu verhindern, es sei denn, sie beinhaltet Vorkehrungen (Backdoors), die es amerikanischen Geheimdiensten ermöglicht, die verschlüsselten Daten wiederherzustellen.
Gleichzeitig versucht sie, einem staatlich vorgeschriebenen, zwingendem Key Recovery (mandatory key recovery) durch ein marktwirtschaftlich begründetes Key Recovery zuvorzukommen.

Neben den technischen Vorstellungen stellt die KRA auch politische Überlegungen zu einem staatlichen Key Recovery Szenario (GAK) an:

die KRA meint, dass die Politik Key Recovery Gesetze verfassen muss, in denen festgelegt wird:

  • unter welchen Umständen staatliche Behörden gesetzmässig auf die Rekonstruktion verschlüsselter Daten zugreifen dürfen
  • dass ein Key Recoveryzugriff nur unter gerichtlicher Aufsicht und nach gerichtlicher Anweisung erfolgen darf und der Zugriff streng an die gerichtlichen Vorgaben gebunden ist
  • wie die Kontrolle und Dokumentation über Aufbewahrung und/oder Vernichtung rekonstruierter Daten geregelt ist
  • dass der Dateninhalt nach seiner Rekonstruktion nicht durch staatliche Einwirkung verändert wird

Nach dem Verkauf von PGP.INC an NAI nimmt Phil Zimmermann bei NAI die Funktion eines Beraters/Mitarbeiters ein, während Phil Dunkelberger, ehemaliger Präsident/CEO von PGP.INC, bei NAI General Manager der Total Network Security Abteilung (zu der PGP gehört) wird.
Während Phil Zimmermann zu Key Recovery einmal gesagt hat, dass Key Recovery Funktionen die Hand eines Polizeistaates stärken würde und eine Invasion der Privatsphäre darstelle, erwähnte er später zur CMRK Funktion in PGP 5/6, dass, solange er etwas dazu zu sagen habe, diese Funktion für die Benutzer optional sei und der Absatzmarkt für PGP solche Funktionen verlange.

Am 6. Dezember 1997, ca. eine Woche nach dem Verkauf, verkündet NAI den Ausstieg aus der KRA mit der Begründung, die Position von NAI und PGP sei es, Regierung und Industrie dazu zu ermutigen, zu einer Politik überzugehen, die den Export starker Kryptografie ohne erzwungene Key Recovery erlaube.
Zur KRA lässt der Direktor des NAI Produktmanagements, Gene Hodges, verlauten, dass das technische Interesse an Key Recovery verständlich, bei NAI aber die Hoffnung bestünde, dass zwingende Key Recovery nicht das Ziel der Regierungspolitik sei.
Es ist anzunehmen, dass dieser Schritt von NAI auf Druck von Phil Zimmermann und vieler Stimmen aus der Kryptoszene unternommen wurde um die Reputation von PGP zu schützen, zumal Zimmermann und die ehemalige PGP.INC Crew von der Mitgliedschaft NAI´s in der KRA wohl erst aus einer Meldung der WIRED NEWS erfahren hatte.

Am 25. Februar 1998 kauft NAI für 300 Millionen US-Dollar die Firma Trusted Information Systems (TIS), die enge Verbindungen zur NSA und zum US-Verteidigungsminsisterium hat, aktives Gründungsmitglied der KRA ist und als Urheber des Key Escrow Konzeptes gilt.
TIS stellt Firewallprogramme mit Key Recovery Features (Gauntlet) und ein eigenes Key Recovery System namens "RecoverKey" (das nach Aussage von Phil Zimmermann aber in keines der PGP Programme integriert wird) her.
Ihr CEO, Stephen Walker, war jahrelang bei der NSA, der Defense Advanced Research Projects Agency (DARPA) und dem Office of the Secretary of Defense angestellt.
Neben Walker rekrutieren sich viele der bei TIS Beschäftigten aus ehemaligen Angestellten und Kryptologen der NSA.

Am 12. November 1998 tritt NAI der KRA wieder bei.
Es ist anzunehmen, dass dieser Schritt in engem Zusammenhang mit der Aquisition von TIS steht.
In einer E-Mail vom 13.11.1998 an die amerikanische PGP-User Mailingliste (Message-ID: (19981113233032.21663.00000701@ng105.aol.com in alt.security.pgp) bemerkt Will Price, Architect/Senior Manager für PGP Client Produkte der Total Network Security Abteilung, dass die Aufführung von NAI auf der KRA Mitgliederpage einzig das Resultat des Aufkaufs von TIS sei.
NAI habe nach der TIS Aquisition ein Paket von Produkten mit eingebauten Key Escrow Funktionen erworben, deren Entfernung oder Modifizierung im Kontext von Überlegungen zu Export und Key Escrow, so dass sie weniger Big Brother haft arbeiten, viel Zeit in Anspruch nehmen wird.
Alle Punkte hätten keine Auswirkungen auf die PGP Gruppe und NAI würde weite wie bisher damit fortfahren, den vollen Sourcecode zu publizieren.

Die Mitgliedschaft von NAI in der KRA wurde zum Zeitpunkt ihrer Verlängerung aufgrund einer Aufforderung von Phil Zimmermann an NAI nicht erneuert.

Zum Thema "Back-Doors" in PGP 5/6 veröffentliche ich an dieser Stelle noch eine E-Mail Benachrichtigung von Phil Zimmermann vom 03.06.1999:

 
 
-----BEGIN PGP SIGNED MESSAGE----- 
Hash: SHA1 
 
I'd like to address the rumors concerning the cryptographic integrity of 
PGP, including recent versions made by Network Associates, as well as 
recent freeware versions built and released by Stale Schumacher on his 
website in Norway at http://www.pgpi.org.  These rumors allege that these 
versions of PGP contain back doors for the US Government to access the 
plaintext messages or keys.  I do not know how such sensationalist 
conspiracy theories get started, but they seem to come from people who 
believe that The X-Files is a documentary. 
 
Let me assure everyone that all versions of PGP that are released from 
Network Associates have the same cryptographic integrity as all previous 
versions of PGP that were released since the old days before I started 
my company, PGP Inc.  In fact, no version of PGP in which I have been 
personally involved has ever had any back doors or any other mechanism 
to intentionally weaken PGP.  That includes versions released by MIT, 
PGP Inc, Network Associates, or Stale Schumacher. 
 
After all the hardship and legal persecution that I endured to bring PGP 
to the world, I find it surprising and offensive that anyone would think 
that I would quietly stand by and tolerate any compromise in the 
cryptographic interity of PGP. 
 
When Network Associates acquired my company in December 1997, they also 
acquired the same engineering team that we had put together at PGP Inc, 
a team dedicated to the same principles of personal privacy that led me 
to create PGP.  This team is still working on PGP today, and will continue 
to help me protect the integrity of PGP.  Network Associates has not 
shown the slightest interest in compromising the integrity of PGP.  They 
recognise that it would not be in their business interests to do so. 
 
We have always published the source code for every version of PGP for 
peer review purposes, and Network Associates has carried on that tradition. 
Anyone may download the source code for PGP from www.pgpi.org and examine 
it for any back doors.  Stale Schumacher, an independent PGP activist 
who is not an employee of Network Associates, has done all the builds 
since PGP 5.0i for the freeware versions of PGP in Europe.  I have known 
Stale for several years and I know that he is committed to the same 
political principles of privacy as I am.  I feel confident that Stale 
would never compromise the integrity of PGP in the versions that he 
builds for distribution on his site.  Nonetheless, anyone who worries 
if the binary executables for PGP are trustworthy may compile the code 
themselves and rebuild the binaries for their own personal use, as long 
as they do not redistribute such rebuilt binaries for others to use. 
 
 -- Philip Zimmermann 
    http://www.pgp.com/phil 
    3 June 1999 
 
-----BEGIN PGP SIGNATURE----- 
Version: PGP 6.5.1b40 
 
iQA/AwUBN1bDM2PLaR3669X8EQLXSACg4Z5+//BgNg4OjeKDugnQ0wmWbXEAoPsl 
v4z0is5aXeLPf0cOJSqnyX9Q 
=QOqg 
-----END PGP SIGNATURE----- 
 

Zu PGP und die Sicherheit von PGP schreibt er am 19.02.2001 an die PGP Gemeinde:

(...)
Let me assure all PGP users that all versions of PGP produced by NAI, and
PGP Security, a division of NAI, up to and including the current (January
2001) release, PGP 7.0.3, are free of back doors. In all previous releases,
up through PGP 6.5.8, this has been proven by the release of complete source
code for public peer review. New senior management assumed control of PGP
Security in the final months of 2000, and decided to reduce how much PGP
source code they would publish. If NAI ever publishes the complete PGP 7.0.3
source code, I am confident that the public will be able to see that there
are still no back doors. Until that time, I can offer only my own assurances
that this version of PGP was developed on my watch, and has no back doors.
In fact, I believe it to be the most secure version of PGP produced to date.
(...)

Das heißt, PGP 7.0.3 ist die letzte Version, für die P. Zimmermann persönlich mit seinem Wort einsteht.

Links: