Zusammenfassung

  • Ein KeyUpdate setzt den Sendeschlüssel einer Seite und den zugehörigen Empfangsschlüssel des Peers fort. Die Gegenrichtung behält ihre Generation, bis sie eine eigene Aktualisierung vollzieht.
  • Das Löschen alter Generationen kann frühere Daten vor einer späteren Offenlegung schützen. Wer jedoch das aktuelle Geheimnis kennt, kann daraus künftige Generationen ableiten; Rotation ist deshalb keine Wiederherstellung nach Kompromittierung.

Die Sitzung bleibt, der Verbrauchszähler nicht

Der Handshake vermittelt leicht den Eindruck einer einmaligen Schlüsselentscheidung. Für kurze Verbindungen genügt dieses Bild. Bei einer langlebigen HTTP/2- oder API-Verbindung wächst jedoch die Zahl der Records, die derselbe AEAD-Schlüssel schützt. Die Vertraulichkeits- und Integritätsgrenzen authentifizierter Verschlüsselung hängen auch von diesem Umfang ab.

RFC 8446 empfiehlt daher ein Update, bevor die jeweils geltenden Nutzungsgrenzen erreicht werden. RFC 9325 fordert langlebige Anwendungen ebenfalls dazu auf, eine Erneuerungsstrategie zu bedenken. Eine universelle Zeitspanne oder Bytezahl folgt daraus nicht; Algorithmus und tatsächliche Last bleiben maßgeblich.

Ältere TLS-Versionen kannten die Neuverhandlung. Sie konnte mitten in einer bestehenden Verbindung mehrere Entscheidungen erneut öffnen, einschließlich kryptografischer Parameter und Authentifizierung. TLS 1.3 entfernte dieses breite Instrument. KeyUpdate wählt weder Version noch Cipher Suite neu, ersetzt kein Zertifikat und verändert keine Anwendungsidentität. Es erneuert ausschließlich Geheimnisse für den Anwendungsverkehr.

Die alte Generation übermittelt ihre Ablösung

Der Sender verschlüsselt die KeyUpdate-Nachricht noch mit seinem bisherigen Sendeschlüssel. Alle danach gesendeten Records verwenden den neuen. Der Empfänger authentifiziert die Anweisung mit seinem aktuellen Empfangszustand und leitet anschließend den nächsten Empfangsschlüssel ab.

Damit liegt die Epochengrenze in der geschützten Reihenfolge selbst. Keine externe Uhr muss einen Umschaltzeitpunkt erraten. Die Implementierung muss aber exakt folgen: Ein verfrühter Wechsel macht die Nachricht unlesbar, ein verspäteter den ersten neuen Record.

Außerdem ist die Grenze gerichtet. Client- und Serververkehr besitzen getrennte Geheimnisse. Wenn eine Seite ihr Senden aktualisiert, schreitet auf der Gegenseite nur der passende Empfangszustand fort. Der Rückweg bleibt unverändert.

Mit update_not_requested endet der Vorgang dort. update_requested bittet den Peer, eine eigene KeyUpdate-Nachricht ohne weitere Rückanforderung zu senden. Erst diese zweite Nachricht bewegt die Gegenrichtung. Zwei unabhängig ausgelöste Anforderungen können sich kreuzen; beide müssen korrekt beantwortet werden. Eine weitere Anforderung darf jedoch nicht vor der ausstehenden Antwort folgen. Updates vor Finished sind unzulässig, und übermäßige Nachrichten müssen begrenzt werden.

Einwegableitung hat zwei verschiedene Aussagen

Nach sicher abgeschlossenem Übergang kann ein Endpunkt das alte Geheimnis vernichten. Erlangt ein Angreifer später nur eine neuere Generation, liefert ihm die Einwegableitung nicht automatisch deren Vorgänger. Alte aufgezeichnete Chiffrate können deshalb trotz späterer Offenlegung geschützt bleiben.

In Vorwärtsrichtung gilt das Gegenteil: Aus dem aktuellen Verkehrsgeheimnis lassen sich seine Nachfolger berechnen. KeyUpdate bringt keine unabhängige Entropie ein und authentifiziert den Peer nicht erneut. Ein Angreifer mit dem gegenwärtigen Geheimnis kann die regulären Endpunkte entlang derselben Kette begleiten.

Die Reaktion muss also vom Anlass abhängen. Eine bevorstehende AEAD-Nutzungsgrenze verlangt eine neue Generation. Der Verdacht auf Offenlegung des aktuellen Geheimnisses verlangt Abbruch und einen frischen Handshake. Wer beides als erfolgreiche „Rotation“ protokolliert, kann fortgesetzte Kompromittierung als Wartungserfolg missverstehen.

HTTP/2 ließ den Schlüssel wechseln, nicht die Identität

In einer HTTP/2-Verbindung laufen viele Streams zugleich. Eine nachträgliche Änderung der verbindungsweiten Identität ließe sich den einzelnen Requests nur schwer sicher zuordnen. Deshalb untersagt RFC 9113 die TLS-1.3-Post-Handshake-Authentifizierung für HTTP/2.

KeyUpdate ist dagegen erlaubt. Eine neue Record-Schutzgeneration verändert unmittelbar weder Identität noch Autorisierung eines Requests. Die Streams laufen weiter, während eine kryptografische Richtung fortschreitet. Gerade der enge Zuständigkeitsbereich macht die Operation multiplexing-tauglich.

QUIC übernimmt diesen Mechanismus nicht. RFC 9001 verbietet TLS-KeyUpdate-Nachrichten in QUIC. Weil Datagramme umgeordnet eintreffen können, nutzt QUIC das Key-Phase-Bit und eigene Bestätigungsregeln. Das Ziel ähnelt sich; das an den geordneten TLS-Recordstrom gebundene Verfahren ist nicht universell.

Erneuerung ohne Freispruch

KeyUpdate bestätigt kein neues Vertrauen, ändert keine Berechtigung, setzt keine Anwendung zurück und beendet keinen Sicherheitsvorfall. Es ordnet gerichtete Generationen von Verkehrsgeheimnissen in derselben fortlaufenden Verbindung.

Seine historische Bedeutung liegt in dieser Begrenzung. TLS 1.3 trennte die routinemäßige Schlüsselpflege von der umfassenden Neuverhandlung. Ein Schlüssel kann für seine Nutzung neu sein und dennoch kryptografisch von der Vergangenheit abstammen.

Quellen und Grenzen

Grundlagen sind RFC 8446, RFC 9001, RFC 9113 und RFC 9325. Sie belegen weder heutige Verbreitung noch Bibliotheksvorgaben oder ein für alle Dienste gültiges Update-Intervall.