Web of Trust
Achtung!
Dieser Artikel wird aktuell in Baustelle/GnuPG/Web of Trust überarbeitet. Daher kann es sein, dass diese Seite hier veraltete oder nicht (mehr) zutreffende Informationen enthält. Vergleiche beide Versionen und wende dich im Zweifelsfall mit deinem konkreten Anliegen an das Support-Forum. Änderungen am Artikel bitte nur in Baustelle/GnuPG/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 (Schlüssel-Server).
Mehrere Keyserver können sich auch zu einem Netzwerk zusammenschließen und synchronisieren sich dann gegenseitig. Mögliche Keyserver sind beispielsweise:
hkp://keyserver.ubuntu.com:11371 (voreingestellt in Seahorse bei Ubuntu)
https://keys.openpgp.org:443 (voreingestellt in gpg bei Ubuntu)
pgp.mit.edu
keys.gnupg.net (Dies war früher ein Alias für das nicht mehr verfügbare Netzwerk der SKS-Keyserver. Der DNS-Name wird jetzt auf einen moderneren Server umgeleitet.)
pgp.surfnet.nl
ldap://keyserver.pgp.com (voreingestellt in Seahorse bei Ubuntu)
Die Keyserver des SKS-Pools sind seit April 2021 nicht mehr erreichbar: Hintergründe
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 Zertifikat für den Widerruf 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-Mail-Adresse 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. Fehlt die Option, verwendet gpg bei Ubuntu als Voreinstellung den Server https://keys.openpgp.org/ 🇬🇧. Die Verbindung wird bei diesem voreingestellten Server über TCP-Port 443 aufgebaut, also derselbe Port wie bei HTTPS-Verbindungen im Webbrowser, und sollte daher bei jeder Firewall funktionieren. Das erforderliche CA-Zertifikat für die HTTPS-Verbindung ist fest in GnuPG integriert.
Die GUI Seahorse verwendet andere Keyserver als gpg.
In der Regel sollte der voreingestellte Schlüssel-Server immer funktionieren. Da sich die meisten Keyserver untereinander synchronisieren, kann man die Angabe eines bestimmten Keyservers erst mal weglassen. Wer dennoch permanent einen anderen Schlüssel-Server verwenden möchte, trägt diesen in die Datei ~/.gnupg/dirmngr.conf ein (Beispiel-Server siehe oben). Bei einer Verbindung über das HKP-Protokoll wird TCP-Port 11371 verwendet, welcher ggf. auf einer dazwischen liegenden Firewall freigeschaltet werden muss. Bei HTTPS-Verbindungen muss ein gültiges CA-Zertifikat lokal vorhanden sein.
keyserver hkp://<SERVERNAME> keyserver https://<SERVERNAME> keyserver ...
Schlüssel suchen¶
Man kann auf einem Keyserver nach einem fremden öffentlichen Schlüssel suchen. Einige, nicht alle Keyserver verfügen dafür über ein Webinterface, man kann aber auch die GUI Seahorse verwenden oder direkt mit gpg auf der Kommandozeile suchen
gpg --search-keys SUCHBEGRIFF gpg --keyserver keyserver.ubuntu.com --search-keys SUCHBEGRIFF
Der erste Befehl sucht auf dem voreingestellten, der zweite auf dem explizit angegebenen Keyserver. Wenn der erste Befehl einen sicher existierenden Schlüssel nicht findet, ist möglicherweise noch der SKS-Pool voreingestellt und man sollte dies ändern.
Als SUCHBEGRIFF kann man z.B."<Vorname Nachname>" (Leer- und andere Sonderzeichen quotieren!), die E-Mail-Adresse der Gegenstelle oder den Fingerprint des gesuchten Schlüssels verwenden, wobei nicht jeder Keyserver alle genannten Möglichkeiten unterstützt. (Es kann bei vielen Treffern ein wenig dauern, bis die Schlüssel nach dem Senden angezeigt werden.)
Schlüssel abrufen¶
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 widerrufen, 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.
Schlüssel veröffentlichen¶
Es wird immer nur der öffentliche Schlüssel hochgeladen.
Ausbaufähige Anleitung
Dieser Anleitung fehlen noch einige Informationen. Wenn Du etwas verbessern kannst, dann editiere den Beitrag, um die Qualität des Wikis noch weiter zu verbessern.
Anmerkung: Details zum neuen Veröffentlichungsprozedere
Das Hochladen eines Schlüssels war früher ganz einfach und unsicher.
gpg --send-key <Eigene_Key_Id>
Nach Attacken auf Keyserver wurde das Verfahren geändert. Der vorstehende Befehl sollte immer nur in Kombination mit einem konkret angegebenen Keyserver benutzt werden, der zu veröffentliche Schlüssel muss mit sich selbst signiert sein (self-sig) und man muss den Betreiber des Keyervers zusätzlich per signierter E-Mail kontaktieren.
Weitere Schlüssel-Server¶
Neben dem bei Ubuntu voreingestellten Keyserver gibt es zwei weitere bekannte Schlüssel-Server. Wer seinen öffentlichen Schlüssel hier hochlädt, muss seine Benutzer-IDs jeweils mit einem Verifikations-Link bestätigen, der per E-Mail an die in der Benutzer-ID angegebene Adresse zugeschickt wird. Man kann also nicht jemandes anderen Schlüssel hochladen. Darüber hinaus kann man hochgeladene Schlüssel auch wieder löschen.
keys.openpgp.org 🇬🇧 soll in Zukunft bei OpenKeychain 🇬🇧 voreingestellt sein. Dieser Server verteilt keine Beglaubigungen von Dritten, unterstützt also nicht das Web of Trust.
Mailvelope Schlüssel-Server 🇬🇧 ist der voreingestellte Server für das Browser-Plugin Mailvelope 🇩🇪.
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.
Ausbaufähige Anleitung
Dieser Anleitung fehlen noch einige Informationen. Wenn Du etwas verbessern kannst, dann editiere den Beitrag, um die Qualität des Wikis noch weiter zu verbessern.
Anmerkung: Die Veröffentlichung von fremden Signaturen auf Keyservern ist fraglich, der folgende Text bedarf einer Klarstellung.
Jetzt muss man entweder den Key an einen Keyserver schicken, oder 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 hier beispielhaft verwendeten E-Mail Programms mutt kann man natürlich ein anderes Programm einsetzen, oder den Schlüssel auch einfach ins Terminal ausgeben lassen und dann per Kopieren-und-Einfügen ins GUI-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) Auswahlmenü:
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?
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).
Problembehebung¶
Generelle Verbindungsprobleme zum Keyserver¶
In neueren GnuPG-Versionen (ab Version 2.1) übernimmt die Kommunikation zu den Keyservern ein gesonderter Prozess (dirmngr). Der Prozess wird für jeden Benutzer einzeln gestartet, und führt DNS-Namensauflösungen durch, cached aktive Verbindungen und merkt sich Keyserver die nicht erreichbar sind. Um sicherzustellen dass dirmngr nicht auf veraltete Informationen zurückgreift (weil z.B. zwischenzeitlich ein VPN-Tunnel gestartet wurde), sollte im Zweifelsfall der Prozess des jeweiligen Benutzers beendet werden [2]:
pkill -u $(id -u) dirmngr
Beim nächsten Aufruf von "gpg" wird dirmngr dann bei Bedarf automatisch neu gestartet.
Um Kommunikationsprobleme mit Keyservern näher zu untersuchen, kann dirmngr auch eine Log-Datei schreiben. Dazu müssen folgende Zeilen in die Konfigurationsdatei ~/.gnupg/dirmngr.conf eingetragen [3] und anschließend dirmngr neu gestartet werden (s.o.).
log-file /tmp/dirmngr.log debug-level advanced
Ein weiteres Problem beim Zugriff auf Keyserver kann die Verwendung von IPv6 sein, obwohl dieses nicht konfiguriert ist. Eine typische Fehlermeldung sieht wie folgt aus:
gpg: error searching keyserver: Cannot assign requested address gpg: keyserver search failed: Cannot assign requested address
In diesem Fall ist es hilfreich über folgenden Eintrag in der Konfigurationsdatei ~/.gnupg/dirmngr.conf IPv6 abzuschalten [3] (sofern dieses nicht verwendet wird):
disable-ipv6
Anschließend muss dirmngr neu gestartet werden (s.o.).
Langsame Verbindung zum Keyserver¶
Per geschickter DNS-Auflösung wird zwar versucht, die Last auf möglichst viele verschiedene physische Server zu verteilen, die auch geographisch nahe zum Benutzer gelegen sind. Manchmal kann es allerdings trotzdem vorkommen, dass der von dirmngr ausgewählte Keyserver überlastet ist und es zu einer Zeitüberschreitung kommt. In diesem Fall kann es helfen, explizit einen anderen Keyserver über den Kommandozeilenparameter "--keyserver <KEYSERVER>" auszuwählen (Liste möglicher Keyserver s. Kapitel Keyserver).
Ebenso kann bei langsamen Verbindungen zum Keyserver das Deaktivieren von IPv6 Abhilfe schaffen (s.o.).
Links¶
https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html 🇬🇧 – Maßnahmen nach Attacken gegen Keyserver