PGP/GnuPG wird immer populärer, nicht zuletzt dank NSA und Konsorten. Wir schauen hinter die Kulissen und zeigen, wie und womit Sie Ihre Schlüsselsammlung aktuell halten.

Von der Verschlüsselung mithilfe von PGP/GnuPG hören viele Benutzer das erste Mal in einem Vortrag auf einer Linux-Veranstaltung oder auf einer “Crypto Party”. Oft sympathisieren sie zunächst nur mit der Idee, finden das Vorgehen dann toll und richtig und ziehen am Ende am gleichen Strang.

Möchten auch Sie Ihren Datenverkehr verschlüsseln, müssen Sie zunächst einmal ein allgemeines Verständnis für Verschlüsselung und die dafür notwendigen Begriffe und Einzelschritte erlangen [1]. Anschließend erzeugen Sie mittels Pretty Good Privacy (PGP) oder GNU Privacy Guard (GnuPG) Ihr eigenes Schlüsselpaar mit einem öffentlichen und einem privaten Schlüssel.

Im zweiten Schritt übermitteln Sie Ihren öffentlichen Schlüssel Ihren Kommunikationspartnern. Traditionell geschieht das entweder direkt als Zeichenkette in Form einer Datei als E-Mail-Anhang [2], in ausgedruckter Form (etwa während einer Keysigning-Party [3]) oder über einen Download der Datei von Ihrer Internetpräsenz. Seit einiger Zeit kommen auch QR-Codes dazu, die man mit dem Smartphone aufnehmen, überprüfen und verwalten kann. In Abbildung 1 sehen Sie Monkeysign [4] – die grafische Oberfläche zu Monkeyscan – mit der Visualisierung eines Schlüssels.

Abbildung 1: Ein GnuPG-Schlüssel als QR-Code.

Mit jedem Kommunikationspartner einzeln den Schlüssel auszutauschen, kompliziert die Dinge ein wenig. Als Erleichterung für den Alltag haben sich Keyserver etabliert [5] (siehe Tabelle “Keyserver (Auswahl)”). Dort hinterlegen Sie Ihren öffentlichen Schlüssel, sodass ihn dort jedermann herunterladen, validieren und unverzüglich zur Kommunikation mit Ihnen nutzen kann. Listing 1 zeigt ein Beispiel für den Aufruf mithilfe von GnuPG [6].

$ gpg --keyserver hkp://keys.gnupg.net --send-keys Schlüsselkennung
gpg: sending key Schlüsselkennung to hkp server

Auf der Kommandozeile heißt das Programm schlicht gpg beziehungsweise in der Version 2 gpg2. Über den Schalter --send-keys geben Sie die Kennung des Schlüssels an, den Sie veröffentlichen möchten. Der Schalter --keyserver spezifiziert den zu verwendenden Keyserver. Dabei spielt es keine Rolle, welchen Keyserver Sie initial beim Aufruf benennen oder bereits vorab in der Datei ~/.gnupg/gpg.conf [7] festgelegt haben. Alle größeren Keyserver [8] agieren in einem Verbund und gleichen regelmäßig miteinander die Datenbank der hinterlegten Schlüssel ab [9]. Innerhalb von 48 Stunden verbreitet sich der publizierte Schlüssel in der Regel so weit, dass er sich automatisch weltweit auf Gültigkeit prüfen lässt.

Beachten Sie bitte, dass Sie nur solche Schlüssel hochladen können, zu denen Sie auch den privaten Schlüssel besitzen. Eine Übersicht der privaten Schlüssel liefert GnuPG beim Aufruf des Schalters --list-secret-keys. Listing 2 zeigt das ausschnittsweise für einen ausgewählten Schlüssel des Autors. Dabei bezeichnet sec das Verfahren und die Kennung des Schlüssels, uid die Beschreibung (“user ID”), und ssb steht für das Verfahren und die Kennung des geheimen Unterschlüssels (“secret subkey”) [10]. In der Ausgabe sehen Sie auch, dass GnuPG dazu die Datei .gnupg/secring.gpg auswertet, in der es Ihre privaten Schlüssel speichert.

$ gpg --list-secret-keys
/home/frank/.gnupg/secring.gpg
------------------------------
sec  4096R/D431AC07 2014-09-05
uid  Frank Hofmann (Hofmann EDV) <frank.hofmann@efho.de>
ssb  4096R/3B074F29 2014-09-05

Einbinden in den Mailclient

Im letzten Schritt ergänzen Sie Ihr Mailprogramm [11] um die passende kryptografische Signatur (siehe Kasten “Orientierung im Signaturwirrwar”). Somit sind Sie in der Lage, ab sofort Ihre Daten signiert und/oder auch gleich verschlüsselt auszutauschen [12].

Abbildung 2 zeigt ein Beispiel anhand des textbasierten E-Mail-Clients Mutt [13]. Die gelb dargestellten Textzeilen zeigen, dass der Absender diese Nachricht kryptografisch signiert hat. Der dabei verwendete GnuPG-Schlüssel besitzt die Kennung D431AC07, basiert auf dem Verfahren RSA und wurde als gültig erkannt. Das bedeutet im Klartext, dass diese E-Mail mit hoher Wahrscheinlichkeit tatsächlich vom in der Mail genannten Absender stammt.

Abbildung 2: E-Mail mit verifizierter kryptografischer Signatur.

Alle derzeit verfügbaren Mailclients bieten eine passende Erweiterung an, um mit signierten und verschlüsselten E-Mails umzugehen. Sie unterscheiden sich aber deutlich hinsichtlich der Komplexität beim Einrichten und Benutzen der Erweiterung. Eine ausführliche Schritt-für-Schritt-Anleitung für Mozilla Thunderbird/Icedove in Kombination mit dem Verschlüsselungsplugin Enigmail [14] finden Sie beispielsweise im Debian-Wiki [15].

Bestehende Schlüssel anzeigen

Abbildung 3 zeigt eine Auswahl der öffentlichen Schlüssel mit dem Namen des Autors, auf die alle Interessierten weltweit uneingeschränkt via Keyserver zugreifen können. Diese Form der internetbasierten Abfrage kann im Alltag als verlässliche Referenz dienen. Jede Zeile umfasst nacheinander den Schlüsseltyp (pub als Abkürzung für “public” – öffentlicher Teil des Schlüssels), die Schlüssellänge samt Verfahren (die Angabe 4096R entspricht einem 4096-Bit-RSA-Schlüssel), die Schlüsselkennung (ID), das Datum der Schlüsselerzeugung und den Namen (User-ID) samt hinterlegter E-Mail-Adresse.

Abbildung 3: Die öffentlichen Schlüssel mit dem Namen des Autors.

Wenn Sie Abbildung 2 und Abbildung 3 miteinander vergleichen, stellen Sie fest, dass die Schlüsselkennung der E-Mail mit jener im vierten Eintrag der Liste identisch ist. Wie aus Abbildung 3 ebenfalls hervorgeht, gibt es mehr als einen “Frank Hofmann” – zum Autor gehören aus der Liste lediglich die Schlüssel in den Zeilen 2 bis 4.

Die Gegenseite prüfen

Alle Kommunikationspartner können kryptografisch signierte E-Mails automatisiert verifizieren, sofern die öffentlichen PGP/GnuPG-Schlüssel wie oben beschrieben zuvor auf einem öffentlichen Keyserver hinterlegt wurden oder alle Beteiligten eine Kopie des öffentlichen Schlüssels der Kommunikationspartner besitzen.

GnuPG hängt die von Ihnen vom Keyserver bezogenen Schlüssel an Ihren lokal gespeicherten Schlüsselbund (“Keyring”) an. Zur Überprüfung benötigen Sie eine bestehende Internet-Verbindung, es sei denn, Sie verfügen über eine vollständige Kopie des Datenbestands des öffentlichen Keyservers (eher unwahrscheinlich).

Listing 3 zeigt den vollständigen Aufruf auf der Kommandozeile, um einen Schlüssel zu beziehen. Über den Schalter --keyserver benennen Sie den Server, wobei hier hkp://keys.gnupg.net als generische Angabe den Keyserver-Verbund bezeichnet. Über den Schalter --recv-keys spezifizieren Sie die Schlüsselkennung des öffentlichen Schlüssels, den Sie von dort beziehen möchten – im Beispiel jene für den RSA-Schlüssel mit der ID C76E337A.

$ gpg --keyserver hkp://keys.gnupg.net --recv-keys C76E337A
gpg: fordere Schlüssel C76E337A von hkp-Server keys.gnupg.net an
gpg: Schlüssel C76E337A: Öffentlicher Schlüssel "Wolfram Eifler <adagio@weifler.in-berlin.de>" importiert
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   3  unterschrieben:   2  Vertrauen: 0-, 0q, 0n, 0m, 0f, 3u
gpg: Tiefe: 1  gültig:   2  unterschrieben:   2  Vertrauen: 2-, 0q, 0n, 0m, 0f, 0u
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:                              importiert: 1  (RSA: 1)

Schlüsselring lesen

Wie schon angesprochen fassen Sie im Alltag mehrere Schlüssel mithilfe eines sogenannten Schlüsselrings zusammen. Auf GnuPG/PGP-Ebene gibt es separate Dateien für öffentliche und private Schlüssel, die jeweils auf das Suffix .gpg enden. Die Datei pubring.gpg beinhaltet den Schlüsselring mit den öffentlichen Schlüsseln, während die Datei secring.gpg die privaten Schlüssel zusammenfasst. Den Inhalt des Schlüsselrings der öffentlichen Schlüssel zeigen Sie wie in Listing 4 gezeigt über das Kommando gpg -k an (Langoption --list-public-keys). Für die geheimen Schlüssel existieren die Gegenstücke -K beziehungsweise --list-secret-keys in der Langform.

$ gpg -k
/home/frank/.gnupg/pubring.gpg
------------------------------
pub   4096R/D431AC07 2014-09-05 uid       [ uneing.] Frank Hofmann (Hofmann EDV) <frank.hofmann@efho.de>
sub   4096R/3B074F29 2014-09-05
pub   1024D/DFA0A4D4 2008-01-10
uid       [  unbek.] Gerold Rupprecht (home email key) <geroldr@bluewin.ch>
sub   2048g/F9E8DE2F 2008-01-10
pub   4096R/612616B5 2009-07-12
uid       [ vollst.] Axel Beckert <abe@deuxchevaux.org>
uid       [ vollst.] Axel Stefan Beckert
uid       [ vollst.] Axel Beckert (FSFE Fellow) <abe@fsfe.org>
uid       [ vollst.] Axel Beckert (Symlink) <xtaran@symlink.ch>
uid       [ vollst.] Axel Beckert (E-Mail + Jabber) <abe@noone.org>
uid       [ vollst.] Axel Beckert (Debian Developer) <abe@debian.org>
uid       [ vollst.] [jpeg image of size 3155]
sub   4096g/004AB7CC 2009-07-12

Schlüssel validieren

Für das Validieren der Schlüssel kennt GnuPG zwei Wege, die Schalter --edit-key [16] und --check-sigs. Für beide benötigen Sie zusätzlich den Namen des zu prüfenden Schlüssels.

Bei --edit-key klärt GnuPG, ob es einen passenden geheimen Schlüssel gibt, und öffnet eine eigene Shell, in der Sie über GnuPG-eigene Kommandos Veränderungen am Schlüssel vornehmen können. Uns interessiert hier nur das Prüfen der Gültigkeit, daher kommt das Kommando check ins Spiel. In Listing 5 zeigt die Ausgabe, dass der Schlüssel gültig ist.

$ gpg --edit-key "Frank Hofmann"
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Geheimer Schlüssel ist vorhanden.
pub  4096R/D431AC07  erzeugt: 2014-09-05  verfällt: niemals     Aufruf: SC
                     Vertrauen: uneingeschränkt Gültigkeit: uneingeschränkt
sub  4096R/3B074F29  erzeugt: 2014-09-05  verfällt: niemals     Aufruf: E
[ uneing.] (1). Frank Hofmann (Hofmann EDV) <frank.hofmann@efho.de>
gpg> check
uid  Frank Hofmann (Hofmann EDV) <frank.hofmann@efho.de>
sig!3        D431AC07 2014-09-05  [Eigenbeglaubigung]
gpg> quit

Beim zweiten, kürzeren Aufruf aus Listing 6 identifiziert GnuPG einen abgelaufenen Schlüssel. Den Status der Überprüfung signalisiert das Programm in der Ausgabe durch ein Flag, das direkt auf den Text sig folgt. Dabei steht ein Ausrufezeichen für eine erfolgreiche Validierung, das Minus für eine “schlechte” Signatur und ein Prozentzeichen für einen Fehler, der während der Validierung auftrat.

$ gpg --check-sigs "Wolfram Eifler"
pub   2048R/C76E337A 2011-05-11 [verfallen: 2016-05-09]
uid                  Wolfram Eifler <adagio@weifler.in-berlin.de>
sig!3        C76E337A 2011-05-11  Wolfram Eifler <adagio@weifler.in-berlin.de>
1 Beglaubigung wegen fehlendem Schlüssel nicht geprüft

Um den gesamten Schlüsselring zu überprüfen, rufen Sie GnuPG wieder mit dem Schalter --check-sigs auf. Diesmal geben Sie jedoch keinen spezifischen Schlüsselnamen an und erhalten als Ergebnis eine Übersicht zum Status aller Schlüssel des Schlüsselrings.

Lokalen Keyring aktualisieren

Bereits bezogene Schlüssel können ablaufen oder vom Eigentümer zurückgezogen (“revoke”) beziehungsweise erweitert oder geändert werden. Um einen oder mehrere Einträge im lokalen Schlüsselring zu aktualisieren, kennt GnuPG den Schalter --refresh-keys. Benennen Sie einen Schlüsselnamen, aktualisiert das Tool nur diesen, ansonsten alle bestehenden Einträge im Schlüsselring (Listing 7). “Signatur” bedeutet in diesem Kontext, dass ein anderer Benutzer den Schlüssel signiert und damit bestätigt hat.

$ gpg --keyserver hkp://keys.gnupg.net --refresh-keys
gpg: 8 Schlüssel werden per hkp://keys.gnupg.net aktualisiert
gpg: fordere Schlüssel D431AC07 von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel 5F962E33 von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel 222694C4 von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel DFA0A4D4 von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel 612616B5 von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel 4A2E162B von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel 95930EDE von hkp-Server keys.gnupg.net an
gpg: fordere Schlüssel C76E337A von hkp-Server keys.gnupg.net an
gpg: Schlüssel D431AC07: "Frank Hofmann (Hofmann EDV) <frank.hofmann@efho.de>" nicht geändert
gpg: Schlüssel 5F962E33: "Frank Hofmann (privat) <fh@efho.de>" nicht geändert
gpg: Schlüssel 222694C4: "Frank Hofmann (LinuxBus) <linuxbus@efho.de>" nicht geändert
gpg: Schlüssel DFA0A4D4: "Gerold Rupprecht (home email key) <geroldr@bluewin.ch>" 1 neue Signatur
gpg: Schlüssel 612616B5: "Axel Beckert <abe@deuxchevaux.org>" 190 neue Signaturen
gpg: Schlüssel 612616B5: "Axel Beckert <abe@deuxchevaux.org>" 1 neuer Unterschlüssel
gpg: Schlüssel 4A2E162B:"Axel Beckert (ISG D-PHYS) <beckert@phys.ethz.ch>" 2 neue Signaturen
gpg: Schlüssel 95930EDE: "Axel Beckert (no legal relevance) <abe@deuxchevaux.org>" 14 neue Signaturen
gpg: Schlüssel C76E337A: "Wolfram Eifler <adagio@weifler.in-berlin.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 8
gpg:                             unverändert: 4
gpg:                     neue Unterschlüssel: 1
gpg:                         neue Signaturen: 207
gpg: 3 marginal-needed, 1 complete-needed, PGP Vertrauensmodell
gpg: Tiefe: 0  gültig:   3  unterschrieben:   2  Vertrauen: 0-, 0q, 0n, 0m, 0f, 3u
gpg: Tiefe: 1  gültig:   2  unterschrieben:   2  Vertrauen: 2-, 0q, 0n, 0m, 0f, 0u

Grafische Schlüsselverwaltung

Sagen Ihnen grafische Programme mehr zu als die Werkzeuge für die Kommandozeile, sollten Sie sich Seahorse, Kgpg aus dem KDE-Projekt sowie den GNU Privacy Assistant GPA näher ansehen.

Mit dem kompakten Seahorse [17] aus dem Gnome-Fundus (Abbildung 4) verwalten Sie sowohl Zertifikate (Abbildung 5) als auch GnuPG- und SSH-Schlüssel. Es integriert sich fest in den Ubuntu- beziehungsweise Gnome-Desktop. Um Ihren lokalen GnuPG-Schlüsselring aktuell zu halten, synchronisiert Seahorse auf Wunsch die vorhandenen Schlüssel mit dem Keyserver-Verbund. Das erreichen Sie über den Menüpunkt Entfernt | Schlüssel abgleichen und veröffentlichen.

Abbildung 4: Seahorse liefert jederzeit einen Überblick zu den Schlüsseln und Signaturen.

Abbildung 5: Auf Wunsch präsentiert Seahorse die Details zu einem GnuPG- oder SSH-Schlüssel.

Der GNU Privacy Assistant [18] wirkt auf den ersten Blick umfangreicher als Seahorse, konzentriert sich aber auf die GnuPG-Schlüsselverwaltung (Abbildung 6). In GPA fügen Sie beispielsweise Schlüssel hinzu, modifizieren und signieren diese oder gleichen Ihren Keyring mit dem Keyserver-Verbund ab.

Abbildung 6: Mit dem GNU Privacy Assistant GPA behalten Sie alle Schlüssel im Blick.

Fazit

Mit GnuPG und dessen grafischen Frontends halten Sie auf unproblematische Weise bei überschaubarem Aufwand Ihren Keyring stets aktuell. Zum Stöbern nach mehr Informationen empfehlen wir Ihnen das GnuPG-Wikibook [19] sowie einen Beitrag über bewährte OpenPGP-Verfahrensweisen [20].

Bislang unbeantwortet bleibt die Frage, wo und wie Sie private Schlüssel und die dazugehörigen Dateien sicher ablegen. Dieser Frage gehen wir in einem Folgeartikel in einer der nächsten Ausgaben nach.