Überblick oder "Was ist PGP ?"
Diese Anleitung geht vom Einsatz der CKT PGP 6.5.8 Version aus.
Informationen zu CKT [Cyber Knight Templar] PGP
- die CKT Versionen werden von Imad R. Faiad, basierend auf dem veröffentlichten Sourcecode der regulären PGP 6.5.8 Version, gepflegt und mit dem Sourcecode veröffentlicht
- neben den bekannten symmetrischen Algorithmen IDEA, CAST, Triple-DES sind ausserdem die OpenPGP Algorithmen Blowfish, Twofish und AES-128 bis AES-256 implementiert
- neben den bekannten Hashalgorithmen MD5 und SHA-1 ist ausserdem RIPE-MD-160 implementiert
- unterstützt die Herstellung von DH/DSS, ElGamal, RSA v.3 und RSA v.4 Keys
- erweiterte Anzeigeoptionen in PGPkeys und den Verschlüsselungs-/Entschlüsselungswindows
- Anzeige der Key-ID und des Fingerprints im Kommentar
- Bestimmung des Subkey Algorithmus bei v.4 Keys
- die Lizenz von NAI PGP erlaubt die eigene Kompilierung des Quellcodes,
untersagt aber jede Modifizierung des Quellcodes, wie es bei PGP CKT der Fall ist.
Deshalb sollte man vom Einsatz von PGP CKT im kommerziellen Umfeld absehen und stattdessen eine reguläre NAI PGP 6.5.8 Version einsetzen.
Die Geschichte von PGP
PGP 5.0 als grafisches Benutzerprogramm war die neueste PGP-Entwicklung
seit Erscheinen der PGP Version 2.6.3 und wurde im Juni 1997 veröffentlicht.
PGP 5.0 basierte auf der PGP Version 3.0, die aber nie veröffentlicht
wurde.
Die Version 2.6.3, die kommandozeilenorientiert arbeitet und über
die Eingabeaufforderung oder über grafische Shells (Benutzeroberflächen)
bedient wird, erfreut sich weiterhin (teilweise aus guten Gründen)
grosser Beliebtheit.
Es gibt einige Unterschiede zwischen beiden Versionen, die auch
in dieser Anleitung behandelt werden und Einschränkungen im Funktionsumfang,
der bei der Version 6 nicht so gross ist wie bei der Version 2.6.3.
Wer sich näher mit der Version 2.6.3 beschäftigen möchte, kann sich
die informative Comp.Security.PGP.FAQ,
mit der deutschen Übersetzung von Michael Uplawski der comp.security.pgp
FAQ von A. "Galactus" Engelfriet herunterladen.
![]() Phil Zimmermann 1996, nachdem das Verfahren gegen ihn endgültig eingestellt wurde. |
PGP ist die Abkürzung für "Pretty Good Privacy",
was sich etwas holprig mit "Ganz guter Geheimhaltung"
übersetzen lässt. PGP wurde von dem amerikanischen Programmierer Phil Zimmermann geschrieben und im Jahr 1991 als Freeware veröffentlicht. Weil es kurz darauf von unbekannten Personen aus den USA nach Europa gelangte, wurde gegen Zimmermann drei Jahre lang wegen Verstosses gegen die amerikanischen Exportkontrollgesetze ermittelt, denn PGP wurde wegen seiner starken Verschlüsselung in den USA als "Waffe" eingestuft, die nicht in andere Staaten exportiert werden durfte. |
Laut der Pressemitteilung vom 13.12.1999 besitzt Network Associates ab sofort eine Exportlizenz der amerikanischen Regierung zur weltweiten Ausfuhr von PGP.
Dazu Noah Salzmann von NAI am 14.12.1999:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I suppose I shouldn't get into a "ADK features are not Key Escrow" debate
as I am sure everyone's opinions are already set in stone...
However, I would like to address the perception (below) that the ADK
feature has been "locked-open" as this is indeed not the case.
PGP business products, as sold in the US or anywhere else, do not have
the ADK feature turned on by default. The purchasing company must turn
this on themselves.
PGP products sold in the retail channel, like Personal Privacy, _never_
force the user to respect an ADK. The retail (and freeware) users can
always encrypt to the primary key while avoiding the ADK that is
associated with that primary key. If a company wants to prevent
retail/freeware users from sending their employees ADK-less mail then
they must put up scanning tools on their mail server to enforce their
policy.
NAI/PGPinc has never entered into an agreement with the U.S. Government
in which we have traded features in PGP software for an export license,
nor would we ever do so.
We have never built a weakened version of PGP. In fact, we don't even
include 56-bit DES in our IPsec software, even though must of our
competitors do. :-P
Noah Salzman
noah@nai.com
408.346.5186
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQA/AwUBOFayHSQ6gdj6pyJyEQK2MACgiACc/uhd6Qfjq3aNaIeIikdA8UgAn1CQ
xxMT8fRvpUoQu4YQXVOqWFME
=m+WS
-----END PGP SIGNATURE-----
Zur angesprochenen ADK Funktion siehe GAK, CMR, ARR, MRK, ADK und PGP 5/6.
1996 gründete Zimmermann seine Firma PGP Included, nachdem die
Ermittlungen gegen ihn eingestellt wurden, im Dezember 1997 wurde
PGP Inc. von der Firma Network Associates gekauft - zu diesem Zeitpunkt
stand PGP bei Version 5.5.3 -, die bis zur Version 7.0.3 mit Zimmermann
zusammen weiterentwickelt und vertrieben wurde.
Auch die meisten Entwickler aus dem Team von Zimmermann wechselten
mit, der Kern der Entwickler hat sich von 5.0 bis 7.0 nicht geändert.
Die erste Version von PGP nach dem Verkauf an NAI war PGP 5.5.5
- der Version 5.5.3 war nur ein neuer Infotext (About Button) hinzugefügt
worden.
Die erste, neu überarbeitete und um PGPdisk und eine spezielle Businessvariante
erweiterte Version unter NAI war die PGP 6.0 Reihe aus dem Jahr
1998. Mit dem PGPadmin Tool der Businessvariante Desktop Security
war es auch zum ersten Mal möglich, eigenständige PGP Client-Installer-Versionen
für Anwender zu erstellen, die über eine vorgegebene Konfiguration
eine Erzeugung von Public Keys mit ADK-Keys erzwingen konnte.
Die OpenPGP Allianz
Anfang 2001 verlässt Phil Zimmermann NAI, um Beratertätigkeiten
bei anderen Firmen, darunter HushMail, aufzunehmen und die Entwicklung weiterer
OpenPGP Implementationen voranzutreiben.
Ein weiterer Beweggrund wird in der veränderten Geschäftspolitik
von NAI vermutet, die auch einschließt, den Quellcode von PGP nach Version
6.5.8 nicht mehr vollständig zu veröffentlichen.
Phil Zimmermann übernimmt eine persönliche Garantie
für die Integrität von NAI PGP nur noch bis PGP 7.0.3
Dem Zweck der Förderung von OpenPGP dient auch die gegründete OpenPGP
Allianz.
Daneben dient die OpenPGP Allianz der technischen Abstimmung zwischen einzelnen
Entwicklern, bzw. Firmen, die, gestützt auf den OpenPGP Standard RFC
2440, eigene Implementationen herstellen, um Kompatibilität zwischen
den einzelnen Umsetzungen zu gewährleisten, der gemeinsamen Vermarktung
OpenPGP kompatibler Produkte, der Promotion der PGP PKI und des Erfahrungsaustausches
und der Beratung zwischen den Mitgliedern.
Die Mitgliedschaft ist für Unternehmen, Organisationen und Personen offen,
die an der Produktentwicklung oder Erbringung von Diensten, welche auf dem
OpenPGP Standard basieren, beteiligt sind.
Zu den Mitgliedern zählen u. a. Biodata, GnuPG, Network Associates, Hush
Communications, Qualcomm, Zero-Knowledge.
Das Ende von NAI PGP
Ende 2001 mehrten sich die Gerüchte, NAI wolle PGP einstellen. NAI selbst
lässt verlautbaren, einige PGP Komponenten in andere NAI Produktlinien
zu integrieren und den Rest verkaufen zu wollen.
Im Februar 2002 verschwinden die PGP Seiten und Links von der NAI Website
und Network Associates teilt seinen PGP Kunden mit, dass die weitere Entwicklung
des PGP Desktop Produktes eingestellt wurde und es keine Bugfixes und Updates
mehr gibt. Die Crew des ursprünglichen PGP Teams wird aufgelöst
und in andere NAI Abteilungen versetzt. Dies alles, nachdem NAI keinen Käufer
für seine PGP Produktlinie gefunden hatte.
Die technischen Komponenten
PGP ist ein Programm, mit dem man lokal auf der eigenen Festplatte
alle Dateiarten verschlüsseln kann.
Besondere Bedeutung hat PGP aber dadurch erlangt, dass eine Vielzahl
von Internetanwendern weltweit PGP zur Verschlüsselung von E-Mails
und anderer Daten, die über Netzwerke versendet werden, benutzen.
Darüber hinaus kann man mit PGP Texte in Klarform (Faxe, E-Mails)
mit einer digitalen Signatur versehen, um auch im elektronischen
Bereich, in dem eine handschriftliche Unterschrift nicht möglich
ist, eine Überprüfung der Authentizität elektronisch vorliegender
Texte und Daten zu ermöglichen.
Sowohl zur Verschlüsselung als auch zur Signierung setzt PGP dabei
mathematische Verschlüsselungsmethoden, sogenannte kryptografische
Algorithmen, wie IDEA, RSA, Diffie-Hellmann, MD5 und SHA-1, ein,
die in der Welt der Kryptografie als anerkannt sicher vor Entschlüsselung,
bzw. Errechnen der originalen Daten (z. B. des Klartextes einer
E-Mail) aus der verschlüsselten Form durch nicht autorisierte dritte
Parteien eingestuft werden.
Ein kurzer Blick auf die Struktur und Funktionsweise des Internets
reicht aus, um sich die Notwendigkeit der Verschlüsselung und Signierung
vor Augen zu führen.
Wenn eine E-Mail versendet wird, werden die Datenpakete der E-Mail
zum Mailserver des Providers übertragen, von dort versendet der
Mailserver die Mail an den Ziel-Mailserver des Empfängers. Dabei
wird die E-Mail meistens mehrere Rechner im Internet passieren,
bis sie am Zielserver ankommt. Der Mailserver des Empfängers überträgt
schliesslich die E-Mail auf den Rechner des Empfängers. Während
des ganzen Transportweges werden die Datenpakete stets in lesbarem
Klartext übertragen. D. h. an verschiedenen Stationen des Weges
kann die E-Mail abgefangen und auch verändert werden: Auf dem Weg
vom eigenen Rechner zum Mailserver, zwischen den einzelnen Rechnern
während des Transportes und vom Ziel-Mailserver zum Empfänger. Verschafft
sich eine Person einen illegalen Zugang zu einem der beteiligten
Rechner, kann auch dort direkt die E-Mail abgefangen werden. Zu
diesem Zweck gibt es spezielle Programme wie die Paket-Sniffer,
mit denen Datenpakete abgefangen werden können. Die abgefangenen
Pakete können auch in ihrem Inhalt verändert und wieder in den Datenstrom
eingespeist werden.
Zur Verschlüsselung und Signierung bedient sich PGP des asymmetrischen Verschlüsselungsverfahrens und der Idee des "Web of Trust".
Asymmetrisches Schlüsselverfahren
In diesem Kapitel werden die einzelnen Bestandteile der asymmetrischen
Verschlüsselung beschrieben und in Schaubildern der Verschlüsselungs-
und Signiervorgang dargestellt.
Eine interaktive Flashdarstellung findet sich auf der Seite "Visualisierung
zur digitalen Signatur" des Instituts für Telematik
der Fraunhofer Gesellschaft
(Anmerkung: Diese Darstellung bezieht sich auf S/MIME und Signaturen
nach dem SigG, wo die Schlüssel in einem Trustcenter erstellt
werden, die Verschlüsselungsprinzipien sind aber vergleichbar).
Bei PGP 6 wird, wie schon zuvor mit der Version 2.6.3 ia oder 2.6.3 in, das asymmetrische Schlüsselverfahren eingesetzt. Das heisst, jeder PGP-Benutzer hat zwei zusammengehörende Schlüssel (ein Schlüsselpaar), bestehend aus:
Private Key ("privater Schlüssel")
der Aufbewahrungsort für den eigenen (wenn man nur einen PGP-Key
benutzt) oder die eigenen (wenn man mehrere PGP-Keys verwendet)
privaten Schlüssel ist der private Schlüsselbund (die Datei "secring.skr")
PGP bildet einen Hashwert aus der gewählten Passphrase, den "Secret
Key". Mit dem Secret Key wird der Private Key von PGP verschlüsselt
und dann im Secring gespeichert. Somit wird der Private Key direkt
durch den Secret Key und indirekt durch die dem Secret Key zugrunde
liegende Passphrase geschützt.
Detaillierte Informationen zur Passphrase, auch "Mantra"
genannt, finden sich in der Mantra FAQ
Mit dem Private Key werden verschlüsselte Nachrichten entschlüsselt
und die digitalen Unterschriften ("Signaturen") erzeugt.
Deshalb wird PGP jedesmal, wenn man entschlüsselt oder signiert,
die Passphrase abfragen, da ja in beiden Fällen der Private Key,
bzw. Secret Key zum Einsatz kommt.
Public Key ("öffentlichen Schlüssel")
der Aufbewahrungsort für alle öffentlichen Schlüssel, also auch
dem eigenen Public Key ist der öffentliche Schlüsselbund (die Datei
"pubring.pkr")
Mit dem Public Key wird eine Nachricht verschlüsselt oder die Signatur
eines Absenders überprüft. Verschlüsselung und Signierung können
dabei miteinander kombiniert werden.
Dabei kann man aus dem Public Key den Private Key nicht berechnen
und ohne den Private Key zu besitzen, kann man keine Nachricht entschlüsseln,
die mit dem dazugehörigen Public Key verschlüsselt wurde. Auch wenn
mit dem Private Key eine Signatur erstellt wurde, kann man aus dieser
Signatur nicht den Private Key errechnen.
Darüber hinaus kann eine Nachricht nicht entschlüsselt, bzw.
Signaturen erstellt werden, wenn der Private Key entwendet wurde,
wenn der Angreifer die Passphrase und damit den Secret Key nicht
kennt, bzw. über Wörterbuchangriffe (Dictionary Attack) errechnen
kann.
PGP und die Sicherung des Umfeldes
Der Klima-Rosa-Angriff, März 2001
Dies galt bis zur Veröffentlichung des Klima-Rosa Angriffsszenarios
Mitte März 2001.
Die beiden tschechischen Kryptologen Vlastimil Klima und Tomas Rosa
der zur ICZ Gruppe gehörenden Firma Decros hatten während
einer Forschungsarbeit im Auftrag des tschechischen Geheimdienstes
verschiedene Wege entdeckt, um den private key OpenPGP-kompatibler
PGP-Programme (PGP, GnuPG) zu errechnen ohne Notwendigkeit, die
Passphrase zu erraten oder den Algorithmus anzugreifen, mit denen
der private key verschlüsselt wird.
Der Angriff wird durch fehlerhafte, bzw. fehlende Schutz- und Authentifizierungsmassnahmen
im Schlüsselformat von (Open)PGP-Keys ermöglicht.
Im Klima-Rosa Szenario muss ein Angreifer physischen Zugriff auf
den private key einer Zielperson in Form des privaten Schlüsselbundes,
sprich sekring.skr bei PGP oder secring.gpg bei GnuPG, bzw. des
exportierten private keys in Form einer Datei nehmen.
Der Angreifer führt einige wenige Modifikationen in den öffentlichen
und geheimen Bestandteilen des Datenpakets aus, das den private
key enthält und schiebt diese modifizierte Version der Zielperson
unter.
Wenn die Zielperson das nächste Mal Signaturen mit dem modifizierten
private key erstellt und der Angreifer im Besitz einer derart signierten
Nachricht ist, kann der Angreifer mit einem Programm aus der Signatur
den private key der Zielperson berechnen und anschliessend damit
selbst authentische Signaturen im Namen der Zielperson erstellen.
Abschliessend speichert er die ursprüngliche Version des private
keys am Ursprungsort zurück, um seinen Einsatz zu vertuschen.
Dazu NAI/PGP:
Am 20. März gaben zwei tschechische Kryptologen in einer Presseerklärung bekannt, daß sie eine Schwachstelle im openPGP-Standard gefunden hätten, der in PGP-Produkten und anderen Verschlüsselungsprodukten verwendet wird. Wir räumen ein, daß diese Schwachstelle zwar theoretisch besteht; unseren Anwendern sichern wir aber zu, daß zur Ausnutzung der Schwachstelle physischer Zugriff auf den Rechner und die Modifizierung von Dateien erforderlich ist. Grundlegende Voraussetzung für Sicherheit und Schutz der Privatsphäre ist die Kontrolle über den Rechner. Ist diese Mindestvoraussetzung erfüllt, werden Risiken auf ein Minimum reduziert. Selbst wenn die Schwachstelle ausgenutzt würde, so wäre davon nur die Signatur betroffen. Zugriffe auf verschlüsselte Daten sind auf keinen Fall möglich. Nach Meinung von Sicherheitsexperten ist das aus der Schwachstellen erwachsende Risiko als gering zu veranschlagen. Um aber auch dieses Risiko auszuschließen, wird PGP entsprechende Maßnahmen ergreifen, um die Schwachstelle in der ab Mitte des Jahres erhältlichen Version zu beseitigen.
Sandra L. Brooks
Direktor für Produktmarketing
Zusatz:
Es bleibt festzuhalten, dass der Klima-Rosa Angriff ein Angriff mit hohem
Gefahrenpotential darstellt, aber den physischen Zugriff auf den private key
voraussetzt.
Wie an diesem Ort schon früher ausgeführt, zählte zu einem
verantwortungsvollen Einsatz von PGP schon immer der besondere Schutz des
private keys.
Ausserdem stellt sich die Frage, ob ein Angreifer, dem möglich ist, auf
den private key zuzugreifen, nicht sowieso weitergehende Überwachungs-
und Spionagemethoden wie Key-Logger, Abhörwanzen, TEMPEST-Attacken u.
ä. gegen die Zielperson fahren würde.
Siehe dazu als Beispiel KEY-LOGGER - die Wanzen im Rechner
Für PGP 2.6.3 IN und GnuPG sind gegen den Klima-Rosa Angriff
gepatchte Versionen verfügbar.
Links:
- Cryptologists
from Czech company ICZ detected serious security
vulnerability of an international magnitude - RUS-CERT: Schwachstellen in der Handhabung des geheimen Schlüssels
- Klima/Rosa:
Attack on Private Signature Keys of the OpenPGP format, PGP programs
and other applications compatible with OpenPGP
- dass der Public Key ohne Bedenken weitergeben werden kann,
der Private Key niemals - dass eine starke Passphrase gewählt wird
- das die Passphrase niemals weitergegeben und/oder für andere Personen zugänglich aufbewahrt wird
- dass die Passphrase nie in Vergessenheit gerät
Mehr noch:
Der Private Key sollte möglichst sicher abgelegt
sein.
Zum Beispiel kann man den Secring auf einer Diskette abspeichern
und diese nur einlegen, wenn man PGP benutzen will. Dazu muss in
PGP noch der Pfadhinweis zum Secring abgeändert werden.
Fallweise ist eine zusätzliche Sicherung des Secrings durch Verschlüsselung
der Datei Secring.skr oder der gesamten Diskette durch ein anderes
Verschlüsselungstool überlegenswert.
Geeignete und sichere Verschlüsselungstools auf DOS und Windowsebene
finden sich auf der
No Big Brother
Page - Kryptografische Programme.
Denn wenn jemand den Secret Key und die ihn schützende Passphrase
des Keybesitzers kennen würde, könnte er alle an den Keybesitzer
verschlüsselte E-Mails entschlüsseln !
Doch dazu später.
Siehe auch Die
Sicherheit des geheimen Schlüssels von Ralf Senderek.
USB-Sticks als Speichermedium
Eine weitere, sehr interessante Lösung stellen USB-Plugins
dar, weil USB mittlerweile zu den Standardschnittstellen der Motherboards
zählen, die Handhabung sehr einfach ist, die Speicherung und
Bearbeitung von Keymaterial schneller als auf Diskette von statten
geht, das Medium stabiler als eine Diskette und besser zu transportieren
ist.
Die Speichergrößen erlauben es auch, GnuPG und PGP (Anwendungen)
mitzuspeichern.
Deshalb möchte ich exemplarisch drei Produkte vorstellen, die mir im Web aufgefallen sind:
Pen Drive
- erhältliche Kapazitäten von 4 MB, 128MB und 256MB (Stand Okt. 20001)
- außer bei Windows 98 keine zusätzlichen Treiber
Linux - unterstützt flash ROM (EEPROM) für ISP (In-System Programming) zum Update der Firmware über den USB Port
- unterstützt Toshiba & Samsung NAND Flash Memory 32Mbit, 64Mbit, 128Mbit, 256Mbit, 512Mbit and 1Gbit.
- unterstützt USB-Spezifikation 1.1
- USB-Transferrate: bis zu 12Mbits/sec.
- unterstützt Stromsparmodi
- Schreibschutz
Links:
- Pen Drive Homepage
- Windhorst Deutscher Distributor
Voyager
- erhältliche Kapazitäten: 16 MB, 32 MB, 64 MB
- Passwortschutz
- Schreibschutz
- Material: ASB
- USB-Transferrate: bis zu 12Mbits/sec.
- unterstützt USB-Spezifikation 1.1
Links:
Flash USB-Drive
- erhältliche Kapazitäten: 16MB, 32MB, 64MB, 128MB, 256MB
- unterstützt USB-Spezifikation 1.1
- Schreibschutz
- EMI Compliance FCC, CE, EMI, EMS
- Stromversorgung via USB-Bus (4.5V - 5.5V)
Links:
imafox Flash USB-Drive Homepage
Getestet habe ich den Voyager und den Pen Drive Stick.
Beide Sticks funktionierten bei mir unter W2K nach Installation
der Treiber einwandfrei.
Beim Voyager wurde noch ein Passwort vergeben.
Wie versprochen, bringt beim Pen Drive W2K die Treiber bereits mit,
so dass nur die W2K Installations-CD nötig war (nett war auch
das beiliegende USB-Adapterkabel, das in den USB-Port meiner Tastatur
eingesteckt, ein bequemes Andocken des USB-Sticks ermöglicht).
Das Pen Drive (in der Größe 32 MB) konnte ich sowohl
mit FAT, als auch mit NTFS formatieren.
Nach Kopieren der Keyringe für GnuPG und CKT PGP auf die Sticks
und Anpassen der Pfade in der Konfiguration von GnuPG und PGP habe
ich nun ein sichere und mobiles Speichermedium für meine GnuPG/PGP-Daten.
Nebenbei habe ich GnuPG und meine Password Safe Passwortdatenbank
ebenfalls noch untergebracht.
PGP und sicheres Umfeld
Es ist sinnvoll, sich darüber hinaus weitergehende
Überlegungen zur Sicherheit des Systems, auf dem PGP arbeitet,
zu machen, d. h. für eine möglichst sichere Umgebung zu sorgen.
Das trifft gerade für Windowssysteme zu. Denn es hilft nichts,
PGP zu verwenden, aber z. B. die Möglichkeit zuzulassen, dass
ein Hacker über das Internet in den eigenen PC einbricht,
ein Remote Control Sever über ein "Trojanisches Pferd"
Virus installiert oder die Passphraseeingabe durch anwesende
Personen in der Umgebung vom Monitor abgelesen werden kann.
Neben der Verwendung eines starken Keys mit einem sicheren
Algorithmus und einer starken Passphrase sollte man deshalb
für einen starken Virenschutz sorgen, also z. B. alle Programme
vor Installation mit einem Virenscanner überprüfen, den eigenen
Rechner gegenüber dem Internet mit einem Firewall- und/oder
Intrusion Detection Programm absichern und sensible Daten
wie den Private Key und die Passphrase sicher "verwahren".
Sieht man einmal von einem TEMPEST-Angriff oder einem installierten
Key-Logger
System ab, gegen den ein normaler Anwender eh keine Chance
hat, kann man so wenigstens die wichtigsten Angriffspunkte,
die ein durchschnittlicher Angreifer wählen würde, neutralisieren.
Der Scarfo-Fall
Der bekannteste Fall des Jahres 1999, wo zum
ersten Mal ein Software-Keylogger (als Bestandteil eines umfassenderen
Keyloggersystems) eingesetzt wurde, war die Untersuchung des
FBI gegen Nicodemo Scarfo, einem Angehörigen der Gambiano
Mafiafamilie.
Das FBI war in das Büro von Scarfo eingebrochen und hatte
die Festplatte seines Computers kopiert. Wichtige Daten hatte
Scarfo aber mit PGP verschlüsselt.
Deshalb suchte das FBI, nur mit einem Durchsuchungsbefehl
ausgestattet, das Büro nochmals auf und installierte
im Computer das, was der Deputy Assistant Director der Investigative
Technology Branch der FBI Laboratory Division, Randall S.
Murch, in einer Gerichtsanhörung
als "Key Logger System (KLS)" bezeichnete. Murch
beschreibt das KLS so:
FBI engineers configured a hardware/software and/or firmware solution based upon previously developed techniques which would permit the FBI to obtain the defendant's key (den PGP Private Key) and key-related information (die Passphrase). These techniques, and their various components, have become to be known collectively within the FBI as the Key Logger System (KLS).
(...)
The KLS, depending upon the hardware and software configuration of a targeted computer and the use of that computer, can, and typically will, have multiple components.
(...)
A component of the KLS deployed in this case was a "keystroke capture" component that was designed to record, under certain conditions described below, each keystroke typed on the keyboard.
(...)
In conclusion, the KLS, by design, prohibited the capture of keyboard keystrokes whenever the computer modem was on; other component(s), described above, limited their capture to only the passphrase and key-related information.
Für Windows Systeme siehe auch die Win-Security Page und die No Big Brother Page No. 2.
Grafische Darstellung des Ver- und Entschlüsselungsvorgangs
beim asymmetrischen Verfahren mit PGP:
Verschlüsselung durch den Absender:

Entschlüsselung durch den Empfänger:

Wie aus den Abbildungen hervorgeht, kommt beim asymmetrischen Verschlüsselungsverfahren
auf Seiten des Absenders der öffentliche RSA oder DH Schlüssel (Public
Key) des Empfängers, der weltweit jeder Person, die PGP einsetzt,
zur Verfügung steht und ein konventioneller Verschlüsselungsalgorithmus
wie IDEA, CAST oder Triple-DES zum Einsatz, aber kein Passwort oder
eine Passphrase.
Auf Seiten des Empfängers kommt der private Schlüssel (Private Key)
des Empfängers, der nur ihm vorliegt und sonst keiner anderen Person,
seine Passphrase und einer der konventionellen Verschlüsselungsalgorithmen
zum Einsatz.
Grafische Darstellung des Ver- und Entschlüsselungsvorgangs
beim symmetrischen Verfahren

Wie aus der Abbildung hervorgeht, wird beim symmetrischen Verschlüsselungsverfahren
der Absender den Klartext, z. B. eine E-Mail, mit einem IDEA, CAST
oder Triple-DES Schlüssel verschlüsseln, wobei der Schlüssel durch
eine Passphrase, die sich der Absender ausdenkt, verschlüsselt,
bzw. geschützt wird. Der Empfänger wiederum muss die gleiche Passphrase
angeben, damit der gleiche Schlüssel, der auf Seiten des Absenders
noch zur Verschlüsselung eingesetzt wurde, als Entschlüsselungsschlüssel
den verschlüsselten Text in Klartext entschlüsselt.
Damit der Empfänger aber überhaupt den Entschlüsselungsvorgang starten
kann, muss ihm zuvor durch den Absender die Passphrase über einen
abhör- und abfangsicheren Kanal (z. B. persönliches Treffen, abhörsichere
Telefonleitung) zugegangen sein.
Wenn aber ein sicherer Kanal die Vorbedingung ist, bzw. existiert,
kann der Absender auch gleich den Klartext über diesen sicheren
Kanal an den Empfänger weitergeben, ohne eine Verschlüsselung einsetzen
zu müssen.
Der Vorteil beim asymmetrischen Verfahren besteht also gerade darin,
dass dieser sichere Kanal nicht vorliegen muss, um Texte abhör-
und abfangsicher über grosse Entfernungen austauschen zu können,
da auch der Austausch einer Passphrase keine Vorbedingung darstellt.
Aus diesem Grund ist das symmetrische Verfahren nur sinnvoll, wenn es entweder von ein und derselben Person verwendet wird, z. B. vom Anwender, der seine Dateien auf der eigenen Festplatte verschlüsseln möchte (so wird das symmetrische Verfahren von PGP und PGPdisk zur Verschlüsselung lokaler Daten angewendet) oder in einem Umfeld, wo Daten für zwei Personen verfügbar vorliegen sollen, aber keiner dritten Person und diese zwei Personen die Möglichkeit haben, die gemeinsame Passphrase persönlich auszutauschen, z. B. zwei Kollegen, die ein gemeinsames Projekt in einer Firma bearbeiten.
Wer sich einen näheren Überblick zu kryptografischen Verfahren und Begriffen verschaffen möchte, sollte sich die (englischsprachige) FAQs About Today's Cryptography? der RSA Labors besorgen.
Zu beachten ist auch, dass sich das Dateiformat des Pub- und Secrings
von PGP 6 von dem Dateiformat von PGP 2.6.3 unterscheidet. Deshalb
sollte man darauf achten, dass ein Zugriff einer PGP Version auf
die falsche Datei ausgeschlossen ist und es nicht zu einer versehentlichen
Umbenennung oder Löschung einer Pub- oder Secring Datei kommt, wenn
sich die Dateien beider Versionen im gleichen Verzeichnis befinden
oder bei beiden Versionen der gleiche Zugriffspfad angegeben ist.
Veränderungen an den Public- und Private Keys, die in einer PGP-Version
durchgeführt werden, sollten analog in der anderen PGP-Version wiederholt
werden.
Auf diesem Wege können Fehlermeldungen, die beim Ent- und Verschlüsseln
auftreten und fälschlicherweise einer Inkompatibilität oder Keyfälschung
zugeschrieben werden, im Vorfeld verhindert werden.