Replay-Angriffe und Schwachstellen durch Nonce-Wiederverwendung

Eine Nonce (number used once) stellt sicher, dass die zweimalige Verschlüsselung derselben Klartextnachricht unterschiedliche Chiffretexte erzeugt. Dies ist für die semantische Sicherheit entscheidend: Ein Angreifer, der mehrere Chiffretexte beobachtet, erhält keine Information darüber, ob sie denselben oder unterschiedliche Klartexte verschlüsseln. In Stromchiffren und Blockchiffren im CTR-Modus dient die Nonce als Ausgangswert für die Erzeugung des Schlüsselstroms und ist daher für die Sicherheit von entscheidender Bedeutung.

In AES-GCM wird die 96 Bit lange Nonce verwendet, um einen Zähler für die Verschlüsselung im CTR-Modus zu initialisieren, und sie fließt außerdem in die GHASH-Authentifizierungsberechnung ein. Der Zählerwert für jeden AES-Block wird durch Erhöhen des von der Nonce abgeleiteten Werts bestimmt. Verwenden zwei Verschlüsselungen dieselbe Nonce und denselben Schlüssel, erzeugen sie denselben Schlüsselstrom. Dadurch entspricht das XOR ihrer Chiffretexte dem XOR ihrer Klartexte.

Zwei GCM-Chiffretexte, die mit demselben (Schlüssel, Nonce)-Paar verschlüsselt wurden: Ihr XOR entspricht dem XOR ihrer Klartexte. Kennt ein Angreifer einen der Klartexte, was bei Szenarien mit frei wählbarem Klartext häufig vorkommt, kann er den anderen sofort wiederherstellen. Selbst ohne einen bekannten Klartext verrät das XOR der Chiffretexte Sprachmuster und kann mit Crib-Dragging-Techniken angegriffen werden. Dies ist eines der katastrophalsten Fehlverwendungsmuster in der Kryptografie.

Die Wiederverwendung einer GCM-Nonce hat neben der Wiederherstellung des Klartexts eine weitere katastrophale Folge. Der GHASH-Authentifizierungsschlüssel H wird ausschließlich aus dem Verschlüsselungsschlüssel abgeleitet. Wenn zwei Nachrichten dasselbe (Schlüssel, Nonce)-Paar verwenden, kann der Angreifer polynomiale Gleichungen lösen, um H wiederherzustellen. Mit bekanntem H kann er gültige GCM-Authentifizierungstags für beliebige Chiffretexte fälschen und damit die Nachrichtenintegrität vollständig brechen.

TLS 1.3 hat aus den Risiken der Nonce-Wiederverwendung in TLS-1.2-Implementierungen gelernt. TLS 1.3 erzeugt GCM-Nonces, indem die 12 Byte lange Write-IV, die aus dem Handshake abgeleitet wird, mit der 8 Byte langen Sequenznummer per XOR verknüpft wird, nachdem diese auf 12 Byte mit Nullen aufgefüllt wurde. Da die Sequenznummern für jeden Datensatz erhöht werden, verwendet jeder Datensatz eine eindeutige Nonce. Dadurch entfällt das Risiko der Erzeugung zufälliger Nonces, während der Mechanismus der Sequenznummern die Eindeutigkeit der Nonces sicherstellt.

Bei einem Replay-Angriff fängt ein Angreifer eine gültige Nachricht oder ein gültiges Authentifizierungstoken ab und sendet es später erneut, um eine betrügerische Wirkung zu erzielen. Beispiele sind das erneute Senden einer Banktransaktion, um eine doppelte Belastung zu verursachen, das erneute Senden einer gültigen Authentifizierungsantwort, um sich als Benutzer auszugeben, oder das erneute Senden eines signierten Befehls an ein Gerät. Der Angreifer muss die Nachricht weder verstehen noch verändern; das bloße erneute Senden der abgefangenen Daten reicht für den Angriff aus.

Das Einfügen eines Zeitstempels in authentifizierte Nachrichten bietet Schutz vor Replay-Angriffen. Der Empfänger akzeptiert Nachrichten nur innerhalb eines kurzen Zeitfensters, beispielsweise innerhalb von 5 Minuten nach dem angegebenen Zeitstempel. Eine Nachricht, die Stunden später erneut gesendet wird, liegt außerhalb dieses Zeitfensters und wird abgelehnt. Der Zeitstempel muss authentifiziert werden, also innerhalb des HMAC oder der zusätzlichen AEAD-Daten liegen, damit ein Angreifer ihn nicht so verändern kann, dass die Nachricht aktuell erscheint.

Sequenznummern bieten einen stärkeren Replay-Schutz als Zeitstempel, da sie nicht nur alte Wiederholungen, sondern auch doppelte und verspätet oder in falscher Reihenfolge zugestellte Nachrichten erkennen. Der Empfänger verwaltet die erwartete nächste Sequenznummer sowie ein gleitendes Fenster kürzlich gesehener Nummern. Jede Nachricht muss eine Sequenznummer innerhalb des zulässigen Fensters besitzen, die zuvor noch nicht gesehen wurde. TLS verwendet Sequenznummern, um das Wiederholen von Datensätzen innerhalb einer Sitzung zu verhindern.

Für AES-GCM wird empfohlen, zufällige Nonces mit einer Länge von 96 Bit aus einem kryptografisch sicheren pseudorandomisierten Zahlengenerator (CSPRNG) zu erzeugen. Bei zufälligen Nonces mit 96 Bit erreicht die Kollisionswahrscheinlichkeit gemäß der Geburtstagsgrenze nach 2^32 Verschlüsselungen, also etwa 4 Milliarden, den Wert 2^-32. Für Anwendungen mit hohem Datenaufkommen sollten Sie auf eine zählerbasierte Nonce umsteigen oder ein anderes AEAD-Verfahren wie XChaCha20-Poly1305 mit seiner 192 Bit langen Nonce verwenden, um das sichere Limit zu erhöhen.

Deterministische, zählerbasierte Nonces vermeiden Probleme mit der Geburtstagsgrenze, erfordern jedoch eine sorgfältige Zustandsverwaltung. Der Zähler muss über Neustarts der Anwendung hinweg persistent gespeichert werden. Ein Zähler, der beim Neustart auf null zurückgesetzt wird, führt bei Verwendung desselben Schlüssels sofort zu einer Nonce-Wiederverwendung. Der Zähler muss atomar aktualisiert werden, bevor die Nonce verwendet wird, nicht danach. In verteilten Systemen erfordern zählerbasierte Nonces eine Koordination, damit nicht zwei Knoten denselben Zählerwert verwenden.

XChaCha20-Poly1305 erweitert die Nonce von ChaCha20-Poly1305 von 96 auf 192 Bit. Bei zufälligen Nonces mit 192 Bit ist die Kollisionswahrscheinlichkeit gemäß der Geburtstagsgrenze selbst nach 2^96 Verschlüsselungen vernachlässigbar, also bei einer astronomisch großen Anzahl von Nachrichten. Dadurch ist die Erzeugung zufälliger Nonces ohne praktische Bedenken hinsichtlich der Geburtstagsgrenze sicher. libsodiums crypto_secretbox (XSalsa20-Poly1305) verwendet aus demselben Grund 192 Bit lange Nonces.

Zusammenfassung zur Nonce-Wiederverwendung: Nonces sorgen für die Eindeutigkeit von Chiffretexten. Die Wiederverwendung einer GCM-Nonce gibt das XOR der Klartexte preis und bricht durch die Wiederherstellung von H die Authentifizierung. TLS 1.3 verwendet das XOR von Sequenznummer und IV, um die Eindeutigkeit der Nonces sicherzustellen. Replay-Angriffe senden gültige Nachrichten unverändert erneut. Zeitstempel und Sequenznummern in authentifizierten Nachrichten verhindern Replay-Angriffe. Verwenden Sie für GCM zufällige Nonces mit 96 Bit und berücksichtigen Sie dabei die Geburtstagsgrenze oder verwenden Sie XChaCha20 für einen größeren Raum zufälliger Nonces.