TLS stolpert über die "Glückliche 13"
Als "Lucky 13" firmiert ein Angriff auf die Technik, die Web-Verbindungen verschlüsselt. Er nutzt das Zeitverhalten beim Entschüsseln von TLS-Nachrichten aus. Bislang ist die Gefahr zwar noch gering, doch das könnte sich ändern, warnen die Forscher.
- Christian Kirsch
Britische Forscher des Royal Holloway College der Universität London haben ein Verfahren gefunden, mit dem sich per TLS gesicherte HTTP-Verbindungen entschlüsseln lassen. Dazu nutzen der Doktorand Nadhem AlFardan und Professor Kenny Paterson das Zeitverhalten des Verfahrens beim Entschlüsseln von TLS-Daten.
(Bild: Forschungsbericht )
In der Regel werden diese Datensätze im Cipher-Block-Chaining-Modus (CBC) verarbeitet. Dabei werden auf eine feste Länge mit Padding-Bytes aufgefüllte Blöcke verschlüsselt. Die Padding-Bytes enthalten jeweils einen Hinweis auf ihre Anzahl: So dienen etwa drei 0x2- oder acht 0x7-Bytes zum Auffüllen. Die kompletten Blöcke enthalten im Fall von TLS neben den eigentlichen Nutzdaten einen Message Authentication Code (MAC), der die Integrität der Daten sichern soll. Er bezieht jedoch das Padding nicht mit ein.
Ein Angreifer kann nun korrekt verschlüsselte Daten mitschneiden, manipulieren und dem Empfänger zum Entschlüsseln zusenden. Reagiert der mit einem Padding- statt mit einem MAC-Fehler, lässt sich diese Information zum sukzessiven Entschlüsseln der Daten verwenden. Ein Verfahren, das diesem "Padding Oracle" ähnelt, diente bereits zum Knacken einer XML-Verschlüsselung.
Auch SSL/TLS war für diese Padding-Oracle-Angriffe anfällig; diese Schwächen wurden jedoch durch Patches behoben. Aktuelle Versionen liefern schon keine Fehlermeldungen mehr, wenn die MAC-Prüfung fehlschlägt. Die Zeitunterschiede, an denen man erkennen konnte, ob das Padding falsch war, sollten ebenfalls ausgemerzt werden, indem der MAC auch bei falschem Padding berechnet wurde. Allerdings gibt es immer noch einen winzigen Zeitunterschied, weil das Entschlüsselungsverfahren dann nicht weiß, wie viele dieser Bytes es entfernen muss. In diesem Fall berechnet der Empfänger den MAC-Wert über den gesamten Block inklusive dem beschädigten Padding -- und das dauert etwas länger, als wenn das Padding nicht in dessen Berechnung einbezogen wird.
In ihrer Untersuchung (PDF-Dokument) zeigen AlFardan und Paterson nun, dass sich diese geringe Zeitdifferenz unter bestimmten Umständen ausnutzen lässt, um die Daten komplett zu entschlüsseln. Denn TLS benutzt immer HMACs, die jeweils den Hashwert für höchstens 55 Bytes berechnen. Der Angriff nutzt Nachrichten, die mit Padding länger und ohne kürzer als diese 55 Bytes sind. Ist das Padding beschädigt, braucht der Entschlüsselungsprozess etwas länger, da er HMAC-Werte sowohl für die ersten 55 Bytes als auch für den Rest berechnen muss.
Die beiden Forscher führten diesen Angriff in einem LAN aus und konnten einen Klartext nach 223 TLS-Sessions entschlüsseln, wenn SHA1 als HMAC-Algorithmus verwendet wurde. War bekannt, dass es sich um einen Base64-kodierten Text handelte, sank die Anzahl der Sessions auf 219. Für einen praktikablen Angriff auf TLS reiche das noch nicht, das verwandte DTLS (Datagram TLS) lasse sich jedoch damit schon angreifen. Es beendet nämlich eine Session nicht sofort bei einem Fehler, wie das TLS tut.
Bislang lassen sich die beschriebenen Angriffe nur aus einer geringen Entfernung ausführen und nur, wenn der Angreifer genügend Sessions erzeugen kann. Deshalb, so AlFardan und Paterson, "bildet der Angriff keine wesentliche Gefahr für normale TLS-Nutzer." Es sei allerdings eine Binsenweisheit, dass Attacken mit der Zeit besser würden, "und wir können nicht vorhersehen, welche Verbesserungen an unserem Verfahren oder welche gänzlich neuen Methoden noch entdeckt werden."
Der für das Verfahren gewählte Name "Lucky 13" bezieht sich auf die 13 Header-Bytes, die in die Berechnung des MAC-Werts einfließen. Abwehrmaßnahmen sind für einige TLS-Implementierungen bereits verfügbar (GnuTLS, PolarSSL, CyaSSL, Opera und BouncyCastle). Andere Entwickler arbeiten noch daran (OpenSSL, Firefox' NSS). Microsofts Implementierung ist nach eigenen Angaben nicht betroffen. Apple wurde von den Wissenschaftlern informiert, hat sich jedoch nicht geäußert.
Update 5.2.13 16:00: Die OpenSSL-Entwickler haben inzwischen die aktualisierten Versionen 1.0.1d, 1.0.0k und 0.9.8v bereitgestellt, die "Lucky 13" ausschließen sollen. Die Lücke hat die Kennung CVE-2013-0169 erhalten (ck)
