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 chloe@cyb.org 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) <chloe@cyb.org> (2) Chloe (Freie Autorin) <chloe@tel.net> 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) <chloe@cyb.org> (2) Chloe (Freie Autorin) <chloe@tel.net>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) <chloe@cyb.org> (2) Chloe (Freie Autorin) <chloe@tel.net> Befehl> check uid Chloe (Journalistin) <chloe@cyb.org> sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) <chloe@tel.net> 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) <chloe@cyb.org>
(2) Chloe (Freie Autorin) <chloe@tel.net>
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) <chloe@cyb.org>"
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) <chloe@cyb.org>
(2) Chloe (Freie Autorin) <chloe@tel.net>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) <chloe@cyb.org>
beglaubigt durch 1B087D04 um 2000-06-07
beglaubigt durch 1B087D04 um 2000-06-07
User-ID: ``Chloe (Journalistin) <chloe@cyb.org>''
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) <chloe@tel.net>''
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) <chloe@tel.net>
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) <chloe@cyb.org>''
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) <chloe@cyb.org>
(2) Chloe (Freie Autorin) <chloe@tel.net>
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) <chloe@cyb.org> sig! 1B087D04 2000-06-07 [Eigenbeglaubigung] uid Chloe (Freie Autorin) <chloe@tel.net> 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.