Cryptography Reference
In-Depth Information
tiert, genauer, existierte (siehe unten). Dieses Orakel gibt bei Eingabe eines Chiffretextes
c lediglich zurück, ob c PKCS#1-konform ist oder nicht. Ein Chiffretext c ist PKCS#1-
konform , falls die Entschlüsselung c d mod n einen Bitvektor von der Form (6.4.7) liefert.
Mit einem solchen Orakel und etwa einer Million geschickt gewählter Orakelanfragen ge-
lingt es einem Angreifer, einen gegebenen Chiffretext c auch ohne Kenntnis des privaten
Schlüssels zu entschlüsseln! Die grobe Idee des Angriffs ist, dass durch geeignete Wahl
der Orakelanfragen potentielle Klartexte in einer Art Intervallschachtelung immer weiter
eingegrenzt werden, so dass am Ende nur noch der Klartext zu c übrig bleibt.
Wie erwähnt, ist der Angriff von Bleichenbacher deshalb besonders ernstzunehmen,
weil das geforderte Dechiffrierorakel in der Praxis existiert(e), nämlich in Form des weit
verbreiteten kryptographischen Protokolls SSL 3.0, welches einen sicheren Kanal zwischen
einem Client und einem Server etabliert, und als solches für die sichere Kommunikation
in Web-Browsern eingesetzt wird. In der Schlüsselaustauschphase von SSL 3.0 sendet der
Client u. a. einen im PKCS#1-Standard verschlüsselten Sitzungsschlüssel an den Server,
den Client und Server dann zur sicheren Kommunikation verwenden. Wenn der Server den
verschlüsselten Sitzungsschlüssel empfängt, entschlüsselt er den Chiffretext zunächst mit
seinem privaten Schlüssel und testet dann, ob der erhaltene Klartext PKCS#1-konform
ist, d. h. von der Form (6.4.7) ist, und ob der darin enthaltene Nutztext x das richtige
im SSL 3.0 festgelegte Format hat. Ist beides der Fall, wird der Server das Protokoll
einfach fortsetzen. Ist aber der Klartext nicht PKCS#1-konform oder stimmt das For-
mat des Nutztextes nicht, so hängt es von der konkreten Implementation von SSL 3.0
ab, wie der Server reagiert. Der SSL 3.0 Standard lässt (genauer ließ) einen gewissen
Spielraum. In einigen Implementationen gibt der Server Fehlermeldungen zurück, die dar-
über Aufschluss geben, welcher der beiden Fälle eingetreten ist - der Klartext ist nicht
PKCS#1-konform oder das Format des Nutztextes stimmt nicht. Damit kann SSL 3.0
aber als Dechiffrierorakel, wie es der Bleichenbacher-Angriff benötigt, missbraucht wer-
den und der Bleichenbacher-Angriff ist möglich! Nachdem dieser Angriff bekannt wurde,
wurden die Implementationen von SSL 3.0 geändert, so dass die Fehlermeldungen keinen
Aufschluss mehr über PKCS#1-Konformität zulassen.
Aufgrund des Bleichenbacher-Angriffs hat man sich verstärkt praktikablen Alternati-
ven zu PKCS#1 zugewandt, die volle CCA-Sicherheit bieten. Eine solche Alternative,
die Eingang in PKCS#1 v2.1 gefunden hat, ist das urspünglich von den Kryptographen
Mihir Bellare und Phillip Rogaway 1994 entwickelte OAEP-Verfahren ( optimal asymme-
tric encryption padding ). Dabei werden Klartexte zunächst mit Hilfe von Hashfunktionen
transformiert, bevor sie mit dem RSA-Verfahren (oder einer anderen Familie von Einweg-
funktionen mit Hintertür) verschlüsselt werden. Modelliert man die Hashfunktionen als
zufällige Funktionen ( Random Oracles ), dann kann man zeigen, dass OAEP unter der
RSA-Annahme CCA-Sicherheit bietet. Random Oracles werden uns auch im Kontext
digitaler Signaturen noch begegnen.
6.5
ElGamal
Das ElGamal genannte asymmetrische Kryptoschema wurde 1984 von Taher ElGamal
veröffentlicht und basiert auf einem Schlüsselvereinbarungsprotokoll, welches Die und
Search WWH ::




Custom Search