IT-Sicherheit Schwachstellen im Internet-Verschlüsselungsprotokoll
Beim E-Mails schicken oder Onlineshoppen senden wir sensible Daten wie Passwörter und Kontoinformationen durch das Internet. Absolut sicher sind sie derzeit nicht.
Wer E-Mails abruft, sich in das universitäre WLAN Eduroam einwählt oder einen Onlineshop nutzt, ist auf eine verschlüsselte Datenübertragung angewiesen. Schließlich sollen Fremde keine Passwörter und Kontodaten mitlesen können. In all diesen Anwendungen ist das gleiche Verschlüsselungsprotokoll im Einsatz: TLS, kurz für Transport Layer Security. Bis vor ein paar Jahren galt es als absolut sicher.
„Dann gingen verschiedene Angriffe auf das Protokoll um die Welt, und man hat gemerkt, dass es noch viel Verbesserungspotenzial gibt“, erzählt Prof. Dr. Jörg Schwenk vom Lehrstuhl für Netz- und Datensicherheit. Gemeinsam mit seinem Team war er an einigen solcher Angriffe beteiligt. Die daraus resultierenden Erkenntnisse werden in eine neue Version von TLS einfließen, die die Internet Engineering Task Force derzeit standardisiert.
Frühe Gedanken um Sicherheit
Die Transport Layer Security geht auf die Firma Netscape zurück, welche den ersten Internetbrowser auf den Markt brachte. „Die Entwickler haben sich relativ früh Gedanken darüber gemacht, dass man im Internet einen gewissen Schutz braucht, zum Beispiel für Onlineshops“, weiß Schwenk.
Dafür brachten sie 1994 das Verschlüsselungsprotokoll Secure Socket Layer (SSL) heraus, dessen spätere Versionen in TLS umbenannt wurden. Die aktuelle Version trägt die Bezeichnung 1.2. Voraussichtlich 2016 oder 2017 wird dann der Nachfolger TLS 1.3 verfügbar sein. Darin ist quasi alles neu. Und zwar in zweierlei Hinsicht: zum einen auf Ebene der eigentlichen Verschlüsselung, zum anderen auf Ebene der Schlüsselaushandlung.
Um eine Nachricht zu verschlüsseln, sind zwei Dinge erforderlich: eine Verschlüsselungsvorschrift, die vorgibt, nach welchem Schema die Nachricht zu verändern ist. Und ein Schlüssel, den beide Parteien kennen müssen, um die Nachricht chiffrieren und dechiffrieren zu können. Die Verschlüsselungsvorschrift darf öffentlich bekannt sein, der Schlüssel jedoch nicht. Denn nur mit ihm kann man die Nachricht dechiffrieren. Solange der Schlüssel also geheim ist, ist der Inhalt der Nachricht geschützt.
Damit zwei Parteien sicher miteinander kommunizieren können – etwa wenn ein Kunde oder eine Kundin Kreditkartendaten an einen Webshop übermitteln möchte –, müssen sich die beiden zunächst auf einen Schlüssel einigen, also ein gemeinsames Geheimnis aushandeln. In diesem Prozess können Sicherheitslücken auftreten, genauso wie bei der eigentlichen Verschlüsselung.
Geheimer Schlüssel gestohlen
Jörg Schwenks Team gelang es zum Beispiel, den Schlüssel zu stehlen, den zwei Parteien mit TLS 1.2 aushandeln. Prinzipiell kann die Schlüsselaushandlung auf drei Wegen erfolgen; die meisten Probleme verursacht das sogenannte RSA-Handshake-Verfahren, benannt nach den Erfindern Rivest, Shamir und Adleman.
Bildlich erklärt funktioniert es so: Der Server des Webshops schickt dem Kunden einen Briefkasten zu. Der Kunde steckt eine geheime Nachricht in den Briefkasten und schickt ihn zurück an den Server. Der öffnet den Briefkasten und kommt so an die geheime Nachricht heran. Diese Nachricht fungiert dann als Schlüssel, mit dem der Kunde seine Kreditkartendaten chiffriert.
Über einen sogenannten Bleichenbacher-Angriff verschaffte sich Schwenks Team Zugang zu dem Schlüssel: Dazu versahen die IT-Sicherheitsexperten die geheime Nachricht mit Fehlern, bevor sie sie in den Briefkasten steckten und an den Server schickten. Das machten sie nicht nur einmal, sondern immer wieder, wobei sie die geheime Nachricht jedes Mal leicht variierten.
Der Server erwartet, dass die Nachricht in einer bestimmten Form bei ihm ankommt; sie muss mit den Ziffern Null und Zwei beginnen. Ist das nicht der Fall, startet der Server eine Fehlerbehandlung. Die Nachrichten der RUB-Forscher enthielten bewusst Fehler, fingen also nicht immer mit Null und Zwei an. Für die Fehlerbehandlung braucht der Server länger, als wenn er normal mit dem Schlüsselaustausch fortfahren kann. Dieser Zeitunterschied erlaubte Rückschlüsse auf den Inhalt der Nachricht, also auf den Schlüssel, der eigentlich geheim bleiben sollte.
Mehr Sicherheit dank neuer TLS-Version
Ein solcher Angriff auf die Transport Layer Security wird in Version 1.3 nicht mehr möglich sein. Das RSA-Handshake-Verfahren wird durch den Diffie-Hellman-Schlüsselaustausch ersetzt. „Mein Doktorvater Albrecht Beutelsbacher hat das Verfahren einmal wie folgt erklärt“, erinnert sich Schwenk. „Man steckt zwei geheime Zutaten in ein Rezept. Wenn man umgerührt hat, kann man nicht mehr herausfinden, was die zwei Zutaten waren.“ Somit könnte auch niemand das Rezept nachmachen.
Um den Schlüssel zu generieren, denken sich die zwei miteinander kommunizierenden Parteien jeweils ein Teilgeheimnis aus und mischen diese. Daraus entsteht der Schlüssel. Anschließend löschen beide Parteien die geheimen Zutaten, aus denen sie die Teilgeheimnisse erzeugt haben. Ohne diese Zutaten lässt sich der Schlüssel nicht erneut berechnen.
Geheimgerichte in den Vereinigten Staaten können Firmen zwingen, Schlüssel herauszugeben.
Das ist auch für die Praktiken von Geheimdiensten relevant. Schwenk erklärt: „Geheimgerichte in den Vereinigten Staaten können Firmen zwingen, Schlüssel herauszugeben, mit denen die Daten ihrer Kunden chiffriert sind.“ Die Geheimdienste können so tonnenweise verschlüsselte Informationen aufzeichnen und auf Halde legen; wenn sie Einblick benötigen, besorgen sie sich von den Firmen den Schlüssel und dechiffrieren die gespeicherten Daten. „Große Firmen wie Google oder Amazon wollen das aber nicht“, so Schwenk.
Mit dem Diffie-Hellmann-Verfahren wird es nicht mehr möglich sein, Daten aus der Vergangenheit zu entschlüsseln. Denn die geheimen Zutaten, aus denen der Schlüssel erzeugt wird, werden gelöscht, sobald sie nicht mehr gebraucht werden. „So können Geheimdienste nur noch von jetzt bis in die Zukunft abhören“, sagt der Bochumer Wissenschaftler, „aber nicht mehr in die Vergangenheit.“
Sicherheitslücken in Vorgängerversionen ausnutzen
Der oben beschriebene Angriff ist nur ein Beispiel dafür, wie das RUB-Team sich mit der Sicherheit von TLS beschäftigt hat. Dr. Juraj Somorovsky, Mitarbeiter am Lehrstuhl für Netz- und Datensicherheit, war zum Beispiel an dem Drown-Angriff beteiligt, der im März 2016 Aufsehen erregte. Er und seine Kollegen umgingen die Sicherheitsmechanismen der aktuellen TLS-Version 1.2, indem sie sich über eine Vorgängerversion Zugang verschafften.
Häufig sind auf Servern alte Versionen von SSL und TLS installiert, um möglichst viele verschiedene Browser unterstützen zu können; denn ältere Browser kommen oft nicht mit den neuen Sicherheitsprotokollen zurecht. Über Schwachstellen in den veralteten Protokollen konnten die Forscher beim Drown-Angriff die aktuellen TLS-Sicherheitsmechanismen aushebeln. Auf ähnlichem Wege gelang es einem anderen Team vom Lehrstuhl für Netz- und Datensicherheit, digitale Signaturen in der aktuellen TLS-Version 1.2 zu fälschen.
Jedes halbe Jahr habe es jemand geschafft, die TLS-Verschlüsselung auf anderem Wege zu brechen.
So trugen die RUB-Forscher dazu bei, dass die Transport Layer Security nun überarbeitet wird. „Der Anstoß dazu waren allerdings die vielen Angriffe auf die Verschlüsselung, nicht auf die Schlüsselaushandlung“, berichtet Jörg Schwenk. Jedes halbe Jahr habe es jemand geschafft, die TLS-Verschlüsselung auf anderem Wege zu brechen. Schwenk: „Da hat man festgestellt, dass das gesamte Design schlecht ist.“
Sicherheitsbedenken sind aber nicht der einzige Grund für den neuen TLS-Standard. Der Konzern Google setzte sich zum Beispiel für ein neues Verfahren für die Schlüsselaushandlung ein, weil ihm der aktuelle Handshake schlicht zu langsam ist.
Jörg Schwenks Motivation, sich in den Prozess einzubringen, ist eine ganz andere. Um Geld geht es jedenfalls nicht. „Ich möchte relevante Forschung machen, die Impact hat“, sagt er. So wie seine Arbeiten zur Transport Layer Security, die nun direkt in die praktische Anwendung münden.
