eMudhras schwache CA-Schlüssel: 5 PKI-Mythen entlarvt

Einer der privaten Schlüssel der Zertifizierungsstelle von eMudhra ist die Zahl 4. Keine 384-Bit-Zahl, die mit einer 4 beginnt, sondern wirklich nur 4, aufgefüllt mit 47 Null-Bytes, damit es respektabel aussieht. Das ist ein Fehler bei der Schlüsselerzeugung einer Zertifizierungsstelle, von dem ich gesagt hätte, dass er unmöglich ist. Er überstand Audits, die Cross-Signierung durch Sectigo und siebzehn Monate in produktionsnaher Infrastruktur, bis jemand das Naheliegende versuchte: ein einzelnes Byte per Brute-Force zu knacken. Hier sind fünf PKI-Annahmen, die dieser Vorfall ein für alle Mal erledigt.

Mythos 1: „Ein strukturell gültiges Zertifikat ist ein sicheres Zertifikat“

Jede automatisierte Prüfung in der Pipeline bestätigte, dass diese Zertifikate in Ordnung seien. Und in einem engen, nutzlosen Sinn hatten sie recht. Der öffentliche Schlüssel zu d = 4 ist ein völlig gültiger Punkt auf der Kurve P-384. Die ASN.1-Kodierung lässt sich parsen, die Signatur verifiziert sich, die Kette baut sich auf. Jedes Linting-Tool, jeder strukturelle Validator und jede Compliance-Checkliste, die ein Zertifikat durchgeht und prüft, ob es wohlgeformt ist, winkt diese Zertifikate durch, weil sie wohlgeformt sind.

Genau darin liegt die Falle. Strukturelle Validierung beantwortet die Frage „Ist das ein korrekt formatiertes Zertifikat?“. Sie beantwortet nicht die Frage „Wurde der darin enthaltene Schlüssel korrekt erzeugt?“. Bei Schlüsseln auf elliptischen Kurven sind das nahezu völlig unabhängige Eigenschaften. Der private Schlüssel ist schlicht ein Skalar d; der öffentliche Schlüssel ist d × G, wobei G der Erzeugerpunkt der Kurve ist. Das gesamte Sicherheitsargument beruht darauf, dass man d aus dem öffentlichen Punkt nur durch Lösen des diskreten Logarithmusproblems zurückgewinnen kann, aber nur dann, wenn d tatsächlich aus dem vollen 384-Bit-Raum gewählt wurde. Wählt man d dagegen aus 8 Bit, wird das „unmögliche“ Problem zu einer Schleife mit höchstens 255 Durchläufen.

Am resultierenden Zertifikat ist davon nichts zu erkennen. Der aus d = 4 abgeleitete öffentliche Punkt sieht genauso zufällig aus wie einer aus einem ordnungsgemäß erzeugten Schlüssel. Man kann es nicht auf den ersten Blick erkennen, und man kann es auch nicht mit einem Linter finden. Der einzige Weg, es zu wissen, ist, kleine Werte und bekannte schwache Muster durchzuprobieren, und genau das ist passiert: Der Melder ließ Googles paranoid_crypto-Testsuite gegen das Korpus der Common CA Database laufen, direkt nach der Installation, und erhielt einen Treffer. Eine Prüfung, die auf einem Laptop Millisekunden dauert, gegen Schlüssel, die für echte Browser das Vertrauen verankern.

Die erste Lehre daraus: Gültigkeit ist notwendig, aber bei Weitem nicht hinreichend. Wenn Ihre PKI-Tests bei „das Zertifikat lässt sich parsen und verketten“ aufhören, testen Sie die Hülle und ignorieren den Inhalt.

Mythos 2: „Baseline Requirements und Audits fangen Fehler bei der Schlüsselerzeugung ab“

Zertifizierungsstellen unterliegen den Baseline Requirements des CA/Browser Forum und werden nach den WebTrust- oder ETSI-Kriterien geprüft. Es gibt Zeremonie-Dokumentation, HSM-Anforderungen und Vorgaben zur Schlüssellänge. Die Schlüssel von eMudhra hatten die richtige Länge, auf dem Papier 384 Bit. Die Lücke im Audit ist: Compliance prüft die Darstellung des Schlüssels, nicht die Prozessentropie, die ihn erzeugt hat. Ein Schlüssel, der mit 47 Null-Bytes aufgefüllt ist, belegt auf der Festplatte trotzdem 48 Bytes.

Laut eMudhras eigener Darstellung im Mozilla-Incident-Ticket liest sich die Ursache wie eine schwarze Komödie: Ein Fehler im Zeremonie-Skript erzeugte ein zweites, schwaches Schlüsselpaar auf dem HSM; die beiden Paare hatten ähnliche Namen; ein Mensch wählte für den CSR das falsche aus. Drei getrennte Fehler, ein Skriptfehler, eine Namenskollision, ein Auswahlfehler, und an keiner Stelle fragte eine Kontrolle: „Hat dieser Schlüssel tatsächlich die Entropie, für die wir das HSM bezahlt haben?“

Das sollte jedem Ingenieur Sorgen machen, der eine eigene interne PKI betreibt. Wenn eine öffentlich vertrauenswürdige CA, mit Root-Programmen im Nacken und Audits im Kalender, einen privaten Schlüssel gleich 4 ausliefern kann, was steckt dann im Vault-PKI-Backend oder in Ihren Active-Directory-Certificate-Services-Vorlagen? Die Abhilfe ist günstig, und es gibt keine Ausrede, sie nicht umzusetzen. Führen Sie nach jeder Schlüsselerzeugung und bevor Sie damit irgendetwas signieren, den Schlüssel durch paranoid_crypto oder mindestens eine triviale Plausibilitätsprüfung:

from cryptography.hazmat.primitives.asymmetric import ec
CURVE_ORDER_BITS = 384
def sanity_check_private_key(key: ec.EllipticCurvePrivateKey) -> None:
d = key.private_numbers().private_value
# Reject keys whose effective entropy is far below the curve size.
# A healthy P-384 key should have a bit length close to 384.
if d.bit_length() < CURVE_ORDER_BITS - 32:
raise ValueError(
f"Suspiciously small private scalar: {d.bit_length()} bits"
)
# Also reject known bad values outright.
if d < 2**16:
raise ValueError("Private scalar is trivially brute-forceable")

Dreißig Sekunden Arbeit. Damit wären alle acht Schlüssel von eMudhra aufgefallen. Audits prüfen, ob Prozesse existieren; sie prüfen nicht, ob die Prozesse an einem bestimmten Dienstag im April tatsächlich funktioniert haben. Nur Tests der Ausgabe leisten das.

Mythos 3: „Ein kompromittierter CA-Schlüssel lässt sich eindämmen“

Wenn ein CA-Schlüssel im üblichen Sinn „kompromittiert“ wird, gibt es einen Dieb. Jemand hat den Schlüssel zu einem bestimmten Zeitpunkt exfiltriert, und man kann den Wirkungsradius abschätzen: Zertifikate, die nach dem Diebstahl von Parteien mit dem gestohlenen Schlüssel ausgestellt wurden. Unschön, aber begrenzt. Wir haben schon einmal darüber geschrieben, was passiert, wenn die Kompromittierung einer Intermediate-CA eine Vertrauenskette sprengt, und das übliche Vorgehen (widerrufen, Vertrauen entziehen, neu ausstellen) setzt ein Vorher und ein Nachher voraus.

Bei diesem Vorfall gibt es kein Vorher und Nachher. Der Schlüssel war praktisch öffentlich, sobald das Zertifikat erstellt wurde, denn jeder, der das Zertifikat je angesehen hatte, konnte ihn in Millisekunden zurückgewinnen. Es gibt kein Diebstahl-Ereignis, das sich eingrenzen ließe. Das Zeitfenster umfasst die gesamte Laufzeit der Zertifikate, ab April 2025, und es gibt keine Möglichkeit herauszufinden, wer, falls überhaupt jemand, durch die offene Tür gegangen ist. Die Aussage von eMudhra, die Intermediates hätten keine Endzertifikate ausgestellt, was durch Certificate-Transparency-Logs gestützt wird, ist für das, was diese CAs getan haben, tatsächlich beruhigend. Über das, was jemand mit d=4 im Netzwerk opportunistisch hätte anstellen können, sagt sie nichts.

Schlimmer noch: Die Reaktion selbst kann nicht vollständig greifen. Chrome und Firefox sperrten die Intermediates innerhalb weniger Stunden über CRLSet und OneCRL, und beide verlangen CT-Logging, sodass gefälschte TLS-Zertifikate in diesen Browsern ohnehin nie validiert worden wären. Gut. Doch dieser Schutz endet an der Browsergrenze, und damit kommen wir zum nächsten Mythos.

Mythos 4: „Wenn die Browser sicher sind, ist das Ökosystem sicher“

Browser sind das Best-Case-Szenario im TLS-Ökosystem und stellen operativ nur einen Teil der TLS-Clients dar, auf die es Ihnen ankommt. Denken Sie daran, was in Ihrer Infrastruktur tatsächlich HTTPS-Verbindungen aufbaut: curl, Pythons requests, Node, Go-Binaries, Java-Dienste, git, Paketmanager, Cloud-SDKs. Diese Clients haben drei Eigenschaften, die hier ungünstig zusammenwirken: Sie vertrauen einem CA-Bundle auf der Festplatte, sie prüfen Widerruf standardmäßig nicht und sie prüfen Certificate Transparency nicht. Alle drei Schutzmechanismen, die den Chrome-Nutzern geholfen haben, fehlen.

Scott Helme hat das konkret gezeigt: Mit einem gefälschten Zertifikat für api.stripe.com, das an eine der schwachen Intermediates von eMudhra gebunden war, meldete das Standard-curl SSL certificate verify ok, Python schloss den Handshake ab, Node meldete die Verbindung als autorisiert, und Windows CryptoAPI akzeptierte die Kette. Auf jedem getesteten Linux- und macOS-Rechner. Ein gefälschtes Zertifikat für jeden beliebigen Hostnamen, akzeptiert von den Standardwerkzeugen, auf denen Ihre Deployment-Skripte und CI-Runner aufbauen. Das ist kein Browser-Problem, sondern ein Problem Ihrer eigenen Infrastruktur.

Die Angriffsfläche ist schlimmer, als sich die meisten vorstellen:

• curl | sh-Installer und Self-Updater. rustup, nvm, der Homebrew-Installer, unzählige „install.sh“-Seiten. Ein gefälschtes Zertifikat bedeutet hier, Angreifer-Code auszuführen, häufig als root.
• CI/CD-Pipelines. Runner laden Abhängigkeiten und veröffentlichen Artefakte, während sie Cloud-Zugangsdaten und Signierschlüssel bei sich haben, oft auf veralteten Basis-Images.
• Server-zu-Server-Verkehr. Zahlungs-Webhooks, OAuth-Token-Austausch, Cloud-SDK-Aufrufe mit Geheimnissen in Headern.
• IoT- und Embedded-Geräte. Eingefrorene Firmware mit CA-Bundles, die sich erst ändern, wenn die Zertifikate ablaufen, im Juli 2039.
• Windows-Codesignierung. Zwei der acht schwachen Schlüssel gehörten zu Codesignatur-CAs; Malware, die damit signiert wurde, sieht aus wie Software eines legitimen Herausgebers.

Die handlungsrelevante Empfehlung ist langweilig und richtig: Aktualisieren Sie alles, was ein CA-Bundle mitliefert. Ihr Betriebssystem-Paket ca-certificates, certifi, Node, Homebrew. Und bauen Sie Ihre Container-Images neu, sobald die Basis-Images das Misstrauen übernommen haben, denn Layer merken sich alles. Der nicht umsetzbare Teil betrifft Geräte, die Sie nicht aktualisieren können. Dieser Smart-TV wird einen Schlüssel gleich 4 noch anderthalb Jahrzehnte lang vertrauen. Wenn Sie noch ein Argument dafür brauchten, Ihre IoT-Geräte im Netzwerk zu segmentieren, dann ist das dieses.

Mythos 5: „Irgendjemand prüft das bestimmt schon“

Die stillschweigend niederschmetterndste Zeile des Vorfalls stammt vom Melder: Die Entdeckung kam daher, dass er paranoid_crypto als schnellen Korpustest gegen das CCADB-Korpus laufen ließ, bevor er sich den Zertifikaten der Teilnehmer zuwandte. Das niedrig hängende Obst. Die eigenen Worte des Melders: „Den größten Teil meiner Zeit habe ich damit verbracht, die Grundlagen durchzugehen, von denen alle angenommen hatten, dass sie schon jemand anderes erledigt hat, ein kritischer Fehler, der in der Sicherheit niemals passieren darf.“

Lesen Sie das noch einmal. Acht private CA-Schlüssel, die Kronjuwelen einer öffentlich vertrauenswürdigen Instanz, quergezeichnet unter Sectigos AAA Certificate Services Root, waren siebzehn Monate lang per Brute-Force angreifbar. Gefunden wurden sie nicht von einem Auditor, nicht von einem Root-Programm und auch nicht von der CA selbst, sondern von einer einzelnen Person, die ein Open-Source-Werkzeug ohne Anpassung laufen ließ. Das Ökosystem ging kollektiv davon aus, dass die Grundlagen abgedeckt seien. Niemand hatte sie abgedeckt.

Das ist ein allgemeineres Muster in der Sicherheitsinfrastruktur, und deshalb predige ich immer wieder über defensive Ingenieurskunst, also Systeme, die Katastrophen widerstehen, statt Systemen, die von korrektem Betrieb ausgehen. Die Prüfungen, die das abgefangen hätten, sind geradezu peinlich günstig:

1. paranoid_crypto oder gleichwertige Prüfungen auf schwache Schlüssel bei jedem Schlüssel zur Erzeugungszeit und bei jedem CSR vor der Signatur ausführen.
2. Entropie empirisch prüfen: die Bitlänge des privaten Skalars kontrollieren und alles ablehnen, dessen effektive Entropie unplausibel niedrig ist, wie im Codebeispiel oben.
3. Die Zeremonie testen, nicht nur die Konfiguration. Schlüsselzeremonien trocken durchspielen und die tatsächlich erzeugten Artefakte prüfen, einschließlich des benannten HSM-Objekts, das im CSR landet.
4. Ausgestellte Zertifikate kontinuierlich scannen, nicht nur Ihre Vorlagen. Das Zertifikat ist die Grundwahrheit; alles davor ist Absicht.

Das Zertifikat ist die Grundwahrheit. Alles davor, also Skripte, Zeremonien und Audits, ist nur Absicht.

Acht Bit reichen aus

Es hat fast etwas Beruhigendes, wenn eine Katastrophe eine alberne Ursache hat. Ein Skriptfehler, zwei ähnlich benannte Schlüssel auf einem HSM, ein Mensch, der den falschen wählt: kein Nationalstaat, keine neuartige Kryptanalyse, nur eine Slapstick-Episode mit siebzehn Monaten Zündschnur. Aber gerade die Albernheit ist die Warnung. Wenn das schwächste Glied einer öffentlich vertrauenswürdigen CA ein einziges Byte sein kann, dann bestimmt nicht Ihre Kurvenwahl oder Ihr HSM-Budget die Stärke Ihrer PKI. Sie hängt davon ab, ob irgendjemand irgendwo in der Pipeline die Ausgabe tatsächlich getestet hat.

Die Browser-Hersteller haben ihren Teil innerhalb weniger Stunden erledigt. Der Rest liegt bei uns: Prüfen Sie Ihre eigene Schlüsselerzeugung, führen Sie die günstigen Tests aus, aktualisieren Sie jedes CA-Bundle, das Sie erreichen, und segmentieren Sie die Geräte, die Sie nicht erreichen. Und hören Sie auf anzunehmen, dass schon jemand anderes die Grundlagen geprüft hat. In der Sicherheit ist das die teuerste Annahme überhaupt.