AES-GCM kann die Vertraulichkeit einer Nachricht schützen und unbefugte Änderungen erkennen. Für sich allein sagt es dem Empfänger nicht, ob eine ansonsten gültige Nachricht bereits verarbeitet wurde.
Drei Anforderungen werden leicht verwechselt: eindeutige Schlüssel/Nonce-Paare für die Verschlüsselung, Authentifizierung der Nachricht und ihres Kontexts sowie Replay-Behandlung auf Protokollebene. HKDF kann bei der Schlüsselableitung helfen, erfüllt aber nicht automatisch alle drei.
Nonce-Wiederverwendung und Replay sind unterschiedliche Ereignisse
| Ereignis | Was passiert | Erforderlicher Schutz |
|---|---|---|
| Nonce-Wiederverwendung bei der Verschlüsselung | Unterschiedliche Klartexte werden mit demselben GCM-Schlüssel und derselben Nonce verschlüsselt | Eine zuverlässige Strategie zur Zuweisung von Schlüsseln und Nonces |
| Manipulation | Chiffretext oder authentifizierter Kontext wird verändert | Authentifizierte Entschlüsselung und Zurückweisung bei Fehlschlag |
| Replay | Eine zuvor gültige verschlüsselte Nachricht wird erneut zugestellt | Zustand und Anwendungsregeln, die Duplikate oder veraltete Nachrichten erkennen |
| Umordnung | Gültige Nachrichten treffen in anderer Reihenfolge ein | Protokolldefinierte Reihenfolge und begrenzte Behandlung von Nachrichten außerhalb der Reihenfolge |
Ein erneut zugestellter Chiffretext kann weiterhin einen gültigen Authentifizierungstag besitzen. Es wurde nichts verändert. Deshalb ist die Aussage falsch, jedes Duplikat scheitere automatisch an der AES-GCM-Authentifizierung. RFC 5116 trennt die AEAD-Schnittstelle ausdrücklich von Anti-Replay-Diensten.
Warum sich das Schlüssel-Nonce-Paar nicht wiederholen darf
Die Nonce von GCM muss nicht geheim sein, aber unter einem gegebenen Schlüssel die Eindeutigkeitsanforderungen des Verfahrens erfüllen. Eine Nonce mit 96 Bit beziehungsweise 12 Byte ist üblich; diese Länge zu wählen garantiert keine korrekte Erzeugung.
Werden derselbe Schlüssel und dieselbe Nonce für unterschiedliche Klartexte wiederverwendet, wird der Verschlüsselungsschlüsselstrom wiederverwendet und Beziehungen zwischen den Klartexten werden offengelegt. Das kann auch die Authentizität untergraben und Fälschungen ermöglichen. Die Folgen sind schwerwiegend, sollten aber nicht als automatische Offenlegung aller alten Schlüssel oder sämtlicher Nachrichten eines Kontos beschrieben werden. Der betroffene Umfang hängt vom wiederverwendeten Schlüssel und vom Protokoll ab.
NIST SP 800-38D definiert GCM und seine Anforderungen. Implementierungen müssen die geltenden Aufrufgrenzen und Regeln zur Nonce-Erzeugung einhalten, keine vereinfachte Faustregel wie „bis zu so vielen Nachrichten sicher“.
Was HKDF beiträgt
HKDF, spezifiziert in RFC 5869, leitet Schlüsselmaterial aus geheimem Eingangsmaterial mithilfe von Extraktions- und Expansionsschritten ab. Protokolle können Kontextkennzeichnungen und unterschiedliche Eingaben verwenden, um Schlüssel für verschiedene Zwecke zu trennen.
HKDF ist deterministisch. Wiederholt ein abgestürzter oder auf einen früheren Stand zurückgesetzter Client denselben Zustand und dieselben Eingaben, kann er erneut dieselbe Ausgabe ableiten. HKDF zu einem Entwurf hinzuzufügen macht die Wiederverwendung von Nonces daher nicht unmöglich.
Schlüssel pro Nachricht können die Inhaltsmenge reduzieren, die unter einem einzelnen Schlüssel geschützt wird. Sichere Zustandsfortschreibung, Schlüsseltrennung und Löschung bleiben jedoch wichtig. Derselbe Nonce-Wert unter tatsächlich unterschiedlichen Schlüsseln ist nicht derselbe Fehler wie die Wiederholung eines Schlüssel/Nonce-Paars; das Protokoll muss sicherstellen, dass die Schlüssel wirklich unterschiedlich sind.
Replay-Schutz gehört ins Protokoll
Ein Empfänger kann Nachrichtenkennungen, Sequenzpositionen, Sitzungsepochen oder verbrauchte Ratchet-Schlüssel verfolgen. Relevante Felder müssen authentifiziert sein, damit ein Angreifer eine alte Nachricht nicht als neue kennzeichnen kann.
Die Anwendung muss anschließend entscheiden, was ein Duplikat bedeutet. Eine doppelte Chatblase ist lästig; dieselbe Aktion zweimal auszuführen kann gravierender sein. Netzwerk-Wiederholungen sind normal, daher ist neben kryptografischen Prüfungen häufig idempotente Verarbeitung nötig.
Verlangen Sie nicht, dass jede gültige Nachricht strikt in Reihenfolge ankommt, sofern das Protokoll dieses Verhalten nicht vorgibt. Mobile Clients verbinden sich regelmäßig erneut, wiederholen Übertragungen und empfangen verspätete Nachrichten. Sichere Behandlung unterscheidet eine legitime verspätete Nachricht von einer bereits verbrauchten Nachricht oder einer mit falschem Kontext.
Was vor einer Schutzaussage getestet werden sollte
- Neustart nach der Zuweisung einer Nonce, aber vor der Erfassung des Versands: Kann sich die Zuweisung wiederholen?
- Wiederherstellung eines älteren Zustandsschnappschusses: Können Schlüssel, Zähler oder Replay-Datensätze zurückgesetzt werden?
- Gleichzeitiges Senden durch zwei Worker oder Geräte: Sind ihre Schlüssel/Nonce-Bereiche getrennt?
- Zweimalige Zustellung derselben gültigen Nachricht: Wird die Anwendungsaktion nur einmal ausgeführt?
- Änderung einer Sitzungskennung oder eines Headers: Ist der Kontext kryptografisch gebunden?
- Zustellung gültiger Nachrichten außerhalb der Reihenfolge: Werden unterstützte Verzögerungen behandelt, ohne veralteten Zustand zu akzeptieren?
APIs für authentifizierte Entschlüsselung sollten Klartext erst nach erfolgreicher Verifikation an die Anwendung zurückgeben. Das ist eine Schnittstellenanforderung, keine Behauptung, dass keine Implementierung intern jemals einen temporären Klartextpuffer berechnet.
Livaras Aussagen richtig lesen
Livaras Sicherheitsdokumentation nennt AES-256-GCM, nachrichtenbezogene Schlüsselketten und LVR1/LGS1-Kontext. Diese Grundbausteine beweisen für sich genommen weder korrekte Wiederherstellung nach Abstürzen noch korrekte Nonce-Zuweisung oder Replay-Zurückweisung. Solche Aussagen benötigen versionierte Protokolldetails und Testnachweise.
Ein robuster Entwurf weist jede Aufgabe ausdrücklich zu: Die Schlüsselableitung erzeugt die vorgesehenen Schlüssel, AEAD authentifiziert Inhalt und Kontext, und zustandsbehaftete Protokolllogik entscheidet, ob eine gültige Nachricht jetzt akzeptabel ist.
