Der GNU Privacy Guard

Signieren von Schlüsseln

Mit gpg --sign-key ID gibt man an, dass man den Schlüssel mit der entsprechenden ID (wie bei --export oder --list-keys) signieren und somit beglaubigen will. GnuPG stellt zur Sicherheit noch ein paar Fragen, die man möglichst ehrlich beantworten sollte. Das soll heißen, dass der Schlüssel wirklich zu überprüfen ist: persönlich, mit amtlichen Ausweis und gpg-Fingerabdruck. Für solche Zwecke gibt es zum Beispiel Keysigning-Partys, worauf ich später noch zurückkommen werde.

Natürlich sollte man der Welt zeigen, dass man diesen Schlüssel signiert hat. Das macht man, indem man den Schlüssel an einen Keyserver oder dem Schlüsseleigentümer per E-Mail sendet (am besten verschlüsselt), er ihn dann importiert und selbst zum Keyserver schickt.

Bearbeiten und Löschen

Mit gpg --edit-key ID (kurz: --edit) erhält man eine interaktive GnuPG-Kommandozeile zum Bearbeiten des Schlüssels. help oder auch die Manpage leisten dazu Hilfe. Wenn man die Begriffe beherrscht, ist die Menüführung an sich sehr einfach. Mit den verfügbaren Befehlen kann man alle bisher gemacht Angaben nochmals verändern, Schlüssel signieren, ein JPEG-Foto (nicht zu groß!) von sich hinzufügen, Owner-Trusts setzen und vieles mehr.

Das Kommando --delete-key ID entfernt den angegebenen öffentlichen Schlüssel aus dem Schlüsselbund (z.B. falls man versehentlich einen falschen oder veralteten importiert hat). --delete-secret-key ID löscht angegebene (eigene) geheime Schlüssel.

PGP-Keyserver

Ich hab es vorher schon etwas erwähnt. Ein Keyserver speichert die öffentlichen Schlüssel für alle (leider auch für Spammer) abrufbar ab. Um Keyserver anzugeben, kann man die Option --keyserver Keyserver benutzen. Ich empfehle aber einen Eintrag wie keyserver Keyserver in die ~/.gnupg/gpg.conf. Außerdem empfehle ich einen Blick in die Manpage (man gpg), wegen --keyserver-options (bzw. seinen gpg.conf-Konfigurationszeilen), womit man Timeouts, Proxyserver und andere Dinge einstellen kann.

Werner Koch, der Entwickler von GnuPG, schrieb mir nach Erstveröffentlichung des Artikels eine Mail und bat mich, einen Keyserver zu empfehlen. Er schrieb:

»Fast alle Keyserver haben gewaltige Probleme mit OpenPGP-Schlüsseln, die über die ganz einfache Struktur hinausgehen. Man sollte sie deswegen nicht mehr benutzen. Die Round-Robin-Adresse subkeys.pgp.net ist eine Alternative, da diese Server gepatcht sind und die Keys wenigstens nicht mehr unbrauchbar machen - falls das passiert ist, kann man sowieso nichts mehr machen. Meine Empfehlung lautet, SKS-Keyserver zu benutzen. Diese haben eine moderne Software, die aktiv entwickelt wird, und zudem noch einen sehr fortschrittlichen Synchronisationsmechanismus. Sie syncen auch mit den alten Keyservers, sofern die Keys in Ordnung sind. In Deutschland ist keyserver sks.keyserver.penguin.de angebracht.«

Viele Keyserver bieten ein Web-Interface zur Suche, zum Abrufen und zum Einsenden von öffentlichen Schlüsseln an. Allerdings ist es oft schneller und einfacher, GnuPG selbst mit dem Keyserver kommunizieren zu lassen. Hierzu beherrscht GnuPG verschiedene Protokolle:

Das Horowitz Key Protocol, kurz HKP, benannt nach Marc Horowitz vom MIT, der den ersten Keyserver überhaupt programmierte und aufsetzte. Dieser ist aber jetzt anscheinend veraltet bzw. fehlerhaft (siehe oben), daher bitte nicht verwenden! HKP basiert eigentlich auf HTTP und ist nur eine Art Erweiterung. Sowohl die ältere PKS-Software als auch die neue und bessere SKS-Serversoftware kommunizieren über HKP, das über Port 11371 läuft. Beispiele nutzbarer Server sind: x-hkp://sks.keyserver.penguin.de, x-hkp://random.sks.keyserver.penguin.de, x-hkp://keyserver.noreply.org, hkp://subkeys.pgp.net. Wer hinter einer Firewall sitzt, wird sich über einen HKP-Server auf Port 80 freuen, wie zum Beispiel hkp://keyserver.kjsl.com:80 (gepatchter PKS) oder hkp://pgp.srv.ualberta.ca:80 (SKS).
Finger ist ein sehr altes Protokoll, um Informationen eines anderen Nutzers (auf demselben oder anderem Host) zu bekommen. Solch eine Information kann auch der öffentliche Schlüssel sein (je nach Fingerdämon in ~/.pgpkey, ~/.pubkey oder ~/.plan). Als Keyserver gibt man finger:User@Host an. Finger läuft über TCP-Port 79.
GnuPG kann auch per E-Mail Keys anfordern, hochladen, suchen. Allerdings erhält man die Antwort des Servers auch nur per E-Mail und nicht von gpg selbst. Dazu sollte ein lauffähiger und konfigurierter MTA (z.B. Exim, Postfix, Sendmail, etc.) installiert sein. Die Serversoftware dazu stammt von Michael Graff. Das Keyserver-Schema sieht so aus: mailto:E-Mailadresse, meist mailto:pgp-public-keys@Server. Allerdings habe ich den Verdacht, dass alle E-Mailkeyserver veraltete PKS-Software laufen haben.
Das Lightweight Directory Access Protocol, kurz LDAP, ist eigentlich ein Protokoll für Verzeichnisdienste. Network Associates Inc. kreierten die erste (einzigen?) LDAP-Keyserversoftware. Beispiele: ldap://certserver.pgp.com funktionierte bei mir als einziger, angeblich soll auch ldap://pgp.surfnet.nl gute Dienste leisten. LDAP-Keyserver lauschen auf Port 11370 und LDAPS-Keyserver auf 11369.

Für alle Protokolle sind GnuPGs Befehle die gleichen, aber das Verhalten mag leicht unterschiedlich sein. HKP ist die übliche und wahrscheinlich auch älteste Methode, daher beziehe ich mich immer auf das Verhalten von gpg, wenn es mit einem HKP-Keyserver kommuniziert.

Also wie lauten die Befehle?

Mit gpg --search-keys "Stephan Beyer" (kurz: --search) suche ich z.B. alle meine öffentlichen Schlüssel, und natürlich die meiner namentlichen Doppelgänger. GnuPG zeigt mir daraufhin die Treffer an. Aus diesen Treffern kann ich einen auswählen und dieser wird automatisch importiert.
Mit gpg --send-keys 0xFCC50404F (kurz: --send) exportiere ich meinen Schlüssel an den angegebenen Keyserver. GnuPG meldet sich dabei nur mit einer Fehler- oder Erfolgsmeldung zurück.
Mit gpg --recv-keys 0xDEADBEEF 0xF00BA211 (kurz: --recv) importiere ich direkt die öffentlichen Schlüssel mit den Schlüssel-IDs 0xDEADBEEF und 0xF00BA211. (Die Beispiele sind rein fiktiv.) Ist der zu empfangende Schlüssel bereits im Schlüsselbund, so entspricht das --recv einem --refresh.
gpg --refresh-keys (kurz --refresh) aktualisiert alle importierten öffentlichen Schlüssel. Dies kann man auch auf bestimmte Schlüssel (analog zu den anderen Befehlen) eingrenzen. Ist ein zu aktualisierender Schlüssel nicht im Schlüsselbund enthalten, so wird er ignoriert.