Zusammenfassung

  • Im Angriffsszenario der RFC 2405 genügte eine kürzere Schlüssellebensdauer nicht: IP-Datagramme beginnen häufig mit bekanntem oder erratbarem Headertext.
  • DES-CBC bot Vertraulichkeit, keine Authentifizierung. IV, Schlüsselrecherche, Integrität und die Verwaltung von Security Associations behandelten verschiedene Probleme.

Eine Lebensdauer ohne allgemeine Stoppuhr

Die im November 1998 veröffentlichte RFC 2405 spezifizierte DES im CBC-Modus als Vertraulichkeitsmechanismus für ESP. Sie schrieb weder eine feste Zeitspanne noch eine allgemeine Datenmenge pro Schlüssel vor. Stattdessen sollte die Entscheidung vom Wert der geschützten Information und einer Einschätzung der Angreiferressourcen abhängen. Das ist eine Risikobewertung, keine Zusage, dass planmäßiger Schlüsselwechsel den Algorithmus widerstandsfähig macht.

Das Dokument nannte den Grund: Ein Entwurf für eine eine Million US-Dollar teure DES-Knackmaschine sollte nach einer Schätzung von 1993 einen Schlüssel in dreieinhalb Stunden wiederfinden können. Außerdem beginnen IP-Datagramme oft mit bekanntem oder leicht erratbarem Headertext. Die Schlussfolgerung der RFC bezog sich genau auf dieses Szenario: Häufiger Schlüsselwechsel würde den beschriebenen Known-Plaintext-Angriff nicht verhindern. Das sind historische Angaben aus der 1998 veröffentlichten RFC, keine heutigen Preise, Benchmarks oder Testergebnisse.

Als damalige Einschränkung hielt sie fest, dass DES-CBC immerhin mehr Privatsphäre als eine Übertragung im Klartext bot.

Drei Schutzfunktionen, drei Aufgaben

Jedes ESP-Datagramm enthielt einen expliziten Initialisierungsvektor von acht Oktetten. Die RFC verlangte einen zufälligen Wert und untersagte einen Zähler oder eine Quelle mit geringer Hamming-Distanz zwischen aufeinanderfolgenden Werten. Dadurch konnte der Empfänger ein Datagramm selbst dann entschlüsseln, wenn ein anderes verloren ging oder umgeordnet wurde. Dieser paketbezogene Startpunkt authentifizierte den Chiffretext nicht und verteuerte die Suche nach einem DES-Schlüssel nicht.

RFC 2405 stellt ausdrücklich klar, dass DES-CBC kein Authentifizierungsmechanismus ist. Sie rät dringend davon ab, die Verschlüsselung ohne passende Authentifizierung einzusetzen, und beschreibt CBC-Cut-and-Paste-Angriffe. Authentifizierung kann das Integritätsproblem adressieren; Schlüsselwechsel ist kein Ersatz dafür. Vertrauen hing außerdem von Algorithmus, Implementierung, Verwaltung der Security Associations, Schlüsselstärke und allen beteiligten Knoten ab.

Von „muss implementiert werden“ zu „MUST NOT“

Spätere ESP-Algorithmusanforderungen änderten ihre Einstufung schrittweise. RFC 4305 führte DES-CBC als „SHOULD NOT“, nachdem frühere Anforderungen die Implementierung verlangt hatten. RFC 4835 behielt diese Stufe bei; RFC 7321 änderte sie zu „MUST NOT“; RFC 8221 setzte das fort. Diese Folge dokumentiert datierte Interoperabilitätsanforderungen, nicht den Tag, an dem jedes Gerät DES abgeschaltet hätte.

Ein Standard kann künftigen Kompatibilitätsdruck senken, aber installierte Systeme nicht automatisch entfernen. Spezifikation, lokale Konfiguration, ausgehandelter Transform, authentifizierte Paketverarbeitung und gemessene Nutzung sind verschiedene Belege. Keiner folgt allein aus einem Absatz zur Schlüssellebensdauer.

Quellen