RSA SecurID Seeds geklaut
Kleines Update zu meinem RSA SecurID-Artikel von neulich: Bei RSA scheinen tatsächlich die Token Seeds geklaut worden zu sein und RSA muß nun alle (!) Tokens durch neue ersetzen.(Nachtrag)
Heise, Spiegel, Golem und bestimmt viele andere melden, daß RSA nun sämtliche (ca. 40 Millionen) RSA Tokens austauschen muß. In Fefes Blog findet sich ein Hinweis auf diese Webseite, wonach tatsächlich die Seeds geklaut wurden.
Wie ich in meinem Artikel von neulich schon schrieb, ist eine Kompromittierung der Verifikationsdaten schon ohne Kenntnis des Algorithmus und selbst dann, wenn es ein Falltürmechanismus (bzw. irgendwas asymmetrisches) wäre, schon ein Totalverlust der Sicherheit, weil der geringe Suchraum von 106 einen Brute Force Angriff leicht ermöglicht und deshalb eventuelle Asymmetrien so gut wie wertlos sind. Es scheint aber laut dem Artikel so zu sein, daß der Token Seed alle Daten enthält, also daß man mit Seed und Algorithmus (und was man im Artikel offenbar vergessen hat, Kenndaten über die Zeitdrift des Tokens) den Token vollständig simulieren kann. (Zwischen Simulieren des Tokens und einem echten Einloggen fehlen einem dann noch Benutzername und PIN.)
Also im Prinzip eine Total-Kompromittierung. Erstaunlich ist eher, daß man den Tokens bisher einen so hohen Sicherheitswert zugestanden hat (was ich nie habe, ich habe meine damaligen Kunden immer in Hinblick darauf gewarnt). Denn das RSA mit den Seeds leichtfertig umging (wobei ich mir noch nicht sicher bin, ob das, was bei RSA nun geklaut wurde, und das, was als Datei einer Packung Tokens beiligt, gleichwertig ist, oder ob die bei RSA mehr geklaut wurde), indem man das einfach als offene Diskette oder CD beilegte, war offensichtlich. Insofern müssen sich eher alle die „Sicherheitsexperten”, die jetzt so höhnisch und schadenfroh über RSA hetzen, fragen lassen, warum sie nicht vorher schon auf den Trichter gekommen sind, daß das zwar bequem und Doof-User-tauglich, keinesfalls so sicher sein kann, wie RSA behauptet hat. Die Sicherheitslücken und die Nachlässigkeiten von RSA haben einen in die Nase gebissen. Aber viele „Sicherheitsexperten” sind eben auf Kenntnis des publizierten Wissens und der publizierten Meinung beschränkt.
Interessant ist jedoch, das mich zu meinem Artikel von neulich ein Kommentator unter dem Namen oder Pseudonym „Jack Hollister” so extra aggressiv anging, wie ich denn RSA so besonders kritisieren könne. RSA habe keine Schwäche, die nicht sämtliche anderen One-Time-Passwort-Systeme auch hätten. Stimmt nicht. Es geht hier durchaus um RSA-spezifische Schlamperei.
Grundsätzlich muß allerdings schon folgern, daß OTP-Tokens, wie komplett verschlossen vom Hersteller kommen, systematisch unsicher sein müssen. Es muß notwendigerweise irgendeine Form von Individualisierung stattfinden. Oder anders ausgedrückt, es muß in dem ganzen Krypto-Spiel irgendwo ein Geheimnis mitspielen, das weder der Hersteller/Lieferant kennt, noch das trivial abhörbar ist (und damit prinzipiell auch nicht vom Benutzer selbst über eine Tastatur eingegeben werden darf).
Die Konsequenz wäre also, daß Tokens bei der Vergabe noch mit dem Verifikationsserver verbunden und mit einem oder mehreren individuellen Geheimnis ausgestattet werden müssen, und daß sie dem Benutzer die Wahl lassen, gegen welchen Login-Server sie sich authentifizieren, wenn man sich anmeldet. Daß also auch das individuelle Geheimnis und der Server, gegen den man sich anmeldet, in die Berechnung des Token-Codes mit einfließen. Aber dann bräuchte das Ding schon wieder eine Taste oder sowas.
Nachtrag: Nu hab ich (weil mich noch ein Anruf unterbrochen hat) ganz vergessen zu schreiben, worauf ich eigentlich hinauswollte:
Wenn RSA selbst die Seeds hat und jeden Token simulieren kann – dann haben es die amerikanischen Geheimdienste auch. RSA Tokens sind also sowas wie eine amerikanische Backdoor by Design.
5 Kommentare (RSS-Feed)
Weil das zwar mehr Geld kostet (nicht nur bezüglich Speicher, sondern auch Stromversorgung usw.), aber keinen ernsthaften kryptographischen Vorteil bringt. (Außerdem war Speicher eben nicht billig, als die Dinger entwickelt wurden.) Würde man die Liste der Zufallswerte klauen, wäre man genauso naß. Ansonsten kann man einen Token nämlich ziemlich primitiv bauen, da braucht’s keinen Prozessor, da reicht irgendein ASIC oder FPGA. Außerdem muß die Batterie da drin mindestens mal ca. 5 Jahre halten (meine ältesten ACE-Tokens haben nach über 10 Jahren noch geblinkt.)
Ansonsten wäre es einfach, bei 5 Jahren Laufzeit bräuchte man 5*365*24*60 = 2.628.000 Zufallswerte, mit jeweils etwa 20 Bit. Käme als mit etwa 8 MByte hin. Aber die Batterie dürfte das wohl nicht packen. Außerdem müßte man es neu entwickeln. Und das, obwohl kein erkennbarer Vorteil gegenüber steht.
Das Problem ist ja nicht der Seed. Das Problem ist, daß RSA eine Kopie des Seeds hat. Das ist also das falsche Problem, das Du betrachtest.
Die Abwesenheit eines Algorithmus halte ich schon für einen kryptographischen Vorteil – wenn man nichts macht, kann man auch nicht viel verkehrt machen. Ich muss zugeben, mir über den Stromverbrauch hatte gar keine Gedanken gemacht zu haben, finde das jetzt aber nicht so schlimm: Ein USB-Stick braucht im Ruhezustand nix, und die Elektrik schaltet den Chip alle paar Stunden mal kurz an und kopiert einen Block geeigneter Größe in den RAM um (der in der rechnenden Variante auch da sein muss, und eine CPU wohl auch – wenn das Teil halbwegs sicher sein soll, braucht man Blum-Blum-Shub oder etwas noch besseres, damit man nicht aus dem Keystream den Seed errechnen kann).
Unabhängig vom Algorithmus plädiere ich weiterhin dafür, dass der Seed (sei es n=p*q oder ein ganzes OTP) direkt beim und vom Kunden generiert wird (End-zu-End-Verschlüsselung im weitesten Sinne) und RSA den gar nicht zu sehen kriegt (was man nicht hat, kann die Regierung nicht beschlagnahmen).
Wieso „Abwesenheit eines Algorithmus” ?
Glaubst Du, die Zufallszahlen kommen vom Himmel gefallen, wenn Du sie nicht im Token, sondern im PC berechnest?
Worauf Du hinauswillst ist ja nicht die Abwesenheit eines Algorithmus, sondern daß die Entropie des Geheimnisses so groß ist wie die Summe aller angezeigten Token-Codes, und nicht nur wie das Seed, mit dem das Token initialisiert wird. Und woher in einem PC oder Server diese viele Entropie kommen soll, mußt Du erst erklären. Das ist ja nicht Algorithmen-los, nur weil der Algo unsichtbar irgendwo im PC versteckt ist und nicht mehr im Token. Da legt man sich leicht selbst rein.
Ganz wichtige Grundregel in der Kryptographie: Immer überlegen, wo die Zufallszahlen bzw. Entropie herkommt. Und das Problem bei RSA ACE ist eben, daß alles, was da an Entropie drinsteckt, vom Hersteller kommt.
Mal eine Frage eines Laien: Wer ist denn der Hersteller der Tokens, die bei PayPal Anwendung finden? Hat dieser “Angriff” auf die RSA-Token hierauf eine Auswirkung?
Was ich nicht verstehe: Warum haben die Teile überhaupt Seeds? Speicher kostet nix, einfach im Firmenserver pro Token 10^9 echte Zufallswerte generieren und je auf lokaler HD und Stick ablegen, letzterer zeigt dann minütlich einen neuen an (in anderen Worten, der “Seed” ist einige GB lang und der “Pseudozufallsgenerator” ist der Arrayzugriff). Wenn ein Token abhanden kommt, File im Server löschen, fertig. Dann bleibt immer noch das Problem, dass jemand ein Token mit Salpetersäure schichtweise wegätzt und die Daten in Form einzelner Elektronen aus den Zellen pult, aber das hat man jetzt auch schon (und sollte lange genug dauern, um auf dem Server zu reagieren – “Müller hat sich seit 4 Tagen nicht angemeldet” reicht ja als auslösende Warnung).