GAK, CMR, ARR, MRK, ADK und PGP 5/6
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 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.
NAI hat CMR als Aternative zum "Key Recovery"-Konzept, d. h. der Rückgewinnung des eigenen Entschlüsselungskeys durch Dritte und dem Konzept des "Key Escrow", dem Hinterlegen des Entschlüsselungskeys bei einer zentralen Stelle, entworfen.
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 5/6, 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öße
- 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 diesem ein CAF (Corporate Access Field), bzw. ARR (Additional Recipient Record) Bereich hinzugefügt.
Er enthält die Information, daß 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 "muß", bzw. bei jeder Verschlüsselung der Firmen Public Key (CMRK/ADK) verwendet wurde.
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 außerhalb 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 außerhalb 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, daß der Benutzer mit einem Drittkey verschlüsseln muß, 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, daß 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, daß 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, daß 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, daß 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 muß ein DH/DSS Key sein.
Verstößt ein Benutzer gegen Policies oder verliert das Vertrauen der Firma, kann also eine dritte Person den Public Key des Benutzers widerrufen, so daß der Benutzer nicht mehr in der Lage ist, mit diesem Key verschlüsselte Nachrichten zu lesen.
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, daß die neuen DH/DSS-Keys nicht bloß 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.
PGP 5/6 Versionen
Vorteile von PGP for Business Security 5/6
Trotzdem sollte man, wenn man sich zum Einsatz der PGP 5/6 Version entschließt, die Version PGP for Business Security 5/6 installieren, da diese Version folgende Möglichkeiten bietet:
- Anzeige in PGPkeys, daß ein Public Key ein CMR-Field besitzt
- Möglichkeit, eine Warnmeldung einzustellen, für den Fall, daß man an einen Public Key mit CMR-Field verschlüsselt (in derzeitigen Versionen deaktiviert)
- Möglichkeit, eine Datei konventionell zu verschlüsseln
- Möglichkeit, die Verschlüsselungsalgorithmen IDEA, CAST, Triple-DES ein- oder auszuschalten und einen Algorithmus als bevorzugten Algorithmus zu definieren
- Einblick in die CMR/GAK-Funktionsweise von PGP 5/6
- Eingebautes File Wiping Tool zum Löschen und Überschreiben von Dateien (wobei die Dateinamen erhalten bleiben und mit Diskeditoren wieder sichtbar gemacht werden können)
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").
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.
Es soll trotzdem an dieser Stelle deutlich darauf hingewiesen werden, daß ein zu Hause vom Privatuser mittels einer PGP 5/6 Version (die aus sicherer Quelle stammt), erzeugter Key, genauso sicher ist, wie ein Key, der mit PGP 2.6.3 erzeugt wurde. Die ungewollte Drittkeyverschlüsselung über den eigenen Key ist ausgeschlossen.
Bekommt man aber von einem Mailpartner einen DH-Key, der mit zwingender Drittkeyverschlüsselung ausgestattet ist, wird der Mailpartner die Nachricht auch nur erhalten können, wenn auch an den Drittkey verschlüsselt wurde.
Ich hoffe, die PGP-Version des OpenPGP-Projektes wird dem ein Ende bereiten und diese Anleitung überflüssig machen.
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 Mitglied in der Key Recovery Alliance.
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, daß die Politik Key Recovery Gesetze verfassen muß, in denen festgelegt wird:
- unter welchen Umständen staatliche Behörden gesetzmäßig auf die Rekonstruktion verschlüsselter Daten zugreifen dürfen
- daß 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
- daß 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, daß 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, daß, 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 MAI 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äßt der Direktor des NAI Produktmanagements, Gene Hodges, verlauten, daß das technische Interesse an Key Recovery verständlich, bei NAI aber die Hoffnung bestünde, daß zwingende Key Recovery nicht das Ziel der Regierungspolitik sei.
Es ist anzunehmen, daß 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, daß 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, daß 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 daß 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.
Links:
|