Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

So funktionieren der CBC und HMAC

Der gängigste und auch heute meist noch eingesetzte Modus ist der sogenannte Cipher-Block-Chaining-Modus (CBC). Dabei wird zunächst der sogenannte Initialisierungsvektor (IV) als Zufallswert generiert und mit dem ersten Datenblock in einer Bit-weisen XOR-Operation verknüpft. Das Ergebnis wird verschlüsselt. Der nächste Datenblock wird dann mit dem verschlüsselten ersten Block ebenfalls XOR-verknüpft (das Schema ist in Abbildung 1 dargestellt).

Abbildung 1: Das CBC-Schema ist relativ simpel aufgebaut.

Die Verschlüsselung einer Übertragung mit CBC garantiert allerdings nur, dass die Daten von einem Angreifer nicht mitgelesen werden können. Die Echtheit der Daten garantiert sie nicht. Daher wird bei einer TLS-Verbindung vor der Verschlüsselung mit CBC das sogenannte HMAC-Verfahren angewandt. Hier wird aus der Nachricht und dem Schlüssel ein Hash gebildet und übertragen.

Die Kombination HMAC und CBC erwies sich als erstaunlich wackelig. Vor allem die Entscheidung, zuerst HMAC und anschließend CBC anzuwenden, stellte sich als Fehlgriff heraus. Das Problem: Ein Angreifer kann durch Einschleusen eines fehlerhaften Datenblocks anhand der zurückgegebenen Fehlermeldung herausfinden, ob das sogenannte Padding, also das Auffüllen von fehlenden Bytes in einem Block, einen Fehler verursacht oder die Überprüfung des HMAC-Hashes. Denn TLS verschickte in diesen Fällen in früheren Versionen unterschiedliche Fehlermeldungen.

Durch das Senden einer großen Zahl fehlerhafter Datenblöcke konnte ein Angreifer Details über den verwendeten Schlüssel herausfinden. Diese Form des Angriffs erhielt den Namen "Padding Oracle".

Später änderte man das System so, dass ein Angreifer immer dieselbe Fehlermeldung erhält. Doch dabei ergab sich das nächste Problem: Die Antwortzeit ermöglichte dem Angreifer trotzdem herauszufinden, ob die Überprüfung des Datenblocks beim Padding oder beim HMAC-Hash fehlschlug.

Auf diesen Methoden basieren die in jüngster Zeit bekannt gewordenen Angriffe BEAST und Lucky Thirteen. Detailveränderungen in den Protokollimplementierungen unterbanden diese vorläufig. Doch das gestaltete sich alles andere als einfach. So zeigte sich zum Beispiel, dass eine der Änderungen, die eingeführt wurde, um die BEAST-Attacke zu verhindern, anschließend eine Form der Lucky-Thirteen-Attacke gerade erst ermöglichte.

Authentifizierung und Verschlüsselung

Modernere Blockverschlüsselungsmodi kombinieren Authentifizierung und Verschlüsselung in einem Schritt. Ein derartiger Modus ist etwa der sogenannte Galois-/Counter-Mode (Abkürzung GCM, dargestellt in Abbildung 2 ). Dieser gilt zwar als relativ kompliziert, aber im Gegensatz zu anderen Verfahren ist GCM frei von Patentansprüchen und weist bislang keine bekannten Sicherheitsprobleme auf.

Abbildung 2: Authentifizierung und Verschlüsselung in einem – der Galois-/Counter-Mode.

AES mit dem GCM-Verfahren wird von TLS in der Version 1.2 unterstützt. In allen früheren TLS-Versionen setzen sämtliche Blockverschlüsselungen auf CBC. Von den Autoren der BEAST-Attacke ist noch ein weiterer Angriff auf TLS veröffentlicht worden. Bei der sogenannten CRIME-Attacke handelt es sich ebenfalls um ein Timing-Problem. Hier machen sich die Autoren eine Schwäche in der Kompressionsroutine von TLS zunutze. Anhand der Antwortzeit eines Servers konnten sie Rückschlüsse auf den Inhalt eines Datenblocks ziehen.

Die TLS-Datenkompression wird nur selten eingesetzt, da viele Browser sie nicht unterstützen. Für Serveradministratoren ist es das Beste, diese einfach auszuschalten.

Neben den Blockchiffren bieten ältere TLS-Versionen auch Unterstützung für die Stromverschlüsselung RC4. Das Verfahren wurde von Ron Rivest entwickelt und war ursprünglich nicht zur Veröffentlichung vorgesehen. Doch 1994 tauchte ein Quellcode der RC4-Verschlüsselung in einer Newsgroup auf. Seitdem erfreut es sich großer Beliebtheit, weil es relativ simpel und sehr schnell ist.

Der Einsatz von RC4 ist auch in TLS möglich und ist bei älteren Versionen des Standards die einzige Möglichkeit, wenn man die Nutzung von CBC vermeiden möchte. Viele Experten empfahlen daher bis vor kurzem, bei TLS-Verbindungen ausschließlich auf RC4 zu setzen. Große Webseiten wie Google setzten auf RC4 als primären Algorithmus und der Kreditkartenstandard PCI-DSS forderte von Serveradministratoren, alle CBC-Algorithmen abzuschalten und nur Verbindungen über RC4 anzunehmen. Ein Fehler, wie sich nun herausstellte. Auf der Fast-Software-Encryption-Konferenz im März präsentierte ein Team um den Kryptografen Dan Bernstein einen Angriff auf RC4 und TLS [4] .

Bei der Stromverschlüsselung von RC4 tauchen bestimmte Bits an manchen Stellen nicht nur zufällig auf, sondern mit erhöhter Häufigkeit. Durch statistische Analysen lassen sich so Rückschlüsse auf den Inhalt ziehen. Ein mögliches Angriffsziel könnte etwa ein Cookie in einer Webanwendung sein.

Anders als die Schwächen in CBC gibt es vermutlich keine einfache Möglichkeit, die Probleme von RC4 im Rahmen von TLS zu beheben, ohne mit dem Standard zu brechen. Die Empfehlung, aufgrund der Schwächen von CBC stattdessen auf RC4 zu setzen, ist also keine Option mehr.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023