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".
[...]
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:
- 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. - 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. - 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:
- 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. - 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.
- 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.
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 Ader 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:
|
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: