Stand der Kryptografie 2014: Prozess und nicht Produkt

Originalartikel von Morton Swimmer, Senior Threat Researcher

Kryptografie ist ständig unter Beschuss – und entwickelt sich aus diesem Grund weiter. Doch Bedrohungen können großen Schaden anrichten. Das hat kürzlich Heartbleed gezeigt sowie vor längerer Zeit die Probleme mit verschiedenen Algorithmen wie RC4, MD5, SHA1 und Dual_EC_DRBG (übrigens sollte keiner davon weiter verwendet werden). Kann man der Verschlüsselung trauen? Nein! Ja! Vielleicht!

 

Es bedarf einer Menge solider aber auch raffinierter Mathematik, um einen guten Verschlüsselungsalgorithmus oder ein Kryptografieprotokoll zu erstellen. Es gibt wahrscheinlich nur eine Handvoll von Spezialisten, die tief genug in der Informationstheorie und Statistik stecken, um starke Algorithmen erstellen zu können. Zudem sind diese Könner nicht die Richtigen für die Kryptoanalyse – die Kehrseite des Entwerfens einer Chiffre ist nämlich deren Knacken.

Nützliche Algorithmen wie Einweg-Hashes (z.B. MD5) wurden von hochspezialisierten Könnern erstellt und dann rigoros analysiert und solange angegriffen, bis sie erfolgreich geknackt waren. Dann ging es zurück ins Design. Trotz dieser Zyklen werden die Algorithmen irgendwann geknackt.

Die Studie von 2004 führte zu weiteren Angriffen gegen das SSL/TLS-Protokoll, das Web-Browsing sichern soll. Doch auch heute noch wird auf Basis der Daten aus dem Crossbear SSL-Projekt MD5 in SSL/TLS-Zertifikaten verwendet. Auch wenn einige der Schwachstellen von MD5 angeblich geschlossen wurden, werden die Angriffe immer besser.

Wegen der ausgeklügelten Mathematik hinter der Kryptografie ist es sehr schwierig, eine sichere Implementierung eines bestimmten Algorithmus zu erhalten. Es wurden bereits eine Vielfalt an ausnutzbaren Fehler in den Implementierungen gefunden, und daher lautete die Empfehlung, wo immer möglich eine vertrauenswürdige quelloffene Umsetzung einzusetzen oder die Programmierung an einen Kryptografen zu vergeben, der sich entsprechend auskennt.

Dann aber kam Heartbleed. OpenSSL ist eine quelloffene Implementierung des SSL/TLS-Protokolls und der dazugehörigen Algorithmen – sollte also ein Vorbild für die Art und Weise sein, wie Kryptografie zu implementieren ist. Das Schlimme an Heartbleed war nicht die Tatsache, dass ein Fehler vorhanden war, sondern dass dieser nicht bereits vor über zwei Jahren gefunden wurde. So etwas sollte in einem Open Source-Projekt nicht passieren, wo Änderungen öffentlich sind und immer wieder geprüft werden.

Als Reaktion gab die OpenBSD Community zu verstehen, dass das Vertrauen in die Führung durch OpenSSL erschüttert sei und sie erstellten LibreSSL. Weil die erste Tat dieser Community darin bestand, eine Menge Code für ältere Plattformen zu entfernen (LibreSSL läuft nicht auf VMS), wird sie schnell ausschließlich zu einer OpenBSD-Bibliothek. Sollte diese Vorgehensweise Schule machen, so ist dies ein Verlust, weil die abweichenden Codes so unterschiedlich sind, dass keine gemeinsamen Sicherheits-Patches mehr funktionieren. Auch sollte zudem klar sein, dass Heartbleed nichts mit der tatsächlichen Verschlüsselung in OpenSSL zu tun hatte!

Ist Hardware-Sicherheit besser?

Die Antwort ist nein. Kürzlich hatte ein Chip-Hersteller Kryptografie in seine CPUs oder Chipsets eingebaut. Üblicherweise handelt es sich dabei um die Implementierung eines „Standard“-Chiffres (wie AES) oder eines Pseudo Random Number Generators (PRNG).

Trotz der Enthüllungen von Edward Snowden darüber, dass die NSA unterschiedliche Verschlüsselungsalgorithmen unterlaufen hat (vor allem Dual_EC_DRBG PRNG, 2006 von NIST veröffentlicht), nimmt Trend Micro an, dass AES keine Backdoors oder angreifbare Fehler beinhaltet. Doch was passiert, sollte AES doch kompromittiert werden? In diesem Fall hat der Anwender Verschlüsselungshardware, die er nicht verwenden kann. Sollte die Raw-Implementierung sich als fehlerhaft erweisen, kann sie nicht gefixt werden, doch werden einige Bibliotheken sie trotzdem nutzen, weil sie da ist.

Wäre es da nicht sinnvoller gewesen, allgemeine Verschlüsselungsprimitive zu implementieren, die dazu verwendet werden können, jeden Algorithmus einzubauen? Das Problem besteht nicht mehr nur in der Theorie: FreeBSD hat entschieden, den PRNGs in den Intel- und VIA-Chipsets nicht länger zu trauen und nutzen sie nicht mehr ohne Verstärkung. Ob die Zweifel berechtigt sind, weiß man nicht.

Eine andere Art, in der Hardware trügerische Verschlüsselungssicherheit liefert, besteht in der Vertraulichkeit der Schlüssel und Algorithmen. Das GMS Konsortium war der Ansicht, die A5/1- und A5/2-Algorithmen (für Stimmverschlüsselung in GSM-Netzen) geheim halten zu können, indem sie in lizenzierte Chips implementiert wurden. 1994 demonstrierte ein Forscher, wie einfach das Reversing von Chips ist, und 2003 wurde Fehler in den Algorithmen gefunden. Mittlerweile haben Hacker zum wiederholten Mal Schlüssel aus Firmware extrahiert, die eigentlich nicht auf Lesezugriff von außen zugeschnitten ist.

Auch ist es wahrscheinlich, dass Geheimdienste die meisten heute verwendeten Verschlüsselungsalgorithmen knacken können, wenn sie das wollen und es ihnen nützlich erscheint.

Auch einen weiteren Grund zur Sorge gibt es: Quantum-Computing, sollte es den Labs entwachsen, ist in der Lage die nötige Verarbeitung zu leisten, um die meisten Verschlüsselungen zu brechen. Glücklicherweise sind die derzeit erhältlichen Computer sowohl sehr teuer als auch nicht wirkliche Quantum-Systeme – noch nicht.

Vielleicht bringt Quantum-Kryptografie die Rettung. Sie ist nicht so breit aufgestellt wie die traditionelle und wird auch nicht alles ersetzen, doch bringt sie ein paar neue Fähigkeiten mit. In den ersten Jahren des neuen Jahrtausend setzten Schweizer Forscher einen Glasfaser-Linkf zwischen und Genf und Lausanne auf und führten eine erfolgreiche Quantum-Schlüsselverteilung durch. Es gibt zwar noch so manches Problem zu lösen, doch ist die Technologie schon sehr weit.

Fazit

Die Ansicht, dass Kryptografie ein Produkt sei, dass man kauft und dann sicher ist, ist falsch. Es handelt sich um einen Prozess, der nicht endet.

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.