Original-URL des Artikels: https://www.golem.de/news/verschluesselung-was-noch-sicher-ist-1309-101457.html    Veröffentlicht: 09.09.2013 12:15    Kurz-URL: https://glm.io/101457

Verschlüsselung

Was noch sicher ist

Die NSA soll auch in der Lage sein, verschlüsselte Verbindungen zu knacken. Ein Überblick über kryptographische Algorithmen und deren mögliche Probleme.

Die jüngsten Enthüllungen von Edward Snowden, die am Donnerstag veröffentlicht wurden, verursachen in der Welt der Kryptographie einigen Wirbel: Der US-Geheimdienst NSA und der britische GCHQ sollen auch in der Lage sein, verschlüsselte Verbindungen mitzulesen. In erster Linie setzen die Geheimdienste dabei wohl auf Hintertüren und Sicherheitslücken in Anwendungen, aber die Berichte im Guardian legen zumindest nahe, dass sie auch direkt in der Lage sind, Verschlüsselungen zu brechen. Im Jahr 2010 soll der NSA dabei ein Durchbruch gelungen sein, der es fortan ermöglichte, einen Großteil der verschlüsselten Verbindungen im Netz mitzulesen.

Die Berichte lenken die Aufmerksamkeit auf die vielen kleinen Probleme, die in kryptographischen Algorithmen und Protokollen in den vergangenen Jahren gefunden wurden. Fast alle weit verbreiteten Verschlüsselungstechnologien - ob SSL, SSH oder PGP - nutzen an vielen Stellen veraltete Algorithmen, die nicht mehr dem Stand der Technik entsprechen.

Seit den Enthüllungen rätseln Kryptographen, welche Algorithmen noch sicher sind. Nachfolgend ein Überblick über den Stand der wissenschaftlichen Debatte bei einigen der wichtigsten Krypto-Algorithmen.

RC4 - schnell, einfach - und unsicher?

Als einer der wahrscheinlichsten Kandidaten für Durchbrüche bei kryptographischen Angriffen gilt die Stromverschlüsselung RC4. Die britische IT-Nachrichtenseite The Register berichtet darüber, im Nachrichtenmagazin Spiegel warnt auch der Berliner Informatikprofessor Rüdiger Weis vor RC4 und hält hier Durchbrüche bei der Entschlüsselung für wahrscheinlich. Auch Star-Kryptograph Bruce Schneier, der den Guardian bei den Enthüllungen beraten hat, hält dies für eine plausible Vermutung.

RC4 wurde ursprünglich von Ron Rivest im Jahr 1987 entwickelt. Rivest hatte nicht geplant, den Algorithmus zu veröffentlichen. Im Jahr 1994 jedoch tauchte der Quellcode von RC4 in einer Newsgroup auf. Seitdem hat der Algorithmus eine erstaunliche Karriere hinter sich. So wurde er etwa im WLAN-Standard WEP eingesetzt. Vor allem SSL-/TLS-Verbindungen nutzen aber RC4.

Zuletzt nahm die Nutzung von RC4 noch deutlich zu. Aufgrund von Schwächen in den CBC-Verfahren von TLS (dazu später mehr) wechselten viele Serverbetreiber zu RC4. So werden etwa zur Zeit Verbindungen zu Google.com in der Regel mit RC4 abgesichert.

Der Code für RC4 ist nur wenige Zeilen lang und der Algorithmus ist sehr schnell. Dass RC4 nicht besonders sicher ist, ist jedoch keine Neuigkeit. Im Jahr 2001 zeigte ein Team um den Kryptographen Adi Shamir, dass die ersten 256 Bytes eines RC4-Schlüsselstroms eine vorhersehbare Struktur vorweisen. Gelöst wurde das zunächst dadurch, dass die ersten Schlüsselstrombytes verworfen wurden. Jedoch zeigten immer wieder neue Forschungsergebnisse, dass weitere Schlüsselstrombytes sich nicht wie Zufallsbytes verhalten.

Im Frühjahr dieses Jahres zeigte Dan Bernstein, dass die Schwäche in RC4 genutzt werden kann, um TLS-Verbindungen anzugreifen. Dafür sind zwar mehrere Gigabytes an verschlüsselten Daten notwendig. Doch Bernstein warnte, dass es wahrscheinlich möglich sei, den Angriff durch weitere Forschung zu verbessern. Gut möglich, dass die NSA dies bereits getan hat.

Fazit: RC4 ist alt und unsicher. Es sollte nicht mehr benutzt werden.

AES - die Geschichte eines Standards

Der wichtigste symmetrische Verschlüsselungsalgorithmus ist heutzutage der Advanced Encryption Standard (AES). AES war das Ergebnis eines Wettbewerbs, den die US-Behörde NIST (National Institute of Standards and Technology) veranstaltet hat. Im Jahr 2001 wurde der Algorithmus Rijndael zum neuen Kryptostandard gekürt.

Auch wenn viele Kryptographen damals den Wettbewerb und die Arbeit des NIST lobten: Die Entscheidung war nicht unumstritten. Insbesondere der Microsoft-Mitarbeiter Niels Ferguson kritisierte Rijndael. Ferguson störte sich an der simplen mathematischen Struktur des Algorithmus. In einem Vortrag, den er 2001 auf der Hackers-at-Large-Konferenz gehalten hat, sagte Ferguson, wenn einer der AES-Finalisten in den nächsten fünf Jahren gebrochen würde, würde es ihn bei Rijndael am wenigsten verwundern. Ferguson selbst hatte zusammen mit Bruce Schneier und anderen den Algorithmus Twofish entwickelt, der Rijndael in der AES-Auswahl unterlag.

AES erwies sich dann tatsächlich als nicht so sicher wie erhofft. Nicht wenige Kryptographen sind der Meinung, dass man besser auf Twofish oder Serpent, einen weiteren AES-Finalisten, hätte setzen sollen. Trotz allem sind jedoch sämtliche Angriffe auf AES weit davon entfernt, das Verfahren wirklich brechen zu können. AES gibt es in drei Varianten: 128, 192 oder 256 Bit.

Alex Biryukov und Johann Großschädl haben 2012 einmal versucht auszurechnen, wie aufwendig ein Angriff auf AES mit 128 Bit mit Hilfe von Supercomputern wäre. Das Ergebnis hinterlässt zumindest ein ungutes Gefühl: Es ist zwar enorm aufwendig, aber nicht unmöglich. Die Kosten für die Chipproduktion lägen im Bereich von etwa 80 Milliarden Dollar. Der größte Flaschenhals wäre jedoch die Energieversorgung. Ein solcher Spezialrechner würde die Leistung von 4 Terawatt benötigen. Das ist mehr, als die Vereinigten Staaten insgesamt an Strom verbrauchen.

Klar dürfte also sein: Eine solche Anlage lässt sich zwar theoretisch von Menschen bauen, aber mit Sicherheit nicht in den Geheimanlagen der NSA. Dafür ist dort schlicht nicht genug Platz.

Fazit: AES gilt als sicher, ist aber nicht der beste verfügbare Algorithmus. Wer paranoid ist, kann auf AES mit 256 Bit setzen. Mögliche Alternativen sind Twofish und die Stromverschlüsselung Salsa20.

Verschlüsselungsmodi - CBC und HMAC

Zwei Angriffe auf TLS - BEAST und Lucky Thirteen - haben zuletzt die Aufmerksamkeit auf Probleme mit den Operationsarten von Blockverschlüsselungen wie AES gelenkt. Eine Blockverschlüsselung ist zunächst einmal nur in der Lage, einen einzelnen Block - etwa 256 Bit - zu verschlüsseln. Um AES in einem Protokoll wie TLS zu nutzen, muss hierfür ein Verschlüsselungsmodus gewählt werden. Üblich war hierbei bislang das sogenannte Cipher-block chaining (CBC).

Zusätzlich zur Verschlüsselung benötigt eine geschützte Verbindung noch ein Verfahren, das die Integrität der Verbindung garantiert. Klassischerweise kommt hierfür das MAC-Verfahren HMAC zum Einsatz.

Es gibt verschiedene Möglichkeiten, CBC und HMAC miteinander zu kombinieren. Wirklich sicher ist die Konstruktion nur dann, wenn zuerst verschlüsselt und anschließend ein MAC über die verschlüsselten Daten gebildet wird (Encrypt-then-MAC). TLS macht es genau andersherum (MAC-then-Encrypt). Das Problem dabei: Kann ein Angreifer erkennen, ob ein fehlerhaftes Paket bei der Entschlüsselung oder bei der MAC-Prüfung abgewiesen wird, ist er in der Lage, damit eine verschlüsselte Verbindung anzugreifen.

SSH bereichert das Ganze um eine weitere wenig sichere Variante: Hier wird zuerst verschlüsselt, der MAC wird jedoch über die unverschlüsselten Daten gebildet. Erst in Version 6.2 unterstützt OpenSSH auch die Variante Encrypt-then-MAC.

Eine Alternative sind sogenannte authentifizierte Verschlüsselungsmodi, die Verschlüsselung und Integrität in einem Schritt erledigen. TLS kennt hier den Galois/Counter-Modus (GCM), allerdings erst in der jüngsten Protokollversion TLS 1.2. Diese wird bislang von kaum einem Browser unterstützt.

Wer auf ältere TLS-Standards angewiesen ist, hat nur die Wahl zwischen CBC in der problematischen MAC-then-Encrypt-Kombination oder dem ebenfalls als problematisch geltenden RC4.

Fazit: Blockchiffren sollte man mit authentifizierten Verschlüsselungsmodi wie GCM nutzen. Wenn es CBC sein soll, dann nur in der Kombination Encrypt-then-MAC.

RSA, zu kurze Schlüssel und das Padding

Bei den asymmetrischen Verschlüsselungsverfahren, also Verfahren, bei denen ein öffentlicher und ein privater Schlüssel genutzt werden, heißt der wichtigste Algorithmus immer noch RSA. Das Verfahren wurde 1977 von Ron Rivest, Adi Shamir und Leonard Adleman entwickelt und basiert auf dem Faktorisierungsproblem. Die Faktorisierung großer Zahlen gilt als schwieriges Problem und die Sicherheit von RSA hängt davon ab.

In den 90er Jahren wurde RSA mit Schlüssellängen zwischen 512 und 1.024 Bit genutzt. Das entsprach etwa den Möglichkeiten des damals aufkommenden Programms Pretty Good Privacy (PGP). 1999 wurde zum ersten Mal eine 512-Bit-Zahl faktorisiert. 2003 warnte Adi Shamir, einer der Erfinder des Verfahrens, dass auch RSA mit einer Schlüssellänge von 1.024 Bit nicht mehr sicher ist. Verbesserungen bei Faktorisierungsalgorithmen und die Möglichkeit von Spezialhardware würden es einem finanzkräftigen Angreifer ermöglichen, derartige Schlüssel zu brechen.

Eran Tromer, ein ehemaliger Student von Adi Shamir, geht inzwischen davon aus, dass die Kosten für einen derartigen Supercomputer bei etwa einer Million Dollar liegen. Dass die NSA derartige Schlüssel brechen kann, daran dürften kaum noch Zweifel bestehen. Die Frage ist allerdings: Ist sie auch in der Lage, 1.024-Bit-Schlüssel in großer Zahl zu brechen und somit - ganz praktisch - den Internetverkehr zu überwachen?

RSA mit 1.024 Bit wird nach wie vor von vielen HTTPS-Webseiten eingesetzt, auch das Anonymisierungsnetzwerk Tor arbeitet mit solch kurzen RSA-Schlüsseln.

Ein weiterer Aspekt bei RSA ist das Padding-Verfahren. Bevor ein Datenblock mit RSA verschlüsselt oder signiert werden kann, findet ein Vorverarbeitungsschritt statt. Fast alle RSA-Implementierungen nutzen hierbei noch das veraltete Verfahren aus dem Standard PKCS #1 1.5. Das hat zwar keine bekannten Sicherheitsprobleme, allerdings ist es sehr leicht möglich, PKCS #1 1.5 in unsicherer Art und Weise zu implementieren.

Die beiden Kryptographen Mihir Bellare und Philip Rogaway haben bereits 1994 zwei bessere Padding-Verfahren vorgeschlagen: OAEP für die RSA-Verschlüsselung und PSS für RSA-Signaturen. Sie sind im Standard PKCS #1 2.1 spezifiziert. Leider nutzt bislang fast niemand OAEP oder PSS.

Fazit: Zehn Jahre, nachdem der Erfinder von RSA vor seinem eigenen Algorithmus gewarnt hat, ist es höchste Zeit, diese Warnung ernst zu nehmen. RSA-Schlüssel mit einer Länge von 1.024 Bit sollten nicht mehr genutzt werden. 2.048 Bit gelten als sicher. Wer paranoid ist, kann auch 4.096 Bit verwenden, fast alle Anwendungen unterstützen das. OAEP und PSS sind älteren Padding-Verfahren vorzuziehen, sie werden allerdings bislang von Protokollen und Software kaum unterstützt.

DSA, ElGamal und Diffie-Hellman

RSA ist zwar mit Abstand das wichtigste Public Key-Verfahren, aber auch Verfahren, die auf dem sogenannten diskreten Logarithmusproblem (DLP) basieren, spielen noch eine gewisse Rolle. Vor allem beim Schlüsselaustausch, der Verbindungen mit Perfect Forward Secrecy ermöglicht, ist das Diffie-Hellman-Verfahren von Bedeutung.

Das ElGamal-Public-Key-Verfahren ist vor allem unter dem Namen DSA (Digital Signature Algorithmus) bekannt. Der DSA-Standard wurde von einem ehemaligen NSA-Mitarbeiter entwickelt. Für die Schlüssellängen gilt dasselbe wie bei RSA. Denn die besten Angriffe auf das Faktorisierungsproblem lassen sich auch für das diskrete Logarithmusproblem nutzen. Einfach ausgedrückt: Ein 1.024-Bit-DSA-Schlüssel ist mit hoher Wahrscheinlichkeit genauso unsicher wie ein 1.024-Bit-RSA-Schlüssel.

Der DSA-Standard unterstützte lange Zeit nur 1.024-Bit-Schlüssel, was dazu führt, dass diese heute noch oft im Einsatz sind. GnuPG etwa hat lange Zeit in der Standardeinstellung 1.024-Bit-DSA-Schlüssel genutzt.

DSA hat eine Schwäche, die manchen Kryptographen Sorgen bereitet: Es benötigt gute Zufallszahlen, und zwar nicht nur bei der Erzeugung des Schlüssels, sondern bei jeder erzeugten Signatur. Wird ein DSA-Schlüssel auch nur zeitweise mit einem unbrauchbaren oder kompromittierten Zufallsgenerator genutzt, dann ist die Sicherheit des Verfahrens nicht mehr gegeben. Aus solchen Signaturen kann ein Angreifer im schlimmsten Fall den privaten Schlüssel berechnen.

Das Diffie-Hellman-Verfahren hat zwar keine Schlüssel, aber es findet in einem sogenannten Modulus statt. Die Größe des Modulus ist von der Sicherheit her vergleichbar mit der Schlüssellänge. Und auch hier gilt: 1.024 Bit sind noch weit verbreitet. So nutzt etwa der Apache-Webserver für Perfect Forward Secrecy mit dem Diffie-Hellman-Verfahren 1.024 Bit. Und es gibt bislang keine Möglichkeit, dies zu ändern, ohne den Quellcode zu patchen.

Fazit: RSA ist DSA vorzuziehen, da es weniger anfällig für schlechte Zufallsgeneratoren ist. Ansonsten gilt in Sachen Schlüssellänge oder Modulus: 1.024 Bit sind zu wenig.

Elliptische Kurven

In den vergangenen Jahren wurden Public-Key-Verfahren zunehmend populär, die auf sogenannten elliptischen Kurven basieren. Dabei handelt es sich im Kern um Verfahren, die dem ElGamal- oder Diffie-Hellman-Verfahren ähnlich sind. Allerdings kommen diese mit deutlich kürzeren Schlüsseln aus und arbeiten somit auch schneller. Die besten Angriffe auf das diskrete Logarithmusproblem funktionieren bei elliptischen Kurven nicht.

Das am weitesten verbreitete Verfahren auf Basis elliptischer Kurven ist das ECDSA-Signaturverfahren. Auch zum Schlüsselaustausch bei TLS können elliptische Kurven eingesetzt werden. Hierfür kommen meist elliptische Kurven zum Einsatz, die vom US-NIST entwickelt wurden. ECDSA hat dieselben Probleme mit schwachen Zufallszahlen wie DSA.

Nach den jüngsten Enthüllungen zeigen sich manche Kryptographen besorgt angesichts der vom NIST entwickelten Kurven. Anders als AES wurden diese nicht in einem offenen Verfahren bestimmt und es ist unklar, wie viel Einfluss die NSA auf das NIST hat. Bruce Schneier empfiehlt im Guardian, gar nicht auf elliptische Kurven zu setzen.

Die Kryptographen Dan Bernstein und Tanja Lange warnen ebenfalls vor den NIST-Kurven, halten jedoch die Verwendung von elliptischen Kurven generell für sinnvoll. Sie haben mit Curve25519 eine Alternative entwickelt, die sich zuletzt einiger Beliebtheit erfreute. Allerdings kann Curve25519 nicht in Kombination mit dem ECDSA-Standard genutzt werden.

Fazit: Die Nutzung von elliptischen Kurven ist umstritten. Manche Kryptographen halten diese für sicherer, andere bevorzugen klassische Verfahren wie RSA. Einige Kurven wurden vermutlich von der NSA mitentwickelt, eine Hintertür ist vorstellbar, aber nicht sehr wahrscheinlich. Elliptische Kurven mit zu kurzen Schlüsseln werden praktisch nirgendwo verwendet.

Hash-Verfahren

Kryptographische Hash-Algorithmen sind ein wichtiger Teil vieler Verschlüsselungsprotokolle. Im Jahr 2005 kam einige Bewegung in die Debatte um Hash-Verfahren: Die Chinesin Wang Xiaoyun präsentierte einen Kollisionsangriff auf das bis dahin oft eingesetzte MD5. Auch das jüngere SHA-1 galt nicht mehr als sicher.

Bis heute konnte zwar noch niemand öffentlich eine Kollision auf SHA-1 präsentieren, jedoch gilt es nur als eine Frage der Zeit, bis das gelingt. Sowohl SHA-1 als auch dessen Nachfolger SHA-2 wurden von der NSA entwickelt. Allerdings gilt SHA-2 inzwischen als sehr gut untersucht. SHA-3 wurde ähnlich AES in einem Wettbewerb gekürt, doch bislang fehlt die finale Version des neuen Standards.

Kollisionsangriffe, wie sie auf MD5 und vermutlich auf SHA-1 möglich sind, sind nur unter speziellen Bedingungen ein Sicherheitsproblem. Dazu zählen etwa digitale Signaturen. An vielen Stellen können auch die alten Hash-Verfahren eingesetzt werden. Allerdings ist es oft schwierig herauszufinden, ob in einer bestimmten Situation ein Kollisionsangriff ein Problem darstellt. Im Zweifel sollte man daher kollisionsresistente Verfahren nutzen.

Fazit: Obwohl SHA-2 von der NSA entwickelt wurde, gilt es als sehr sicher. MD5 und SHA-1 sollten nicht mehr verwendet werden. SHA-3 ist noch nicht final verabschiedet, besitzt aber einige interessante Eigenschaften.

Quantencomputer

Während ein Angriff auf Verfahren wie RSA bei entsprechend langen Schlüsseln mit einem klassischen Computer praktisch nicht durchführbar ist, wäre er mit einem Quantencomputer sehr wohl möglich. Peter Shor konnte 1994 zeigen, dass sich die Faktorisierung großer Zahlen oder das diskrete Logarithmusproblem auf einem Quantencomputer effizient lösen lassen. Auch das diskrete Logarithmusproblem in elliptischen Kurven ist mit Quantenrechnern angreifbar.

Einen Quantencomputer zu bauen, der zur Faktorisierung von Schlüsseln geeignet ist, ist eine gigantische Herausforderung. Viele zweifeln daran, ob es überhaupt jemals möglich sein wird. In einem Laborversuch gelang es IBM-Ingenieuren, einen Quantencomputer mit 7 Bit zu betreiben - aus wissenschaftlicher Sicht ein Durchbruch, aber zum Angriff auf Kryptoverfahren völlig nutzlos.

Man müsste einen Quantencomputer bauen, der einen gesamten RSA-Schlüssel auf einmal angreifen kann - also 2.048 oder 4.096 Bit. Ein interessanter Aspekt ergibt sich daraus allerdings: Verfahren mit elliptischen Kurven sind aufgrund ihrer kurzen Schlüssel gegenüber Quantencomputern deutlich verwundbarer.

Für symmetrische Verfahren sind Quantencomputer keine wirkliche Bedrohung. Sie würden die Schwierigkeit eines Angriffs nur auf die Quadratwurzel reduzieren. Ein Angriff auf AES-256 wäre also so schwer wie ein klassischer Angriff auf AES-128.

Es existieren auch Public-Key-Verfahren, die gegen Quantencomputer immun sind. Allerdings handelt es sich dabei um exotische und wenig untersuchte Verfahren. Mit der Entwicklung von solchen Verschlüsselungsverfahren beschäftigt sich die Post-Quanten-Kryptographie.

Keine Bedrohung für Verschlüsselungsverfahren sind übrigens die Quantencomputer der Firma D-Wave. Dieser machte zuletzt Schlagzeilen, weil Google und die Nasa gemeinsam einen D-Wave-Quantencomputer gekauft haben. Der D-Wave-Computer ist kein generischer Quantencomputer und nicht in der Lage, den Algorithmus von Shor auszuführen.

Fazit: Einen Quantencomputer im Keller der NSA hält kaum jemand für möglich. Trotzdem: Die Forschung an Post-Quanten-Algorithmen ist sinnvoll. Für den Einsatz in der Praxis ist jedoch noch nichts verfügbar.

Bessere Verschlüsselung einsetzen

Nicht wenige haben in den vergangenen Tagen behauptet, die NSA könne sowieso jede Verschlüsselung brechen und das sei auch keine Überraschung. Dafür spricht jedoch nichts. Im Gegenteil: Gute Verschlüsselung hilft, davon ist auch Whistleblower Edward Snowden überzeugt.

Es gibt jedoch an vielen Stellen Nachholbedarf. Probleme mit alten, schwachen Algorithmen wurden viel zu lange nicht ernst genommen. Bessere Verfahren, die längst verfügbar sind, werden nicht genutzt. Oft genug geht Kompatibilität vor Sicherheit - in teilweise fahrlässiger Art und Weise. Das führt etwa heute dazu, dass es kaum möglich ist, einen HTTPS-Server sinnvoll zu konfigurieren, da man entweder auf den problematischen CBC-Modus oder auf den ebenfalls problematischen RC4-Algorithmus setzen muss.

"Verschlüsselung funktioniert", sagte Edward Snowden in einem Interview mit dem Guardian im Juni. "Gut implementierte, starke Verschlüsselung ist eines der wenigen Dinge, auf die man sich verlassen kann."  (hab)


Verwandte Artikel:
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )
CSE: Kanadas Geheimdienst verschlüsselt Malware mit RC4   
(24.10.2017, https://glm.io/130780 )
DUHK-Angriff: Vermurkster Zufallszahlengenerator mit Zertifizierung   
(24.10.2017, https://glm.io/130777 )
Verschlüsselung: Github testet Abschaltung alter Krypto   
(09.02.2018, https://glm.io/132684 )
Das Schwarze Auge: Schönere Neuauflage der Nordlandtrilogie geplant   
(28.01.2013, https://glm.io/97190 )

© 1997–2018 Golem.de, https://www.golem.de/