[Datenschleuder] [63]    SSL Attacke

SSL Attacke In den letzten Tagen ging eine SSL-Attacke durch die Presse. Die Kurzzusammenfassung ist, daß das dem SSL-Protokoll zugrundeliegende PKCS1-Protokoll von RSA, Inc. ein Padding definiert, über die eine Chosen Plaintext Attacke lanciert werden kann. Aber der Reihe nach. PKCS1 ist der Public Key Cryptography Standard #1. So nennt RSA großspurig ihre eigenen Standards. Darin wird eine ganze Sammlung von Verschlüsselungsverfahren definiert, eine Protokoll-Suite sozusagen. Natürlich besteht diese praktisch ausschließlich aus RSA-Produkten. Unter anderem definiert PKCS1 auch ein Protokoll zum Schlüsselaustausch. Krypto-Protokolle basieren meistens auf asymmetrischen und symmetrischen Verschlüsselung, wobei man der Geschwindigkeit wegen ein symmetrisches Verfahren mit einem zufällig generierten Schlüssel (genannt "Session Key") benutzt, und diesen mit der langsameren asymmetrischen Verschlüsselung austauscht. Der Punkt dabei ist, daß man zum Entschlüsseln einer geheimen Nachricht nicht den privaten Schlüssel des Servers knacken muß, sondern es reicht, diesen Schlüssel für das innere, symmetrische Verfahren zu bekommen. Dieser ist aber zufällig gewählt und geht nur verschlüsselt über das Netz, und bei einer Schlüssellänge von 128 Bit kann heute und in absehbarer Zeit niemand einen Schlüssel erraten, indem er alle Möglichkeiten ausprobiert, weil das zu lange dauern würde. Der Total-Angriff auf SSL2 wäre, den privaten Server-Schlüssel zu klauen, weil man dann die komplette Kommunikation abhören kann. Der von Bleichenbacher beschriebene Angriff geht aber nicht so weit, sondern er kann nur einen Session Key herausfinden, und damit eine einzelne Nachricht entschlüsseln. Der Angriffspunkt ist der Schlüsselaustausch, der bei SSL aber nicht bei S/MIME oder SET oder anderen PKCS1-Protokollen auftritt. Die Idee ist, daß PKCS1 einige Felder definiert, bei denen nicht alle Möglichkeiten vergeben sind. Der Angriff besteht jetzt daraus, daß manche Server zuerst das Padding überprüfen, bevor sie schauen, ob die Message überhaupt korrekt entschlüsselt werden konnte. SSL sieht auch eine MAC-basierte Validierung vor, anhand derer man später entscheiden kann, ob die Nachricht korrekt ankam. PKCS1 sieht vor, daß RSA-Nachrichten mit 0x00 0x02 0x??{8,n-m-3} 0x00 0x??{m} anfangen. Die Attacke baut jetzt n Verbindungen zum Server auf. Bei SSL wählt der Client den Session Key aus und teilt ihn dem Server mit dessen öffentlichem Schlüssel (den der Server mitschickt) verschlüsselt mit. Der Angreifer kann jetzt Aussagen über den Session Key machen, indem er Verbindungen aufbaut, die geratene Session Keys hinschicken. Theoretisch müßte der Angreifer alle 128 Bit durchprobieren und schauen, ob das beobachtete Paket herauskommt, wenn er es mit dem public Key des Servers verschlüsselt. Nun hat RSA aber die Eigenschaft, daß man einen Cyphertext komplett entschlüsseln kann, wenn man einige Bits vorhersagen kann. Wenn man jetzt ein ungültiges Paket hinschickt, bei dem aber die beiden festen Bytes am Anfang stimmen, und der Webserver dann eine andere Fehlermeldung als "padding kaputt" zurückliefert, weiß man, daß die ersten beiden Bytes des Plaintextes 0x00 0x02 waren. Der Angreifer kann also manche Bits des Plaintexts bei chosen ciphertext (die Pakete, die er hinschickt) vorhersagen und ist damit ein informationstheoretisches Orakel. Das reicht, um den Plaintext komplett zu recovern. Das Problem ist also, daß man gute Ciphertexte viel wahrscheinlicher generieren kann, wenn man schonmal einen guten hat. Den ersten kriegt man aber nur durch Ausprobieren. Bei der momentanen PKCS1 Implementation liegen die Chancen, einen guten zu raten, bei 1:2^16 bis 1:2^18. Ein Ciphertext ist gut, wenn er 0x00 0x02 am Anfang generiert beim Entschlüsseln. RSA gibt an, daß man ungefähr 20 Millionen Fake-Nachrichten an den Server schicken muß, um den Session-Key der einen mitgelauschten Verbindung zu bekommen und damit die Verbindung entschlüsseln zu können. Praktisch gesehen ist die Attacke damit keine sonderliche Bedrohung, aber man sollte natürlich trotzdem etwas dagegen unternehmen. Wenn jemand gegen einen Web-Server diese Attacke fährt, sammeln sich etwa 300 Megabyte im Fehler-Log mit Meldungen, die einen falsches Padding andeuten. Für einen Webmaster ist also ziemlich klar, wenn sein Server unter Attacke ist, weil die Logs die Platte zum Überquellen bringen. Es bleibt noch, anzumerken, daß eine erfolgreiche Attacke dieser Art nur diesen einen Session Key kompromittiert, und bei späteren Attacken gar nicht hilft. Der Fix ist natürlich ziemlich trivial: man prüft die Padding-Konsistenz erst, wenn die MAC gestimmt hat. Unter diesen Umständen ist nicht direkt einsehbar, wieso IBM eine Fix-Zeit von einer ganzen Woche angekündigt hat für ihren SSL-Webserver. Leider gelang es mir nicht, das tatsächliche Paper zu finden. In Umlauf gebracht wurde das Problem von einer Rundmail der Firma C2, die die Käufer des Stronghold SSL-Servers gewarnt hat, sie mögen bitte updaten. C2 ist von RSA kontaktiert worden, die von Bleichenbacher offenbar direkt angesprochen wurden. RSA hat inzwischen ein Bulletin 7 herausgegeben auf ihrer Website bei http://www.rsa.com/rsalabs/pkcs1/bulletin7.html. Felix von Leitner, felix@ccc.de

[Datenschleuder] [63]    SSL Attacke