Web of Trust

aus Wikipedia, der freien Enzyklopädie
Dies ist die aktuelle Version dieser Seite, zuletzt bearbeitet am 2. August 2022 um 22:02 Uhr durch imported>Leyo(58286) (klein nach Komma).
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Datei:Web of Trust 2.svg
Schematische Darstellung eines Web of Trust

Netz des Vertrauens bzw. Web of Trust (WOT) ist in der Kryptologie die Idee, die Echtheit von digitalen Schlüsseln durch ein Netz von gegenseitigen Bestätigungen (Signaturen), kombiniert mit dem individuell zugewiesenen Vertrauen in die Bestätigungen der anderen („Owner Trust“), zu sichern. Es stellt eine dezentrale Alternative zum hierarchischen PKI-System dar.

Problemstellung

Die Verschlüsselung mit öffentlichen Schlüsseln bietet (gegenüber der symmetrischen Verschlüsselung) den Vorteil, dass der auszutauschende Schlüssel nicht über einen sicheren Kanal übertragen werden muss, sondern öffentlich ist. Zur Übertragung des Schlüssels kann man sich daher eines Verbunds von Schlüsselservern bedienen, auf die jeder seine öffentlichen Schlüssel hochladen kann und von denen jeder den Schlüssel der Person abrufen kann, mit der er kommunizieren möchte. Dadurch ergibt sich aber ein anderes Problem: Eine Person könnte einen Schlüssel veröffentlichen, mit welchem sie sich als jemand anderes ausgibt. Es muss also eine Möglichkeit zur Verfügung stehen, die Authentizität eines Schlüssels zu prüfen.

Die Lösung für dieses Problem besteht darin, die Echtheit eines öffentlichen Schlüssels von einer vertrauenswürdigen Instanz durch ein digitales Zertifikat bestätigen zu lassen. Bei Public-Key-Infrastrukturen ist dies eine Zertifizierungsstelle; im Web of Trust hingegen übernehmen alle Teilnehmer diese Funktion.

Funktionsprinzip

Alice signiert den Schlüssel von Bob und vertraut Bobs Schlüsselsignaturen
Bob signiert den Schlüssel von Carl
      (Bobs Vertrauen in Carls Schlüsselsignaturen ist weder bekannt noch relevant)
Somit betrachtet Alice den Schlüssel von Carl als gültig.

Es ist wichtig, nicht die beiden Arten von Vertrauen, die hier beteiligt sind, zu verwechseln:

  1. Einerseits vertraut man darauf, dass ein Schlüssel (den man nicht selber signiert hat) gültig (authentisch) ist, also der Besitzer des Schlüssels wirklich die Person (oder Institution) ist, die man dafür hält.
  2. Andererseits vertraut man darauf (oder auch nur teilweise oder gar nicht), dass der Besitzer eines Schlüssels nur sorgfältige Schlüsselsignaturen vornimmt, dass also die mit der Signatur zum Ausdruck gebrachte Behauptung desjenigen, dass ein bestimmter Schlüssel zu einer bestimmten Person gehört, verlässlich ist. Dieses Vertrauen wird „Owner Trust“ genannt.

Diese beiden Vertrauensarten sind voneinander unabhängig:

  1. Man kann sich sicher sein, dass ein bestimmter Schlüssel zu einer bestimmten Person gehört. Diese Überzeugung wird in keiner Weise dadurch erschüttert, dass man die Schlüsselsignaturen dieser Person als wertlos betrachtet.
  2. Man kann den Schlüsselsignaturen einer Person voll vertrauen, ohne über einen als gültig betrachteten Schlüssel dieser Person zu verfügen. (Bis zur Verfügbarkeit eines gültigen Schlüssels sind eventuelle Schlüsselsignaturen der Person allerdings wertlos.)

Implizit besteht noch eine dritte Kategorie von Vertrauen, nämlich das in die Sicherheit des signierenden Schlüssels. Eine Person, deren Zertifikaten man voll vertraut, kann aus gutem Grund auch solche Schlüssel besitzen, die auf Grund der Art ihrer Verwendung wenig sicher sind (entsprechend weniger sind ihre Zertifikate wert). „Owner Trust“ wird pro Schlüssel festgelegt, so dass man durchaus für denselben Schlüsselbesitzer bei mehreren Schlüsseln dieses Vertrauen unterschiedlich festlegen kann.

OpenPGP bietet die Möglichkeit, ein Schlüsselzertifikat mit einem (allerdings unpräzisen) Hinweis zu versehen, wie gründlich die Authentizität des Schlüssels geprüft wurde. Die Nutzer des WoT wissen im Allgemeinen nicht, wie gründlich die Identität des Schlüssels und die des Besitzers und welche Komponenten des Schlüssels überhaupt geprüft wurden. Der Signierende kann den Besitzer persönlich kennen, einen Ausweis (o. Ä.) zur Überprüfung eines Fremden verwendet haben oder nicht einmal das; gerade bei ausländischen Namen kann er auch eine abweichende Schreibweise akzeptiert haben. Die Überprüfung der Schlüsselangaben kann sich auf den Namen beschränken (Namen sind nicht eindeutig); sie kann eine oder alle E-Mail-Adressen und sogar die Kommentare umfassen. Selbst im Fall einer als umfassend bekannten Prüfung ist die Sicherheit der Überprüfung eines Ausweises oder einer E-Mail-Adresse nicht einmal annähernd mit der technischen Sicherheit üblicher Kryptografie vergleichbar. Die Sicherheit des WoT ist also begrenzt, was man zum Teil dadurch ausgleichen kann, dass man mehr Signaturen fordert, um einen Schlüssel als gültig anzusehen, was aber die Nutzbarkeit des WoT entsprechend reduziert. Die Validierung eines Schlüssels kann über beliebig (aber begrenzbar) viele Zwischenschritte erfolgen, allerdings müssen dafür alle beteiligten Schlüssel (bis auf den zu validierenden) einen entsprechenden Owner Trust haben.

Zertifikate beim Web of Trust

Beim Web of Trust besteht ein Zertifikat aus der digitalen Signatur, die eine andere Person, die auch am Web of Trust teilnimmt, auf einen Schlüssel abgibt, nachdem sie sich der Identität des Schlüsselinhabers versichert hat (typischerweise bei einer persönlichen Begegnung).

RFC 2440 (inzwischen ersetzt durch RFC 4880) beschreibt ein Verfahren, wie diese Zertifikate mit dem Schlüssel verbunden und mit einer Wertung versehen werden. Das Zertifikat wird mit dem Schlüssel auf einen weltweiten Verbund von Schlüsselservern hochgeladen und kann so von jedermann abgerufen werden.

Von diesen Signaturen sammelt der Schlüsselinhaber möglichst viele an. Personen, die den Schlüsselinhaber nicht kennen und auch keinen persönlichen Kontakt zu ihm haben, können durch die Zertifikate eine hohe Legitimität der Identität ersehen und darin vertrauen.

Beispiel

In einem Web of Trust funktioniert das so:

  1. Alice erzeugt für sich ein Schlüsselpaar und signiert es. Außerdem schickt sie den öffentlichen Teil an einen Schlüsselserver (key server), damit andere Teilnehmer leichten Zugriff darauf haben.
  2. Bob möchte mit Alice verschlüsselt kommunizieren. Dazu besorgt er sich Alices Schlüssel von einem Schlüsselserver, muss aber noch sicherstellen, dass er wirklich den richtigen Schlüssel bekommen hat: Ein Angreifer könnte sich für Alice ausgeben und einen von ihm erzeugten Schlüssel an den Schlüsselserver schicken. Jeder, der meint, eine Nachricht nur für Alice zu verschlüsseln, würde sie in Wirklichkeit für den Angreifer verschlüsseln.
  3. Bob bittet Alice (z. B. bei einem Telefonanruf oder einem persönlichen Treffen) um den Fingerprint ihres öffentlichen Schlüssels. Diesen vergleicht er mit dem des Schlüssels, den er vom Schlüsselserver erhalten hat.
  4. Stimmen beide Fingerprints überein, kann Bob davon ausgehen, den richtigen Schlüssel erhalten zu haben. Darum signiert er den öffentlichen Schlüssel von Alice (genauer: eine oder mehrere ihrer User-IDs) mit seinem privaten und schickt diese Signatur an den Schlüsselserver.
  5. Möchte jetzt Carl mit Alice verschlüsselt kommunizieren, besorgt er sich genau wie Bob Alices öffentlichen Schlüssel vom Schlüsselserver. Dann stellt er fest, dass Bob Alices Schlüssel bereits überprüft hat. Wenn Carl Bobs Schlüssel schon kennt und er Bob vertraut, dass Bob vor der Signatur fremder Schlüssel eine gründliche Überprüfung durchführt, dann muss er nicht erst Alice treffen und diese Prüfung wiederholen. Er vertraut dem Schlüssel von Alice allein aufgrund Bobs vertrauenswürdiger Signatur. Wenn Carl sein Sicherheitsniveau erhöhen möchte oder er speziell Bobs Signaturen nur eingeschränkt vertraut, kann er sein Kryptosystem so konfigurieren, dass mehrere von ihm akzeptierte Signaturen vorhanden sein müssen, damit ein Schlüssel automatisch als gültig angesehen wird.

Formalisierung

Die Schlüsselverwaltung in einem Web of Trust erfolgt mit Hilfe von Schlüsselbunden. Im öffentlichen Schlüsselbund (public keyring) eines Benutzers werden eigene und fremde öffentliche Schlüssel und zugehörige Zertifikate gespeichert, der private Schlüsselbund (private keyring) enthält eigene private Schlüssel. Den öffentlichen Schlüsseln ordnet jeder Benutzer Vertrauen in dessen Besitzer zu („Owner Trust“). Daraus wird der Grad des Vertrauens in die Authentizität anderer Schlüssel („Key Legitimacy“) abgeleitet. Vertrauen in die Echtheit fremder Schlüssel wird entweder über Direct Trust (also die persönliche Überprüfung der Authentizität des öffentlichen Schlüssels eines anderen Benutzers) oder über den Owner Trust der Signierer der fremden Schlüssel etabliert.

Owner Trust

Den Wert für Owner Trust legt jeder Benutzer für die Schlüssel in seinem öffentlichen Schlüsselbund selbst fest (d. h., diese Information wird nicht öffentlich); zur Auswahl stehen bei GnuPG (der RfC macht dazu überhaupt keine Angaben) folgende Werte:

  • „unbekannt“ („unknown“) für Schlüssel, für die man noch keine explizite Angabe gemacht hat (Standardwert)
  • „kein Vertrauen“ („not trusted“) für Schlüssel, deren Zertifizierungen explizit nicht vertraut wird (d. h., Signaturen dieser Schlüssel werden für die Gültigkeitsberechnungen ignoriert)
  • „geringes Vertrauen“ („marginal“) für Schlüssel, denen nur eingeschränkt vertraut wird (d. h., standardmäßig werden drei Signaturen von solchen Schlüsseln benötigt, um einen Schlüssel gültig zu machen)
  • „volles Vertrauen“ („complete“) für Schlüssel, denen voll vertraut wird (d. h., standardmäßig reicht eine solche Signatur aus, um einen Schlüssel gültig zu machen)
  • „absolutes Vertrauen“ („ultimate“) für Schlüssel, die man selber erzeugt hat (diese Beziehung ist nicht fest; man kann eigenen Schlüsseln einen anderen Wert geben und ebenso fremden Schlüsseln diesen Wert zuweisen; bei solchen Schlüsseln reicht immer eine einzige Signatur aus, um einen Schlüssel gültig zu machen)

Beim Standardverfahren zur Gültigkeitsberechnung (WoT) braucht GnuPG mindestens einen Schlüssel mit absolutem Vertrauen im Keyring, weil ansonsten kein Schlüssel gültig wird (und nur die Signaturen gültiger Schlüssel werden berücksichtigt).

Normale Signaturen wirken sich nur auf die Gültigkeit des signierten Schlüssels aus, nicht aber auf dessen owner trust! Der muss für jeden Schlüssel einzeln in der lokalen Datenbank festgelegt werden (bei GnuPG; der RfC erlaubt auch entsprechende Signaturen („Trust Packet“) im Keyring).

Signatory Trust

Signiert Alice den öffentlichen Schlüssel von Bob und überträgt diese Signatur anschließend an einen Schlüsselserver, so kann diese Signatur von Dritten zur Beurteilung der Authentizität des öffentlichen Schlüssels von Bob benutzt werden. Dazu überprüfen sie (im Wesentlichen),

  1. ob der öffentliche Schlüssel von Alice für sie gültig ist (weil sie ihn selbst signiert haben oder er über das WoT gültig wurde) und
  2. ob sie dem öffentlichen Schlüssel von Alice einen positiven owner trust („marginal“ oder „complete“) zugeordnet haben.

Ist beides der Fall, dann wird Bobs Schlüssel entweder schon allein durch die Signatur von Alice gültig („complete“) oder eventuell zusammen mit weiteren („marginal“). Der owner trust von Bobs Schlüssel ändert sich dadurch nicht.

Welchen owner trust Alice für Bobs Schlüssel festgelegt hat, spielt für diesen Vorgang schon deshalb keine Rolle, weil diese Information nicht öffentlich bekannt ist. Der Öffentlichkeit wird nur mitgeteilt, dass Alice von der Identität des Schlüsselbesitzers (Bob) überzeugt ist. Was Alice von Bobs Signaturen hält, hat auf das WoT der anderen Nutzer keinerlei Einfluss.

Key Legitimacy

Das Vertrauen in die Authentizität eines öffentlichen Schlüssels wird durch den „Key-Legitimacy“-Wert ausgedrückt. Er wird aus dem Signatory Trust der signierenden Schlüssel wie folgt berechnet:

  • sei Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle x} die Anzahl von Signaturen, deren Signatory Trust „marginal“ ist
  • sei Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle X} die Anzahl von Signaturen mit einem Signatory Trust „marginal“, die erforderlich ist, damit ein Schlüssel als authentisch eingestuft wird
  • sei die Anzahl von Signaturen, deren Signatory Trust „complete“ ist
  • sei Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle Y} die Anzahl von Signaturen mit einem Signatory Trust „complete“, die erforderlich ist, damit ein Schlüssel als authentisch eingestuft wird

Dann sei Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle L = \frac{x}{X} + \frac{y}{Y}}

Ist , so gilt der überprüfte Schlüssel als nicht authentisch. Bei Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle 0 < L < 1} wird er als „teilweise authentisch“ angesehen und bei Fehler beim Parsen (Konvertierungsfehler. Der Server („https://wikimedia.org/api/rest_“) hat berichtet: „Cannot get mml. Server problem.“): {\displaystyle L\geq 1} als „vollkommen authentisch“. Im Regelfall wählt man Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle X = 2} und Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle Y = 1} , es sind also zwei Signaturen von teilweise vertrauenswürdigen Personen oder eine Signatur einer voll vertrauenswürdigen Person erforderlich, damit ein Schlüssel als authentisch eingestuft wird. Prinzipiell kann aber jeder die Werte für Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle X} und Fehler beim Parsen (MathML mit SVG- oder PNG-Rückgriff (empfohlen für moderne Browser und Barrierefreiheitswerkzeuge): Ungültige Antwort („Math extension cannot connect to Restbase.“) von Server „https://wikimedia.org/api/rest_v1/“:): {\displaystyle Y} je nach persönlichem Paranoia-Grad frei wählen.

Bewertung

Das Web of Trust ermöglicht seinen Teilnehmern einerseits die individuelle Kontrolle darüber, wen sie als vertrauenswürdig einstufen. Zudem gibt es kostenlose Software zur Realisierung des Konzepts des Web of Trust. Auf der anderen Seite erfordert es aber einen hohen Grad an Vorwissen vom Benutzer, es ist nicht juristisch bindend (wie z. B. eine Qualifizierte elektronische Signatur), der Widerruf eines Zertifikats wird nicht sofort allgemein bekannt, wie er es in einer PKI wird, und er ist auch nicht vergleichbar verwirklicht.

Probleme mit dem Datenschutz durch Schlüsselserver

Ein grundsätzliches Problem besteht darin, dass der Inhaber eines Schlüssels bei den derzeit gebräuchlichen Implementierungen technisch keinen Einfluss darauf nehmen kann,

  • wer seinen öffentlichen Schlüssel signiert und
  • ob jemand seinen öffentlichen Schlüssel auf einen öffentlichen Schlüsselserver hochlädt (oder mit neuen Signaturen erneut hochlädt).

Dem Schlüssel haften jedoch personenbezogene Daten an, die mitveröffentlicht werden: Durch die Signaturen anderer Personen, dem wichtigsten Element des Web of Trust, beinhaltet der Schlüssel eine Liste der Personen, die die Identität des Schlüsselinhabers geprüft haben, inklusive Prüfungsdatum. Auf einem Schlüsselserver sind diese Daten öffentlich einsehbar und automatisiert abrufbar, und können so leicht analysiert und somit die Beteiligung des Schlüsselinhabers an sozialen Netzwerken ermittelt werden.

Außerdem sammelt sich mit der Zeit eine öffentliche Liste aller früheren E-Mail-Adressen des Schlüsselinhabers an, solange der Schlüsselinhaber seinen Schlüssel nicht wechselt.

Nicht jedem ist von Anfang an bewusst, dass er durch die Teilnahme am Web of Trust Daten freigibt, die er vielleicht nicht für öffentlich erklären wollte und dass es keine Möglichkeit gibt, sie jemals wieder entfernen zu lassen.

Einmal auf Schlüsselserver exportierte öffentliche Schlüssel können nicht mehr gelöscht werden.[1] Die Schlüsselserver synchronisieren sich ständig untereinander, sodass ein neuer oder ergänzter Schlüssel einschließlich aller Signaturen und Kommentare innerhalb von kürzester Zeit nach dem (erneuten) Hochladen auf allen Schlüsselservern der Welt abrufbar ist, ganz gleich wer den Schlüssel hochgeladen hat und ob der Schlüssel ihm auch gehört.

Die Möglichkeit des Schlüsselwiderrufs (englisch key revocation) besteht bei den gebräuchlichen Implementierungen nur aus dem Erstellen eines Schlüsselwiderrufszertifikats, das dann ebenfalls auf den Schlüsselserver hochgeladen werden muss, dort aber praktisch nichts weiter bewirkt, als den vorhandenen Schlüssel mit dem Hinweis zu versehen, der Schlüssel solle nicht mehr benutzt werden. Software kann, aber muss nicht, solche Schlüssel zum Verschlüsseln verweigern. Mit einer Löschung von Schlüsseln, Signaturen oder Kommentaren hat der Schlüsselwiderruf aber nichts zu tun.

Der Schlüsselinhaber hat damit keine Möglichkeit, Einfluss auf die Verbreitung der Daten zu nehmen, die für das Funktionieren des Web of Trusts notwendig sind. Dies steht im Widerspruch zu dem Zweck von Verschlüsselungsprogrammen, persönliche Daten zu schützen.

Software

Bekannte Umsetzungen des Web of Trust sind das kommerzielle Programm Pretty Good Privacy (PGP) und das freie Programm GNU Privacy Guard (GnuPG), die den RFC 2440 umsetzen.

Das umfangreiche Web of Trust von PGP wurde eingehend untersucht. Es weist, nicht zuletzt wegen der Affinität vieler Mitglieder zu internationalen Open-Source-Projekten wie Debian und der Unterstützung von Organisationen wie der Computer-Fachzeitschrift C’t im Rahmen der „Krypto-Kampagne“ des Heise-Verlags[2] viele starke Verbindungen auf (einen sogenannten „Strong Set“), bei denen zwischen zwei beliebigen Personen im Mittel nur sechs Verbindungsglieder liegen.[3][4]

Soziale Netzwerke

Es sind durchaus auch abseits der Kryptographie Anwendungen der sozialen Grundidee des Web of Trust zu finden. So kennt etwa das CouchSurfing-Netzwerk ein Bürgschaftssystem, in dem „vertrauenswürdige“ Mitglieder neuen Mitgliedern mit einer „Bürgschaft“ ihr Vertrauen erklären können, wodurch sich das Vertrauen der gesamten Gemeinschaft gegenüber dem neuen Mitglied erhöht; jedes Mitglied, welches mindestens drei Bürgschaften erhalten hat, darf seinerseits für andere Mitglieder bürgen. Auf diese Weise entsteht ein soziales Vertrauensnetzwerk.

Literatur

Weblinks

  • Biglumber – Koordinierungsseite für gegenseitiges Schlüsselsignieren (englisch)
  • tent 0.4 – Ankündigung des tent protocol für ein web of trust

Einzelnachweise

  1. ↑ FAQ des Schlüsselservers des Massachusetts Institute of Technology
  2. ↑ c’t Krypto-Kampagne, abgerufen am 17. Februar 2013
  3. ↑ analysis of the strong set in the PGP web of trust, Henk P. Penning, 2. Januar 2013
  4. ↑ Dissecting the Leaf of Trust, Jörgen Cederlöf auf http://www.lysator.liu.se
Abgerufen von „https://de.wikiup.org/index.php?title=Web_of_Trust&oldid=225030042“