Dan J. Bernstein
Dan J. Bernstein (Bild: Alexander Klink / Wikipedia (CC BY 3.0))

SSL/TLS: Schwächen in RC4 ausnutzbar

Ein Team um den Kryptografen Dan Bernstein präsentiert neue Sicherheitsprobleme in der von TLS genutzten RC4-Stromverschlüsselung. Praktisch umsetzbar ist der Angriff nur in seltenen Fällen, die Autoren rechnen aber damit, dass er künftig noch verbessert wird.

Anzeige

Seit gestern macht eine Präsentation des Kryptografen Dan J. Bernstein Furore. Was Bernstein berichtet, hat Sprengkraft: Auf der aktuell stattfindenden Konferenz Fast Software Encryption in Singapur stellt der Professor der University of Illinois einen Angriff gegen die RC4-Verschlüsselung in TLS vor.

TLS (oft noch unter dem alten Namen SSL bekannt) ist das mit Abstand am häufigsten genutzte Verschlüsselungsprotokoll im Internet. Jedes Mal, wenn eine Webseite über https aufgerufen wird, kommt TLS zum Einsatz. Zuletzt geriet das Protokoll stark unter Beschuss.

RC4: Schnell, aber nicht besonders sicher

Dass RC4 kein besonders sicheres Verschlüsselungsverfahren ist, ist schon länger bekannt. Es handelt sich dabei um eine sogenannte Stromverschlüsselung, die ursprünglich vom Kryptografen Ron Rivest entwickelt wurde. Rivest hatte eigentlich keine Veröffentlichung von RC4 geplant, aber 1994 wurde der Quellcode der RC4-Verschlüsselung auf einer Mailingliste anonym veröffentlicht. RC4 erfreute sich schnell großer Beliebtheit, denn es ist relativ simpel zu implementieren und arbeitet sehr schnell.

Bei einer Stromverschlüsselung wird durch einen Pseudozufallszahlengenerator ein Schlüsselstrom erzeugt, der mit dem zu verschlüsselnden Text per XOR verknüpft wird. Das Problem von RC4: Der Zufallsstrom ist nicht immer zufällig. Schnell fanden Kryptografen heraus, dass an bestimmten Stellen im Schlüsselstrom bestimmte Bits mit einer höheren Wahrscheinlichkeit auftauchen.

Genau diese Schwäche nutzt nun der neue Angriff aus. Notwendig für den Angriff ist eine große Zahl von Datenblöcken, die mit denselben Daten anfangen. Das ist beispielsweise bei HTTPS-Verbindungen oft der Fall. Die Autoren sprechen von 2 hoch 30 Datenverbindungen, was mehrere GByte an Daten bedeuten würde. Aber bereits bei 2 hoch 24 Verbindungen könne man Rückschlüsse auf bestimmte Bytes im Datenstrom ziehen. Für einen Angriff auf Webapplikationen ist das unter Umständen bereits genug. Details des Angriffs wollen die Autoren in Kürze in einem Paper veröffentlichen.

Wie praktikabel ein solcher Angriff in realen Szenarien ist, wird sich also erst noch zeigen, aber die Autoren warnen schon jetzt, dass sie auf jeden Fall damit rechnen, dass weitere Forschung die Angriffe noch deutlich verbessern wird.

Auch CBC hat Schwächen

TLS unterstützte eine ganze Reihe unterschiedlicher Verschlüsselungsalgorithmen. RC4 ist das einzige unterstütze Stromverschlüsselungsverfahren, alle anderen Verfahren wie AES, Triple-DES oder Camellia sind sogenannte Blockverschlüsselungen. In der bis heute meistens eingesetzten TLS-Version 1.0 und auch beim Nachfolger TLS 1.1 nutzen alle Blockchiffreverfahren den sogenannte Cipher Block Chaining-Modus (CBC). Die Angriffe BEAST und Lucky Thirteen nutzten Schwächen in CBC beziehungsweise in der Art, wie CBC innerhalb von TLS genutzt wird, aus.

Besonders problematisch ist die Tatsache, dass in TLS CBC in Kombination mit der sogenannten HMAC-Authentifizierung und die Authentifizierung nach der Verschlüsselung eingesetzt wird. Bei früheren TLS-Implementierungen konnte ein Angreifer aufgrund der Fehlermeldung herausfinden, ob die Dekodierung eines Blocks bei der Überprüfung der HMAC-Authentifizerung oder der Datenentschlüsselung scheiterte. Mit Hilfe gezielt eingestreuter fehlerhafter Datenblöcke konnte so ein Angreifer Rückschlüsse auf den Schlüssel ziehen. Später wurde diese Fehlermeldung vereinheitlicht, doch aufgrund der Antwortzeit des Servers war es immer noch möglich, Rückschlüsse zu ziehen. Das war die Grundlage der Lucky-Thirteen-Attacke.

RC4 und CBC mit Problemen, der Ausweg heißt TLS 1.2 

SvenMeyer 10. Aug 2013

https://bugzilla.mozilla.org/show_bug.cgi?id=480514 ...auch sich kurz bei bugzilla zu...

bargdenes 14. Mär 2013

Solange sie im Vollbit Modus genutz wird, ist sie unknackbar...

Kommentieren



Anzeige

  1. Softwareentwickler (m/w) .NET/C#
    Seven2one Informationssysteme GmbH, Karlsruhe
  2. Informatiker (m/w)
    Kassenärztliche Bundesvereinigung, Berlin
  3. Software Tester / Testspezialist: Testautomatisierung / Senior Software Testautomatisierer (m/w)
    imbus AG, Möhrendorf (bei Erlangen), München und Norderstedt (bei Hamburg)
  4. System Engineers (m/w)
    SVA System Vertrieb Alexander GmbH, Karlsruhe und Berlin

 

Detailsuche


Folgen Sie uns
       


  1. HDMI-Handshake

    Firmware 2.0 lässt manche Playstation 4 verstummen

  2. Motorola

    Lenovo übernimmt Googles Smartphone-Sparte

  3. Osquery

    Systemüberwachung per SQL von Facebook

  4. Sicherheitslücke

    Drupal-Team warnt erneut vor Folgen

  5. Spieldesign

    Kampf statt Chaos

  6. Techland

    Last-Gen-Konsolen zu schwach für Dying Light

  7. Passport im Test

    Blackberry beweist Format

  8. Streaming

    Sky als Online-Abo mit Live-TV und Einzelabruf

  9. Band

    Microsofts Wearable hört und fühlt

  10. Quartalszahlen

    Samsungs Gewinn bricht wegen Preiskampf bei Smartphones ein



Haben wir etwas übersehen?

E-Mail an news@golem.de



Moore's Law: Totgesagte schrumpfen länger
Moore's Law
Totgesagte schrumpfen länger

Samsung Galaxy Note 4 im Test: Ausdauerndes Riesen-Smartphone mit Top-Hardware
Samsung Galaxy Note 4 im Test
Ausdauerndes Riesen-Smartphone mit Top-Hardware
  1. Galaxy Note 4 4,5 Millionen verkaufte Geräte in einem Monat
  2. Samsung Galaxy Note 4 wird teurer und kommt früher
  3. Gapgate Spalt im Samsung Galaxy Note 4 ist gewollt

iPad Air 2 im Test: Toll, aber kein Muss
iPad Air 2 im Test
Toll, aber kein Muss
  1. Tablet Apple verdient am iPad Air 2 weniger als am Vorgänger
  2. iFixit iPad Air 2 - wehe, wenn es kaputtgeht
  3. iPad Air 2 Benchmark Apples A8X überrascht mit drei Prozessor-Kernen

    •  / 
    Zum Artikel