Zusammenfassung

  • RFC 3218 behandelte Fehlermeldung, Antwortverhalten und Laufzeit als kryptografische Ausgaben. War ein fehlerhafter RSAES-PKCS1-v1_5-Block von einem korrekt formatierten Block mit falschem Content-Encryption Key zu unterscheiden, konnte die Differenz adaptiv ausgefragt werden.
  • Beim Random Filling ersetzte der Empfänger ein ungültiges Unwrap-Ergebnis durch einen neuen Zufalls-CEK in der erwarteten Länge und führte Inhalts- und Integritätsprüfungen fort. Der Ersatzschlüssel war absichtlich falsch; er ließ den frühen Fehler wie das gewöhnliche Scheitern an einem falschen Schlüssel aussehen.

Der Angreifer musste den Klartext nicht sehen. Es genügte, wenn der Empfänger verriet, ob der noch verborgene Klartext die richtige Form hatte.

Daniel Bleichenbacher zeigte 1998, dass dieses eine Bit einen adaptiven Chosen-Ciphertext-Angriff auf PKCS #1 v1.5 tragen konnte. Ein Angreifer fing einen RSA-Chiffretext ab, transformierte ihn mathematisch und legte den neuen Wert dem Besitzer des privaten Schlüssels vor. Aus dessen Verhalten las er, ob der entschlüsselte Block konform war. Jede Antwort verkleinerte den Zahlenbereich, in dem der geheime Wert liegen konnte. Der private Schlüssel verließ das System nie; die wiederholten Entscheidungen des Systems erledigten dennoch einen Teil der Entschlüsselungsarbeit nach außen.

RFC 3218 übertrug die Gefahr auf die Cryptographic Message Syntax. Das Dokument erschien im Januar 2002 als Informational RFC. Es definierte weder ein neues Nachrichtenformat noch behauptete es, jeder RSA-Einsatz sei gleich. Es löste ein Übergangsproblem: CMS-Software transportierte den symmetrischen Schlüssel für den Inhalt bereits mit RSA PKCS #1 v1.5, und diese installierte Interoperabilität ließ sich nicht schlagartig ersetzen.

Der v1.5-Block folgte einer strengen Grammatik: 00 02, mindestens acht zufällige Nichtnull-Oktette, ein Trenner 00 und schließlich der transportierte Wert. In CMS war dieser letzte Wert der Content-Encryption Key, kurz CEK. Eine abgeschlossene RSA-Operation mit dem privaten Schlüssel konnte somit Bytes liefern, ohne einen gültigen Transportblock zu liefern.

Mehrere Tatsachen mussten getrennt bleiben. Die RSA-Operation war abgeschlossen. Das PKCS-#1-Format war gültig oder ungültig. Der CEK passte zu Algorithmus und Länge. Er war oder war nicht derselbe Schlüssel wie beim Absender. Die Inhaltsentschlüsselung gab Bytes aus. Padding, MAC, Signatur und Anwendung akzeptierten oder verwarfen sie. Intern brauchte die Software diese Unterschiede; extern durften sie nicht zur Abfrageschnittstelle werden.

Der Name Million Message Attack beschrieb eine operative Größenordnung. Ausgehend von einem abgefangenen Chiffretext C wählte der Angreifer einen Faktor S und sandte C' = C * S^e mod n. RFC 3218 schätzte, dass ungefähr eine von 2^16 Transformationen einen Klartext mit 00 02 am Anfang erzeugte. Unter den betrachteten CMS-Bedingungen konnte der Gesamtaufwand in der Größenordnung von 2^20 Nachrichten und Antworten liegen.

Die Million war keine exakte Vorgabe für jeden Schlüssel und Server. Sie zeigte, wie Automatisierung die Kosten veränderte. Eine Million menschlicher Rückfragen wären teuer und auffällig. Ein Mailinglisten-Agent, Gateway oder unbeaufsichtigter Dienst konnte dagegen jede Eingabe maschinell entschlüsseln, klassifizieren und beantworten. Der Angreifer lieferte Verkehr; der Empfänger lieferte Wiederholung.

Nach einer Anfrage konnte der PKCS-#1-Block fehlerhaft sein. Er konnte korrekt aussehen und trotzdem einen erfundenen CEK enthalten. Der falsche CEK konnte an einer Integritätsprüfung scheitern. Bei nicht authentisiertem CBC-Inhalt konnten Zufallsbytes sogar zufällig wie gültiges Padding enden. Dass eine Angriffstransformation den echten CEK ergab, war äußerst unwahrscheinlich.

Der Angriff musste diese Fälle nicht alle benennen. Er musste nur den ersten, den Formatfehler, von den späteren Fehlern eines formal gültigen, aber falschen Schlüssels trennen. Verschiedene Fehlermeldungen konnten das Bit liefern. Antwort statt Schweigen, Verbindungsabbruch, Mail-Bounce, Signaturalarm oder ein reproduzierbarer Zeitunterschied taten es ebenfalls.

Die zentrale Gegenmaßnahme in RFC 3218 hieß Random Filling. Erkannte die PKCS-#1-Decodierung ein ungültiges Format, brach der Empfänger dort nicht ab. Er erzeugte einen kryptografisch zufälligen CEK in der für den Inhaltsalgorithmus erwarteten Länge und behandelte ihn so, als hätte RSA diesen Wert ausgepackt.

Mit dem erfundenen Schlüssel versuchte der Empfänger die Inhaltsentschlüsselung und führte die normalen Padding-, MAC-, Signatur- und Anwendungsprüfungen aus. Der Zufalls-CEK führte fast sicher später zu einem gewöhnlichen Fehler. Sichtbare Meldung und Laufzeit sollten dem Pfad eines richtig formatierten Blocks mit bloß falschem CEK ähneln.

Der Zufalls-CEK war deshalb kein Wiederherstellungsschlüssel. Er rekonstruierte das Geheimnis des Absenders nicht, rettete den Inhalt nicht und autorisierte die Nachricht nicht. Er war wegwerfbarer Zustand, der die Ausführung zu einem üblichen Fehlerpunkt trug, ohne den früheren Grund offenzulegen. Seine funktionale Richtigkeit bestand darin, unvorhersehbar und nahezu sicher falsch zu sein.

Ein fester Fallback-CEK hätte diesen Schutz umgekehrt. Eine Konstante wirkte für reproduzierbare Tests bequem und sparte den Zufallsgenerator im Fehlerfall. Ein Angreifer, der die Konstante kannte, konnte jedoch CMS-Inhalt damit verschlüsseln und einen absichtlich fehlerhaften RSA-Transport beilegen. Nahm der Empfänger den Fallback-Pfad, wurde der Inhalt gültig verarbeitet; andernfalls scheiterte er. Die Tarnung schuf ein schärferes Orakel.

Der Ersatzwert musste bei jeder Verwendung neu, kryptografisch unvorhersehbar und korrekt lang sein. Wiederverwendung hätte dem unsichtbaren Zweig eine stabile Identität gegeben, die präparierter Inhalt erkennen konnte.

Auch der Zeitpunkt der Zufallserzeugung konnte sprechen. War der Generator langsam und wurde nur nach einem Fehler aufgerufen, markierte seine Laufzeit den Pfad. RFC 3218 schlug deshalb vor, für jede Nachricht einen Zufallskandidaten zu erzeugen und ihn nach einem gültigen Unwrap wegzuwerfen. Erfolg und Fehler trugen dann ähnliche Kosten.

Damit war keine universelle konstante Laufzeit bewiesen. Speicherzugriffe, Parser, Logging, Arbeitswarteschlangen, Netzwerkantworten und Anwendungsaktionen konnten weiterhin auseinanderlaufen. Die Empfehlung verhinderte, dass eine einheitliche Fehlermeldung einen offensichtlichen Rechenzweig verdeckte.

Die CEK-Länge erzeugte eine weitere Schichtgrenze. Eine allgemeine RSA-Bibliothek konnte das Format prüfen, ohne zu wissen, ob die Anwendung 8, 16, 24 oder 32 Byte erwartete. Gab sie den Wert zurück und verwarf eine höhere CMS-Schicht eine falsche Länge mit einer besonderen Ausnahme, wanderte das Orakel nur nach oben.

Auch die Schicht mit Kenntnis des Inhaltsalgorithmus musste Werte falscher Länge zufällig ersetzen. Die Sicherheitseigenschaft verlief über Softwaregrenzen. Die unterste kryptografische Primitive konnte nicht allein garantieren, was Kontext aus einer höheren Schicht erforderte.

Genauere Prüfungen erhöhten den Aufwand: alle Padding-Oktette kontrollieren, CEK-Länge prüfen und bei DES-Familien gegebenenfalls Paritätsbits auswerten. Jede zusätzliche Bedingung verringerte die Chance, dass eine zufällige Transformation akzeptiert wurde.

Ein seltenes Orakel blieb jedoch ein Orakel. Verriet die Antwort, welche Bedingung scheiterte, konnte der Angreifer mit höherem Aufwand weiter dasselbe Bit sammeln.

Nicht authentisierter CBC-Inhalt zeigte zudem, wie schwach „Entschlüsselung lieferte Daten“ als Beleg war. Zufälliger Klartext konnte scheinbar korrektes Padding besitzen. Betrachtete eine Implementierung nur das letzte Byte als Abschneidelänge, schätzte RFC 3218 die scheinbare Gültigkeit auf etwa 1/32. Eine Prüfung aller geforderten Padding-Bytes senkte sie in Richtung 1/255.

Keine dieser Koinzidenzen machte den Zufallsinhalt sinnvoll. MAC oder Signatur boten einen stärkeren späteren Ablehnungspunkt. Sie erlaubten trotzdem nicht, das anfängliche PKCS-#1-Urteil gesondert zu veröffentlichen; der Schutz beruhte darauf, diesen Zweig in späteren Fehlern aufgehen zu lassen.

OAEP bot eine sauberere kryptografische Richtung. PKCS #1 v2.0 hatte RSAES-OAEP spezifiziert, und RFC 3218 erklärte den diskutierten Angriff dort für nicht anwendbar. OAEP war aber auf dem Draht nicht mit v1.5 kompatibel. Absender, Empfänger, Zertifikate, Algorithmuskennungen und installierte CMS-Software mussten gemeinsam wechseln.

Die bessere Primitive zu benennen schaltete das alte Ökosystem nicht ab. Random Filling war eine Koexistenzmaßnahme: Solange das Legacy-Format Verkehr annahm, musste begrenzt bleiben, was sein Fehlerpfad nach außen sagte.

TLS hatte eine verwandte Gefahr bei RSA-verschlüsselten Premaster Secrets behandelt. Seine Spezifikationen ließen den Server mit einem Zufallswert fortfahren, statt Format- oder Versionsfehler zu verraten. Das Prinzip war verwandt, die späteren Spuren aber protokollspezifisch. TLS-Handshake, CMS-Nachricht und Mail-Agent hatten verschiedene Zustandsautomaten und Reaktionen.

Die allgemeine Disziplin lag oberhalb von RSA: Ein interner Parser darf keine Frage beantworten, die das äußere Protokoll nicht sicher beantworten kann. Das Protokoll muss festlegen, welche Arbeit weiterläuft, welche endgültige Ablehnung erscheint und welche Seitenkanäle angeglichen werden.

RFC 3218 behauptete nicht, Random Filling authentisiere Absender, entferne jeden Timing-Kanal, repariere kompromittierte private Schlüssel oder beweise die Sicherheit einer Implementierung. Es lieferte auch keine Einsatzstatistik. Seine Aussage war enger und dauerhafter: Kann ein innerer Unterschied wiederholt abgefragt werden, gehört die Fehlerbehandlung zum Kryptosystem.