GnuPG Anleitung - Seite 7
Schlüssel-Management
Das grundsätzliche Kommando, mit dem man den Schlüsseleditor in der Konsole öffnet:
gpg --edit-key Schlüssel-ID oder Benutzer-ID gpg> Kommando gpg> save oder quit
Für den Überblick können im Schlüsseleditor das list, check und fpr Kommando hilfreich sein. Das list Kommando gibt alle Informationen zu Schlüsseln aus. Das check Kommando überprüft und listet alle Zertifikate. Das fpr Kommando zeigt den Fingerabdruck des Hauptschlüssels an.
Einzelne Kommandos können auch direkt erfolgen:
gpg --Kommando Schlüssel-ID oder Benutzer-ID
Zur Gewährleistung der Eindeutigkeit sollte die Schlüssel-ID des Hauptschlüssels statt der Benutzer-ID als Parameter benutzt werden. Zur Ermittlung der Schlüssel-ID lässt man sich passende Schlüssel anzeigen. Die Schlüssel-ID sollte in Langform (mit den sechszehn letzten Zeichen des Fingerprints) und mit dem gesamten Fingerprint angegeben werden.
gpg --Kommando 4623BA84 (Kurzform, 32-Bit) gpg --Kommando 5A1796454623BA84 (Langform, 64-Bit) gpg --Kommando "2883 3DFE AF81 8885 51C0 5241 5A17 9645 4623 BA84"
In der gpg.conf sollte man für Anzeigen generell die Langform und die Ausgabe des Fingerprints festlegen:
keyid-format long with-fingerprint
Siehe auch die Heise-Meldung Haufenweise Fake-PGP-Schlüssel im Umlauf und den Artikel OpenPGP: Duplicate keyids - short vs long im Sumptuous Capital Blog.
Während der Bearbeitung eines Schlüssels erfolgen nach Eingabe eines Kommandos u. U. weitere selbsterklärende Nachfragen, Bestätigungsanfragen, Auswahldialoge und die Abfrage der Passphrase. Mit dem help Kommando erhält man eine Übersicht aller möglichen Kommandos. Jede Bearbeitung wird mit save oder quit abgeschlossen. Mit dem save Kommando werden vorgenommene Änderungen gespeichert oder mit dem quit Kommando der Schlüsseleditor verlassen und alle Änderungen verworfen.
Anzeigen
Anzeige-Kommandos kann zusätzlich ein Muster als Parameter mitgegeben werden, um nur die Schlüssel auswerfen zu lassen, bei denen Teile oder der gesamte Inhalt einer Benutzer-ID (Namen und E-Mail Adressen) oder die Schlüssel-ID auf das Muster zutreffen. Zusätzlich kann der Umfang und der Inhalt der Ausgaben vorab mit Parametern für die list-options Option in der gpg.conf bestimmt werden.
- Kurze Anzeige
gpg --list-keys [Muster]
- Anzeige plus Zertifikate
gpg --list-sigs [Muster]
- Anzeige plus Zertifikate und ihrem Überprüfungsstatus
gpg --check-sigs [Muster]
- Anzeige plus Fingerabdruck des Hauptschlüssels
gpg --Kommando --fingerprint [Muster]
Abkürzungen
Bei der Ausgabe werden in der ersten Spalte je nach gewähltem Kommando verschiedene Kürzel angezeigt:
Kürzel | Bedeutung |
---|---|
pub | Hauptschlüssel |
sub | Unterschlüssel |
D | DSA Schlüssel |
g | Elgamal Schlüssel |
R | RSA Schlüssel |
uid | zertifizierte Benutzer-ID |
rev | zurückgezogener Schlüssel oder zurückgezogenes Zertifikat |
sig | Zertifikat |
sig L | lokales Zertifikat |
sig N | Zertifikat ist mit Anmerkung versehen |
sig P | Zertifikat ist mit Beglaubigungs- bzw. Zertifizierungs-Richtlinie versehen |
sig X | Zertifikat ist verfallen |
sig R | Anzeige beim Eigenzertifikat: Schlüssel ist mit einem "designated revoker" versehen |
sig R | Anzeige beim Fremd-Zertifikat: Zertifikat ist nicht-zurückziehbar |
sig 3 | Zertifikat mit Überprüfungsgrad 3 |
sig 2 | Zertifikat mit Überprüfungsgrad 2 |
sig 1 | Zertifikat mit Überprüfungsgrad 1 |
sig | Zertifikat mit Überprüfungsgrad 0 |
sig! | korrektes Zertifikat |
sig- | falsches Zertifikat |
sig% | Fehler bei der Zertifikats-Überprüfung |
Parameter
Parameter für die list-options Option in der gpg.conf:
Parameter | Erklärung |
---|---|
no-show-photos | keine Anzeige von Foto(-ID)s |
show-policy-urls | Anzeige der URL zur Zertifizierungs-Richtlinie |
show-notations | Anzeige von Anmerkungen |
show-keyserver-urls | Anzeige der URL zum bevorzugten Schlüsselserver |
show-uid-validity | Anzeige des Vertrauensgrads vor der Benutzer-ID |
show-unusable-uids | Anzeige zurückgezogener oder ungültiger Benutzer-IDs |
show-unusable-subkeys | Anzeige zurückgezogener oder abgelaufener Unterschlüssel |
show-sig-expire | Anzeige von Zertifikat-Ablaufdatum |
In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die list-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.
list-options [no-]parameter1 parameterN
Benutzer-ID
hinzufügen
gpg --edit-key test@test.de gpg> adduid
Anwendung:
- neue oder zusätzliche E-Mail bzw. Kontaktadresse
- Wechsel des E-Mail Providers
- alte Kontaktadresse nicht mehr genutzt und wird zurückgezogen
- Aufnahme eines zusätzlichen Spitznamens oder Pseudonyms
bevorzugen
gpg --edit-key test@test.de gpg> uid N gpg> primary
Damit wird bei mehreren Benutzer-IDs eine als die primäre Benutzer-ID gekennzeichnet und sollte bei der Auflistung oder Auswahl von Schlüsseln primär angezeigt werden.
Anwendung:
- bei mehr als einer Benutzer-ID
entfernen
gpg --edit-key test@test.de gpg> uid N gpg> deluid
Für N wird die Nummer der betreffenden Benutzer-ID ausgewählt, die gelöscht werden soll. Wurde der Schlüssel bereits veröffentlicht, muss die Benutzer-ID zurückgezogen und der Schlüssel danach neu veröffentlicht werden.
zurückziehen
gpg --edit-key test@test.de gpg> uid N gpg> revuid
Damit wurde für die ausgewählte Benutzer-ID ein Rückzugsvermerk ausgestellt und in der Schlüsselanzeige wird der Benutzer-ID der [widerrufen] Hinweis vorangestellt. Um den Rückzug global wirksam werden zu lassen, muss der Schlüssel exportiert bzw. auf einem Schlüsselserver veröffentlicht werden.
Anwendung:
- Kontaktadresse wird nicht mehr genutzt
Passphrase ändern
gpg --edit-key test@test.de gpg> passwd
Danach wird die alte Passphrase abgefragt und 2x die neue Passphrase eingegeben.
Ablaufdatum ändern
Hauptschlüssel
gpg --edit-key test@test.de gpg> expire Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll. 0 = Schlüssel verfällt nie <n> = Schlüssel verfällt nach n Tagen <n>w = Schlüssel verfällt nach n Wochen <n>m = Schlüssel verfällt nach n Monaten <n>y = Schlüssel verfällt nach n Jahren Wie lange bleibt der Schlüssel gültig? (0) 2014-12-31
Statt allgemeiner Zeitraumangaben mit n Zeitraum kann auch ein bestimmtes Datum nach dem Muster YYYY-MM-DD angegeben werden.
Anwendung:
- alternativ zum kompletten Schlüssel-Widerruf und Erstellung eines neuen Schlüssels
Unterschlüssel
gpg --edit-key Schlüssel-ID gpg> key N gpg> expire Bitte wählen Sie, wie lange der Schlüssel gültig bleiben soll. 0 = Schlüssel verfällt nie <n> = Schlüssel verfällt nach n Tagen <n>w = Schlüssel verfällt nach n Wochen <n>m = Schlüssel verfällt nach n Monaten <n>y = Schlüssel verfällt nach n Jahren Wie lange bleibt der Schlüssel gültig? (0) 2014-12-31
Für N wird die Nummer des Unterschlüssels ausgewählt, dessen Ablaufdatum geändert werden soll. Statt allgemeiner Zeitraumangaben mit n Zeitraum kann auch ein bestimmtes Datum nach dem Muster YYYY-MM-DD angegeben werden.
Anwendung:
- alternativ zum Unterschlüssel-Widerruf oder Hinzufügen eines neuen Unterschlüssels
Schlüsselserver vorgeben
Eigenzertifikat
gpg --edit-key Schlüssel-ID gpg> keyserver Geben Sie die URL Ihres bevorzugten Schlüsselservers ein: hkps://keys.openpgp.org
Zusätzlich bzw. alternativ kann die URL des Schlüsselservers in der gpg.conf hinterlegt werden, so dass die URL automatisch bei neu erzeugten Schlüsseln oder bei Änderung der Krypto-Präferenzen im Eigenzertifikat gespeichert wird:
default-keyserver-url URL
Signaturen
- gpg.conf
sig-keyserver-url hkps://keys.openpgp.org
Mit den Angaben wird zukünftig der öffentliche Schlüssel vom angegebenen Schlüsselserver bezogen, wenn der Kommunikationspartner den Schlüssel aktualisiert oder zwecks Signaturüberprüfung erstmalig herunterlädt.
Schlüssel exportieren
öffentlichen Schlüssel
gpg --output schlüsseldatei --armor --export test@test.de
Wer einen Schlüssel im Binärformat benötigt, ersetzt --armor durch --no-armor.
privaten Schlüssel
gpg --output schlüsseldatei --armor --export-secret-keys test@test.de
Wer einen Schlüssel im Binärformat benötigt, ersetzt --armor durch --no-armor.
zum Schlüsselserver
gpg [--keyserver URL] --send-keys 92CFDAD95A2EEAA6
Wurde in der gpg.conf keine Schlüsselserver URL mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden. Zu Schlüsselservern wird von GnuPG nur der öffentliche Schlüssel gesendet.
Parameter
Über Parameter für die export-options Option in der gpg.conf kann vorab das Exportverhalten beeinflusst werden.
Parameter | Erklärung |
---|---|
export-attributes | zusätzliche Attribute der Benutzer-ID wie ein Foto als Foto-ID werden mitexportiert |
export-clean | Zertifikate nicht nutzbarer Benutzer-IDs und von Schlüsseln, die zum Zeitpunkt des Exports nicht im öffentlichen Schlüsselring vorhanden sind, werden vor dem Export entfernt |
export-minimal | bis auf aktuelle Eigenzertifikate werden alle anderen Zertifikate vor dem Export entfernt |
In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die export-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.
export-options [no-]parameter1 parameterN
Die gleichen Parameter können im Schlüsselserver Kommando mit --keyserver-options [no-]parameter1 parmaterN
verwendet werden. Weitere Parameter für Schlüsselserver sind unter Schlüsselring aktualisieren aufgeführt.
Schlüssel importieren
aus lokaler Datei
gpg --import datei
vom Schlüsselserver
Ist die Schlüssel-ID bekannt:
gpg [--keyserver URI] --recv-keys Schlüssel-ID
Ist nicht bekannt, ob ein Schlüssel existiert:
gpg [--keyserver URI] --search-keys Muster
Wurde in der gpg.conf keine Schlüsselserver URI mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden.
GnuPG wirft danach eine nummerierte Liste aller Schlüssel aus, auf die das Muster zutrifft. Nach Eingabe einer Nummer wird der betreffende Schlüssel in die öffentliche Schlüsselringdatei importiert.
Parameter
Über Parameter für die import-options Option in der gpg.conf kann vorab das Importverhalten beeinflusst werden.
Parameter | Erklärung |
---|---|
import-clean | Zertifikate nicht nutzbarer Benutzer-IDs und von Schlüsseln, die zum Zeitpunkt des Imports nicht im öffentlichen Schlüsselring vorhanden sind, werden nach dem Import entfernt |
import-minimal | bis auf aktuelle Eigenzertifikate werden alle anderen Zertifikate nach dem Import entfernt |
In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die import-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.
import-options [no-]parameter1 parameterN
Die gleichen Parameter können im Schlüsselserver Kommando mit --keyserver-options [no-]parameter1 parmaterN
verwendet werden. Weitere Parameter für Schlüsselserver sind unter Schlüsselring aktualisieren aufgeführt.
Schlüssel löschen
fremde Schlüssel
gpg --delete-keys 89E6F36838F20095 pub 1024D/0x89E6F36838F20095 2012-02-25 test2 test2 <test2@test.de> Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j
eigene Schlüssel
Das Löschen eigener Schlüssel bietet sich für Schlüssel an, die nur lokal im Gebrauch waren und nicht bereits zur Kommunikationsverschlüsselung veröffentlicht wurden. Bereits veröffentlichte Schlüssel müssen zuerst zurückgezogen und können ggf. danach auch gelöscht werden.
Wenn man eigene Schlüsselpaare entfernen will, möchte man i. d. R., dass der private und der öffentliche Schlüssel aus beiden Schlüsselringdateien gelöscht wird.
gpg --delete-secret-and-public-keys 92CFDAD95A2EEAA6 sec 3072D/0x92CFDAD95A2EEAA6 2012-02-09 test test <test@test.de> Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j Dies ist ein privater Schlüssel! - Wirklich löschen? (j/N) j pub 3072D/0x92CFDAD95A2EEAA6 2012-02-09 test test <test@test.de> Diesen Schlüssel aus dem Schlüsselbund löschen? (j/N) j
Schlüssel an- und abschalten
Ein abgeschalteter Schlüssel kann nicht mehr zur Verschlüsselung verwendet werden, solange er abgeschaltet ist. Dafür können weiterhin Signaturen überprüft werden und Zertifikate sind weiterhin Schlüsseln bzw. Benutzer-IDs zuzuordnen.
abschalten
gpg --edit-key Schlüssel-ID gpg> disable
anschalten
gpg --edit-key Schlüssel-ID gpg> enable
Anwendung:
- alternativ zur Löschung eines Schlüssels
Schlüssel zurückziehen
Das Eigenzertifikat und die eigenen Zertifikate der Benutzer-IDs des gesamten Schlüssels oder Unterschlüssel werden zurückgezogen, indem für die Zertifikate ein Widerrufszertifikat ausgestellt und anschließend der Schlüssel mit dem Widerrufszertifikat veröffentlicht wird.
Anwendung:
- Passphrase vergessen
- Schlüsselringdateien beschädigt
- Schlüssel wird nicht mehr verwendet
- der geheime Schlüssel wurde komprimitiert
- verwendeter Algorithmus gebrochen oder geschwächt
Die beiden ersten Punkte legen nahe, für jeden neu erstellten Schlüssel, der auch veröffentlicht wird, ein externes Widerrufszertifikat direkt nach der Erstellung anzufertigen und zur späteren Verwendung sicher zu verwahren. Zur sicheren Verwahrung kann man z. B. neben der Speicherung auf einem externen, ggf. zugangsgeschützten Medium alle Widerrufszertifikate in ein Archiv packen und das Archiv mit GnuPG symmetrisch verschlüsseln. Da während der Anfertigung von Widerrufszertifikaten die Passphrase abgefragt wird, ist deshalb ein späteres Widerrufszertifikat bei vergessener Passphrase nicht mehr möglich.
Unterschlüssel
gpg --edit-key Schlüssel-ID gpg> key N gpg> revkey
Gesamtschlüssel
gpg --output zertdatei --gen-revoke Schlüssel-ID
Mit dem obigen Kommando wird das Widerrufszertifikat erzeugt und zur späteren Verwendung in der externen zertdatei Datei gespeichert. Zum Zeitpunkt des tatsächlichen Widerrufs des Schlüssels wird die Datei wie beim Schlüssel-Import importiert und anschließend der öffentliche Schlüssel mit dem Widerrufszertifikat exportiert und verbreitet bzw. an einen Schlüsselserver gesendet. Widerrufene Schlüssel werden von GnuPG nicht mehr zur Verschlüsselung berücksichtigt.
Widerrufene Schlüssel sind in Auflistungen an einem enstprechenden Vermerk erkennbar:
In der Konsole:
pub 3072D/0x92CFDAD95A2EEAA6 2012-02-09 [widerrufen: 2012-02-27] Schl.-Fingerabdruck = 0469 14AB 60F2 D0D8 C1F9 C89D 92CF DAD9 5A2E EAA6 uid [widerrufen] test test <test@test.de> sub 4096g/0xB728BB7FFBC19289 2012-02-09 [widerrufen: 2012-02-27]
Widerruf-Agent
Ein Schlüsseleigentümer kann einen anderen Schlüsselinhaber zum Widerruf-Agenten ernennen („designated revoker“), der stellvertretend den Schlüssel des Schlüsseleigentümers zurückziehen bzw. ein Rückzugs-Zertifikat ausstellen kann.
gpg --edit-key Schlüssel-ID gpg> addrevoker sensitive Geben sie die User-ID des designierten Widerrufers ein: Schlüssel-ID
Durch den sensitive Parameter werden Informationen zum Widerruf-Agenten bei einem Schlüssel-Export nicht mitexportiert, solange die --export-options export-sensitive-revkeys Exportoption nicht verwendet wird.
Um für den fremden Schlüssel ein Rückzugs-Zertifikat auszustellen, gibt der Widerruf-Agent das folgende Kommando ein und verfährt mit dem Rückzugs-Zertifikat wie beim Widerruf eines Gesamtschlüssels, um den Schlüssel tatsächlich zu widerrufen.
gpg --output zertdatei --desig-revoke Schlüssel-ID
Unterschlüssel hinzufügen
siehe Schlüsselerstellung → Unterschlüssel (Signieren) u. Unterschlüssel (Verschlüsseln)
Anwendung:
- alter Unterschlüssel abgelaufen oder komprimitiert
- alternativ zur Erstellung eines komplett neuen Schlüssels
Vetrauensgrad vergeben
gpg --edit-key Schlüssel-ID gpg> trust Bitte entscheiden Sie, in wieweit Sie diesem User zutrauen, Schlüssel anderer User korrekt zu prüfen (durch Vergleich mit Lichtbildausweisen, Vergleich der Fingerabdrücke aus unterschiedlichen Quellen ...)? 1 = Weiß nicht so recht 2 = Nein, ihm traue ich NICHT 3 = Ich vertraue ihm marginal 4 = Ich vertraue ihm vollständig 5 = Ich vertraue ihm absolut m = Zurück zum Menü Ihre Auswahl?
Anwendung:
- für das Web of Trust sollte jedem neu aufgenommenen Schlüssel neben der zumindest lokalen Zertifizierung auch ein Vertrauensgrad vergeben werden
Schlüssel zertifizieren
lokal
Ein lokales Zertifikat wird bei einem Schlüssel-Export nicht mitexportiert, sondern gilt nur im lokalen Schlüsselring und der Vertrauens-Datenbank für das lokale Web of Trust.
gpg --lsign-key Schlüssel-ID
Anwendung:
- für das lokale Web of Trust sollte jeder neu aufgenommene Schlüssel neben der Vergabe eines Vertrauensgrads zumindest lokal zertifiziert werden
exportierbar
Ein normales Zertifikat wird bei einem Schlüssel-Export mitexportiert und trägt so zum globalen Web of Trust bei. Deshalb sollte der Schlüssel nach der Zertififizierung an einen Schlüsselserver gesendet werden.
gpg --sign-key Schlüssel-ID
Werden Schlüssel nach festen Regularien einer Beglaubigungsrichtlinie zertifiziert, kann die URL zur Beglaubigungsrichtlinie im Zertifikat gespeichert werden. Dazu übergibt man dem Kommando zusätzlich --cert-policy-url URL
oder setzt die URL dauerhaft in die gpg.conf:
cert-policy-url https://domain.tld/richtlinie
Ein weiterer Typ des normalen Zertifikats ist ein Zertifikat, das der Aussteller zu einem späteren Zeitpunkt nicht widerrufen kann.
gpg --edit-key Schlüssel-ID gpg> nrsign
Trust-Zertifikat
Bei einem Trust-Zertifikat handelt es sich um ein lokales oder exportierbares Zertifikat, in dem gleichzeitig Informationen über die Vertrauenswürdigkeit des Schlüsseleigentümers gespeichert sind. Zusätzlich ist im Zertifikat angegeben, bis zu welcher Vertrauenspfad-Tiefe der Schlüsseleigentümer seinerseits „in unserem Namen“ Trust-Zertifikate an andere Schlüsseleigentümer vergeben kann und ob die Zertifikate auf einen bestimmte Domainnamen der Benutzer-IDs bzw. Benutzerkreis beschränkt sind oder an jeden beliebigen Schlüsseleigentümer vergeben werden können.
gpg --edit-key Schlüssel-ID gpg> tsign (exportierbar) oder ltsign (lokal) Bitte wählen Sie, wie lange die Beglaubigung gültig bleiben soll. 0 = Schlüssel verfällt nie <n> = Schlüssel verfällt nach n Tagen <n>w = Schlüssel verfällt nach n Wochen <n>m = Schlüssel verfällt nach n Monaten <n>y = Schlüssel verfällt nach n Jahren Wie lange bleibt die Beglaubigung gültig? (0) 0 Wie genau haben Sie überprüft, ob der Schlüssel, den Sie jetzt beglaubigen wollen, wirklich der o.g. Person gehört? Wenn Sie darauf keine Antwort wissen, geben Sie "0" ein. (0) Ich antworte nicht. (default) (1) Ich habe es überhaupt nicht überprüft. (2) Ich habe es flüchtig überprüft. (3) Ich habe es sehr sorgfältig überprüft. Ihre Auswahl? ('?' für weitere Informationen): 3 Bitte entscheiden Sie, in wieweit Sie diesem User zutrauen, Schlüssel anderer User korrekt zu prüfen (durch Vergleich mit Lichtbildausweisen, Vergleich der Fingerabdrücke aus unterschiedlichen Quellen ...)? 1 = Ich vertraue ihm marginal 2 = Ich vertraue ihm vollständig Ihre Auswahl? 2 Geben Sie bitte die Tiefe dieser "Trust"-Signatur ein. Eine Tiefe größer 1 erlaubt dem zu signierenden Schlüssel Trust-Signatures für Sie zu machen. Ihre Auswahl? 2 Geben Sie bitte eine Domain ein, um die Signatur einzuschränken oder nur die Eingabetaste für keine Domain Ihre Auswahl? test.de
Anwendung:
- Aufbau bzw. Nutzung einer OpenPGP PKI
Zertifikat löschen
Wurde der Schlüssel bereits veröffentlicht, müssen Zertifikate zurückgezogen und der Schlüssel danach neu veröffentlicht werden.
gpg --edit-key Schlüssel-ID gpg> uid N gpg> delsig
Zertifikat zurückziehen
gpg --edit-key Schlüssel-ID gpg> uid N gpg> revsig
Anwendung:
- der Schlüssel bzw. Schlüsseleigentümer ist nicht mehr vertrauenswürdig
Schlüsselring aktualisieren
Das refresh-keys Kommando sollte in Abständen ausgeführt werden, um die Schlüssel im öffentlichen Schlüsselring zu aktualisieren. Dabei werden Änderungen an Schlüsseln wie neue oder zurückgezogene Zertifikate, Unterschlüssel, Benutzer-IDs usw. vom Schlüsselserver abgerufen und geänderte Schlüssel in den öffentlichen Schlüsselring importiert.
gpg [--keyserver URI] --refresh-keys
Wurde in der gpg.conf keine Schlüsselserver URI mit der keyserver Option hinterlegt, muss der Schlüsselserver im Kommando angegeben werden.
Parameter
Die Ansteuerung und Verwendung von Schlüsselserver-Funktionen kann man durch Parameter für die keyserver-options Option in der gpg.conf beeinflussen:
Parameter | Erklärung |
---|---|
include-revoked | Berücksichtigung zurückgezogener oder auch vom Schlüsselserver fälschlich als zurückgezogen makrierter Schlüssel |
include-disabled | Berücksichtigung abgeschalteter Schlüssel |
auto-key-retrieve | Automatischer Bezug und Import von Schlüsseln bei der Signaturprüfung, die noch nicht im öffentlichen Schlüsselring gespeichert sind |
honor-keyserver-url | Verwendung des Schlüsselservers, dessen URL im Eigenzertifikat gespeichert ist |
timeout=n | die Kommunikation mit dem Schlüsselserver wird n Sekunden Inaktivität abgebrochen |
In die gpg.conf werden ausgewählte Parameter mit Komma oder Leerzeichen getrennt hinter die keyserver-options Option gesetzt. Mit no-parameter wird die Bedeutung negiert.
keyserver-options [no-]parameter1 parameterN
HKPS Schlüsselserver
Einige Schlüsselserver sind nicht nur über das unverschlüsselte HTTP Keyserver Protokoll (HKP – Horowitz Schlüsselserver Protocol), sondern auch über das verschlüsselnde HTTPS Keyserver Protokoll (HKPS) erreichbar, so dass Schlüssel-Aktualisierungen, -Importe und -Exporte veschlüsselt übertragen werden. Für die Ansteuerung und Verwendung von HKPS Schlüsselserver relevante Optionen können in der dirmngr.conf Konfigurationsdatei hinterlegt werden.
Nach Abschaltung des SKS Keyserverpools bieten sich drei Schlüsselserver an:
- der Schlüsselserver, den eventuell der eigene Mailanbieter betreibt (z. B. bei mailbox.org)
- der mit Hockeypuck betriebene Ubuntu Schlüsselserver, der Standard-Schlüsselserver ist, wenn kein anderer Schlüsselserver in der GnuPG Konfiguration angegeben wird und sich mit anderen Schlüsselservern synchronisiert
- der mit Hagrid betriebene keys.openpgp.org Schlüsselserver, der mit E-Mail Verifizierung arbeitet und sich nicht mit anderen Schlüsselservern synchronisiert
keys.opengpg.org
Nach Export des öffentlichen Schlüssels wird die Schlüsseldatei zuerst zu keys.open.org hochgeladen. Nach dem Upload stößt man über Buttons die Verifizierung der im Schlüssel erkannten E-Mail Adressen an, die über den Aufruf der URLs in den E-Mail Nachrichten von keys.openpgp.org abgeschlossen ist. Erst dann kann der Schlüssel über die Benutzer-ID bzw. E-Mail Adresse gefunden und der Schlüssel vollständig vom Schlüsselserver bezogen werden:
Will man später eine Benutzer-ID entfernen, die für einen veröffentlichten Schlüssel verifiziert wurde, ruft man die Management-Seite auf und klickt den Delete Button an:
Da es z. Zt. nur einen keys.openpgp.org Schlüsselserver gibt, der sich nicht synchronisiert, sollte man den Schlüssel parallel zum Ubuntu Schlüsselserver hochladen. Weitere Besonderheiten von keys.openpgp.org werden auf der FAQ und Usage Seite erläutert.
Anonymisierung
Wer Privoxy und Tor installiert hat, kann den gesamten unverschlüsselten oder verschlüsselten Datenverkehr anonymisieren. Dafür verwendet man den folgenden Parameter für die keyserver-options Option mit http://127.0.0.1:8118/ als Proxyadresse. Da Anonymisierung und verschlüsselter Transport zeitaufwendiger sind, bietet sich ein entsprechender Timeout-Wert von >= 60 Sekunden für die timeout keyserver-options Option an.
Parameter | Erklärung |
---|---|
http-proxy=http://adresse:port/ | für HTTP/HKP Schlüsselserver wird der Verkehr über den angegebenen Proxy geleitet |
In der torrc Tor Konfigurationsdatei wird der Hostname des Schlüsselservers in die TrackHostExits Liste aufgenommen, um für die Dauer der Verbindungen zum Schlüsselserver den gleichen Tor Ausgang-Router zu verwenden.
gpg_refresh Linux-Skript
Das Skript kann man z. B. täglich oder wöchentlich per cron nutzen, um die Schlüssel automatisch zu aktualisieren. Das Skript löscht nach der Aktualisierung alle Schlüssel, die nach der Aktualisierung immer noch abgelaufen sind, d. h. deren Ablaufdatum nicht geändert wurde. Wer das nicht möchte, entfernt nach # Abgelaufene Schlüssel entfernen den gpgdel ; sleep 5 && Aufruf.
Um unabhängig von anderweitigen Schlüsselringdateien (z. B. die APT Schlüsselringdatei) zu sein, die u. U. neben der pubring.gpg Schlüsselringdatei in der gpg.conf des Benutzers eingetragen sind, auf die der Benutzer aber keinen Schreibzugriff hat, wird in der gpgdefault Variable die gpg.conf ignoriert und die zu verwendende Schlüsselringdatei explizit benannt.
Im gpgrefresh Cron Skript muss der Pfad zum gpg_refresh Skript und der Loginname des BENUTZERS eingetragen werden, dessen Schlüssel aktualisiert werden sollen. Im gpg_refresh Skript ist ebenfalls der Loginname einzusetzen und mit GnuPG 2.0 zu entscheiden, ob man einen Schlüsselserver ohne (HKP) oder mit (HKPS) Verschlüsselung verwenden will. Außerdem ist zu entscheiden, ob die Namensauflösung des Schlüsselserver-Hostnamen und die Aktualisierung über Privoxy und Tor anonymisiert werden oder nicht. Entsprechende Hinweise stehen im Skript.
Vor der Aktualisierung wird ein Backup der Schlüsselringe und Vertrauens-Datenbank angelegt, das bei erfolgreicher Aktualisierung gelöscht und ansonsten wieder zurückgespielt wird. Beide Skripte sind so gehalten, dass es keinerlei Ausgaben gibt und nur per Mail über die Resultate informiert wird.
- /etc/cron.weekly/gpgrefresh
#!/bin/sh sudo -H -u BENUTZER /pfad/gpg_refresh >/dev/null exit 0
#!/bin/sh gpguser="BENUTZER" gpghome="/home/$gpguser/.gnupg" export gpghome gpgbackup="/home/$gpguser/tmp" gpg="/pfad/bin/gpg2" gpgdefault="--no-options --no-default-keyring --keyring $gpghome/pubring.gpg --quiet --no-verbose --no-tty" # GnuPG 2.1: # gpgdefault="--no-options --no-default-keyring --keyring $gpghome/pubring.kbx --quiet --no-verbose --no-tty" # GnuPG 2.0: # HKP-Schlüsselserveradresse # keyserver="hkp://eu.pool.sks-keyservers.net" # HKPS-Schlüsselserveradresse keyserver="hkps://hkps.pool.sks-keyservers.net" cacertfile="/pfad/sks-keyservers.netCA.pem" gpglist () { $gpg $gpgdefault --list-public-keys --with-colons 2>/dev/null | grep "^pub:" | wc -l } gpgdel () { for keyid in $($gpg $gpgdefault --list-public-keys --with-colons 2>/dev/null | grep "^pub:e" | cut -d: -f5); do $gpg $gpgdefault --batch --yes --no-auto-check-trustdb --delete-key $keyid done } gpgtdbupd () { $gpg $gpgdefault --batch --check-trustdb >/dev/null 2>&1 } # Namensauflösung für Schlüsselserver # nicht anonymisiert: dig -t A -4 $(echo $keyserver | cut -d/ -f3) | grep NOERROR > /dev/null # anonymisiert: # tor-resolve $(echo $keyserver | cut -d/ -f3) >/dev/null 2>&1 if [ $? -gt 0 ]; then echo "Namensauflösung für GPG-Keyrefresh fehlgeschlagen - Status Code: $?\nWiederholen Sie die Aktualisierung mit $0." | mail -s "GPG-Keyrefresh: Namensausflösung" root exit 1 fi # Backup der Schlüsseldaten cp -f $gpghome/*.gpg $gpgbackup/ >/dev/null 2>&1 && \ # GnuPG 2.1: # cp -f $gpghome/pubring.kbx $gpghome/*.gpg $gpgbackup/ >/dev/null 2>&1 && \ # Schlüssel-Aktualisierung # mit GnuPG 2.0 muss ohne Anonymisierung über Privoxy und Tor die Zeile # --keyserver-options http-proxy=http://127.0.0.1:8118/ \ # entfernt werden. $gpg $gpgdefault --no-auto-check-trustdb --keyserver "$keyserver" \ --keyserver-options ca-cert-file\=$cacertfile,no-honor-keyserver-url,no-include-isabled,timeout\=60 \ --keyserver-options http-proxy=http://127.0.0.1:8118/ \ --import-options merge-only,import-clean \ --refresh-keys >/dev/null 2>&1 # GnuPG 2.1: # $gpg $gpgdefault --no-auto-check-trustdb \ # --keyserver-options no-honor-keyserver-url,no-include-isabled,timeout\=60 \ # --import-options merge-only,import-clean \ # --refresh-keys >/dev/null 2>&1 refreshstatus=$? keyzahlold="$(gpglist)" # Abgelaufene Schlüssel entfernen # TrustDB aktualisieren # Backups löschen oder wiederherstellen. # Benachrichtigung if [ $refreshstatus = 0 ]; then gpgdel ; sleep 5 && gpgtdbupd && sleep 5 && rm $gpgbackup/*.gpg keyzahl="$(gpglist)" echo "GPG-Keyrefresh wurde mit Status Code $refreshstatus beendet.\nIm Schlüsselring befinden sich jetzt $keyzahl Schlüssel. Vor der Aktualisierung $keyzahlold Schlüssel." | mail -s "GPG-Keyrefresh: erfolgreich" root exit 0 else mv $gpgbackup/*.gpg $gpghome/ echo "GPG-Keyrefresh wurde mit Status Code $refreshstatus abgebrochen. Das Backup der Schlüsselringdateien wurde wiederhergestellt.\nSie können die Aktualisierung manuell mit $0 wiederholen" | mail -s "GPG-Keyrefresh: Fehlschlag" root exit 1 fi exit 0
Krypto-Präferenzen
Die Bevorzugung von Algorithmen durch die Reihenfolge in verschiedenen Listen wirkt sich auf die lokale Verschlüsselung von Daten und die Verschlüsselung von Kommunikationsinhalten aus. Bei der lokalen (nicht-symmetrischen) Verschlüsselung mit eigenen Schlüsseln wird GnuPG immer die Algorithmen einsetzen, die in den Reihenfolgen an erster Stelle stehen.
Bei der Verschlüsselung von Daten oder Kommunikationsinhalten mit einem fremden Schlüssel will sowohl der Schlüsselanwender, als auch der Schlüsseleigentümer seine Präferenzen berücksichtigt wissen. GnuPG besitzt dafür einen intelligenten Mechanismus, der die Liste der Präferenzen im Eigenzertifikat des öffentlichen Schlüssels des Schlüsseleigentümers auf Übereinstimmung mit den Präferenzen abgleicht, die der Schlüsselanwender hat. Aus beiden Listen bildet GnuPG eine neue Liste der Algorithmen, die Schlüsseleigentümer und Schlüsselanwender gemeinsam haben und verwendet diese bei der Verschlüsselung, Signierung und Erzeugung von Prüfsummen.
anzeigen
Mit dem Befehl erhält man die Ausgabe aller von GnuPG unterstützen und in der OpenPG Spezifikation zugelassenen Algorithmen zur Public-Key („Öff. Schlüssel“) und symmetrischen („Verschlü.“) Verschlüsselung, für die Prüfsummen („Hash“) und zur Komprimierung.
Zum Setzen der bevorzugten Algorithmen im Eigenzertifikat mit dem setpref Kommando und in der gpg.conf mit den *-preferences Optionen kann man die Klarnamen oder die ebenfalls angegebenen Sn, Hn und Zn IDs der OpenPGP Spezifikation verwenden.
gpg --version Unterstützte Verfahren: Öff. Schlüssel: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Verschlü.: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Komprimierung: nicht komprimiert, ZIP, ZLIB, BZIP2
Der Befehl listet die im Eigenzertifikat gespeicherte Reihenfolge der bevorzugten Algorithmen auf:
gpg --edit-key Schlüssel-ID gpg> showpref [ uneing.] (1). test test <test@test.de> Verschlü.: TWOFISH, AES256, AES192, AES, 3DES, BLOWFISH, CAST5 Digest: SHA256, RIPEMD160, SHA1 Komprimierung: BZIP2, ZLIB, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify
setzen
Als Beispiel werden die obigen Präferenzen auf AES256 und TWOFISH für die symmetrische Verschlüsselung, SHA256 für die Prüfsummen und BZIP2 für die Komprimierung gesetzt:
gpg --edit-key Schlüssel-ID gpg> setpref AES256 TWOFISH SHA256 BZIP2 Setze die Liste der Voreinstellungen auf: Verschlü.: AES256, TWOFISH, 3DES Digest: SHA256, SHA1 Komprimierung: BZIP2, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify Die Voreinstellungen wirklich ändern? (j/N) j
Die Anzeige der Präferenzen nach der Änderung:
gpg --edit-key Schlüssel-ID gpg> showpref [ uneing.] (1). test test <test@test.de> Verschlü.: AES256, TWOFISH, 3DES Digest: SHA256, SHA1 Komprimierung: BZIP2, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify
Hat man mit den *-preferences Optionen in der gpg.conf ein „Profil“ der bevorzugten Algorithmen gespeichert (siehe Schlüsselerstellung), kann man mit einem weiteren Kommando das Profil als neue Präferenzen in das Eigenzertifikat übertragen bzw. speichern:
gpg --edit-key Schlüssel-ID gpg> updpref Setze die Liste der Voreinstellungen auf: Verschlü.: TWOFISH, AES256, AES192, AES, 3DES, BLOWFISH, CAST5 Digest: SHA256, RIPEMD160, SHA1 Komprimierung: BZIP2, ZLIB, ZIP, nicht komprimiert Eigenschaften: MDC, Keyserver no-modify Die Voreinstellungen wirklich ändern? (j/N) j