Das Noise-Protokollframework

Das Noise Protocol Framework (Trevor Perrin, 2016; aktuelle Fassung von 2018) ist ein Framework zum Erstellen sicherer Kommunikationskanäle mithilfe einer kleinen Anzahl von Primitiven und einer Mustersprache. Statt ein einzelnes Protokoll festzulegen, definiert Noise ein Vokabular von Handshake-Mustern, die die Abfolge und Reihenfolge der DH-Operationen beschreiben. Jedes gültige Noise-Muster kann mit konkreten DH- (Curve25519 oder Curve448), Verschlüsselungs- (AESGCM oder ChaChaPoly) und Hash-Funktionen (SHA-256, SHA-512, BLAKE2) instanziiert werden. Noise wird in WireGuard, WhatsApp, Signal (als Grundlage von X3DH), dem Lightning Network und I2P verwendet.

Jeder Noise-Handshake hat einen Initiator (I) und einen Responder (R). Jede Partei kann zwei Schlüsseltypen besitzen: einen statischen Schlüssel (langfristiger Identitätsschlüssel, bezeichnet mit s/S) und einen ephemeren Schlüssel (für jede Sitzung neu erzeugt, bezeichnet mit e/E). Kleinbuchstaben bezeichnen den Schlüssel der lokalen Partei; Großbuchstaben bezeichnen den öffentlichen Schlüssel der entfernten Partei. Ein Noise-Muster legt fest, welche Schlüssel (als Klartext oder verschlüsselt) gesendet und welche DH-Operationen ausgeführt werden. Beispielsweise bedeutet "e": "meinen ephemeren öffentlichen Schlüssel senden"; "es" bedeutet: "DH(my_ephemeral, remote_static) ausführen". Jede DH-Ausgabe wird in den fortlaufenden Hash-Zustand des Handshakes eingemischt.

Der Kern von Noise ist der SymmetricState, der drei Werte verwaltet: ck (Chaining Key, initialisiert mit einem Hash des Protokollnamens), h (Handshake-Hash, der fortlaufende Hash des Transkripts) und k (aktueller Verschlüsselungsschlüssel). MixKey(input) führt HKDF(ck, input) aus, um ck und k zu aktualisieren. MixHash(data) hasht data und mischt das Ergebnis in h. EncryptAndHash(plaintext) verschlüsselt mit k und mischt das Chiffrat in h. DecryptAndHash(ciphertext) entschlüsselt und mischt das Chiffrat in h. Der Handshake-Hash h sorgt für die Transkriptbindung: Jede von einem Angreifer vorgenommene Änderung an einer Nachricht verändert h, sodass die Entschlüsselung fehlschlägt. Am Ende des Handshakes erzeugt Split() zwei getrennte CipherStates zum Senden und Empfangen.

Noise_XX ist das am häufigsten verwendete Muster für gegenseitige Authentifizierung. Es bietet eine gegenseitige Authentifizierung statischer Schlüssel, wobei die statischen Schlüssel beider Parteien während des Handshakes übertragen werden. Muster: (1) -> e (der Initiator sendet den ephemeren öffentlichen Schlüssel). (2) <- e, ee, s, es (der Responder sendet seinen ephemeren Schlüssel, führt DH(e,e) und DH(e,s_resp) aus und sendet den verschlüsselten statischen Schlüssel). (3) -> s, se (der Initiator sendet den verschlüsselten statischen Schlüssel und führt DH(s_init, e_resp) aus). Nach Schritt 3 haben beide Parteien drei DH-Ausgaben in den Sitzungsschlüssel eingemischt: ee (Forward Secrecy), es (Server-Authentifizierung), se (Client-Authentifizierung). Der Sitzungsschlüssel ist unabhängig von einer Kompromittierung langfristiger Schlüssel nach Ende der Sitzung.

WireGuard verwendet ein von Noise_IK abgeleitetes Muster, bei dem der Initiator den statischen Schlüssel des Responders im Voraus kennt. (1) -> e, es, s, ss (der Initiator sendet seinen ephemeren Schlüssel, führt DH(e, S_resp) aus, sendet den verschlüsselten statischen Schlüssel und führt DH(s_init, S_resp) aus). (2) <- e, ee, se (der Responder sendet seinen ephemeren Schlüssel und führt DH(e_resp, e_init) sowie DH(e_resp, S_init) aus). Das IK-Muster verbirgt die Identität des Initiators (sein statischer Schlüssel wird in Schritt 1 mit dem statischen Schlüssel des Responders verschlüsselt) und wird innerhalb einer RTT abgeschlossen. WireGuard fügt der verschlüsselten Nutzlast des Initiators einen Zeitstempel hinzu, um Wiedergaben zu verhindern. Das verleiht WireGuard seine charakteristische Einfachheit: ein vollständiger VPN-Handshake in zwei UDP-Paketen.

Der Handshake-Hash h am Ende eines Noise-Handshakes ist ein Transkript-Hash, der jede gesendete Nachricht umfasst. Er dient als Wert für die Kanalbindung: Beide Parteien berechnen dasselbe h, und jedes nachgelagerte Protokoll, das an die Noise-Sitzung gebunden werden soll, kann h als Nonce oder Kanal-ID einbeziehen. Dadurch wird eine kombinierte Authentifizierung ermöglicht: Nach dem Noise-Handshake kann ein TLS-artiger Zertifikatsauthentifizierungsschritt ausgeführt werden, der das Zertifikat über h an diese konkrete Sitzung bindet. Kanalbindung verhindert Credential-Forwarding-Angriffe, bei denen Authentifizierungsnachweise aus einer Sitzung in einer anderen Sitzung wiederverwendet werden. Split() stellt der Anwendung h zusammen mit den Sitzungsschlüsseln bereit.

Noise unterstützt verzögerte Muster für Situationen, in denen der Initiator den statischen Schlüssel des Responders nicht im Voraus kennt. Noise_NX (der Initiator hat keinen statischen Schlüssel; der Responder überträgt seinen) ähnelt einer unidirektionalen TLS-Verbindung. Noise_XX behandelt den Fall, dass beide Parteien Schlüssel austauschen müssen. Noise_IK kann auf Noise_XXfallback zurückgreifen, wenn die Vermutung des Initiators bezüglich des statischen Schlüssels des Responders falsch ist (z. B. nach einer Schlüsselrotation). Das Fallback-Muster ermöglicht es dem Responder, zu signalisieren: "Sie haben den falschen Schlüssel verwendet; hier ist mein neuer öffentlicher Schlüssel", ohne externen Beobachtern zu verraten, dass ein Fallback stattgefunden hat – so bleibt die Opazität des Protokolls erhalten.

WhatsApp und Signal verwenden Noise_XX, um sichere Kanäle zwischen Clients und Servern einzurichten. Das Binärprotokoll von WhatsApp verwendet Noise_XX mit Curve25519, ChaChaPoly und SHA-256. Der statische Schlüssel des Clients ist sein langfristiger Identitätsschlüssel. Nach dem Noise-Handshake führt die Anwendungsschicht eine zusätzliche Authentifizierung durch (Signal-Registrierung, Verifizierung der Telefonnummer). Die Schlüsselvereinbarung X3DH (Extended Triple Diffie-Hellman) von Signal führt vier DH-Operationen aus, um über einen asynchronen Nachrichtenaustausch ein gemeinsames Geheimnis zwischen zwei Benutzern herzustellen – dies ist kein standardmäßiges Noise-Muster, verwendet aber ähnliche Konzepte zur Mischung von DH-Ausgaben. Anschließend übernimmt der Double Ratchet die laufende Verschlüsselung der Nachrichten.

Noise und TLS 1.3 lösen dasselbe Problem (authentifizierter Schlüsselaustausch), verfolgen dabei aber unterschiedliche Ansätze. TLS 1.3 ist ein einzelnes Protokoll mit vorgeschriebenen Cipher Suites, Zertifikatsformaten (X.509) und Erweiterungen. Es wurde für Webbrowser und Server entwickelt – ein Einheitsprotokoll für die meisten Anwendungsfälle. Noise ist ein Framework: Es legt weder ein Zertifikatsformat noch eine PKI oder eine Transportbindung fest. Dadurch ist Noise kleiner (die gesamte Noise-Implementierung von WireGuard umfasst weniger als 400 Codezeilen) und formal leichter zu analysieren, allerdings muss die Anwendung die Identitätsverwaltung separat übernehmen. Noise wird für geschlossene Systeme (App-zu-Server, VPN) bevorzugt, bei denen eine PKI überdimensioniert wäre; TLS für offene Systeme (Web), bei denen die Interoperabilität von Zertifikaten erforderlich ist.

Noise-Muster wurden im eCK-Sicherheitsmodell (erweitertes Canetti-Krawczyk-Modell) formal analysiert. Kobeissi, Bhargavan und Blanchet analysierten Noise mit Proverif und fanden Nachweise für Authentifizierung und Schlüsselvertraulichkeit für alle 12 grundlegenden Noise-Muster. Die Nachweise setzen die standardmäßige DH-Härteannahme (Curve25519) sowie die Sicherheit der zugrunde liegenden AEAD- und Hash-Funktionen voraus. Die kompositionale Struktur von Noise, bei der jede DH-Ausgabe schrittweise eingemischt wird, erleichtert die Analyse im Vergleich zu komplexen TLS-ähnlichen Protokollen mit vielen Zustandsübergängen. Die kryptografische Verifikation von Noise gab WireGuard und WhatsApp bereits vor ihrer Einführung ein hohes Maß an Vertrauen in die Sicherheit ihrer Protokolle.

Häufige Fehler bei der Implementierung von Noise: (1) Musterverwechslung – die Verwendung von Noise_IK, wenn der statische Schlüssel des Responders nicht zuverlässig vorab verteilt wurde, führt zu einer falschen Identitätszuordnung (der Initiator verschlüsselt möglicherweise unbemerkt mit einem falschen Schlüssel). (2) Wiedergabeschutz – Noise bietet Authentifizierung, aber keinen Wiedergabeschutz für Nachrichten der Transportphase; Nonces (64-Bit-Zähler) müssen erzwungen werden, und ein Überlauf (nach 2^64 Nachrichten) muss eine erneute Schlüsselableitung auslösen. (3) Prolog-Integrität – der Noise-Prolog (ein Byte-String, der vor Beginn des Handshakes in h eingemischt wird) muss den gesamten Protokollkontext (Version, Algorithmusauswahl) enthalten, um Downgrade-Angriffe zu verhindern. (4) Missbrauch von PSKs – Noise unterstützt PSK-Erweiterungen zum Einmischen vorab geteilter Schlüssel; PSKs müssen eine hohe Entropie besitzen und dürfen keine Benutzerpasswörter sein.

Was bedeutet die Noise-Musternotation "es" in einem Handshake-Muster?

Noise ist ein Framework zum Erstellen authentifizierter Schlüsselaustauschprotokolle mithilfe einer Mustersprache für DH-Operationen. Der SymmetricState verwaltet Chaining Key (ck), Transkript-Hash (h) und Chiffrierschlüssel (k), die durch MixKey/MixHash aktualisiert werden. Noise_XX bietet gegenseitige Authentifizierung in 1,5 RTT; Noise_IK (WireGuard) wird bei bekanntem Responder-Schlüssel in 1 RTT abgeschlossen. Der Handshake-Hash h dient als Kanalbindung. Noise wurde für alle grundlegenden Muster mithilfe von Proverif formal verifiziert. Es wird gegenüber TLS für Protokolle in geschlossenen Systemen (WireGuard, WhatsApp) bevorzugt, in denen eine PKI nicht erforderlich ist. Eine korrekte Implementierung erfordert Wiedergabeschutz, Prolog-Integrität und PSKs mit hoher Entropie.