Wer Verschlüsselung schwächt, gefährdet alle

Crypto Wars und ihre Folgen
Kommentare

2015 war für die Kryptografie ein ereignisreiches Jahr. So bahnt sich zum Beispiel ein neuer Crypto War an, gleichzeitig haben die Nachwirkungen des letzten ihr unschönes Gesicht gezeigt. Da trifft es sich gut, dass es auf dem 32. Chaos Communication Congress eine passende Auswahl an Vorträgen gab.

Seit der Veröffentlichung der von Edward Snowden geleakten NSA-Daten ist die Verunsicherung groß: Was kann die NSA entschlüsseln? Wo hat sie bei der Entwicklung von Protokollen und Technologien überall die Finger im Spiel? Was ist noch sicher? Welchen Protokollen kann man noch vertrauen? Fest steht nur eins: Verschlüsselung ist der einzige Schutz vor der Wissbegierde der Cyberkriminellen und Geheimdienste. Unverschlüsselte Kommunikation kann immer abgehört werden, und sicherheitshalber sollte man davon ausgehen, dass sie auch tatsächlich belauscht wird; gar nicht einmal unbedingt von den Geheimdiensten, denen verraten die Metadaten mehr als genug. Natürlich sammeln sie alle unverschlüsselt übertragenen Daten, warum sollten sie darauf verzichten? Auf die Entschlüsselung verschlüsselter Daten sind sie aber nicht mehr angewiesen, wie Ex-NSA-Chef Michael Hayden im Januar ganz eindeutig erklärt hat, weshalb die Geheimdienste auch keine Hintertüren in den Kryptoprodukten brauchen, wie sie von Strafverfolgern und Politikern gefordert werden. Denn ohne Hintertür kommen sie an die von immer mehr Anbietern Ende-zu-Ende-verschlüsselten Daten nicht heran.

Crypto Wars reloaded

Eigentlich sollte man annehmen, dass die Politiker nach den Crypto Wars der 1990er-Jahre begriffen haben, dass sie mit einer Schwächung der Kryptografie nur den Kriminellen und ausländischen Mächten in die Hände spielen und die eigene Wirtschaft und die eigenen Bürger gefährden. Dem ist aber nicht so, und es gibt erneut Versuche, den Begehrlichkeiten von Strafverfolgern und Co. nach Hintertüren in der Verschlüsselung nachzugeben. Wir befinden uns also im nächsten Crypto War und müssen um die Sicherheit unserer Kommunikation kämpfen – zumindest in manchen Staaten, denn zum Beispiel hat die niederländische Regierung die Gefahr von Hintertüren erkannt, sich Anfang Januar eindeutig dagegen ausgesprochen und schon zuvor dem OpenSSL-Projekt eine Unterstützung in Höhe einer halben Million Euro zugesichert. Und auch in Frankreich scheint man erkannt zu haben, dass Hintertüren missbraucht werden können.

„Crypto Wars Part II“ auf dem 32C3

Mit den aktuellen Crypto Wars hat sich Kurt Opsahl, Deputy General Counsel der Electronic Frontier Foundation (EFF), auf dem 32C3 befasst. Die Kryptografie, insbesondere die Verschlüsselung, war während des Kalten Kriegs noch eine militärische Technologie. Das änderte sich im Laufe der Zeit, und in den 1990er-Jahren wurde ihre Nutzung allgemein üblich – woraus sich einige Probleme ergaben, denn damals galt Verschlüsselung noch als eine Waffe, die den gleichen Exportbeschränkungen wie echte Waffen unterlag. So verwendete der Netscape Navigator Mitte der 1990er-Jahre 128 Bit lange Schlüssel für SSL – die in der Exportversion auf 40 Bit beschränkt wurden. Dass sich diese kurzen Schlüssel von den Geheimdiensten schon damals innerhalb weniger Tage brechen ließen, dürfte selbstverständlich sein. Inzwischen lässt sich diese Verschlüsselung innerhalb von Stunden brechen, wie zum Beispiel Logjam bewiesen hat. Auf diesen Angriff komme ich gleich noch zurück.

Ein weiterer Baustein im Kampf gegen eine starke Verschlüsselung war der von der NSA entwickelte Clipper-Chip für Sprachkommunikation, der eine Hintertür enthielt und außerdem Schwachstellen, die einem Angreifer Zugriff auf die darüber abgewickelte Kommunikation gegeben hätte – weshalb der Clipper-Chip dann letztendlich aufgegeben wurde.

Es dauerte einige Jahre, dann hatte auch der letzte Politiker eingesehen, dass er mit einer Schwächung der Verschlüsselung, vor allem der Einführung einer Hintertür, nicht nur dem eigenen Geheimdienst einen Gefallen tat, sondern auch gegnerischen Geheimdiensten und Kriminellen.

Schnell und überall: Datenzugriff mit Entity Framework Core 2.0

Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

C# 7.0 – Neues im Detail

Christian Nagel (CN innovation)

1997 sagte FBI-Direktor Louis Freeh „[W]e‘re in favor of strong encryption, robust encryption. The country needs it, industry needs it. We just want to make sure we have a trap door and key under some judge‘s authority where we can get there if somebody is planning a crime.“ Da die Forderung nach einer schwachen Verschlüsselung nicht besonders gut ankommt, hat man sie etwas anders formuliert: Man will natürlich eine starke Verschlüsselung. Aber auch eine Hintertür, um die Verschlüsselung bei Bedarf zu brechen. Und genau die gleiche Forderung steht nun wieder im Raum. 2010 sagte FBI General Counsel Valerie Caproni „They can promise strong encryption. They just need to figure out how they can provide us plain text.“ Jetzt verlangt man auch keine Hintertür mehr – man möchte lediglich den Klartext haben.

Sichere Verschlüsselung hilft Terroristen und Kriminellen!

In den letzten Jahren hat der Einsatz von Verschlüsselung stark zugenommen. In Smartphones wurde die Verschlüsselung gespeicherter Daten zum Standard, und auch immer mehr Messaging-Anwendungen verschlüsseln die Kommunikation per Default. Inzwischen sogar meist als Ende-zu-Ende-Verschlüsselung, sodass der Anbieter keinen Zugriff auf die unverschlüsselte Kommunikation mehr hat. Was nun zum Beispiel dem britischen Premierminister Cameron gar nicht passt, weshalb er alles versucht, Verschlüsselung ohne Hintertür zu verbieten.

Die von Kurt Opsahl anschließend aufgeführten Argumente der Verschlüsselungsgegner dürften hinlänglich bekannt sein. Sie laufen im Grunde darauf hinaus, dass Verschlüsselung von Kriminellen und Terroristen missbraucht wird und es ohne Hintertür keine Möglichkeit gibt, dagegen vorzugehen.

Key-Escrow-Ansatz

Parallel zu den Versuchen, Hintertüren politisch und gesetzlich einzuführen, gibt es auch entsprechende technische Ansätze. Denn falls ein Staat wirklich Hintertüren per Gesetz einführen würde, wäre es problematisch, wenn man dann keine entsprechende Technik parat hätte. Der häufigste Ansatz ist dabei „Key Escrow“: Die Daten werden mit einem symmetrischen Schlüssel verschlüsselt, der Schlüssel dann asymmetrisch sowohl für den Empfänger als auch den „Escrow Agent“ verschlüsselt. Bei Bedarf kann der Escrow Agent die Daten mit seiner Kopie des symmetrischen Schlüssels entschlüsseln, was zu einer Reihe von Problemen führt: Erst einmal wäre das gesamte System kompromittiert, wenn der private Schlüssel des Escrow Agents kompromittiert wird. Dann bricht das System die „Forward Secrecy“, bei der jede Kommunikation mit einem individuellen Schlüssel verschlüsselt wird, der sich nach Abschluss der Kommunikation nicht mehr ermitteln lässt, sodass die Entschlüsselung der aufgezeichneten Kommunikation nachträglich nicht mehr möglich ist. Beides lässt sich durch das Aufsplitten der Schlüssel umgehen, was das Ganze aber nur weiter verkompliziert.

Außerdem: Wer soll der Escrow Agent sein? Die Regierung? Welche? Die Provider? Eine dritte Partei? In allen Fällen gibt es die Gefahr, dass bösartige Mitarbeiter Schaden anrichten. Und unabhängig davon sind die Zugriffspunkte der Strafverfolger auf die entschlüsselte Kommunikation verlockende Angriffsziele für Cyberkriminelle und „staatlich gesponserte“ Angreifer.

Politiker sind oft lernresistent

Nun sollte man meinen, dass all diese Argumente auch den verstocktesten Politiker und Strafverfolger davon überzeugen, dass Hintertüren eine Gefahr sind. Das tun sie sogar, aber statt Hintertüren aufzugeben, werden sie einfach umbenannt. Man fordert nun keine Hintertür mehr, die missbraucht werden könnte, sondern möchte die Vordertür nutzen. Man möchte einen „sicheren goldenen Schlüssel“ für die Verschlüsselung haben, was natürlich totaler Unsinn ist, aber das stört Politiker ja selten.

Projekt „BULLRUN“

Es gibt bereits einige Ansätze, (Ende-zu-Ende-)Verschlüsselung zu verbieten bzw. Hintertüren zu erzwingen, zum Beispiel in Großbritannien und Indien. Solange sie nicht wirksam sind, müssen sich die Strafverfolger etc. mit technischen Angriffen auf die Verschlüsselung zufriedengeben – von denen es einige gibt. Zunächst suchen die Geheimdienste und Strafverfolger nach Stellen, an denen die Daten unverschlüsselt übertragen werden, etwa innerhalb von oder zwischen verschiedenen Rechenzentren der Diensteanbieter.

Darüber hinaus gibt es Angriffe auf die Verschlüsselung selbst. So gibt zum Beispiel die NSA 250 Millionen US-Dollar pro Jahr für das Projekt „BULLRUN“ aus, über das zum Beispiel Schwachstellen in Produkte eingebaut und Policies, Standards und Spezifikationen kommerzieller Public-Key-Kryptografie manipuliert werden. Das bekannteste Ergebnis ist der Zufallszahlengenerator Dual_EC_DRBG, dessen Ausgaben sich vorhersagen lassen. 2004 bezahlte die NSA RSA Security 10 Millionen US-Dollar, damit dieser Zufallszahlengenerator der Defaultgenerator in deren Produkten wurde. Und 2015 wurde bekannt, dass Juniper in seinen VPN Appliances den Dual_EC_DRBG verwendet, allerdings mit einer anderen Konstante als der von der NSA verwendeten, sodass jemand anderes die Hintertür nutzen konnte. Außerdem wurden hartkodierte Passwörter für SSH und Telnet gefunden. Allem Anschein nach hat da jemand die Kontrolle über die Hintertür der NSA übernommen.

Und zu guter Letzt gibt es noch die Möglichkeit, die Daten über auf den Endgeräten eingeschleuste Schadsoftware noch vor der Verschlüsselung auszuspähen.

Argumente für die Verschlüsselung

Kurt Opsahl führt eine Reihe von Argumenten für die Verschlüsselung und gegen deren Schwächung auf, von denen aus Platzgründen hier nur die pragmatischen aufgeführt werden können:

  • Die Schwächung der Verschlüsselung funktioniert nicht. Open Source und freie Software sind schwer zu stoppen.
  • Es ist mathematisch unmöglich, die Verschlüsselung gleichzeitig stark und schwach zu machen.
  • Die Schwächung der Verschlüsselung für gesetzestreue Bürger hält Terroristen (und Kriminelle und feindliche Geheimdienste etc.) nicht von der Nutzung starker Verschlüsselung ab.

Kurt Opsahl fordert deshalb dazu auf, die Verschlüsselung zu fördern, zum Beispiel,

  • indem sie genutzt und verbessert wird,
  • indem anderen ihre Nutzung beigebracht wird,
  • indem „Censorship Resistant“-Kryptotools entwickelt werden (Open Source, weit verteilt und damit nicht einfach aus dem Verkehr zu ziehen, reproduzierbare Builds, um die Sicherheit der Binaries zu garantieren).

Welche Folgen eine Schwächung der Verschlüsselung haben kann, wurde 2015 in zwei Fällen deutlich: Sowohl der FREK-Angriff als auch Logjam nutzten die so genannte „Exportverschlüsselung“ aus. Die „Exportverschlüsselung“ verwendet kurze Schlüssel und wurde von der US-Regierung in den 1990er-Jahren für alle Programme erzwungen, die aus den USA exportiert werden sollten. Die Beschränkungen gelten zwar schon lange nicht mehr, viele Programme unterstützten die unsicheren Schlüssellängen aber auch 2015 noch – es könnte ja mal jemand kommen, der sie benötigt –, was lange Zeit niemand für ein größeres Problem gehalten hat, da Client und Server die verwendeten Verfahren und Schüssellängen individuell aushandeln und natürlich niemand mehr solch unsichere Verfahren verwenden würde.

Exportverschlüsselung, Logjam und die NSA

J.Alex Halderman und Nadia Heninger haben auf dem 32C3 beschrieben, wie Logjam funktioniert und welche Folgen der Angriff für die Benutzer hat. Außerdem gibt es in den Snowden-Dokumenten deutliche Hinweise darauf, dass die NSA solche Angriffe regelmäßig durchführt.

Der Logjam-Angriff auf HTTPS

Der Logjam-Angriff besteht aus zwei Schritten: Zuerst wird der TLS-Handshake so manipuliert, dass für den Diffie-Hellman-Schlüsselaustausch die unsichere Exportvariante verwendet wird. Und danach wird dieser schwache Schlüsselaustausch gebrochen, was mit heutiger Hardware sehr schnell geht. Zumal ein weiteres Problem den Angriff erleichtert.

1. Der Angriff auf den TLS-Handshake

Der TLS-Handshake beginnt mit der Vereinbarung der zu verwendenden Kryptoalgorithmen. Dazu sendet der Client in seiner ClientHello-Nachricht eine Liste mit den von ihm unterstützten Algorithmen. Der Server wählt einen der Algorithmen aus und teilt seine Wahl dem Client mit.

Der Diffie-Hellman-Schlüsselaustausch

Das Prinzip des Diffie-Hellman-Schlüsselaustauschs besteht darin, dass sich die Kommunikationspartner über eine unsichere Verbindung je eine Nachricht zusenden. Aus diesen Nachrichten können sie dann einen gemeinsamen Schlüssel berechnen. Mathematisch funktioniert das folgendermaßen:

 

  1. Alice und Bob einigen sich auf eine Primzahl p und eine Primitivwurzel (*) g mod p mit 1 < g < p-1. p und g müssen nicht geheim bleiben, können also über eine unsichere Verbindung übertragen werden. Außerdem können sie vorab vereinbart und immer wieder verwendet werden.
  2. Alice wählt eine geheime Zahl a < p und sendet Bob A = ga mod p.
  3. Bob wählt eine geheime Zahl b < p und sendet Alice B = gb mod p. A und B müssen nicht geheim bleiben, können also über eine unsichere Verbindung übertragen werden.
  4. Alice berechnet k = Ba mod p (und kann danach a löschen).
  5. Bob berechnet k’ = Ab mod p (und kann danach b löschen).

 

(*) g ist eine Primitivwurzel von p, wenn sich alle Zahlen von 1 bis p-1 als Reste der Form gi mod p darstellen lassen.

Die von Alice und Bob getrennt voneinander berechneten k und k’ sind identisch, denn es gilt k = gba mod p = gab mod p = k’, und können als Sitzungsschlüssel für ein symmetrisches Kryptoverfahren verwendet werden.

Ein lauschender Angreifer kennt zwar p, g, A und B, aber um den Schlüssel k zu ermitteln, muss er das so genannte Diffie-Hellman-Problem lösen: Bekannt sind g, gx und gy. Welchen Wert hat gxy? Dazu muss er diskrete Logarithmen berechnen können: Er benötigt das x aus gx mod p (oder das y aus gy mod p). Das ist ein so genanntes mathematisch hartes Problem und ähnlich schwer wie die Faktorisierung.

TLS unterstützt verschiedene Varianten des Diffie-Hellman-Schlüsselaustauschs (siehe Textkasten: „Der Diffie-Hellman-Schlüsselaustausch“). Die Standardversion mit unbegrenzter Stärke wird als „ephemeral“ Diffie-Hellman oder kurz DHE bezeichnet und in Cipher-Suiten verwendet, die mit TLS_DHE_* beginnen.

Bei DHE ist der Server für die Auswahl der Diffie-Hellman-Parameter zuständig. Er wählt p und g, berechnet gb und sendet (p, g, gb) signiert mit seinem privaten asymmetrischen Schlüssel in einer ServerKeyExchange-Nachricht an den Client. Der Client prüft die Signatur und antwortet mit einer ClientKeyExchange-Nachricht, die sein ga enthält.

Um Downgrade-Angriffe zu verhindern und die vereinbarten Werte zu überprüfen, berechnen Client und Server das TLS Master-Secret gab und einen Message Authentication Code (MAC) ihrer Sicht des Handshake-Ablaufs. Diese MACs werden in einem Finished-Nachrichten-Paar ausgetauscht und überprüft. War die Prüfung erfolgreich, beginnt die Übertragung der symmetrisch verschlüsselten Anwendungsdaten.

p ist üblicherweise mindestens 1 024 Bit lang. Mit derart langen Zahlen lässt sich zwar rechnen, es dauert aber viel zu lange, um einen Man-in-the-Middle-(MitM-)Angriff durchzuführen. SSL 3.0 und TLS 1.0 unterstützen aber auch so genannte „Export-grade Diffie-Hellman“-Cipher-Suiten, die den Exportbeschränkungen aus den 1990er Jahren entsprechen. Diese DHE_EXPORT-Suiten verwenden Primzahlen mit maximal 512 Bits Länge, die ausgetauschten Nachrichten entsprechen aber in allen anderen Aspekten den DHE-Nachrichten.

Obwohl die Exportbeschränkungen schon lange nicht mehr gelten, unterstützen viele Bibliotheken und Server weiterhin diese eigentlich überflüssigen Cipher-Suiten. Und viele TLS-Server sind nach wie vor so konfiguriert, dass sie sowohl den aktuell üblichen 1024-Bit-DHE-Schlüsselaustausch als auch den unsicheren 512-Bit-DHE_EXPORT-Schlüsselaustausch unterstützen.

Das wurde nicht als Problem angesehen, da die meisten modernen TLS-Clients die DHE_EXPORT-Suiten weder anbieten noch unterstützen. Und jetzt kommt ein Fehler im TLS-Protokoll zum Tragen: Wenn der Server DHE_EXPORT auswählt, sendet er eine signierte ServerKeyExchange-Nachricht mit einem 512 Bit langem p512, die ansonsten identisch mit der ServerKeyExchange-Nachricht beim normalen DHE ist. Kritisch ist dabei, dass im signierten Teil der Nachricht kein Hinweis auf die gewählte Cipher-Suite enthalten ist. Wenn ein Client DHE anbietet, kann ein MitM die ClientHello-Nachricht so ändern, dass eine vom Server akzeptierte DHE_EXPORT-Suite angeboten wird, und alle sonst in Frage kommenden Suiten löschen. In der als Antwort gesendeten ServerHello-Nachricht wird dann vom MitM die DHE_EXPORT-Suite durch eine passende DHE-Suite ausgetauscht, die ServerKeyExchange-Nachricht aber unverändert weitergeleitet. Der Client interpretiert das daraufhin vom Server erzeugte (p512, g, gb) als gültige DHE-Parameter und führt den Handshake fort.

Client und Server haben zu diesem Zeitpunkt unterschiedliche Handshake-Abläufe. Ein Angreifer, der b in Echtzeit berechnen kann (und dazu kommen wir gleich), kann das Master Secret und die Verbindungsschlüssel berechnen und den Handshake mit dem Client abschließen. Anschließend kann er dem Client Daten schicken, die der als vom Server stammend akzeptiert.

Um das noch einmal klarzustellen: Die Clients würden zwar nie DHE_EXPORT vereinbaren, merken aber nicht, das es ihnen aufgezwungen wird. Sie halten die vom Server empfangenen Werte für die einer DHE-Cipher-Suite, die sie dem Server selbst angeboten haben.

2. Der Angriff auf den DH-Schlüsselaustausch

Damit der DH-Schlüsselaustausch sicher ist, muss die Berechnung des diskreten Logarithmus zum Ermitteln von b schwierig sein und auf jeden Fall nicht in Echtzeit erfolgen können. Das gilt aber nur eingeschränkt: Mit 512 Bit langen Werten lässt sich rechnen, zwar nicht in Echtzeit, aber immerhin in sehr überschaubaren Zeiträumen.

Die Entdecker von Logjam konnten innerhalb von sieben Tagen Zwischenergebnisse berechnen. Dabei werden alle Berechnungen durchgeführt, die nur von der Primzahl p abhängig sind. Das Ergebnis ist eine Tabelle mit Zwischenwerten, und darauf aufbauend dauert die finale Berechnung des Logarithmus, um das b aus gb mod p zu erhalten, dann nur noch 90 Sekunden. Wer sich die Mühe macht, diese Vorberechnungen durchzuführen, kann also als MitM-TLS-Verbindungen aufbrechen.

Das ist schon mal schlecht, aber noch nicht das wirkliche Problem. Denn auch bei 512 Bit Länge stehen noch reichlich Primzahlen zur Auswahl, und für jede davon müssten die Zwischenergebnisse berechnet und gespeichert werden. Nicht, dass NSA und Co. das nicht tun würden, sie haben ja reichlich Geld und damit Rechenzeit und Speicherplatz. Das wirkliche Problem sind die verwendeten Primzahlen, die wie im Kasten erwähnt fest vereinbart und veröffentlicht werden können: Es werden zu oft die gleichen Primzahlen verwendet, siehe Tabelle 1 (nach hier).

Tabelle 1: Die beliebtesten 512-Bit-Primzahlen für DH mit TLS

Tabelle 1: Die beliebtesten 512-Bit-Primzahlen für DH mit TLS

8,4 Prozent der Alexa-Top-Million-HTTPS-Sites unterstützen DHE_EXPORT-Suiten, und 92 Prozent davon verwenden zwei verschiedene 512-Bit-Primzahlen. Oder anders ausgedrückt: Wer sich die Mühe macht, für diese beiden Primzahlen die Zwischenergebnisse vorab zu berechnen (was jeweils sieben Tage dauert), kann knapp acht Prozent der Alexa-Top-Million-HTTPS-Sites als MitM angreifen.

Und weil echte Zahlen noch überzeugender als Prozentwerte sind: Die populärste 512-Bit-Primzahl befindet sich fest kodiert in vielen Apache-Webservern. Sie wurde 2005 mit Apache 2.1.5 eingeführt und war bis Version 2.4.7 in Gebrauch. Und wurde dann nicht etwa ausgetauscht, mit Version 2.4.7 endete die Unterstützung der Export-Cipher-Suiten. Es gibt immer noch rund 564 000 Server mit von den Browsern als vertrauenswürdig eingestuften Zertifikaten, die diese Primzahl verwenden – und damit für MitM-Angriffe anfällig sind.

MitM-Angriff in der Praxis

Die Forscher testeten den Angriff als MitM zwischen einem TLS-Client und einem beliebigen Server, der DHE_EXPORT unterstützt und die beliebte 512-Bit-Primzahl des Apache Webserver verwendet. Das größte Hindernis war die rechtzeitige Berechnung von b und damit gab, um die Finished-Nachricht des Servers zu fälschen, bevor der Handshake vom Client abgebrochen wird. Diese Berechnung dauert wie bereits erwähnt ungefähr 90 Sekunden, und das ist für manche Clients länger als sie dem Handshake zugestehen. Aber dieses Problem lässt sich lösen.

Nicht-Browser-Clients, vor allen Kommandozeilentools wie cURL und Git haben große Zeitlimits für das Timeout oder auch gar keine und lassen sich problemlos angreifen. Webbrowser erkennen einen Timeout früher, lassen sich aber mitunter überlisten, länger zu warten. So kann Firefox durch TLS-Fehlermeldungen dazu gebracht werden, den Handshake-Timer neu zu starten und die TLS-Verbindung für unbegrenzte Zeit offen zu halten. Andere Browser beenden die Verbindung nach einer Minute. Damit die Verzögerung nicht auffällt, kann ein Request für eine Ressource aus dem Hintergrund angegriffen werden, sodass die Verzögerung nicht beim Aufbau der Seite auffällt.

Manche TLS-Server verwenden nicht für jede Verbindung einen neuen Wert von b, sondern berechnen gb einmal und nutzen diesen Wert für mehrere Verbindungen, mitunter bis zum nächsten Neustart. Ein einmal vom Angreifer berechnetes b kann also immer wieder verwendet werden.

Anti-Downgrade-Flag

Nachdem der Logjam-Angriff im Mai 2015 vorgestellt wurde, haben die Browserhersteller die Minimalanforderungen an die DH-Schlüssellängen erhöht: Der Internet Explorer, Chrome und Firefox auf 1024 Bit, Safari auf 768 Bit. Und im Draft für TLS 1.3 wurde ein Anti-Downgrade-Flag eingeführt.

Lust auf eigene Experimente?

Wer mit dem Angriff experimentieren möchte, kann auf die Vorberechnungen der Forscher zurückgreifen. Die wurden über das Twitter-API veröffentlicht, der Twitter-Bot @DLogBot wartet auf Anfragen.

Angriffe auf Diffie-Hellman zur Massenüberwachung

768-Bit-Zahlen sind bereits für akademische „Angreifer“ knackbar, 1024-Bit-Zahlen für „state-level attackers“, also Geheimdienste.

Nachdem die Zwischenergebnisse vorberechnet wurden, ist die eigentliche Berechnung kein größeres Problem mehr. Diese Vorberechnungen dauern für die 768-Bit-Zahlen zwar deutlich länger als bei 512-Bit-Zahlen und nochmal sehr viel länger für 1024-Bit-Werte, sind aber möglich. Wie so oft ist es nur eine Frage des Geldes – der Angreifer muss gewaltig in Rechenleistung investieren. Ein speziell für das Berechnen der Primzahlen entwickelter Computer, der eine 1024-Bit-Primzahl pro Jahr knacken kann, würde ungefähr 100 Millionen US-Dollar kosten. Nach diesen Vorberechnungen können alle darauf aufbauenden Logarithmen quasi in Echtzeit berechnet werden.

Ein Angreifer, der es nur auf einen bestimmten Server und damit eine bestimmte Primzahl abgesehen hat, wird diesen Aufwand sicher auf sich nehmen, wenn er unbedingt an die Daten herankommen will. Geld genug hat zumindest die US-Regierung den Geheimdiensten zur Verfügung gestellt.

Bricht die NSA Diffie-Hellman?

Es gibt schon länger Gerüchte, dass der NSA ein „großer Durchbruch“ bei der Entschlüsselung gelungen ist, und durch die Snowden-Enthüllungen sind die Budgets der NSA bekannt.

Würden für eine bestimmte 1024-Bit-Primzahl die Vorberechnungen durchgeführt, könnten die Verbindungen zu 66 Prozent aller VPN-Server und 26 Prozent aller SSH-Server belauscht werden. Würden auch die Vorberechnungen für eine weitere 1024-Bit-Primzahl gemacht, könnten die Verbindungen von 18 Prozent der Alexa-Top-1-Million-HTTPS-Domains belauscht werden.

Die NSA kann laut den Snowden-Enthüllungen VPN-Verbindungen belauschen. Aufgrund des ebenfalls in den Snowden-Papieren enthaltenen Ablaufs der Entschlüsselung der VPN-Verbindungen und der ebenfalls bekannten Vorbedingungen dafür ist es sehr wahrscheinlich, dass die Entschlüsselung der VPN-Verbindungen über einen Angriff auf den Diffie-Hellman-Schlüsselaustausch passiert.

Fazit

Wer Verschlüsselung schwächt oder Hintertüren einbaut, um Kriminelle zu fangen, hilft ihnen damit letztendlich nur. Denn die Kriminellen (oder ausländische Geheimdienste etc.) werden diese Schwachstellen in der Verschlüsselung nutzen und die Kommunikation gesetzestreuer Bürger belauschen. Die Kriminellen selbst aber werden sich davon nicht stören lassen. Oder glaubt wirklich jemand von den Politikern und Strafverfolgern, dass Kriminelle unsichere Verschlüsselungen nutzen, nur weil die Nutzung starker Verschlüsselung verboten ist? Allen, die ohnehin schon gegen eines oder mehrere Gesetze verstoßen, wird es ziemlich egal sein, wenn sie gegen ein weiteres verstoßen.

Was die aktuelle Massenüberwachung betrifft – davor kann man sich schützen. Und darf es sogar – zumindest noch. Alex Halderman und Nadia Heninger raten zum Einsatz von Elliptic Curve Cryprography (ECC). Falls man den vom NIST entwickelten und möglicherweise von der NSA manipulierten Kurven nicht vertraut, gibt es zum Beispiel von Daniel J. Bernstein entwickelte Alternativen. Ist der Einsatz von ECC nicht möglich, sollten Primzahlen von mindestens 2014 Bit Länge verwendet werden. Die lassen sich noch einige Zeit mit brechen. Ist auch deren Einsatz nicht möglich, sollten zumindest individuell erzeugte 1024 Bit lange Primzahlen verwendet werden. Die können die Regierungen zwar brechen, aber das kostet Zeit (und Geld).

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -