die raven homepage
Ein Unterschlüssel, der als öffentlicher Schlüssel im Umlauf ist oder ein kompletter Schlüssel, der vom Schlüsselbesitzer nicht mehr verwendet wird, bzw. von den Schlüsselbenutzern nicht mehr verwendet werden soll, weil z. B. beim Schlüsselbesitzer die Passphrase in Vergessenheit geraten, der private Schlüssel verloren gegangen oder in fremde Hände gelangt ist oder weil der Schlüssel einfach nicht mehr benutzt wird, kann vom Schlüsselbesitzer widerrufen oder zurückgezogen werden.
Genauer gesagt wird nicht der Schlüssel an sich widerrufen, sondern dessen Eigenzertifikat und die eigenen Zertifikate der User-IDs.
D. h. der Schlüssel wird mit einem zusätzlichen Zertifikat versehen, das den kompletten Schlüssel oder einen Unterschlüssel als vom Besitzer widerrufen ("revoked") ausweist. Dieses Merkmal wird sowohl von GnuPG als auch vom Schlüsselserver als Angabe zum Schlüssel angezeigt.
Das Beispiel der vergessenen Passphrase zeigt, dass man das Rückzugszertifikat ("Revocation Certificate") nicht erst versucht zu erzeugen, wenn man nicht mehr im Besitz der Passphrase ist oder das Speichermedium, auf dem sich der private Schlüssel befand, gelöscht wurde, weil man ohne Passphrase und privaten Schlüssel auch kein Rückzugszertifikat ausstellen kann - sondern optimal sofort nach der Erstellung eines Schlüssels in Form eines externen Rückzugszertifikats für den kompletten Schlüssel.
Da auch ein Angreifer Interesse an diesem Rückzugszertifikat hat, könnte er doch damit den eigenen Schlüssel auf einem Schlüsselserver als widerrufen markieren, gilt es, das Rückzugszertifikat direkt nach der Erstellung sicher vor unbefugtem Zugriff und Zerstörung zu verwahren.
Ein Rückzugszertifikat kann als externes Zertifikat erzeugt werden, das den gesamten Schlüssel (inklusive des Hauptsignierschlüssels und aller Unterschlüssel) widerruft und das erst zum Zeitpunkt des tatsächlichen Widerrufs dem Schlüssel zugeordnet wird, indem das Rückzugszertifikat in die Schlüsselringe importiert und anschließend der Schlüssel an den Schlüsselserver gesendet wird.
Diese Form des Rückzugszertifikats bietet sich an, um zu einem späteren Zeitpunkt unter allen Umständen einen Schlüssel widerrufen zu können.
Es ist deshalb das wichtigste Rückzugszertifikat, dass GnuPG Anfänger nach der Erstellung ihres Schlüssels anfertigen sollten.
Die zweite Form des internen Rückzugszertifikats wird mit dem Schlüsseleditor direkt zu einem bestimmten Unterschlüssel hinzugefügt. Mit Ausnahme des widerrufenen Unterschlüssels bleibt der Schlüssel (d. h. Hauptsignierschlüssel und weitere Unterschlüssel) weiter gültig und verwendbar. In diesem Fall sendet man den Schlüssel sofort an einen Schlüsselserver, entweder direkt über GnuPG oder indirekt mit dem exportierten Schlüssel.
Diese Form des Rückzugszertifikats bietet sich an, wenn nur bestimmte Schlüsselbestandteile widerrufen werden sollen und die Veröffentlichung des Widerrufs sofort oder in naher Zukunft erfolgt.
Ein internes Rückzugszertifikat kann auf ähnlichem Weg auch für den Widerruf eines einzelnen Zertifikats oder einer User-ID ausgestellt werden.
Die internen Rückzugszertifikate für Schlüsselkomponenten sind für den GnuPG Anfänger erst einmal von nachrangigem Interesse.
Damit sich die Information eines Rückzugszertifikats verbreitet, sendet man den öffentlichen Schlüssel, dem ein Rückzugszertifikat zugeordnet wurde an einen Schlüsselserver – direkt mit GnuPG oder über Eingabe des exportirten Schlüssels in ein Schlüsselserver-Weboberfläche. In dringenden Fällen auch per E-Mail an die Kommunikationspartner, damit diese sofort ihren öffentlichen Schlüsselbund aktualisieren.
Ist der öffentliche Schlüssel nicht über einen Schlüsselserver veröffentlicht worden, sollte das Rückzugszertifikat mit einer Kopie der Schlüsselringdateien importiert und anschließend der exportierte öffentliche Schlüssel gesichert werden.
Ist der öffentliche Schlüssel veröffentlicht, reicht das gesicherte Rückzugszertifikat (s. o.), weil es bei einem Verlust der lokalen Schlüsselringdateien immer noch mit dem öffentlichen Schlüssel auf dem Schlüsselserver zusammengeführt werden kann.
Man kann nur selbst erstellte Zertifikate widerrufen, d. h. das Eigenzertifikat, Zertifikate, die man selbst für User-IDs fremder öffentlicher Schlüssel und die User-IDs des eigenen Schlüssels ausgestellt hat.
Widerruft man ein eigenes Zertifikat einer eigenen User-ID, das mit dem zugehörigen Hauptsignierschlüssel erstellt wurde, wird damit die User-ID selbst widerrufen.
Bei einer User-ID eines fremden Schlüssels wird die User-ID durch den Widerruf des Zertifikats, das man für die User-ID ausgestellt hatte, nicht widerrufen, weil nur der fremde Schlüsselbesitzer seine eigene User-ID durch ein Rückzugszertifikat widerrufen kann.
Der Grund für den Widerruf einer eigenen User-ID kann darin liegen, dass sich die Kontaktangaben (E-Mail Adresse, Tel.-Nr., Namensänderung durch Heirat usw.) oder die Angaben zur Organisationszugehörigkeit (Abteilung X in Firma X statt Abteilung A in Firma B) geändert haben.
Der Widerruf eines einzelnen Zertifikats einer eigenen User-ID kann deshalb ausgestellt werden, weil das Zertifikat mit einem alten Schlüssel erstellt wurde, der selbst wieder nicht mehr verwendet oder widerrufen wurde.
Der Widerruf des eigenen Zertifikats einer fremden User-ID kann deshalb ausgestellt werden, weil man dem Schlüssel bzw. seinem Schlüsselbesitzer nicht mehr vertraut, den Verdacht hat, dass dessen privater Schlüssel in fremde Hände gelangt ist oder die Angaben der User-ID nicht mehr mit der Person übereinstimmen, mit der man kommuniziert, bzw. der Schlüsselinhaber keine neue User-ID erstellt hat und nicht mehr kontaktiert werden kann.
Trotz einiger Designschwächen stellen Schlüsselserver eine zentrale Komponente bei der Anwendung von GnuPG und für das Web-of-Trust dar. Auf Schlüsselserver können GnuPG Anwender öffentliche Schlüssel hinterlegen, wo sie von anderen GnuPG Anwendern abgerufen oder mit GnuPG abgeglichen werden können. Dabei reicht es, öffentliche Schlüssel auf einem Schlüsselserver zu hinterlegen, weil die Schlüsselserver miteinander vernetzt sind und den Schlüsselbestand miteinander synchronisieren (abgesehen von ein paar Ausnahmen).
Schlüsselbesitzer und -benutzer können ebenfalls Schlüssel mit veränderten Angaben und Bestandteilen auf die Schlüsselserver durch einfaches Hochladen des Schlüssels aktualisieren.
Über eine Synchronisierung des öffentlichen Schlüsselrings, bzw. Abgleich eines Schlüssels im öffentlichen Schlüsselring mit einem Schlüsselserver können so Aktualisierungen indirekt an alle Schlüsselbenutzer weitergereicht werden, ohne direkt mit allen Kommunikationspartnern kommunizieren zu müssen.
Die Anlässe, einen öffentlichen Schlüssel auf einen Schlüsselserver hochzuladen oder als Datei zu exportieren und die Datei weiterzuverbreiten: Ein neuer öffentlicher Schlüssel soll veröffentlicht werden, ein Schlüssel oder eine Schlüsselkomponente wurde mit Rückzugszertifikaten versehen, bzw. widerrufen, einem Schlüssel wurde eine neue User-ID hinzugefügt, ein fremder Schlüssel wurde zertifiziert, Angaben zu Kryptopräferenzen wurden im Schlüssel geändert.
Genauso wie den öffentlichen Schlüssel kann man auch die privaten Schlüssel, bzw. deren geheime Bestandteile z. B. für ein Backup oder die Verwendung in einer anderen OpenPGP Anwendung exportieren.
Private Schlüssel werden niemals auf einen Schlüsselserver geladen oder per E-Mail versendet. Bei unsachgemäßer und unsicherer Speicherung der exportierten Schlüsseldatei besteht die Gefahr der Kompomitierung des Schlüssels.
An die Schlüsselserver kann man mit GnuPG nicht nur öffentliche Schlüssel senden, sondern auch öffentliche Schlüssel anderer Schlüsselbesitzer direkt einsehen, anfordern und dem eigenen Schlüsselring hinzufügen.
Oder ein Schlüssel wird in Form einer Schlüsseldatei mit GnuPG importiert, die von der Website eines Schlüsselbesitzers heruntergeladen, von ihm per E-Mail zugeschickt oder über die Abfrage per Schlüsselserver-Weboberfläche bezogen wurde.
Weitere Optionen für den Import und Export von Schlüsseln sind im Anhang 4 aufgeführt.
Mit den folgenden Kommandos kann man Schlüssel aus den Schlüsselringen löschen. Zu beachten ist, das Schlüssel und Schlüsselbestandteile auf Schlüsselserver nicht gelöscht, sondern nur zurückgezogen werden können. D. h. es ist eigentlich nur sinnvoll, fremde Schlüssel und Schlüsselbestandteile zu löschen und bei eigenen Schlüsseln nur die Schlüssel und Schlüsselbestandteile, die noch nicht auf einem Schlüsselserver veröffentlicht wurden.
Öffentlichen Schlüssel löschen
gpg --delete-key Key-ID
Privaten Schlüssel löschen
gpg --delete-secret-key Key-ID
Privaten und öffentlichen Schlüssel löschen
gpg --delete-secret-and-public-key Key-ID
Haben sich die Angaben zur User-ID geändert oder ergeben sich zusätzliche, neue Angaben, z. B. um neue E-Mail Adressen von Mail oder Jabber Accounts anzugeben, kann man wie oben beschrieben veraltete User-IDs zurückziehen und neue User-IDs hinzufügen.
Dabei ist zu beachten, dass jede neu hinzugefügte User-ID automatisch zur primären User-ID wird, die auch als User-ID in grafischen GnuPG Tools und vom Schlüsselserver angezeigt werden. Deshalb muss man ggf. eine bestimmte User-ID zur primären User-ID bestimmen, deren Adresse hauptsächlich zur Kommunikation benutzt wird.
Sei es, dass man den Gültigkeitszeitraum eines Unterschlüssels nicht verlängern möchte, einen Unterschlüssel zurückgezogen hat oder neben einem RSA auch einen Elgamal Unterschlüssel zur Verschlüsselung anbieten möchte.
Steht der Ablauf eines Hauptsignier- oder Unterschlüssels bevor, soll ein Schlüssel eine begrenzte Gültigkeitsdauer erhalten oder sind Schlüssel bereits abgelaufen, kann das Ablaufdatum geändert werden.
Für den Hauptsignierschlüssel
Für einen Unterschlüssel
Zur Verbesserung der Sicherheit und des Schutzes vor einem Angriff kann die Passphrase regelmäßig geändert oder "verstärkt" werden.
Die Kommandos entfernen nicht verwertbare Zertifikate und User-IDs, die z. B. abgelaufen, zurückgezogen, doppelt, veraltet vorliegen. Gültige Eigenzertifikate bleiben in jedem Fall erhalten.
Soll eine Bereinigung automatisch für alle Schlüssel bei deren Im- oder Export durchgeführt werden, können entsprechende Optionen in der gpg.conf gesetzt werden.
