Wie die NSA verschlüsselte Verbindungen ausspionieren kann

16. Oktober 2015, 09:41
23 Postings

Schwäche beim Schlüsselaustausch ermöglicht Geheimdiensten höchstwahrscheinlich den Zugriff

Wenn es darum geht, verschlüsselte Informationen zu knacken, kommen in Filmen und Serien gerne riesige Rechenzentren oder besonders ausgeklügelte, natürlich bislang unbekannte Hacks zum Einsatz. Und tatsächlich zeigen die von Edward Snowden geleakten NSA-Dokumente, dass der US-Geheimdienst so manche Tools in seinem Arsenal hat, von denen anderer nicht einmal zu träumen wagen. Und doch lebt auch die NSA in ihren Alltagsaktivitäten vor allem von einem: Den Fehlern anderer.

Vorfall

Im Fundus der Snowden-Dokumente findet sich eines, in dem die NSA stolz beschreibt, dass es gelungen sei, die Verschlüsselung von VPN-Verbindungen zu unterwandern. Bis dato ist dabei unbekannt, wie der Geheimdienst dies geschafft hat, immerhin sollten diese Verbindungen rein mathematisch selbst mit den größten existierenden Supercomputern derzeit nicht knackbar sein. Die Computerwissenschafter J Alex Halderman and Nadia Heninger meinen nun aber eine Erklärung gefunden zu haben.

Verschlüsselung

Das Problem stecke in der Art, wie das Diffie-Hellman-Protokoll einen verschlüsselten Kanal zwischen zwei Rechnern aufbaut. Zur Absicherung der Daten muss jede Seite zunächst einen privaten und einen öffentlichen Schlüssel erstellen, der untereinander getauscht wird. Zudem wird aber auch ein gemeinsamer, öffentlicher Schlüssel erstellt, der de fakto eine sehr große Primzahl ist.

Fehlerhaft

Und genau hier entsteht das Problem: Da dieser gemeinsame Schlüssel ohnehin öffentlich ist, und die Berechnung eines neuen einiges an Rechenkraft benötigt, verwenden viele Diffie-Hellman-Implementationen die selbe Primzahl einfach weiter. Dies geht soweit, dass eine einzelne Primzahl dazu genutzt wird, um rund zwei Drittel sämtlicher VPN-Verbindungen und eine Viertel aller SSH-Server abzusichern. Eine weitere Primzahl teilen sich rund 20 Prozent der eine Million meistgenutzten HTTPS-Seiten. Und genau hier setzen die Forscher nun an: Über Vorberechnungen lässt sich solch eine Primzahl knacken. Ist dies einmal gelungen, können darauf aufsetzende, verschlüsselte Verbindungen innerhalb von wenigen Minuten mitgelesen werden.

Aufwand

Das Knacken der Primzahl selbst ist hingegen ein extrem rechenaufwändiger Prozess. Selbst kurze Zahlen – etwa mit einer Länge von 512 Bit – benötigen rund eine Woche, um die Vorberechnung durchzuführen. "Dank" des Umstands, dass die Zahlen weiterverwendet werden, ist dies aber ein Aufwand, der sich für staatliche Spione durchaus rentiert.

Logjam

Das beschriebene Problem ist erstmals vor einigen Monaten unter dem Namen Logjam bekannt geworden, und hat dazu geführt, dass die meisten Browser beim Schlüsselaustauch solch kurze Primzahlen mittlerweile ablehnen. Dies ändere aber nichts an der grundlegenden Problematik, wie die Forscher betonen. Denn für jemanden mit ausreichend finanziellen Ressourcen ließen sich auch Systeme bauen, mit denen Schlüssel mit 1.024 Bit Länge berechnet werden könnten. Die Forscher veranschlagen hier ein Budget von mehreren hundert Millionen US-Dollar und einen Zeitaufwand von einem Jahr. Dies mag zunächst unrealistisch klingen, dank der Wiederverwendung der Primzahlen könnte sich dieser Aufwand für die NSA aber rentieren. Immerhin stehen dem Geheimdienst alleine für die Kryptoanalyse jedes Jahr 11 Milliarden US-Dollar zur Verfügung.

Hinweise

In ihrer Untersuchung betonten die Forscher, dass man natürlich nicht beweisen könne, dass dies der tatsächliche Angriffspunkt der NSA gegen verschlüsselte Verbindungen ist. Ihre These passe aber besser zu all dem, was über die technischen Fähigkeiten des Geheimdiensts bekannt ist als alle anderen bisher kursierenden Erklärungsversuche.

Lösungsversuche

Die Lösung für das beschriebene Problem scheint naheliegend: Würde für jede Verbindung eine frische Primzahl berechnet, würde sich der beschriebene Angriff nicht mehr realistisch umsetzen lassen. Dagegen spricht allerdings, dass einige Diffie-Hellman-Implementationen derzeit die Primzahl sogar fix im Code verankert haben, eine schnelle Änderung der aktuellen Situation ist also kaum zu erwarten. Auch werden sich wohl viele Serverbetreiber gegen den zusätzlichen Rechenaufwand wehren.

Ausblick

Längerfristig sollte der Wechsel auf andere Schlüsseltauschverfahren eine Lösung bringen. So sollen künftig elliptische Kurven zum Einsatz kommen, die für dieses spezifische Szenario nicht anfällig wären. Allerdings geben sich die Forscher in dieser Hinsicht keinerlei Illusionen hin: Bis zu einer umfassenden Lösung würden wohl noch viele Jahre vergehen.

Konkrete Maßnahmen

Insofern folgt die Empfehlung fürs erste zumindest die Länge von Diffie-Hellman-Schlüsseln auf 2.048 Bits zu erweitern, dies sollte die Vorberechnung mit aktuellen Rechenkapazitäten unmöglich machen. SSH-Nutzern wird zudem geraten auf die aktuellste Version von OpenSSH zu aktualisieren, die elliptische Kurven dem Diffie-Hellman-Verfahren vorzieht. (apo, 16.10.2015)

  • Artikelbild
Share if you care.