Zum Hauptinhalt springen

2 Web of Trust

Wir definieren das Web of Trust als eine Menge von gemeinsamen VaultysId. Jeder Besitzer einer VaultysId hat seine eigene Menge von VaultysId, um zu kommunizieren. Die in den VaultysId enthaltenen Schlüssel können verwendet werden, um Daten zu signieren oder zu verschlüsseln. Jeder Dienst kann sein eigenes Protokoll verwenden, um Schlüssel daraus abzuleiten.

Es ist jedoch ein Protokoll für das Vertrauenssetup definiert, um die Menge der verlässlichen Schlüssel zu integrieren. Das Protokoll wird als Symetric Relationship Protocol (SRP) bezeichnet, da es darauf abzielt, ein von beiden Parteien signiertes Zertifikat zu erstellen, das auf beiden Seiten gleich ist.

2.1 Symetric Relationship Protocol​

Zwischen Bob und Alice, die jeweils eine VaultysId haben. Die ausgetauschten Daten sind:

  • Protokoll Name (zum Beispiel p2p)
  • Dienst Name (zum Beispiel auth)
  • Zeitstempel, der zur Verhinderung von Replay-Angriffen verwendet wird
  • id1 und id2 sind die VaultysId von Bob und Alice respektive.
  • Nonce (zufällig)
  • sign1 und sign2 sind Signaturen, die vom Signierschlüssel von Id1 und Id2 erstellt wurden
  • metadata1 und metadata2 sind JSON-Objekte, die leer sein können Wir können das Protokoll mit dem Schema zusammenfassen: Nachricht = { Protokoll, Dienst, Zeitstempel, id1, id2, nonce1, nonce2, metadata1, metadata2 } sign1 und sign2 sind Signaturen unter Verwendung der Signierschlüssel von id1 und id2 von sha256(messagepack(message))

Metadaten werden vom Protokoll und Dienst benutzerdefiniert. Zum Beispiel können wir Metadaten verwenden, um Namen, E-Mail und Telefon zwischen den Parteien auszutauschen, damit sie innerhalb des Web of Trust des anderen zertifiziert sind.

Wir definieren:

  • M1 = Protokoll, Dienst, Zeitstempel, id1, nonce1, metadata1
  • M2 = id2, nonce2, metadata2
  • sign1 und sign2 sind Signaturen von sha256(M1 | M2)
  • Zertifikat = sha256(M1 | M2) | sign1 | sign2
  • ZertifikatsId = sha256(Zertifikat)
  • Nachrichten werden mittels MessagePack serialisiert

Das Protokoll muss auf folgende Infrastruktur vertrauen:

  • Eine bidirektionale Kommunikation Kanal, die Bob und Alice bereits bekannt ist. Aktive Angriffe sind erlaubt, außer beim anfänglichen Handshake (siehe später)
  • Ein Speicher, der in der Lage ist, Id und Zertifikat zu speichern. Das Sicherheitsmodell für den Speicher ist ein passiver Angriff (d. h. in der Lage, die Daten zu lesen, aber nicht zu manipulieren).

2.2 Allgemeine Beschreibung​

  • Bob -> Alice: sendet M1
  • Alice überprüft, ob dies die Absicht in Protokoll, Dienst, metadata1 ist, die sie verwenden möchte, und ob die Daten kohärent sind.
  • Alice überprüft, ob der Zeitstempel innerhalb einer angemessenen Zeit liegt (festgelegt durch das Protokoll)
  • Alice -> Bob: sendet M1 + M2 + sign2
  • Bob überprüft, ob metadata2, sign2 kohärent sind
  • Bob -> Alice: sign1
  • Alice überprüft, ob sign1 gültig ist
  • Alice -> Bob: VOLLSTÄNDIG, um das Ende der Kommunikation zu bestätigen
  • Alice und Bob speichern die Ids zusammen mit dem Zertifikat, das für Alice und Bob gleich ist
Info

 In einer zukünftigen Version des Protokolls könnte VOLLSTÄNDIG durch die ZertifikatsId ersetzt werden, wenn sie definiert ist.

2.3 Initialer Handshake​

Der initiale Handshake ist eine Möglichkeit, unbekannte Schlüssel zwischen den Parteien auszutauschen. Der aktive Angriff, bei dem ein Angreifer Daten während des Protokolls ändern kann, fällt nicht in den Geltungsbereich des Sicherheitsmodells. Das obligatorische Setup für die Sicherheit:

  • persönliche Durchführung des Protokolls.
  • sicherer p2p-Kanal:
    • mit einem vorübergehenden zufälligen Schlüssel, der ausgetauscht wird (zum Beispiel über QR-Code), der verwendet wird, um die im Protokoll ausgetauschten Daten zu verschlüsseln
    • Keine Vorwärtsgeheimhaltung erforderlich
    • Der Schlüssel wird danach zerstört. Das Protokoll ist gegen spätere Wiederherstellung oder passive Angriffe resistent. Die Konstanten sind definiert:
  • Protokoll = p2p
  • Dienst = auth
  • Zeitstempelabweichung beträgt 10s
  • metadata1 und metadata2 sind leer.
Info

Im Falle eines nicht persönlichen Handshakes kann der Zeitstempel auf ein paar Stunden (typischerweise 2 Stunden) gelockert werden, aber es wird daran erinnert, dass das Sicherheitsmodell darauf besteht, dass der Kommunikationskanal zur Übermittlung von Informationen oder Endpunkt (E-Mail, Chat, SMS) während des Handshakes NICHT kompromittiert ist.

2.4 Authentifizierung​

Nach Abschluss des Handshake-Protokolls ist es jederzeit möglich, sich gegenseitig zu authentifizieren. Zum Beispiel ersetzen wir ein klassisches Anmeldesystem basierend auf Benutzername/Passwort/mfa durch dieses einzelne Authentifizierungsschema:

  • Protokoll = p2p
  • Dienst = auth
  • Zeitstempelabweichung beträgt 10s
  • metadata1 und metadata2 sind leer.

Die Überprüfung auf beiden Seiten, Alice und Bob, hat einen zusätzlichen Schritt, nämlich die Überprüfung der Gültigkeit des Handshake-Registrierungszertifikats auf beiden Seiten:

2.5 Referenzimplementierung​

2.6 Beispiel​

Kanalimplementierungen​

Kanäle sind abstrakte Objekte zum Austausch von Daten in bidirektionaler Weise. Im Wesentlichen werden 2 Methoden benötigt:

  • send(data): void zum Senden von Daten im Fire-and-Forget-Modus
  • async receive(): data zum Warten auf den Empfang von Daten

Wir bieten 2 Implementierungen an:

  • P2P-Kanal unter Verwendung von WebRTC (über die Bibliothek peer.js)
  • Server/Browser-Kanal, der auf
    • nativem fetch() für den Browser
    • expressjs- oder nextjs-Middleware für den Server basiert.

Zum Testen gibt es ein Kanal-Mock (verwendet RAM im selben Prozess) Wir arbeiten an mehreren anderen Implementierungen wie Patr