Login


 
Newsletter
Werbung

Fr, 13. September 2013, 12:02

Software::Security

Roeckx: Aktueller Stand der Kryptografie

Welche Kryptografieverfahren sind im Licht der Spionageaffäre noch sicher verwendbar` Debian-Projektsekretär Kurt Roeckx analysiert in seinem Blog die Lage.

Während die NSA und artverwandte Organisationen alle Daten, legal oder nicht, im Internet, in Telefonnetzen und im Postwesen abhören und speichern, steigt das Bewusstsein für Verschlüsselung bei den Benutzern. Mittlerweile kursieren Gerüchte, dass die Geheimdienste Verschlüsslungen knacken könnten. Diese sind jedoch soweit haltlos, wie sie anerkannt sichere Verfahren und deren korrekte Anwendung betreffen. Einige Verfahren könnten jedoch unterwandert sein oder sind in bestimmten Zusammenhängen nicht mehr sicher genug. Diese gilt es zu vermeiden.

Kurt Roeckx hält es für nicht ganz ausgeschlossen, dass die NSA Algorithmen entwickelt hat, um die Verschlüsselung mit öffentlichen Schlüsseln leichter knacken zu können, oder ein Verfahren wie RC4 knacken kann. Einen Beweis hierfür sieht er allerdings nicht. AES hält er auf jeden Fall noch für sicher.

Der Beitrag von Kurt Roeckx konzentriert sich auf die Verwendung der Protokolle in SSL und TLS. Zunächst betrachtet er die Länge der Schlüssel in Bit. Schlüssel bis zu 80 Bit können unter Umständen durch extrem rechenintensives Durchprobieren aller Möglichkeiten geknackt werden. Die US-Standardorganisation NIST hatte daher 2005 bereits empfohlen, ab 2010 nur noch längere Schlüssel zu verwenden.

In SSL/TLS kommen verschiedene Verfahren gemeinsam zum Einsatz, so dass man zur Bewertung der Sicherheit die schwächste Komponente heranziehen muss. 80 Bit Schlüssellänge bei symmetrischen Verfahren entsprechen 1024 Bit bei asymmetrischen Verfahren mit öffentlichen und privaten Schlüsseln (Public Key). 1024 Bit sind somit heute zu wenig. Ab 2048 Bit, was 112 Bit bei symmetrischen Verfahren entspricht, kann man unbesorgt sein. 3072 Bit entsprechen 128 Bit bei symmetrischen Verfahren, mit steigender Länge wird aber auch immer mehr CPU-Leistung benötigt.

Viele Quellen empfehlen den Einsatz des Diffie-Hellman (DH)-Algorithmus, um »Perfect Forward Secrecy (PFS)« zu erreichen. Es gibt davon zwei Varianten, die Standard-Variante DHE und das auf elliptischen Kurven beruhende ECDHE. Für die Standardvariante sollte man mindestens 2048 Bit lange Schlüssel einsetzen. ECDHE benötigt doppelt so lange Schlüssel, ist aber trotzdem schneller. Sehr viele elliptische Kurven lassen sich verwenden, was jeweils unterschiedliche Verfahren ergibt. Entscheidend ist, welchen veröffentlichten Kurven man vertraut. So warnte Dan Bernstein in einem Vortrag (PDF) dieses Jahr vor den NIST-Kurven, weil diese von kaum einer Software korrekt implementiert werden könnten. Jede Software, die diese verwendet, sei angreifbar.

Auch kryptografische Hash-Funktionen werden benötigt. Aktuell sind MD5 (128 Bit), SHA1 (160 Bit) und SHA2 (256 Bit) nach Roeckx' Einschätzung noch sicher genug (es gibt noch weitere Verfahren, aber die genannten sind besonders verbreitet). Wenn jedoch ein sogenannter Kollisionsangriff möglich ist, sollte MD5 vermieden werden. In SSL/TLS ist MD5 noch als sicher anzusehen.

Wichtig ist auch der Zufallsgenerator, da er unter anderem benötigt wird, um Schlüssel zu generieren. Entscheidend ist dabei vor allem der Anfangswert. Ist dieser von einem Angreifer eingrenzbar, könnte das die Entschlüsselung von Nachrichten wesentlich erleichtern. Leider ist es sehr schwierig, zu bestimmen, ob ein Zufallsgenerator wirklich sicher ist. Man kann nur darauf hoffen, dass die Implementierungen gut genug sind.

Für die eigentliche Nachrichtenverschlüsselung werden üblicherweise symmetrische Algorithmen eingesetzt, da asymmetrische zu langsam sind. TLS kann verschiedene Algorithmen verwenden, die zwischen Server und Client ausgehandelt werden. Einer der populärsten Algorithmen, CBC, wird durch den sogenannten BEAST-Angriff gefährdet, doch dafür existiert ein Workaround. GCM dagegen ist noch nicht weit verbreitet, so dass nun wieder oft RC4 eingesetzt wird. Triple DES hat nur 112 Bit effektive Schlüssellänge, ist aber nach obigen Ausführungen noch ausreichend.

Ideal wäre es nun, wenn die Software diese Erkenntnisse auch nutzen würde, doch das ist nicht immer der Fall. So unterstützt Apache nur DHE-Schlüssel bis 1024 Bit und das Projekt zeigt sich unwillig, das zu verbessern. Erst ab Apache 2.4 ist ECDHE nutzbar. Auch Mozilla bewegt sich laut Roeckx zu langsam. TLS 1.1 und 1.2 werden noch nicht unterstützt. GCM wurde implementiert, doch gibt es noch ein Problem damit. Bei anderen Browsern dürfte es kaum besser aussehen.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung