Zusammenfassung

  • RFC 9709 führt die vollständige DER-Codierung des inneren AlgorithmIdentifier einschließlich seiner Parameter zusammen mit dem ursprünglichen Inhaltschlüssel in HKDF ein.
  • Eine Umschreibung von authentifizierter Verschlüsselung auf CBC oder eine Parameteränderung führt damit zu einem anderen Schlüssel statt zu einem brauchbaren Klartext-Orakel.
  • Die Maßnahme schützt Vertraulichkeit gegen diese Transformation; sie belegt weder Absender, Harmlosigkeit des Inhalts noch die Befugnis für Folgemaßnahmen.

Angegriffen wird die Auslegung

Der von LAMPS behandelte Angriff benötigt den Schlüssel nicht. Ein Vermittler fängt CMS-Inhalt ab, der mit AES-GCM oder AES-CCM geschützt ist, und verpackt ausgewählte Blöcke als AES-CBC. Verarbeitet das schlüsselhaltende System dieses geänderte Objekt und gibt Text, Fehler oder Verhalten preis, kann es Vermutungen über strukturierte Klartextblöcke mit geringer Entropie bestätigen.

Die praktische Reichweite ist begrenzt. Die Unterlagen von IETF 118 erläuterten, dass S/MIME häufig nur sichtbaren Datenmüll erzeugt, Header früh abgewiesen werden können und verwundbare Produkte nicht bekannt waren. Das sind jedoch Eigenschaften einzelner Anwendungen, keine kryptographische Grenze. Vorschauen, Konverter, Quittungen oder automatisierte Abläufe können genau das Signal liefern, das ein Mailprogramm unterdrückt.

RFC 9709 macht die Beschreibung zum Sicherheitseingang. Ein Empfänger kündigt id-alg-cek-hkdf-sha256 ohne Parameter als S/MIME-Fähigkeit an. Nutzt der Sender die Abwehr, steht diese OID im äußeren contentEncryptionAlgorithm. Dessen Pflichtparameter trägt den tatsächlichen inneren AlgorithmIdentifier: Inhaltschiffre und Parameter.

Beide Seiten leiten CEK-prime mit HKDF-SHA-256 ab. Die ursprüngliche CEK ist das geheime Eingangsmaterial. Als Salt dient die feste ASCII-Zeichenfolge “The Cryptographic Message Syntax”. info erhält die gesamte DER-Codierung des inneren Bezeichners: SEQUENCE-Tag, Länge, OID und codierte Parameter. Die Ausgabe ist so lang wie der Ausgangsschlüssel, bis zur Grenze von 8.160 Byte.

Die Bytegenauigkeit ist die Abwehr. Der Wechsel von GCM zu CBC, ein anderer Initialisierungsvektor oder eine andere Parameterdarstellung verändert info und damit den Schlüssel. Der für den ursprünglichen Schlüssel gebildete Chiffretext ist unter der vom Angreifer gewählten Auslegung kein nützlicher Versuch mehr. Entfernt der Angreifer die äußere OID ganz, nutzt der Empfänger die ursprüngliche CEK statt CEK-prime. Die Nachricht wird unzugänglich, ihr Klartext aber nicht offengelegt: Zugriffsverweigerung statt Vertraulichkeitsbruch.

Sieben Tatsachen getrennt halten

Ein belastbares Protokoll unterscheidet die angekündigte Fähigkeit, die empfangene äußere OID, inneren Algorithmus und Parameter, die tatsächlich an HKDF gegebenen DER-Bytes, authentifizierte Entschlüsselung und Prüfung zugehöriger Daten, jede Offenlegung über die Vertrauensgrenze sowie die nachgelagerte Regel für Speicherung, Anzeige oder Aktion.

Ein einziges „erfolgreich entschlüsselt“ verdeckt den Unterschied zwischen Kompatibilitätsfehler und Manipulation. Erfolgreiches Parsen beweist ebenso wenig die Urheberschaft. RFC 9709 trennt Schlüssel; es ersetzt weder Signatur noch Absenderreputation, Inhaltsprüfung oder Geschäftsfreigabe.

Auch authentifizierte Attribute bilden eine eigene Grenze. Ein unverschlüsselter Nachrichtendigest kann eine Klartextvermutung bestätigen. Unaufgeforderter verschlüsselter Inhalt kann Filter für Spam oder Phishing umgehen. Eine Liste zugelassener Absender ist eine mögliche Ergänzung, beantwortet jedoch die Zulassungsfrage statt der Algorithmusbindung.

Ein schmaler gemeinsamer Kern

Die Konstruktion legt SHA-256 fest und handelt keine KDF aus. Eine künftige Hashfunktion bräuchte eine neue OID. Damit bleibt die gemeinsame Regel deterministisch: Hülle erkennen, innere Codierung exakt erhalten, ableiten und gemäß innerem Verfahren authentifizieren oder entschlüsseln.

Übliche Schlüsselpflichten gelten weiter. CEKs brauchen gute Zufallsquellen und Schutz. RFC 5652, RFC 5083, RFC 5084, RFC 5869, RFC 8551 und RFC 4086 bleiben getrennte Grundlagen. Schwache Schlüssel, kompromittierte Geräte oder vorgetäuschte Identitäten werden durch RFC 9709 nicht vertrauenswürdig.

Zum Prüfzeitpunkt zeigte die RFC-Editor-Suche keine gemeldeten Errata für RFC 9709; das SMI-Register der IANA enthielt die Zuweisungen. Das belegt den formalen Koordinationsstand, nicht die Verbreitung.

Quellen