Dipl.-Inform. Carsten Eilers

Nadia Heninger, Zakir Durumeric, Eric Wustrow und Alex Halderman haben ähnliche Untersuchungen durchgeführt. Sie konnten "0.4% of all the public keys used for SSL web site security" kompromittieren. Ursache waren vorhersagbare Zufallszahlen, die sich teilweise wiederholten. Dabei wurden zwei Arten von schwachen Schlüsseln unterschieden: Zum einen die Schlüssel, die mit vorhersagbaren Zufallszahlen erzeugt wurden, zum anderen eine Untermenge, bei denen der öffentliche Schlüssel faktorisiert und damit der private Schlüssel ermittelt werden konnte. Ein Tool zum Faktorisieren der öffentlichen Schlüssel sowie zur Berechnung der zugehörigen privaten Schlüssel wurde entwickelt.

Betroffen sind laut Nadia Heninger überwiegend Embedded Devices wie Router oder VPN-Endpunkte, keine "full-blown web servers". Die Forschergruppe um Arjen K. Lenstra hat in der Hinsicht keine Angaben gemacht, es wurden aber von CAs ausgestellte Zertifikate mit unsicheren Schlüsseln entdeckt. Zumindest diese Zertifikate können nicht von Embedded Devices erzeugt worden sein, ob die zertifizierten Schlüssel evtl. von welchen erzeugt wurden, ist natürlich nicht bekannt.

Nadia Heninger schreibt außerdem:

"Don't worry, the key for your bank's web site is probably safe"

Das ist eine interessante Aussage, denn angeblich wurden ja alle IPv4-Adressen abgeklappert und die verwendeten SSL-Zertifikate eingesammelt. Nadia Heninger müsste also ganz genau wissen, ob ggf. eine Bank betroffen ist. Wieso also nur "probably safe"? Außerdem schränkt sie ihre Aussage weiter ein: "Only one of the factorable SSL keys was signed by a trusted certificate authority and it has already expired" - eine Einschränkung, die es bei den Ergebnissen von Arjen K. Lenstra et al. nicht gibt. Wie viele der von ihnen gefundenen problematischen Schlüssel aber wirklich aus einem CA-Zertifikat stammen, ist nicht bekannt. Banken-Zertifikate dürften aber nicht dabei sein, dazu gleich noch mehr.

Wir haben es also generell mit zwei Problemfeldern zu tun: Zum einen die von einer CA ausgestellten Zertifikate, zum anderen die von Embedded Devices wie Routern usw. selbst erzeugten Zertifikate. Dass die Embedded Devices Probleme mit der Erzeugung von Zufallszahlen haben, ist ein altbekanntes Problem, das u.a. mit der geringeren Leistungsfähigkeit und der mangelnden Entropie erklärt werden kann. Die CAs sollten in der Lage sein, gute Zufallszahlengeneratoren zu verwenden. Sofern sie aber vom Benutzer gelieferte Schlüssel zertifizieren, kann man darüber streiten, ob sie die auf ihre Qualität prüfen sollen/müssen.

Die gebrochenen Schlüssel

Die Schlüsselinhaber der 12.720 RSA-Schlüssel mit einer heute noch üblichen Länge von 1024 Bits, die Arjen K. Lenstra und seinen Kollegen brechen konnten, wurden von den Forschern informiert, sofern das möglich war. Teilweise fehlten aber brauchbare Kontaktinformationen, so dass die Schlüsselinhaber nicht kontaktiert werden konnten. Laut Electronic Frontier Foundation wurden alle Inhaber der von einer CA ausgestellten Zertifikate informiert: "The small number of vulnerable, valid CA-signed certificates have already been identified and the relevant parties have been notified.".

Und damit bekomme ich ein Problem mit den Ergebnissen der Gruppe um Nadia Heninger, die ja angeblich alle IPv4-Adressen untersucht und deren Zertifikate gesammelt hat. Dabei ist nämlich m.E. ein Punkt nicht berücksichtigt worden: Es gibt Shared Server, die zwar eine IPv4-Adresse, aber mehrere Domainnamen besitzen und je nachdem, an welche Domain ein Request gerichtet ist, andere Daten zurück liefern. Es wurden vielleicht alle IPv4-Adressen untersucht, aber bei weiten nicht alle Domains und damit auch nicht alle für Websites verwendeten SSL-Zertifikate.

Auf jedem Fall hat man mehrere von einer CA ausgestellten Zertifikate mit faktorisierbaren Schlüssel, die von Arjen K. Lenstra und seinen Kollegen gefunden wurden, nicht erfasst (denn laut Nadia Heninger wurde ja nur ein von einer CA ausgestelltes Zertifikat mit faktorisierbaren Schlüssel gefunden).

Die Aussage, es seien keine in irgend einer Weise sensiblen Websites betroffen, lässt sich also gar nicht treffen, da nicht alle Zertifikate geprüft wurden. Zumal die meisten Websites, die ihre Verbindungen über HTTPS absichern, in irgend einer Weise und für irgend jemanden sensibel sind, sonst würde man sich nicht die Mühe machen, SSL zu verwenden. Und zumindest eine "small number" davon nutzt unsichere Schlüssel.
Wäre allerdings ein unsicherer Schlüssel einer Bank oder einer anderen in irgend einer Form kritischen oder prominenten Website gefunden worden, hätte die EFF das mit Sicherheit bekannt gemacht. Und da Arjen K. Lenstra und seinen Kollegen u.a. die vom EFF SSL Observatory gesammelten Schlüssel analysiert haben, dürften sie einen großen Anteil aller "prominenten" Zertifikate erfasst haben. Wir können also wohl davon ausgehen, dass alle "wichtigen" Zertifikate sichere Schlüssel verwenden.

Die eigentlichen Gefahren

Wie gefährlich das alles ist, hängt vor allem von den betroffenen Schlüsseln ab. Im Fall der vom Embedded Devices erzeugten Schlüssel besteht die Gefahr, dass ein Angreifer sich im Rahmen eines gezielten Angriffs das gleiche Gerät wie sein Opfer besorgt und damit so lange Schlüssel erzeugt, bis ein passender für das Gerät seines Opfers dabei ist. Wie wahrscheinlich so ein gezielter Angriff ist, kommt dann wieder auf die Geräte an, bzw. wo die eingesetzt werden: Wenn sich ein Angriff lohnt, wird sich früher oder später ein Angreifer finden.

Normale Benutzer müssen sich darüber wohl keine Gedanken machen, Unternehmen etc. sollten sich aber schon davon überzeugen, dass die von ihren Embedded Devices wie Routern und VPN-Endpunkten genutzten SSL-Schlüssel sicher sind. Im Zweifelsfall können die benötigten Schlüssel auf einem normalen Rechner erstellt werden, so dass ein besserer Zufallszahlengenerator zum Einsatz kommt.

Wenn ich die Ergebnisse der beiden Gruppen betrachte, drängt sich mir der Verdacht auf, dass die von Arjen K. Lenstra et al. festgestellten Cluster zumindest zum Teil auf miteinander "verwandten" (um es vorsichtig auszudrücken) Embedded Devices zurückzuführen sind. Ob für jeden Cluster ein bestimmtes Modell verantwortlich ist oder ob mehrere Geräte einzelner Hersteller die gleichen Schlüssel erzeugen, lässt sich ohne weitere Informationen nicht sagen. Es ist aber nahliegend, dass alle Geräte einer Baureihe sich beim Start im gleichen Ausgangszustand befinden, so dass die danach erzeugten Schlüssel auf den gleichen Zufallszahlen basieren. Zumal viele Embedded Devices auf eine batteriegepufferte Uhr verzichten, so dass beim Einsatz der aktuellen Sekunden oder ähnlicher Daten als Entropie eben gerade keine "zufälligen" sondern vorhersagbare Werte verwendet werden.

Bei den unsicheren Schlüssel in von einer CA ausgestellten Zertifikaten muss man zwei Fälle unterscheiden:

1. Ein Benutzer kann einen unsicheren Schlüssel erzeugt und der CA zum Unterzeichnen vorgelegt haben. In diesem Fall kann man darüber streiten, ob es die Aufgabe einer CA ist, die Qualität des vorgelegten Schlüssels zu prüfen. Symantec hat bereits angekündigt, in Zukunft zusätzliche Sicherheitsmaßnahmen zu implementieren, um ggf. die Zertifizierung unsicherer Schüssel zu verhindern.
2. Eine CA hat selbst unsichere Schlüssel erzeugt und an ihre Kunden verkauft. In diesem Fall bleibt nur die Feststellung, dass diese CAs kräftig an dem Ast sägen, auf dem sie sitzen. Es ist ein weiterer Grund, den CAs nicht unbedingt zu vertrauen. Das benzingetränkte Kartenhaus, mit dem Jacob Appelbaum vom Tor Project das bestehende Zertifizierungssystem verglichen hat, glimmt immer stärker.

Leider wissen wir nicht, wo die unsicheren Schlüssel in den CA-Zertifikaten her kommen. Bekannt ist nur, dass es von CAs ausgestellte Zertifikate mit faktorisierbaren Schlüsseln gibt. Wer die Schlüssel erzeugt hat, wissen nur die betroffenen CAs. Als Advocatus Diaboli würde ich ja sagen: "Da sich keine betroffene CA gemeldet und die Schuld auf unsichere vom Kunden erzeugte Schlüssel geschoben hat, hat mindestens eine CA Dreck am Stecken".

Gegenmaßnahmen

Man sieht es einem Zertifikat leider nicht an, wenn es einen schwachen Schlüssel enthält. Lediglich Firefox-Benutzer können auf ein Tool zurückgreifen, um unsichere Zertifikate zu erkennen: Die aktuelle Version 2.0.1 der Erweiterung HTTPS Everywhere enthält die Option, das "Decentralized SSL Observatory" zu aktivieren. Danach werden anonymisierte Kopien aller Zertifikate für HTTPS-geschützte Websites an das SSL Observatory der Electronic Frontier Foundation geschickt, wo sie untersucht werden. Zur Zeit gibt es eine Warnung, wenn ein Zertifikat zu einem Embedded Device gehört und aufgrund unzureichender Zufallszahlen einen unsicheren Schlüssel enthält. Erkennungsfunktionen für weitere gefährliche Zertifikate sollen folgen. Als Benutzer hat man dann die Wahl: Verwendet man dem Schlüssel oder nicht (d.h.: Nutzt man die Website oder nicht). Und der Schlüsselinhaber kann sich Gedanken darüber machen, wo er einen sicheren Schlüssel her bekommt.

Eine Bemerkung am Rande

Der Titel des Papers von Arjen K. Lenstra et al.,"Ron was wrong, Whit is right" spielt auf zwei Kryptographen an: Den im ersten Teil erwähnten RSA-Miterfinder Ron Rivest sowie Whitfield Diffie, der gemeinsam mit Martin Hellman das Diffie-Hellman-Schlüsselaustauschverfahren entwickelt hat. Beim Diffie-Hellman-Schlüsselaustausch wird bei jeder Kommunikation aus zwei über die unsichere Verbindung ausgetauschten Nachrichten ein neuer gemeinsamer Schlüssel berechnet. Während für RSA zwei große, zufällige Primzahlen benötigt werden, benötigen die auf diskreten Logarithmen basierenden DH-Algorithmen wie DSA und ElGamal nur eine zufällige Primzahl.

Ob es hilfreich wäre, auf RSA zu verzichten und stattdessen auf DH zu setzen, wage ich zu bezweifeln. Denn auch dabei gibt es genug Möglichkeiten, Fehler zu machen. Und es ist ja nicht RSA gebrochen, sondern eine unsichere Erzeugung von RSA-Schlüsseln aufgedeckt worden. Und die Verwendung unsicherer Zufallszahlen ist ja nun wirklich ein altbekanntes Problem, über das z.B. 2008 Debian gestolpert ist, als auf Grund eines Patches OpenSSL vorhersagbare Zufallszahlen und dadurch schwache Schlüssel erzeugte. Von denen ja auch Arjen K. Lenstra et al. noch welche entdeckten.

Damit soll das Thema der unsicheren RSA-Schlüssel in SSL-Zertifikaten auch zumindest vorerst abgeschlossen sein. Es besteht kein Grund zur Panik, jeder sollte aber in Zukunft darauf achten, gute Zufallszahlen zu verwenden, um sichere RSA-Schlüssel zu erzeugen.

Das Thema für die nächste Folge habe ich noch nicht festgelegt, evtl. werde ich etwas über die gezielten Angriffe über Advances Persistant Threads schreiben.

Carsten Eilers

---

Übersicht über alle Artikel zum Thema

RSA und die schwachen Schlüssel, Teil 1: Einführung in RSA

RSA und die schwachen Schlüssel, Teil 2: Die Schlüssel

RSA und die schwachen Schlüssel, Teil 3: Die Gefahren