Zusammenfassung

  • RFC 9771 ordnet vertraute AEAD-Begriffe vier Anspruchsklassen zu. Wer sie vermischt, kann mit einer wahren Aussage über einen Algorithmus an der Systemgrenze trotzdem in die Irre führen.
  • Eine belastbare Freigabe braucht einen Eigenschaftsbeleg, der Sicherheitsbegriff, Konstruktion und Version, API-Verhalten, Negativtests, Schlüssellebenszyklus und Protokolleinbindung verknüpft.

Das Adjektiv war nie die Zusicherung

„Authentisierte Verschlüsselung“ klingt wie eine abgeschlossene Sicherheitsentscheidung. Tatsächlich bezeichnet der Begriff ein Primitiv, dessen Schutz aus einem Vertrag zwischen Algorithmus, Schlüssel- und Nonce-Disziplin, Zusatzdaten, Schnittstelle und Protokollzustand entsteht. RFC 9771, im Mai 2025 von der Crypto Forum Research Group der IRTF veröffentlicht, ist gerade deshalb wichtig, weil das Dokument diesen Vertrag nicht zu einem Gütesiegel verkürzt.

Es ist informativ, kein Internetstandard und keine Einsatzfreigabe. Seine Stärke ist die Taxonomie. Konventionelle Sicherheit wird von Eigenschaften für stärkere Angreifer getrennt; beide werden wiederum von Implementierungseigenschaften und von Funktionen unterschieden, die eine erweiterte Schnittstelle erfordern. Käufer, Prüfer und Betreiber können so zuerst die Art einer Behauptung erkennen und danach die passende Evidenz verlangen.

Die konventionelle Schnittstelle nach RFC 5116 nimmt Schlüssel, Nonce, Zusatzdaten und Klartext entgegen; die Entschlüsselung liefert Klartext oder einen Fehler. Schon darin steckt eine Betriebspflicht: Jeder Aufruf unter einem Schlüssel benötigt einen eindeutigen Nonce. „AES-GCM“ im Datenblatt sagt nicht, wer diese Eindeutigkeit besitzt, ob sie eine Snapshot-Wiederherstellung überlebt, wie parallele Sender den Raum teilen oder ob Beschleuniger und Software-Fallback denselben Zustand verwenden.

RFC 9771 erweitert das Vokabular, beantwortet diese Fragen aber nicht stellvertretend. Es ist kein Menü, bei dem mehr Adjektive automatisch mehr Schutz erzeugen, sondern eine Karte unterschiedlicher Nachweispflichten.

Vier Klassen, vier Nachweisarten

Klasse Was sich ändert Erforderliche Evidenz
Konventionelle Sicherheit Grundziel für Vertraulichkeit und Chiffrat-Integrität Konstruktion, Parameter, formaler Begriff, konkrete Grenzen, Testvektoren und Nutzungslimits
Zusätzliche Sicherheit Angreifer erhält Nonce-Wiederholung, Mehrbenutzerzugriff, Leckage oder frühen Klartext Getrennte Integritäts-/Vertraulichkeitsaussagen, Begriff, Abweichungen und Fehlgebrauchstests
Implementierungseigenschaft Art der Berechnung Gemessener Pfad, Speicher und Durchläufe, Prüfgrenze, Gleichlauf von Hardware und Fallback
Zusatzfunktion Neue Schnittstelle, etwa Updates oder wählbare Chiffratverlängerung API-Vertrag, neu gefasstes Grundziel, Zustandswechsel, Kompatibilität und Fehlersemantik

Die Trennung zeigt einen häufigen Fehlschluss. „Ein Durchlauf“, „parallelisierbar“ und „streamfähig“ beschreiben Berechnung, beweisen aber keine Vertraulichkeit oder Integrität. RFC 9771 weist darauf hin, dass ein streamfähiger Aufbau blockweise Sicherheit und Integrität beim Freigeben ungeprüften Klartexts benötigen kann. Eine Durchsatzmessung ist daher kein Sicherheitsbeleg für eine Streaming-API.

Der umgekehrte Fehlschluss ist ebenso gefährlich. Ein formales Ergebnis für die Konstruktion beweist nicht, dass ein Wrapper es erhält. Gibt der Entschlüssler Bytes vor der Tag-Prüfung frei, arbeitet die Anwendung im RUP-Modell. Konventionelle Vertraulichkeit ist nach bewusster Klartextfreigabe unmöglich; die einschlägigen Integritäts- und Klartextziele ändern sich. Eine gepufferte und eine inkrementelle API mit demselben Primitiv dürfen deshalb unterschiedliche Aussagen tragen.

Zusatzfunktionen machen die Grenze besonders sichtbar. RFC 9771 behandelt inkrementelle und robuste authentisierte Verschlüsselung im Anhang, weil beide über konventionelles AEAD hinausgehen. Bei robuster AE wählt der Aufrufer die Verlängerung des Chiffrats und tauscht Länge gegen die bestmögliche Integrität bei dieser Verlängerung. „Robust“ bedeutet hier nicht „Key Robustness“, eine gelegentliche Bezeichnung für Schlüsselbindung. Bleibt im Freigabevermerk nur das Wort übrig, ist die entscheidende Unterscheidung verloren.

Fast gleiche Wörter, andere Voraussetzungen

Nonce-Misuse Resilience und Nonce-Misuse Resistance klingen austauschbar. RFC 9771 unterscheidet sie. Resilience schützt Nachrichten mit frischem Nonce, auch wenn ein Angreifer anderswo Wiederholungen erzwingt. Resistance schützt zusätzlich die tatsächlich unter wiederholten Nonces verarbeiteten Nachrichten, abgesehen von unvermeidbarer Leckage bei identischem Klartext unter identischem Nonce. Resistance impliziert Resilience, nicht umgekehrt.

Der Testplan ändert sich damit. Bei Resilience ist zu zeigen, dass ein Vorfall frischen Verkehr nicht kontaminiert. Bei Resistance muss auch der betroffene Verkehr charakterisiert werden. AES-GCM-SIV in RFC 8452 ist ein standardisiertes fehlgebrauchsresistentes Verfahren. Das überträgt die Eigenschaft weder auf gewöhnliches GCM noch auf das Schlüssel- und Fehlerverhalten einer Integration.

Auch Commitment birgt eine Falle. Key Commitment fragt, ob ein Chiffrat unter verschiedenen Schlüsseln gültig sein kann. Full Commitment bezieht unterschiedliche Nonces, Zusatzdaten und Klartexte ein. Full impliziert Key Commitment, nicht umgekehrt. Das wird betrieblich relevant, wenn erfolgreiche Entschlüsselung den Mandanten, das Konto oder den Kontext bestimmen soll. Forschung zu Context Discovery zeigt, warum Mehrdeutigkeit zwischen gültigen Kontexten real ist. Trotzdem muss der Beleg Konstruktion, Kontextkodierung, Tag-Länge und Sicherheitsbegriff nennen. Ein Wort bindet nicht, was das System nicht kodiert hat.

Vom Anspruch zum Eigenschaftsbeleg

Der Beleg ist ein kompaktes, versioniertes Evidenzobjekt, das Einkauf, Security Engineering, Betrieb und Incident Response ohne gegenseitiges Rätselraten lesen können. Er beginnt mit der exakten Eigenschaft und ihrer RFC-9771-Klasse. „Vertraulichkeit und Integrität bei Nonce-Fehlgebrauch“ ist ein Anspruch; „sicherere Nonces“ ist Werbung. Verwenden Vertraulichkeit und Integrität verschiedene Begriffe, werden beide genannt. Für einen alternativen Begriff ist Äquivalenz zu beweisen oder Nichtäquivalenz offenzulegen.

Danach wird der Gegenstand eingefroren: Algorithmus und Konstruktion, Parameter, Tag-Länge, Provider oder Bibliothek, Version und Build, CPU- oder Beschleunigerpfad sowie Software-Fallback. Designbeweis und Binärtest beantworten verschiedene Fragen; der Beleg braucht beide.

Der Schnittstellenabschnitt hält Eingaben, Zeitpunkt der Ausgabe, Prüfgrenze, Chunk-Reihenfolge, Abbruch und Fehler fest. Er benennt die Verantwortung für Nonces und Zusatzdaten. Ob ein Fehlschlag nichts, einen Puffer, Teilklartext oder einen späten Fehler liefert, entscheidet über das reale Sicherheitsmodell.

Negativtests werden aus der Eigenschaft abgeleitet: wiederholter Nonce, falscher Schlüssel, veränderte Zusatzdaten, Chiffrat aus anderem Kontext, gekürzter oder gefälschter Tag, umgeordnete Chunks, frühe Ausgabe, Rollback, Wiederherstellung, Zählerende, Schlüsselphasenwechsel und Abweichung zwischen Software und Offload. Ein Test beobachtet Verhalten und ersetzt keinen Beweis; der Beweis belegt nicht die Einhaltung seiner API-Prämissen.

Der Schlüssellebenszyklus umfasst Erzeugung und Ableitung, Identität, Nonce- und Sequenzbereich, Parallelität, Grenzen, Rotation, Vernichtung, Sicherung, Wiederherstellung und Mehrbenutzeraggregation. RFC 8645 beschreibt Rekeying-Mechanismen, doch der Einsatz muss Auslöser und Überlappung alter und neuer Zustände zeigen. Änderungen an Provider, Offload, Nonce-Zuteilung, Persistenz oder Rotation lassen den Beleg verfallen.

Zuletzt füllt die Protokolleinbindung die Lücke zum Netz. TLS 1.3 bildet Record-Nonces aus Sequenzzustand; QUIC ergänzt Paketnummern und Schlüsselphasen. Wiederholung, Replay, Wiederanlauf, Migration, Framing, Kontextbindung, Interoperabilität und Hardwareterminierung brauchen eigene Evidenz.

Was Käufer heute verlangen können

RFC 9771 ermöglicht eine präzise Forderung: „Nennen Sie für jede nichtkonventionelle AEAD-Eigenschaft den exakten Sicherheitsbegriff, die betroffene Implementierung und Version, das API-Verhalten zur Wahrung der Voraussetzungen, die Grenztests, die Kontrollen des Schlüssellebenszyklus und die abgedeckten Protokollpfade.“

„Nicht unterstützt“, „nur auf diesem Pfad“ oder „für diesen Fehlerfall nicht bewiesen“ sind wertvolle Antworten. Sie schaffen eine bepreisbare, beobachtbare und überprüfbare Grenze. Gefährlich ist ein Eigenschaftsname ohne Eigentümer und Ablaufdatum: Er macht aus einem bedingten Ergebnis dauerhafte Organisationsgeschichte.

Quellen