X.509-Zertifikate: Single Point of Failure
Der Comodo-Hack von dieser Woche hat es (wieder einmal) gezeigt:
Streng einzeln hierarchische Krypto-Zertifikatsstrukturen wie X.509 leiden (neben vielen anderen Schwächen, an denen X.509 bzw. dessen Umsetzung nach RFC leidet) unter dem Problem, daß sie mit der CA einen Single Point of Failure enthalten. Das ist ein Konstruktionsfehler, der nicht ohne weiteres (d.h. ohne Eingriff in die Datenstrukturen) zu korrigieren ist (gut, man könnte die Extensions dafür nutzen, aber es wäre halt hingemurkst). In einer Baumstruktur hängen viele Abkömmlinge allein von einer CA ab. Ist die kompromittiert, läßt sich alles fälschen. Und genau das ist ja passiert.
Das ist eine erstaunliche Eigenschaft, denn normalerweise baut man in der IT bezüglich Security (und noch mehr Safety bzw. Verfügbarkeit) alles redundant. Nur hier macht man gerade das nicht. Bemerkenswerterweise leidet PGP mit seiner ungeordneten Zertifikatsstruktur nicht bzw. nicht in diesem Maß unter dieser Schwäche.
Insofern müßte man eigentlich von dem Konzept einer einzelnen (übergeordneten) CA abgehen und zu einer n-aus-m-Zertifizierung gehen: Ein Public Key ist dann vertrauenswürdig, wenn von m CAs, denen man vertraut, mindestens n unterschrieben haben, n natürlich >1. Und dann sorgt man dafür, daß im Normalfall jeder Public Key mindestens n+1 Unterschriften trägt. Falls dann jemand einen CA-Schlüssel ergattert (und man es merkt), ist dann noch gar nichts passiert. Er kann nichts fälschen, man kann die CA einfach invalidieren und hat mehr oder weniger viel Zeit, um die Redundanz wieder zu erstellen.
Seltsam, daß man das nicht so gebaut hat. Vielleicht ist das Problem aber nicht X.509, denn das ist ja ziemlich alt, sondern daß man heute immer noch eine so uralte Struktur mit deutlichen Schwächen nutzt.
Die Bundesregierung posaunt gerade, daß sie Sicherheit im Internet betreiben will, und wirft Professoren jede Menge Geld an den Kopf, ohne daß man da erkennbare Ziele hätte. Die Entwicklung eines neuen Verschlüsselungs- und Zertifikatsstandards mit öffentlicher Bereitstellung von Software im Quelltext mit von allen ohne Lizenzgehupse nutzbarem Quelltext – das wäre doch mal eine sinnvolle Entwicklung.
(Bin mal gespannt, welcher Professor das nun wieder aus meinem Blog abschreibt…)
5 Kommentare (RSS-Feed)
Das Problem ist nicht, dass es eine Hierarchie gibt, sondern, dass jede CA jedes Zertifikat unterschreiben kann. Wenn es Einschränkungen gäbe, wer welches Zertifikat unterschreiben dürfte, wäre das Problem eingedämmt.
Es würde sich doch anbieten, mittels DNSSEC Zertifikate zu unterschreiben. Die Rootzone wird ja zumindestens recht gut abgesichert, die Key ceremonies sind ja fast ein Staatsakt. Wenn in einer Untergeordneten Zone Schlüssel kompromittiert werden, haben die alleine das Problem. Nicht gleich die ganze Welt.
Vorteil wäre auch, dass den CAs ihre finanzielle Grundlage entzogen wird: 15 Euro für eine einfache Verifikation der Domain mittels Email mit Bestätigungslink?!
Ich habe mal vor ein paar Jahren für die ENISA einen Vortrag gehalten und darin vorgeschlagen, daß der Inhaber einer (Länder-)domain bestimmen kann, wer dafür Zertifikate ausstellt. Daß also beispielsweise nur Deutschland bestimmen kann, wer Zertifikate für .de-Domains ausstellt. Und noch ein paar andere Verbesserungen.
Interessiert aber niemanden so richtig.
Forschungsgelder werden in Deutschland dafür verpulvert, entweder gar nichts zu machen oder sich mit den Problemen und dem Gegebenen zu arrangieren, statt was zu verbessern.
Würde man beispielsweise offizielle deutsche Zertifizierungsstellen bauen und dann fordern, daß ein Zertifikat mindestens 3 gültige von 5 möglichen Unterschriften trägt, wäre das deutlich robuster.
Betreiber einer TLD bestimmen, wer für diese TLD Zertifikate signieren darf: Ja, das würde helfen die Probleme einzudämmen, sie aber nicht lösen.
Offizielle deutsche Zertifizierungsstellen: CAs, die entweder in staatlicher Hand, von öffentlichen Geldern abhängig oder einfach nah am Staat sind (etwa die Telekom), wäre in etwa mein absolutes Albtraum-Szenario. Hier muß man einfach mal wieder nach China schauen (das Noch-Vorbildsland für alle Internetüberwachungsalbträume, auch wenn Europa da auf Aufholjagd ist), wo sie genau das Problem haben, daß die Regierung eine CA hat und die auch gerne mal benutzt um Dissidenten abzuschnorcheln.
DNSSEC: Es gibt bereits Vorschläge, daß man in bestimmten Resource Records im DNS die Public Keys der CA hinterlegen kann, deren Signatur für diese Domain akzeptiert werden soll. Der Mechanismus wird von den großen CAs eher schlecht geredet, weil Leute sich dann ihre eigenen CAs aufsetzen können und den großen CAs das Geschäftsmodell platzt. Hier ist das Problem, daß DNSSEC selbst eine ganze Reihe von Problemen hat. Es ist besser als kein DNSSEC, aber es ist auch noch nicht die Antwort auf alle Sicherheitsprobleme bei DNS, bestenfalls ein Zwischenschritt.
Ich denke man kann gar nicht genug betonen, wie problematisch CAs in diesem ganzen Modell sind. Dies sind profitorientierte Privatunternehmen, die zwar das Geschäftsmodell “Vertrauen herstellen” haben _sollen_, de facto aber das Geschäftsmodell “Geld verdienen mit der Illusion von Vertrauen” haben. Nahezu alle CAs haben eine lange Geschichte von Schlampereien und Fehlern, das Ausstellen von Zertifikaten für die falschen Domains ist nur eine davon, die CAs müssen sich z.B. auch vorwerfen lassen, daß sie regelmäßig viel zu spät anfangen auf modernere Signatur- und Verschlüsselungs-Algorithmen umzustellen (verursacht ja Kosten).
Ein weiteres Problem ist m.E. X.509 selbst, das aus einem extrem komplexen Standard hervorgegangen ist (Stichwort: DAP), der zurecht an seiner eigenen Komplexität gescheitert ist. Die X.509 Struktur in den Zertifikaten ist nach heutigen Maßstäben vollkommen überzogen und unsinnig und ihr fehlen endlos viele Features die nur zum Teil in Extensions nachgerüstet wurden.
Zu guter Letzt bleibt noch das Problem der Implementierungen gerade auf Client-Seite. Die meisten Clients prüfen Zertifikate nur äußerst oberflächlich und prüfen insbesondere nicht auf die diversen Extensions. Obendrein lassen Hersteller von Geräten oder Software ihre SSL-Komponenten gerne vor sich hin gammeln und updaten sie nur sehr langsam oder für kurze Zeiträume. Was wiederum den CAs Anlaß dazu gibt zu sagen “ja, aber wir können nicht vom unsicheren MD5 auf SHA1 wechseln, dann gehen ja die ganzen alten Clients nicht mehr”.
Vermutlich muß es bei SSL mal richtig übel krachen, bevor sich jemand dieser Probleme annimmt. Mit Blick auf Nonsense-Projekte wie den “Digitalen Radiergummi” bin ich nicht zuversichtlich, daß staatlich geförderte Forschung in Deutschland hier Abhilfe verschaffen kann. Vielleicht wenn man fähige Leute aus dem Ausland fördert und dem Daniel Bernstein mal Geld anbietet, damit er sein DNSCurve endlich mal fertig macht.
Tja, dummerweise ist es meistens so, daß es erst richtig laut krachen muß, und dann alle Eindämmungsversuche versagen, damit sich was ändert. Comodo ist meiner Meinung nach noch zu klein. Wenns verisign oder die Telekom erwischt, ists vielleicht laut genug.
Und der zweite Fail: Sicherheitsmaßnahmen, die aus Bequemlichkeit ausgeschaltet sind.