Schlüsselverfälschungen sind ein nicht zu unterschätzender Unsicherheitsfaktor bei der Public-Key-Kryptographie. Ein Angreifer kann beispielsweise die Schlüsselbunde eines Benutzers manipulieren oder sich einen öffentlichen Schlüssel mit einer vorgetäuschten Identität erzeugen und ihn an andere zum Herunterladen und Benutzen schicken. Wenn z.B. Chloe unbemerkt die Nachrichten, welche Alice an Blake sendet, lesen will, dann könnte sie folgendermaßen vorgehen: zuerst erzeugt sie ein neues Schlüsselpaar mit einer gefälschten Benutzer-ID. Dann ersetzt sie Alices Kopie von Blakes öffentlichem Schlüssel durch den neuen Schlüssel. Anschließend fängt sie die Nachrichten ab, die Alice an Blake sendet. Diese Nachrichten kann sie dann mit dem neuen geheimen Schlüssel entschlüsseln. Dann verschlüsselt sie die Nachricht wieder, aber diesmal mit dem echten öffentlichen Schlüssel von Blake und schickt sie weiter an Blake. Chloe kann jetzt - ohne daß jemand etwas bemerkt - alle von Alice an Blake geschickten Nachrichten mitlesen.
Eine gute Schlüsselverwaltung ist entscheidend für die Integrität Ihrer eigenen Schlüsselbunde, wie auch der Schlüsselbunde anderer Benutzer. Der Kern der Schlüsselverwaltung von GnuPG ist das Signieren von Schlüsseln und verfolgt zwei Hauptzwecke: es erlaubt Ihnen, Verfälschungen an Ihrem Schlüsselbund zu entdecken, und es ermöglicht Ihnen, die Zugehörigkeit eines Schlüssels zu der von der jeweiligen Benutzer-ID genannten Person zu überprüfen. Schlüsselunterschriften werden in einem Web of Trust genannten Schema benutzt, um die Authentisierung auch auf Schlüssel auszudehnen, die nicht direkt von Ihnen selbst, sondern von anderen Personen, denen Sie zutrauen, Schlüssel nur nach sorgfältiger Prüfung zu signieren, signiert worden sind. Durch eine gewissenhafte Schlüsselverwaltung können Sie Schlüsselverfälschungen als einen praktischen Angriff auf ihre sichere und vertrauliche Kommunikation abwehren.
Ein Schlüsselpaar besteht aus einem öffentlichen und einem geheimen Schlüssel und einem Satz von Benutzer-IDs, um die Schlüssel einer realen Person zuzuordnen. Jeder dieser Bestandteile enthält Informationen über sich selbst. Bei einem öffentlichen Schlüssel sind dies seine ID sowie Angaben darüber, wann er erzeugt worden ist, wann seine Gültigkeit abläuft usw. Bei der Benutzer-ID sind das der Name der realen Person, die durch die ID identifiziert wird, eine optionale Bemerkung sowie eine E-mail-Adresse. Der geheime Schlüssel enthält dagegen keine Informationen über die Benutzer-ID.
Wenn Sie Informationen über ein Schlüsselpaar sehen möchten, dann rufen Sie am besten mit der Kommandozeilen-Option --edit-key den Schlüsseleditor auf. Zum Beispiel:
chloe$ gpg --edit-key [email protected] Geheimer Schlüssel ist vorhanden. pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) <[email protected]> (2) Chloe (Freie Autorin) <[email protected]> Befehl>Zusammen mit dem öffentlichen Schlüssel wird angezeigt, ob der geheime Schlüssel verfügbar ist oder nicht. Alle Informationen über die Bestandteile des öffentlichen Schlüssels werden dann aufgelistet. Die erste Spalte gibt den Typ des Schlüssels an. Das Schlüsselwort pub identifiziert den öffentlichen Hauptschlüssel und das Schlüsselwort sub identifiziert einen untergeordneten öffentlichen Schlüssel (Subkey). Die zweite Spalte gibt Länge, Typ und ID des Schlüssels an. Dabei steht D für DSA-Schlüssel, g für einen nur zur Verschlüsselung geeigneten ElGamal-Schlüssel und G für einen ElGamal-Schlüssel, der sowohl zur Verschlüsselung als auch zum Unterschreiben verwendet werden kann. Das Datum der Erzeugung und das Verfallsdatum wird in den Spalten drei und vier angegeben. Die Benutzer-IDs werden nach den Schlüsseln angegeben.
Es stehen noch weitere Befehle zu Verfügung, um zusätzliche Informationen über die Schlüssel zu erhalten. Der Befehl toggle schaltet zwischen den öffentlichen und den geheimen Komponenten eines Schlüsselpaares um, wenn tatsächlich beides zur Verfügung steht.
Befehl> toggle sec 1024D/1B087D04 created: 2000-06-07 expires: never sbb 2048g/6A3E902A created: 2000-06-07 expires: never sbb 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sbb 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) <[email protected]> (2) Chloe (Freie Autorin) <[email protected]>Die Information ist ähnlich der Auflistung für die Komponente des öffentlichen Schlüssels. Das Schlüsselwort sec identifiziert den geheimen Hauptschlüssel und das Schlüsselwort ssb identifiziert die geheimen Subkeys. Die Benutzer-IDs vom öffentlichen Schlüssel werden der Bequemlichkeit halber auch aufgelistet.
Wenn Sie Ihren öffentlichen Schlüssel weitergeben, so geben Sie damit die öffentlichen Komponenten Ihres Hauptschlüssels und Ihrer Subkeys ebenso wie Ihre Benutzer-IDs weiter. Wenn Sie diese Informationen jedoch ungeschützt weitergeben, so besteht ein Sicherheitsrisiko, da es für einen potentiellen Angreifer möglich ist, den Schlüssel zu verfälschen. Der öffentliche Schlüssel kann durch Hinzufügen oder Ersetzen von Schlüsseln oder von Benutzer-IDs modifiziert werden. Der Angreifer könnte beispielsweise durch Verfälschen der E-Mail-Adresse einer Benutzer-ID die E-Mail an sich selbst umleiten. Durch Veränderung der öffentlichen Schlüssel wäre der Angreifer auch in der Lage, die zu ihm umgeleiteten Nachrichten zu entschlüsseln.
Die Benutzung digitaler Signaturen ist die Lösung für dieses Problem. Indem man den öffentlichen Schlüssel sowie die Benutzer-IDs mit seinem geheimen Schlüssel unterzeichnet, lassen sich Verfälschungen daran leicht feststellen. Dieser Vorgang wird Eigenbeglaubigung genannt; ein öffentlicher Schlüssel, der eigenbeglaubigte Benutzer-IDs enthält, wird Zertifikat genannt.
Ein Beispiel: Chloe hat zwei Benutzer-IDs und drei untergeordnete öffentliche Schlüssel bzw. Subkeys. Die Unterschriften auf den Benutzer-IDs können mit dem Befehl check im Schlüsseleditior geprüft werden.
chloe$ gpg --edit-key chloe geheimer Schlüssel ist vorhanden. pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/C0A27DBE created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) <[email protected]> (2) Chloe (Freie Autorin) <[email protected]> Befehl> check uid Chloe (Journalistin) <[email protected]> sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) <[email protected]> sig! 1B087D04 2000-06-07 [Eigenbeglaubigung]Wie erwartet, wird für jede Unterschrift der primäre Schlüssel mit der Schlüssel-ID 0x26B6AAE1 genommen. Die Eigenbeglaubigungen auf den Subkeys sind in dem öffentlichen Schlüssel enthalten, doch werden sie vom Schlüsseleditor nicht gezeigt.
Zu Ihrem ursprünglichen Schlüsselpaar können Sie später sowohl neue Subkeys als auch neue Benutzer-IDs hinzufügen. Eine neue Benutzer-ID wird durch Verwendung des Befehls adduid erzeugt. Dabei werden Sie wieder nach Ihrem wirklichem Namen, E-Mail-Adresse und einer optionalen Bemerkung gefragt. Ein Subkey wird durch Verwendung des Befehls addkey hinzugefügt und kann von beliebigem Typ sein. Das ist so ähnlich, wie Sie es vom Erzeugen Ihres anfänglichen Schlüsselpaares kennen. Wenn Sie einen neuen Subkey oder eine neue Benutzer-ID erzeugen, so werden diese mit Ihrem geheimen Schlüssel eigenbeglaubigt; deshalb müssen Sie auch Ihr Mantra eingeben, wenn der Schlüssel erzeugt wird.
Zusätzliche Benutzer-IDs sind nützlich, wenn Sie für verschiedene Zwecke verschiedene IDs benötigen. So wollen Sie vielleicht eine Benutzer-ID für Ihre Arbeit, eine für Ihre politische Tätigkeit und eine weitere für private Korrespondenz haben. Ihre Mitarbeiter und Geschäftspartner, Politische Mitstreiter und Freunde werden Sie dann jeweils unter einer anderen ID kennen.
Zusätzliche Subkeys sind ebenfalls nützlich. Die zu Ihrem primären öffentlichen Schlüssel gehörigen Benutzer-IDs werden von den Leuten, mit denen Sie kommunizieren, authentisiert, deshalb erfordert eine Änderung des primären Schlüssels eine nochmalige Bestätigung. Wenn Sie mit vielen Leuten kommunizieren, kann dies schwierig und zeitaufwendig sein. Andererseits ist es gut, von Zeit zu Zeit die Subkeys für die Verschlüsselung zu ändern. Wenn ein Schlüssel kompromittiert wurde, ist die Sicherheit aller mit diesem Schlüssel verschlüsselten Daten gefährdet. Durch das Ändern der Schlüssel erreichen Sie jedoch, daß in der Zukunft zu verschlüsselnde Daten nicht auch noch gefährdet werden.
Subkeys und Benutzer-IDs können auch gelöscht werden. Dazu müssen Sie diese zunächst im Schlüsseleditor auswählen, indem Sie die Befehle key bzw. uid benutzen. So wählt beispielsweise der Befehl key 2 den zweiten Subkey aus; ein nochmaliger Aufruf des Befehls key 2 macht diese Auswahl wieder rückgängig. Wird key ohne Argument aufgerufen, wird die komplette Auswahl an Subkeys wieder aufgehoben. Das gleiche gilt für den Befehl uid. Wenn Sie die zu löschenden Benutzer-IDs ausgewählt haben, werden diese mit dem Befehl deluid aus Ihrem Schlüssel entfernt. Ebenso löscht der Befehl delkey alle ausgewählten Subkeys aus Ihren öffentlichen und geheimen Schlüsseln.
Für die lokale Schlüsselverwaltung ist das Löschen von Schlüssel-Komponenten ein geeignetes Mittel, um die öffentlichen Schlüssel anderer von unnötigem Ballast frei zu halten. Hingegen sollten Sie normalerweise keine Benutzer-IDs und Subkeys von Ihrem eigenen Schlüssel entfernen, da Sie so die Weiterverbreitung dieses Schlüssels verkomplizieren. Wenn ein anderer GnuPG-Benutzer Ihren aktuellen öffentlichen Schlüssel importiert, wird dieser standardmäßig mit dessen alter Kopie Ihres öffentlichen Schlüssels zusammengeführt. Dadurch werden effektiv alle Komponenten wieder hergestellt, die Sie gelöscht haben. Um den Schlüssel wirklich zu aktualisieren, müßte der Benutzer zuerst die alte Version Ihres Schlüssels löschen und dann die neue Version importieren. Dies bringt eine zusätzliche Belastung für Ihre Kommunikationspartner mit sich. Es ist daher auch keine gute Idee, Ihren aktualisierten Schlüssel zu einem Key-Server zu schicken. Zum Aktualisieren Ihres eigenen Schlüssels ist es folglich besser, die jeweiligen Schlüsselkomponenten zu widerrufen, statt sie zu löschen.
Um einen Subkey zu widerrufen, wählen Sie ihn im Schlüsseleditor aus, dann können Sie ihn mit dem Befehl revkey widerrufen. Der Schlüssel wird dadurch widerrufen, daß man dem Schlüssel eine Widerruf-Unterschrift hinzufügt. Anders als bei der Kommandozeilen-Option --gen-revoke tritt der Widerruf sofort in Kraft.
Befehl> key 2 pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub* 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) <[email protected]> (2) Chloe (Freie Autorin) <[email protected]> Befehl> revkey Möchten Sie diesen Schlüssel wirklich wiederrufen? j Sie benötigen ein Mantra, um den geheimen Schlüssel zu entsperren. Benutzer: "Chloe (Journalistin) <[email protected]>" 1024-Bit DSA Schlüssel, ID 1B087D04, erzeugt 2000-06-07 pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u sub 2048g/6A3E902A created: 2000-06-07 expires: never sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07 rev! subkey has been revoked: 2000-06-07 sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07 (1) Chloe (Journalistin) <[email protected]> (2) Chloe (Freie Autorin) <[email protected]>
Beim Widerrufen einer Benutzer-ID wird anders verfahren. Durch Unterschriften auf einer Benutzer-ID wird bestätigt, daß der Eigentümer des Schlüssels tatsächlich identisch mit der in der Benutzer-ID genannten Person ist. In der Theorie beschreibt eine Benutzer-ID eine Person für immer, da diese Person sich nie ändert. In der Praxis können sich jedoch Elemente der Benutzer-ID, so z.B. die E-Mail-Adresse oder eine Bemerkung, mit der Zeit verändern und so die Benutzer-ID unbrauchbar machen.
Die Spezifikation von OpenPGP unterstützt den Widerruf einer Benutzer-ID nicht. Man kann sich aber dadurch helfen, daß man seine Eigenbeglaubigung für die entsprechende Benutzer-ID widerruft. Aus den zuvor beschriebenen Sicherheitsgründen werden die Korrespondenzpartner keiner Benutzer-ID ohne gültige Eigenbeglaubigung trauen, GnuPG lehnt den Import eines solchen Schlüssels sogar gänzlich ab.
Eine Unterschrift wird unter Verwendung des Befehls revsig. widerrufen. Da Sie eine beliebige Zahl von Benutzer-IDs unterschrieben haben können, verlangt der Schlüsseleditor von Ihnen für jede Unterschrift eine Entscheidung, ob sie widerrufen werden soll oder nicht.
Befehl> revsig
Befehl> revsig
Sie haben folgende User-IDs beglaubigt:
Chloe (Journalistin) <[email protected]>
beglaubigt durch 1B087D04 um 2000-06-07
beglaubigt durch 1B087D04 um 2000-06-07
User-ID: ``Chloe (Journalistin) <[email protected]>''
unterschrieben mit Ihrem Schlüssel 1B087D04 um 2000-06-07
Ein Widerrufszertifikat für diese Unterschrift erzeugen (j/N)n
User-ID: ``Chloe (Freie Autorin) <[email protected]>''
unterschrieben mit Ihrem Schlüssel 1B087D04 um 2000-06-07
Ein Widerrufszertifikat für diese Unterschrift erzeugen (j/N)j
Es werden nun folgende Beglaubigungen entfernt:
Chloe (Freie Autorin) <[email protected]>
beglaubiigt durch 1B087D04 um 2000-06-07
Wirklich ein Unterschrift-Widerrufszertifikat erzeugen? (j/N) j
Sie benötigen ein Mantra, um den geheimen Schlüssel zu entsperren.
Benutzer: ``Chloe (Journalistin) <[email protected]>''
1024-Bit DSA Schlüssel, ID 1B087D04, erzeugt 2000-06-07
pub 1024D/1B087D04 created: 2000-06-07 expires: never trust: -/u
sub 2048g/6A3E902A created: 2000-06-07 expires: never
sub 1792G/7D5D4DAE created: 2000-06-07 expires: 2002-06-07
rev! subkey has been revoked: 2000-06-07
sub 960D/6E82436B created: 2000-06-07 expires: 2002-06-07
(1) Chloe (Journalistin) <[email protected]>
(2) Chloe (Freie Autorin) <[email protected]>
Eine widerrufene Benutzer-ID wird durch die Widerrufs-Signatur auf der Benutzer-ID angezeigt, wenn die Unterschriften auf den Benutzer-IDs des Schlüssels aufgelistet werden.
Befehl check uid Chloe (Journalistin) <[email protected]> sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) <[email protected]> rev! 1B087D04 2000-06-07 [Widerruf] sig! 1B087D04 2000-06-07 [Eigenbeglaubigung]
Ein Widerruf sowohl der Subkeys als auch der Eigenbeglaubigung auf Benutzer-IDs fügt dem Schlüssel eine Widerrufs-Signatur hinzu. Da also nur etwas hinzugefügt und nichts gelöscht wird, ist ein Widerruf für andere stets sichtbar, wenn Ihr aktueller öffentlicher Schlüssel weitergegeben und mit anderen älteren Kopien davon zusammengeführt wird. Der Widerruf garantiert deshalb, daß jeder die aktuelle Kopie Ihres öffentlichen Schlüssels haben kann.
Das Verfallsdatum eines Schlüssels kann mit dem Befehl expire im Schlüsseleditor aktualisiert werden. Wenn kein Schlüssel ausgewählt ist, wird das Verfallsdatum des primären Schlüssels aktualisiert, ansonsten das des jeweils ausgewählten Subkeys.
Das Verfallsdatum eines Schlüssels ist mit der Eigenbeglaubigung des Schlüssels verbunden. Es wird dadurch aktualisiert, daß man die alte Eigenbeglaubigung löscht und eine neue hinzufügt. Da die Korrespondenzpartner die alte Eigenbeglaubigung noch nicht gelöscht haben, werden sie eine zusätzliche Eigenbeglaubigung auf dem Schlüssel sehen, wenn sie ihre Kopie Ihres Schlüssels aktualisieren. Die jüngste Eigenbeglaubigung hat jedoch jeweils Vorrang, und so werden alle Korrespondenzpartner unzweideutig die Verfallsdaten Ihrer Schlüssel kennen.