Web of Trust
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Ein Kryptografie-System mit öffentlichen und privaten Schlüsseln [2] ist ja gut und schön und ein bedeutender Fortschritt gegenüber symmetrischen Systemen, bei denen man Schlüssel nur im Geheimen austauschen kann. Ein Problem bleibt aber noch: Wie kann man sicher sein, wirklich den Original-Schlüssel des Kommunikationspartners zu erhalten, ohne dass er unterwegs von einem Angreifer durch einen kompromittierten ausgetauscht worden ist? Insbesondere bei der Benutzung öffentlicher Schlüsselserver ("keyserver"), bei denen jedermann seinen eigenen Schlüssel veröffentlichen kann, wäre ein Identitätsdiebstahl sehr einfach realisierbar.
Schlüssel immer nur persönlich zu übergeben gestaltet sich aber leicht unpraktisch in unserer heutigen Zeit, in der man häufig E-Mails mit Leuten austauscht, die am anderen Ende der Welt wohnen, und denen man im realen Leben vielleicht niemals begegnen wird.
Die bekannte SSL-Verschlüsselung benutzt hierfür z.B. ein streng hierarchisches System, in dem einige als vertrauenswürdig angesehene, meist kommerzielle, Zertifizierungsinstanzen mit ihren Schlüsseln die Schlüssel ihrer Kunden nach Prüfung der Identität digital signieren. Die Schlüssel dieser Organisationen werden bei den gängigen Webbrowsern, Betriebssystemen, etc. mitgeliefert.
Hinweis:
Mit der Gründung und dem späteren Verkauf einer solchen Zertifizierungsfirma hat ein gewisser Mark Shuttleworth in den 90er Jahren des vorigen Jahrhunderts eine Menge Geld verdient, das er heute u.a. zur Finanzierung von Ubuntu und der dahinter stehenden Firma Canonical nutzt.
Das OpenPGP-System, das auch hinter GnuPG steckt, benutzt einen anderen Ansatz, das Web of Trust (dt: Netz des Vertrauens). Hier sind es keine zentralen Instanzen, die die Signierarbeit übernehmen, sondern jeder Benutzer X kann den Schlüssel eines jeden Benutzers Y signieren und ihm damit Glaubwürdigkeit verleihen, nachdem er sich von dessen Identität überzeugt hat. Natürlich stellt sich die Frage, wie vertrauenswürdig denn nun Benutzer X selber ist. Die Antwort im Web of Trust lautet: Das bestimmt jeder selbst. Jeder Benutzer legt in seinem Schlüsselbund fest, ob er seinen Kommunikationspartnern z.B. "bedingungslos" oder "teilweise" vertraut. Wenn man nun einen Schlüssel erhält, über dessen Authentizität man sich nicht sicher ist, so vertraut ihm das GnuPG-System, sofern er von mindestens einem "bedingungslos" oder mehreren "teilweise" vertrauenswürdigen Bekannten signiert wurde.
Dieser Artikel behandelt die Benutzung öffentlicher Schlüsselserver (Keyserver), über die der Schlüsselaustausch läuft, den Widerruf kompromittierter Schlüssel und andere Aspekte, die man wissen muss, um am Web of Trust teilzunehmen.
Nachdem man einen GPG-Schlüssel erstellt und auf einen öffentlichen Schlüsselserver hochgeladen hat, kann man die Schlüssel-ID in den Profilinformationen bei ubuntuusers.de eintragen. Die ID des Schlüssels wird dann auf dem Profil angezeigt.
Widerruf von Schlüsseln¶
Ein öffentlicher Schlüssel kann widerrufen werden, wenn der Verdacht besteht, dass der entsprechende private Schlüssel und vielleicht sogar der Passwortsatz in falsche Hände gelangt sein könnte. Der so entwertete Schlüssel lässt sich dann nicht mehr dazu verwenden, weitere Daten zu verschlüsseln. Außerdem können mit ihm keine Signaturen mehr kontrolliert werden, da schließlich angenommen werden muss, dass die Signatur eventuell von einer nicht autorisierten Person durchgeführt wurde. Es ist wichtig zu verstehen, dass das Signieren oder Entschlüsseln mit dem gestohlenen privaten Schlüssel weiterhin möglich ist, da der Dieb den Widerruf ja nicht in seine Datenbank aufnehmen wird. Der Widerruf muss also stattdessen an alle Kommunikationspartner verteilt werden, was z.B. wie die Schlüssel selber ebenfalls über Keyserver (s.u.) stattfinden kann.
Zum Widerrufen ist ein Widerrufzertifikat erforderlich. Zum Erstellen dieses Zertifikats ist der private Schlüssel und der Passwortsatz erforderlich. Daher sollte man das Zertifikat direkt nach der Schlüsselerzeugung erstellen, da später einmal der Passwortsatz vielleicht in Vergessenheit geraten ist oder aber der private Schlüssel nicht mehr existiert oder defekt ist. Das erzeugte Widerrufzertifikat sollte ähnlich sorgfältig behandelt werden wie der private Schlüssel. Empfehlenswert ist auch die zusätzlich vom privaten Schlüssel getrennte Aufbewahrung - am besten auch als Text-Ausdruck auf Papier.
Erstellen eines Widerrufszertifikates¶
Das Zertifikat wird mit folgender Anweisung erzeugt [1]:
gpg --gen-revoke <Kennung>
Anstelle von Kennung kann entweder die KeyID (z. B. BBF427A7) oder aber der Benutzername des Keys (z. B. Mario) angegeben werden. Der erste passende Key wird herangezogen. Die eigentliche Prozedur beginnt aber erst nach einer Sicherheitsabfrage, bei der die entsprechenden Schlüsseldaten nochmals genau überprüft werden sollten:
sec 1024D/BBF427A7 2005-06-18 Mario Nachname <mario _at_ lixnet.de> Ein Widerrufszertifikat für diesen Schlüssel erzeugen? (y/N)
Jetzt wird folgende Auswahl angeboten:
Grund für den Widerruf: 0 = Kein Grund angegeben 1 = Hinweis: Dieser Schlüssel ist nicht mehr sicher 2 = Schlüssel ist überholt 3 = Schlüssel wird nicht mehr benutzt Q = Abbruch (Wahrscheinlich möchten Sie hier 1 auswählen) Ihre Auswahl?
Dies dient nur zur Information und hat auf das Zertifikat sonst keinen Einfluss. Sinnvollerweise wählt man hier 1 , wenn man einen vorsorglichen Widerruf erzeugt. Wenn irgendwann mal 2 oder 3 zutreffen sollten, kann man immer noch ein neues Widerrufzertifikat erzeugen.
Nun kann noch eine eigens verfasste Information angegeben werden. Die Eingabe hier wird durch eine leere Zeile beendet. Abschließend wird man zur Eingabe des Passwortsatzes aufgefordert. Das Zertifikat wird dann auf der Konsole ausgegeben:
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: A revocation certificate should follow iEkEIBECAAkFAkZMUB8CHQAACgkQ543ylotjOHgprACgzTk24kFEFbxmeqt9UThB /yqmZBIAnjO9TqC1YQqS25c84hsvkzslUisH =99Xw -----END PGP PUBLIC KEY BLOCK-----
Dieser Abschnitt stellt das Zertifikat dar und sollte als Datei gesichert werden. Man kann diese Ausgabe auch gleich bei der Erzeugung in eine Datei umleiten:
gpg --output Widerruf_<Kennung>.asc --gen-revoke <Kennung>
Im folgenden Abschnitt wird nun die Anwendung dieses Zertifikates beschrieben.
Öffentlichen Schlüssel widerrufen¶
Mit dem eben erzeugten Zertifikat kann der Schlüssel bei Bedarf widerrufen werden. Dazu muss dieses Zertifikat in den Schlüsselring importiert werden. Angenommen, das Zertifikat ist in der Textdatei Widerruf_BBF427A7.asc gespeichert, so müsste folgendes Kommando ausgeführt werden:
gpg --import Widerruf_BBF427A7.asc
Es erfolgt keine Rückfrage. Der öffentliche Schlüssel wird sofort widerrufen.
Achtung!
Nach dieser Aktion ist der öffentliche Schlüssel erst einmal nur im lokalen Schlüsselring gesperrt. Dieser gesperrte Schlüssel muss nun unbedingt an alle Kommunikationspartner übergeben werden. Auch sollte er (erneut) auf einen Keyserver hochgeladen werden. Man sollte dies auch für Schlüssel in Betracht ziehen, die bisher nicht über Keyserver verbreitet wurden, man aber davon ausgehen muss, das diese doch im Umlauf sind.
Es ist wichtig zu verstehen, dass das Signieren oder Entschlüsseln mit dem gestohlenen privaten Schlüssel weiterhin möglich ist.
Das Verschlüsseln bzw. Prüfen einer Signatur ist mit dem bisherigen öffentlichen Schlüssel auch weiterhin möglich. Daher ist es so wichtig, Kommunikationspartner zu informieren. Ob diese dann den aktuellen (jetzt widerrufenen) Schlüssel importieren, oder aber den bisherigen Schlüssel einfach löschen, ist gleichbedeutend. Der Besitz des widerrufenen Schlüssels verhindert allerdings zusätzlich das versehentliche Wiedereinfügen einer noch funktionierenden Version desselben.
Auch ist zu beachten, dass eine Sperrung nicht mehr ohne weiteres rückgängig gemacht werden kann.
Keyserver¶
Man hat also einen Schlüssel, mit dem man Daten signieren kann und mit dem man für sich selber verschlüsselte Daten entschlüsseln kann. Damit aber andere Nutzer auch die eigene Signaturen überprüfen bzw. Daten verschlüsseln können, brauchen sie den öffentlichen Schlüssel. Diesen kann man seinen Freunden und Bekannten per E-Mail zuschicken oder besser noch auf spezielle Server hochladen, von denen aus sie jeder herunterladen kann. Diese Server heißen Keyserver.
Mögliche Keyserver sind: subkeys.pgp.net, wwwkeys.eu.pgp.net, pgp.mit.edu. Letztendlich ist es jedoch egal an welchen Keyserver man seine Schlüssel schickt, da sie stets miteinander in Kontakt bleiben und sich gegenseitig synchronisieren.
Achtung!
Bitte mit dem Hochladen von Schlüsseln nicht voreilig sein. Ein einmal hochgeladener Schlüssel kann nicht mehr entfernt werden. Er könnte allenfalls als abgelaufen markiert werden, was aber zum Beispiel nicht mehr möglich ist, wenn einmal das Passwort in Vergessenheit geraten ist und zuvor kein Widerrufzertifikat erstellt wurde. Für andere ist es dann nicht mehr so einfach zu erkennen, welcher Schlüssel denn nun gerade aktuell ist. Der Schlüssel sollte also erst hochgeladen werden, wenn man mit GnuPG vertraut ist.
Achtung!
Es besteht die Gefahr, dass man an die angegebene e-Mailadresse Spam-Mails bekommt, da die Keyserver nun einmal öffentlich sind.
Hinweis:
Über die Option --keyserver <domain.name> kann man bei jedem der folgenden Befehle einen bevorzugten Schlüsselserver angeben. Die Voreinstellung funktioniert aber normalerweise, so dass man in den meisten Fällen darauf verzichten kann.
Einen bevorzugten Keyserver kann man in der Datei ~/.gnupg/gpg.conf angeben (Server siehe oben):
keyserver SERVERNAME
Das Hochladen eines Schlüssels ist ganz einfach. Dabei wird immer nur der öffentliche Schlüssel hochgeladen.
gpg --send-key <Eigene_Key_Id>
Ebenso das Suchen nach einem fremden öffentlichen Schlüssel. (Es kann unter Umständen ein wenig dauern, bis der Schlüssel nach dem Senden angezeigt wird)
gpg --search-keys "<Vorname Nachname>"
Einen fremden Schlüssel lädt man mit folgendem Befehl herunter
gpg --recv-keys <Key_Id>
Schlüssel verändern sich mit der Zeit. Es kommen neue Signaturen hinzu (siehe nächster Abschnitt), sie werden widerufen, etc. Um einen Schlüssel im eigenen Schlüsselring auf den neuesten Stand zu bringen, nutzt man folgendes Kommando:
gpg --refresh-keys <Key_Id>
Wird keine Key_Id angegeben, so wird der gesamte Schlüsselbund aktualisiert. Es folgt eine Ausgabe, welche Schlüssel aktualisiert wurden, und bei welchen keine neuere Version verfügbar war.
Signaturen von Schlüsseln¶
Signaturen dienen prinzipiell der Authentifizierung. Man signiert Daten (eine E-Mail, irgendwelche Dokumente, etc), und andere können zweifelsfrei überprüfen, ob die Signatur zu diesen Daten passt oder nicht (d.h. ob sie von Dritten verändert oder gefälscht wurden). Aber wer garantiert nun, dass der Schlüssel auch tatsächlich zu der Person gehört, deren Name und E-Mail-Adresse im Schlüssel stehen?
Dies geschieht in der Regel durch das Web of trust. Verschiedene Personen vergewissern sich, dass andere auch tatsächlich ihren richtigen Namen in den Schlüssel geschrieben haben, und signieren ihn dann - ähnlich wie wenn sie eine E-Mail signieren würden, nur ist es jetzt ein anderer Schlüssel. Es entsteht ein ganzes Netz von Personen, die sich gegenseitig beglaubigen. Dies kann im Freundeskreis geschehen, oder auch auf Key-Signing-Parties. Hier treffen sich die Inhaber von Schlüsseln, tauschen ihre Personalien und die Fingerabdrücke (engl. Fingerprint) ihrer Schlüssel aus und signieren sich anschließend gegenseitig die Schlüssel.
Je mehr Signaturen ein Schlüssel hat, desto sicherer kann man sein, dass er tatsächlich zu der angegebenen Person gehört. Die Signaturen eines Schlüssels können folgendermaßen angezeigt werden:
gpg --list-sigs <Key_Id>
Achtung!
Bitte signiere einen Schlüssel nur dann, wenn du dich von der Identität des Inhabers überzeugt hast. Im Klartext heißt das: Du stehst diesem Menschen gegenüber, er zeigt dir seinen Ausweis, du prüfst, dass das Foto auf dem Ausweis so ähnlich aussieht wie der Mensch vor dir 
und dass die Namen im Ausweis und auf dem Key übereinstimmen, und er bejaht die Frage "ist der Schlüssel mit dem Fingerprint *bla* deiner".
Das Signieren ungeprüfter Schlüssel fremder Leute, die man nie gesehen oder mit denen man höchstens ein paar Mails ausgetauscht hat, untergräbt deine Glaubwürdigkeit und sollte daher unterbleiben!
Signieren von fremden Schlüsseln¶
Das geht so:
gpg --edit-key <ID oder Name>
pub 1024D/AABBCCDD created: 2005-11-15 expires: 2005-11-16 usage: CS sub 2048g/11223344 created: 2005-11-15 expires: 2005-11-16 usage: E [ unknown] (1). Joe Tester <test@beispiel.de>
Hinweis:
Wenn der Schlüssel mehrere Benutzer-IDs (bzw. E-Mail-Adressen) besitzt, kann man durch wiederholtes Angeben der jeweiligen einstelligen Nummer verschiedene IDs anwählen, die man signieren will. Tut man dies nicht, so werden nach einer Sicherheitsabfrage einfach alle IDs dieses Schlüssels signiert.
Wenn man sieht, dass man den korrekten Schlüssel ausgewählt hat, kann man ihn jetzt signieren:
Command> sign
pub 1024D/AABBCCDD created: 2005-11-15 expires: 2005-11-16 usage: CS
Primary key fingerprint: A1C8 EEB5 868E 6576 3349 BFE8 851C 4A45 5E16 EDB5
Joe Tester <test@beispiel.de>
This key is due to expire on 2005-11-16.
Do you want your signature to expire at the same time? (Y/n) y
Are you sure that you want to sign this key with your
key "Der User <ich@example.org>" (ABCDABCD)Hier folgt die Sicherheitsabfrage. Bitte nur dann bejahen, wenn man sicher ist, dass der Fingerprint korrekt ist, die Mailadressen stimmen, etc.
Really sign? (y/N) y You need a passphrase to unlock the secret key for user: "Der User <ich@example.org>" 1024-bit DSA key, ID ABCDABCD, created 1998-11-20
Command> save
Hinweis:
Statt --edit-key und dann sign kann man auch gleich die Option --sign-key verwenden. Eine einzelne Auswahl bestimmter Benutzer-IDs, die man signieren will, ist dabei aber nicht möglich.
Jetzt muss der Key entweder an einen Keyserver geschickt werden ...
gpg --send-key AABBCCDD
... oder, noch besser, man schickt den Key verschlüsselt an die in der UID angegebene Mail-Adresse:
gpg --export AABBCCDD | gpg --encrypt -a --recipient AABBCCDD - | mutt -s "Dein signierter Key" test@beispiel.de
Anstelle des mutt-Befehls kann man den Schlüssel auch einfach ins Terminal ausgeben lassen und dann per Kopieren-und-Einfügen ins Mailprogramm eigener Wahl einfügen.
Der Empfänger kann ihn dann selbst importieren und die neuen Signaturen an den Keyserver schicken:
gpg --decrypt <Datei-mit-Key | gpg --import gpg --send-key AABBCCDD
Der Vorteil dieser Methode ist, dass man damit auch überprüft, ob die Mailadresse stimmt, und dass der Empfänger Mails an ihn auch wirklich entschlüsseln kann.
Vertrauensstufen¶
Das Web of Trust basiert - wie der Name schon sagt - auf Vertrauen. Welches Vertrauen man nun wem entgegenbringt, kann man festlegen, und dieses Vertrauen pflanzt sich dann bis zu einem gewissen Grade durch das Netz fort. Hierbei gibt es zwei unterschiedliche Aspekte zu beachten. Das eine ist das Vertrauen, das man einem bestimmten Benutzer entgegenbringt, nur korrekte Schlüssel zu signieren, und das andere ist das Vertrauen darin, dass ein bestimmter Schlüssel wirklich dem angeblichen Benutzer gehört. Das erste ist ein Wert, den man selbst jedem Schlüssel zuweisen muss, das zweite wird dann aus der Verknüpfung dieser Werte und der digitalen Signaturen abgeleitet. Folgende Vertrauensstufen kann man einzelnen Personen bzw. ihren Schlüsseln zuweisen:
| Beschreibung | Bedeutung |
| unbekannt | Noch keine Angabe gemacht. Unter Umständen fragt GnuPG bei Bedarf nach dem Vertrauen in diesen Kontakt, wenn dessen Signatur benötigt wird. |
| kein Vertrauen | Signaturen von diesem Kontakt werden niemals als gültig anerkannt. |
| "marginales" Vertrauen | Diese Stufe sollte man den meisten Kontakten verpassen, denen man ein grundlegendes Verständnis des Web of Trust zutraut und von denen man nicht annimmt, dass sie betrügen. |
| volles Vertrauen | Diese Stufe sollte man nur Leuten verleihen, die man wirklich gut kennt, auf menschlicher Ebene voll vertraut, und die auch nicht zu einem laxen Umgang bei Sicherheitsprozeduren neigen. |
| ultimatives Vertrauen | Diese Stufe benutzt man üblicherweise nur für sich selbst. |
Wenn man jetzt von irgendwoher (Keyserver, Webseite, E-Mail) einen neuen Schlüssel importiert, aber keine Gelegenheit hat, mit dem Eigner persönlich über den Fingerprint die Authentizität des Schlüssels sicherzustellen, wird auf der Basis der vorhandenen vertrauenswürdigen Schlüssel im Schlüsselbund die Wahrscheinlichkeit dafür bestimmt, dass der Schlüssel wirklich authentisch ist. Standardmäßig sieht es so aus, dass eine einzige Signatur von einer Person mit "vollem Vertrauen" von GnuPG als "Beweis" dafür angesehen wird, dass der Schlüssel echt ist. Dieselbe Vertrauensstufe wird erreicht, wenn die Signaturen von mindestens drei Leuten mit "marginaler Vertrauensstufe" vorliegen. Ist der Schlüssel nur von einem oder zwei "marginal vertrauenswürdigen" Leuten signiert, gilt er als "teilweise vertrauenswürdig", ansonsten als "nicht vertrauenswürdig".
Um die Vertrauensstufe für einen bestimmten Schlüssel neu zu bestimmen, benutzt man wieder das Kommando
gpg --edit-key <Key-ID oder Name>
Die vollständige Beschreibung des Schlüssels wird noch einmal angezeigt, damit man sichergehen kann, auch den gewünschten Schlüssel zu bearbeiten, und dann gibt man folgendes über die Tastatur ein:
Befehl> trust
Es folgen noch einmal die Schlüsselbeschreibung und dann das folgende (ziemlich hässliche, nur teilweise übersetzte) Auswahlmenü:
Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = Weiß nicht so recht oder will es nicht sagen 2 = Nein, ihm vertraue ich NICHT 3 = Ich vertraue ihm ein wenig 4 = I trust fully 5 = Ich habe absolutes Vertrauen m = Zurück zum Hauptmenü Ihre Auswahl?
Wie oben angegeben, sollte man hier in den meisten Fällen die
3 wählen. Danach kann man das Programm mit save oder quit wieder verlassen. (Man kann natürlich das Signieren und die Vertrauensfestlegung nacheinander machen, ohne das Programm zwischendurch verlassen zu müssen.)
Hinweis:
Die Festlegung der Vertrauensstufe alleine bewirkt noch gar nichts, da man in der GnuPG-Logik dann zwar festlegt, dass man der Person vertraut, aber vielleicht wohnt dieser ja in Australien, und man hat keine Möglichkeit festzustellen, ob der GnuPG-Schlüssel wirklich zu dieser Person gehört. Man muss also erstmal selber ein paar Schlüssel signieren (s.o.), um überhaupt ein "Netz" aufbauen zu können. Es spricht allerdings überhaupt nichts dagegen, einem anderen das Vertrauen auszusprechen, dessen Schlüssel man nur über die Schlüssel Dritter verifiziert hat, wenn man der Person an sich vertraut.
Hinweis:
Wenn man aus irgendeinem Grund diese Signaturen nur für sich selber in seinem eigenen Schlüsselbund signieren möchte und diese niemals exportieren und damit anderen helfen möchte, kann man statt sign den Befehl lsign im --edit-keys-Befehl benutzen.
Leider scheint es keine einfache Übersicht über die Vertrauensstufe der einzelnen Schlüssel zu geben, so dass man dafür per --edit-keys einzeln nachsehen muss. Die Wirkung zeigt sich aber bei der Benutzung der einzelnen Schlüssel in den verschiedenen Applikationen, wenn Signaturen als "nicht vertrauenswürdig" gekennzeichnet werden oder beim Absenden verschlüsselter E-Mails ein Warnfenster aufspringt (oder eben nicht).
- Erstellt mit Inyoka
-
2004 – 2017 ubuntuusers.de • Einige Rechte vorbehalten
Lizenz • Kontakt • Datenschutz • Impressum • Serverstatus -
Serverhousing gespendet von
