Das Ver- und Entschlüsseln mit GnuPG übernehmen moderne Mail-Clients fast von alleine. Nur um die Schlüssel muss man sich selbst kümmern – und das ist eine Wissenschaft für sich.

Ach, die guten Vorsätze! Dass E-Mails wie Postkarten auf ihrem Zustellweg (und auf dem Zielserver) für alle lesbar sind, die an die Daten herankommen, das dürften mittlerweile nicht nur die Mail-Gurus wissen. Doch während man selbst für vollkommen unverfängliche Mitteilungen auf Papier selbstverständlich zum Briefumschlag greift, müssen Schutzbehauptungen wie “Ich habe weder vor meinem Provider, noch vor amerikanischen Geheimdiensten irgendetwas zu verbergen” nur all zu oft das schlechte Gewissen in Bezug auf den immer noch fehlenden PGP-/GnuPG-Schlüssel beruhigen.

Dabei bieten mittlerweile fast alle E-Mail-Programme umfangreiche Unterstützung für den elektronischen Briefumschlagerzeuger [1,2]. Zwar entfällt das Argument “bisher nicht benutzt, weil zu umständlich zu bedienen” dadurch nicht vollkommen, es reicht jedoch nicht mehr zur Begründung der vollkommenen PGP/GnuPG-Blockade aus. Wenn dann von guten Freunden oder Bekannten die Einladung zu einer Key-Signing-Party kommt, gewinnt das schlechte Gewissen in jedem Fall die Oberhand …

Handwerkszeug

Vorausgesetzt, das GnuPG-Kommandozeilentool gpg ist installiert, erzeugt der Befehl gpg --gen-key (generate key”) ein neues Schlüsselpaar für den eigenen Gebrauch. Die entsprechende Option findet die Anwenderin recht schnell heraus, wenn sie

gpg --help | less

aufruft; zudem herrscht zumindest zu diesem Punkt keinerlei Dokumentationsmangel (siehe auch [3]). Wer sich partout nicht mit der Kommandozeile anfreunden mag, findet zum Beispiel im GNU-Privacy-Assistenten gpa (http://www.gnupg.org/(de)/related_software/gpa/) einen grafischen Begleiter (Abbildung 1). Leider bietet der bislang nur einen Bruchteil der Funktionalität des Kommandozeilentools; zudem liefern wenige Distributionen die neueste Version mit, und bei älteren ist die Benutzerschnittstelle eine Zumutung. Gründe genug, an dieser Stelle nicht weiter darauf einzugehen.

Abbildung 1: Der GNU Privacy Assistant deckt derzeit nur einen Bruchteil der gpg-Funktionalität ab

Ein paar Verschlüsselungs- und Signierübungen, um sich mit dem neuen Tool bekannt zu machen, eventuelle Konfigurationsmaßnahmen am Mail-Programm (vgl. z. B. [3]), erste signierte und mit dem eigenen privaten Key an sich selbst verschlüsselt verschickte Mails – anschließend können die Party-Vorbereitungen beginnen.

Der erste, wichtige Punkt: Damit die anderen den eigenen öffentlichen Key signieren (und wichtiger noch: ihn zur Erzeugung der Briefumschläge für Mails an eine selbst benutzen) können, müssen sie ihn erst einmal bekommen. Klassischerweise schreibt man ihn mit

gpg --export -a "Name" > public_key

als ASCII-Text in die Datei public_key und wirft diese unter’s Volk. Doch wer will sich die Mühe machen und sie an alle Party-Teilnehmer/innen (von denen man möglicherweise bislang nicht einmal die E-Mail-Adressen hat) zu verschicken oder gar auf Diskette zu verteilen? Nicht auszudenken, welche Arbeit später noch dazukäme: Alle, die nicht auf der Party waren und dennoch verschlüsselte Mails an eine versenden wollen, brauchen ebenfalls immer erst den öffentlichen Schlüssel.

Zum Glück gibt es PGP/GnuPG-Keyserver, und mit gpg ist es kinderleicht, den eigenen public key dort hinauf zu laden (und sich die Schlüssel potentieller Mail-Partner/innen zu holen). Viele dieser Server gleichen ihre Schlüsseldatenbanken miteinander ab. So reicht es meist, sich einen Keyserver, etwa den des Computer Emergency Response Team des “Deutschen Forschungsnetzes” (DFN-CERT), auszusuchen. Diesen trägt man in die GnuPG-Konfigurationsdatei ~/.gnupg/options (die manchmal auch gnupg.conf heißt) ein:

keyserver blackhole.pca.dfn.de

Abbildung 2: Der Keyserver des DFN-CERT lässt sich auch per Web-Interface abfragen

… und schon sucht importiert der Befehl gpg --search-keys email@adres.se den zur angegebenen Mail-Adresse passenden Schlüssel in den eigenen Schlüsselbund für öffentliche Keys (Listing 1). Dieser liegt (wie auch der Bund mit den privaten Schlüsseln, secring.gpg) im Verzeichnis ~/.gnupg und heißt pubring.gpg. Passt der angegebene Suchstring auf mehrere Schlüssel auf dem Server, bietet gpg wie im Beispiel eine Liste zur Auswahl an. Statt der Antwort “importiere die Schlüssel 1-5” hätte dort auch die Eingabe 1 (oder 2 oder …) gereicht: gpg zeigt zu jeder Auswahlmöglichkeit die Schlüssel-ID(entifikationsnummer) an, und die ist in Listing 1 immer 1E786A45. Damit hat man es mit einem einzigen Schlüssel zu tun, der für mehrere E-Mail-Adressen gilt.

webmistress@fri:~$ gpg --search-keys pjung@linux-user.de
gpg: WARNUNG: Sensible Daten k"onnten auf Platte ausgelagert werden.
gpg: siehe http://www.gnupg.org/de/faq.html f"ur weitere Informationen
gpg: Schl"usselbund `/home/webmistress/.gnupg/pubring.gpg' erstellt
gpg: suche nach "pjung@linux-user.de" auf HKP-Server blackhole.pca.dfn.de
Keys 1-5 of 5 for "pjung@linux-user.de"
(1)     Patricia Jung <pjung@linux-user.de>
          1024 bit DSA key 1E786A45, created 2003-01-16
(2)     Patricia Jung <pjung@linux-magazin.de>
          1024 bit DSA key 1E786A45, created 2003-01-16
[…]
(5)     Patricia Jung <pjung@linux-magazine.com>
          1024 bit DSA key 1E786A45, created 2003-01-16
Enter number(s), N)ext, or Q)uit > 1-5
gpg: Schl"ussel 1E786A45: "Offentlicher Schl"ussel "Patricia Jung <pjung@linux-user.de>" importiert
gpg: Anzahl insgesamt bearbeiteter Schl"ussel: 1
gpg:                              importiert: 1

Ehe man jedoch seinen eigenen öffentlichen Schlüssel mit gpg --send-keys "Name" auf den Keyserver hochlädt, bitte einmal tief durchatmen! Denn ab jetzt gilt es, den eigenen privaten Schlüssel wie einen Augapfel zu hüten. Sollten Sie dazu einmal das Passwort vergessen, besteht nicht einmal mehr die Möglichkeit, Ihren Schlüssel wieder zurückzuziehen. (Deshalb bietet es sich an, im Vorfeld mit gpg --gen-revoc "Name" ein “Revocation Certificate” für den eigenen Key zu erstellen und diese Rückzugsmöglichkeit als Ausdruck sicher für den Notfall zu verwahren.)

Fingerabdrücke

Zudem bedarf es für eine selbst wie auch für die E-Mail-Partner/innen einer Möglichkeit, sich zu vergewissern, dass der auf dem Server liegende Schlüssel tatsächlich die Daten enthält, die er enthalten soll. Zu diesem Zweck erzeugt man einen Fingerabdruck des eigenen öffentlichen Keys z. B. mit gpg --fingerprint "Name" oder gpg --fingerprint email@adres.se. (Nicht alle, aber viele gpg-Kommandozeilenoptionen erlauben es, den gewünschten Key über den passenden Namen, die Key-ID, die E-Mail-Adresse oder gar nur über deren local part anzusprechen – solange die Angabe eindeutig ist.)

Auch vom Fingerprint lohnt es, eine Kopie zur eigenen Vergewisserung sicher zu verwahren. Zudem kann man zum Beispiel seinen Mailclient so konfigurieren, dass er ihn in jeder ausgehenden Mail in einer benutzerdefinierten Header-Zeile, einem sogenannten X-Header (etwa: X-GPG-Fingerprint:) mitschickt. Denn an diesem Fingerabdruck hängt eigentlich alles: Um sich zu vergewissern, dass ein Schlüssel, den man vom Keyserver heruntergeladen hat, dem entspricht, was die vermutete Eigentümerin als ihren Key bezeichnet, erfragt man von gpg den Fingerprint des entsprechenden Eintrags im eigenen Schlüsselbund und vergleicht diese Reihe von Hexadezimalzahlen in der Ausgabe …

webmistress@fri:~$ gpg --fingerprint pjung@linux-user.de
[…]
Key fingerprint = 2350 B799 81E8 B20B 3743  D541 CA1E C447 1E78 6A45

… mit dem, was die Schlüsseleignerin selbst als Fingerprint verteilt.

Deshalb gehört zur Vorbereitung der Signierparty, genügend Ausdrucke des eigenen Fingerprints zu erstellen, um sie an die Anwesenden zu verteilen. Gute Organisator(inn)en sammeln die Fingerprints im Vorfeld zusammen und geben sie an die Teilnehmenden weiter.

Partytime

Leider erlaubt der Vergleich der Fingerabdrücke lediglich Rückschlüsse darauf, ob der Schlüssel selbst in Ordnung ist. Ob seine Besitzerin auch tatsächlich diejenige ist, deren Name im Schlüssel verzeichnet steht, lässt sich erst kontrollieren, wenn sie sich ausweisen kann. Aus diesem Grund muss man zu jeder Signierparty mit Personalausweis, Reisepass oder einer anderen amtlichen Legitimation anreisen – denn wie sollte sonst eine bislang Unbekannte tatsächlich darauf vertrauen können, dass Patricia Jung tatsächlich Patricia Jung ist?

Hat man sich auf der Party davon überzeugt, dass die Person, die den Fingerprint auf dem Zettel ausgehändigt hat, tatsächlich so aussieht, wie sich ihr Ausweis einen Menschen ihres Namens vorstellt, kann man sich – wieder zu Hause (oder am Netz) – den entsprechenden public key herunterladen und dessen Fingerprint mit dem erhaltenen vergleichen.

Schlüssel geprüft, Mensch ebenso – doch woher soll man jetzt wissen, dass Mail an die im Schlüssel angegebenen E-Mail-Adressen tatsächlich bei der verifizierten Person ankommen? Damit Adressen im Laufe eines Schlüssellebens hinzukommen oder zurückgezogen werden können, dürfen sie (wie übrigens auch Schlüsselsignaturen) keinen Einfluss auf den Fingerprint haben. Wer also mit seiner Unterschrift seiner Überzeugung Ausdruck verleihen will, dass Mensch, E-Mail-Adresse und Schlüssel zusammenpassen, kommt an einer Überprüfung der Mail-Adressen nicht vorbei.

Zu diesem Zweck schickt man eine mit dem verifizierten öffentlichen Schlüssel verschlüsselte Mail an die zu signierenden Adressen der Inhaberin. Die Nachricht enthält die Bitte, den Mail-Inhalt signiert zurückzuschicken. Um sicherzustellen, dass die Empfängerin den Inhalt dieser “Challenge-Mail” nicht erraten kann, sondern ihn wirklich entschlüsseln muss, schickt man im Mail-Text einen Zufallsstring mit. Einen solchen erzeugt zum Beispiel der Befehl

dd if=/dev/random bs=1 count=10 2>/dev/null | uuencode -m - | sed -n 2p

Im Netz finden sich Skripte wie [4], die – nach einer gewissen Anpassungsarbeit – dabei helfen, dieses Prozedere zu automatisieren.

Kommt die (hoffentlich notierte) Zeichenkette signiert zurück, weiß man, dass die Empfängerin die Nachricht dechiffrieren konnte; stimmt die Signatur dieser Antwort, wurde die Mail auf dem Weg nicht verändert.

webmistress@fri:~$ gpg --edit pjung@linux-user.de
gpg (GnuPG) 1.2.1; Copyright (C) 2002 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Secret key is available.
pub  1024D/1E786A45  created: 2003-01-17 expires: never      trust: u/u
sub  2048g/62D4F0F4  created: 2003-01-17 expires: never
(1)  Patricia Jung <pjung@linux-user.de>
(2)  Patricia Jung <pjung@linux-magazin.de>
[…]
(5). Patricia Jung <pjung@linux-magazine.com>
Command> 1
pub  1024D/1E786A45  created: 2003-01-17 expires: never      trust: u/u
sub  2048g/62D4F0F4  created: 2003-01-17 expires: never
(1)* Patricia Jung <pjung@linux-user.de>
(2)  Patricia Jung <pjung@linux-magazin.de>
[…]
(5). Patricia Jung <pjung@linux-magazine.com>
Command> sign
pub  1024D/1E786A45  created: 2003-01-17 expires: never      trust: u/u
 Primary key fingerprint: 2350 B799 81E8 B20B 3743  D541 CA1E C447 1E78 6A45
     Patricia Jung <pjung@linux-user.de>
How carefully have you verified the key you are about to sign actually belongs
to the person named above?  If you don't know what to answer, enter "0".
   (0) I will not answer. (default)
   (1) I have not checked at all.
   (2) I have done casual checking.
   (3) I have done very careful checking.
Your selection? 3
Are you really sure that you want to sign this key
with your key: "Webmistress <webmistress@answergirl.de>"
I have checked this key very carefully.
Really sign? y
You need a passphrase to unlock the secret key for
user: "Webmistress <webmistress@answergirl.de>"
1024-bit DSA key, ID 2F0F137E, created 2003-04-28Geheime Passphrase des eigenen secret keys
Command> quit
Save changes? y

Erst dann beginnt die Unterschriftszeremonie. Dabei kommt der Befehl gpg --edit email@adres.se zum Einsatz und öffnet ein interaktives Tool, das die zu diesem Schlüssel gehörenden Adressen listet (Listing 2). Auf der internen Kommandozeile eingegeben, zeigt der Befehl help [Enter] an, welche Möglichkeiten der Nutzerin jetzt offen stehen. Will sie alle Adressen signieren, gibt sie einfach sign [Enter] ein; ist Beschänkung angesagt, wählt sie vor diesem Kommando die passende Zahl aus und bestätigt sie mit [Enter]. In ersterem Fall fragt gpg noch einmal nach (“Wirklich alle?”) – für ja heißt die Antwort [y], für nein [n].

Dann kommt die Vertrauensfrage: “Haben Sie eine gründliche Überprüfung vorgenommen (Antwort: [3]) oder nur eben so la la ([2])?” Diese Angabe legt die Stufe des Vertrauens fest, den die Antwortende einer Signatur mit diesem Schlüssel entgegenbringt. Eine letzte Bekräftigung wird fällig, dann kommt die Stunde der Wahrheit: Das Tool fragt die Passphrase des eigenen geheimen Schlüssels ab. Dann befindet sich die Anwenderin wieder auf der eingebauten Kommandozeile, auf der sie zum Abschied quit sagt. Erst wenn sie jetzt noch einmal bestätigt, dass sie die Änderungen abspeichern will, speichert gpg den fremden Schlüssel tatsächlich mit Signatur ab.

Natürlich nützt das nur dann etwas, wenn diese Unterschrift auch veröffentlicht wird. Denn an ihrer Hand werden alle, die der Signierenden vertrauen, die Schlüsselinhaberin jedoch nicht kennen, ihren Vertrauenswert in den Schlüssel der letzteren festlegen. Dazu kann die Signatorin entweder den neu signierten Schlüssel exportieren und an die Eigentümerin zurückschicken (und ihr das Verteilen überlassen) – oder sie lädt die Signatur einfach mit gpg --send-keys "Name" auf den Keyserver. Ein gpg --refresh-keys bringt dann jeweils den eigenen Schlüsselbund auf den neuesten Stand – und der Run auf die Top 1000 im Web of Trust [5] kann beginnen.