Fehlerhafte Key Ceremony bei eMudhra: Acht vertraute CA-Schlüssel trivial knackbar

Acht Zwischenzertifizierungsstellen des indischen Unternehmens eMudhra wurden mit privaten Schlüsseln ausgestattet, die sich aus den öffentlichen Zertifikaten in deutlich weniger als einer Sekunde rekonstruieren lassen. Das meldete am 17. Oktober 2026 ein Forscher, der unter dem Namen „Wayne“ auftritt. Mozilla erhielt die Meldung um 20:06 UTC, weitergeleitet vom Chrome Root Program. Binnen etwa zwei Stunden rekonstruierte Mozilla die Schlüssel eigenständig und ohne die Methode des Meldenden zu kennen. Damit war bestätigt, dass der Fehler in der Schlüsselerzeugung lag und sich trivial ausnutzen ließ.

Ursache war kein Einbruch. Nach Darstellung von eMudhra war es ein fehlerhaftes Skript, das bei einer Key Ceremony lief; menschliche Kontrollen bemerkten den Fehler nicht.

01Wie schwach die Schlüssel waren

Es handelte sich um Elliptic-Curve-Schlüssel auf P-384. Ein korrekt erzeugter privater Schlüssel ist eine Zahl aus einem Raum von rund 2^384 Werten. Laut dem Incident Report von Mozilla lagen alle acht Schlüssel unter 256, ein Angreifer musste also nur 256 Kandidaten testen. Die Schlüssel lauteten 4, 56, 66, 115, 155, 156, 230 und 237. Der private Schlüssel von „EM OV TLS CA - G3C“ war schlicht 4.

Ein öffentlicher Elliptic-Curve-Schlüssel ist der private Skalar, multipliziert mit dem Basispunkt der Kurve. Ein Skalar unter 256 lässt sich daher finden, indem man einige hundert Vielfache dieses Punktes berechnet. Danach genügt ein Vergleich mit dem öffentlichen Schlüssel im Zertifikat. Daraus erklären sich die berichteten Wiederherstellungszeiten von unter einer Sekunde. Ars Technica beziffert die effektiven Schlüsselgrößen auf 3 bis 8 Bit. Eine Herstelleranalyse spricht von „Bytes“, was nicht zu den Schlüsselwerten selbst passt.

Der Schlüssel einer Zwischen-CA kann jedes Endzertifikat signieren, das zum darüberliegenden Root führt. Wer einen dieser Schlüssel besaß, konnte Zertifikate für beliebige Domains fälschen und Server imitieren, um Datenverkehr abzufangen oder zu verändern. Wie Ars anmerkt, setzt die Ausnutzung weiterhin eine aktive Adversary-in-the-Middle-Position voraus. Für manche Angreifer ist das eine hohe Hürde, für jeden mit Kontrolle über ein lokales Netz jedoch leicht zu nehmen.

Der Umfang ist wichtig. Die acht Schlüssel stammen aus einem Stapel von 24 Zwischenzertifikaten, die am 30. April 2025 erzeugt wurden. Sechs stellen TLS-Zertifikate aus, zwei dienen dem Code-Signing; Sectigo hat alle acht im Mai 2025 per Cross-Signing beglaubigt. Mit den Cross-Signs waren 16 Zertifikate betroffen.

02Was bei der Ceremony schiefging

Eine Key Ceremony ist das skriptgesteuerte, beobachtete Verfahren, in dem eine CA ihre sensibelsten Schlüssel in Hardware-Sicherheitsmodulen (HSMs) erzeugt. eMudhra sagt, bei der Ceremony seien HSMs nach FIPS 140-2 Level 3 verwendet worden. Die aktualisierte Stellungnahme betont, der Fehler habe in einem Verfahrensschritt gelegen und nicht im Fehlen von HSMs.

Der Bugzilla-Bericht schildert den Ablauf:

• Die Ceremony erzeugte im HSM wie vorgesehen starke ECC-Schlüsselpaare.
• Eine genehmigte Abweichung fügte einen Wrap/Unwrap-Test hinzu, weil die Schlüssel in diesem Fall für den Export vorgesehen waren. Beim Wrapping wird ein Schlüssel unter einem anderen Schlüssel verschlüsselt, damit er zwischen HSMs transportiert werden kann.
• Ein Codefehler erzeugte zusätzlich ein zweites, schwaches Schlüsselpaar im HSM.
• Die Bezeichnungen des schwachen Paares ähnelten denen der Originale, sodass es irrtümlich zum Erstellen der Certificate Signing Requests verwendet wurde, die der Root dann signierte.
• Dieselben CSRs gingen zum Cross-Signing an Sectigo.

In dieser Kette musste keine Kryptohardware versagen. Das HSM erzeugte auf Anforderung einen schlechten Schlüssel, und ein Mensch oder ein Prozess wählte den falschen aus. Das Unternehmen räumt selbst ein, dass ein Skriptfehler zur Ausstellung von CAs mit schwachen Schlüsseln führte. Es bestätigte zudem menschliche Fehler an mehreren Stellen und versprach, jede bisher durchgeführte Key Ceremony erneut zu prüfen. Das deutet auf fehlende Maker/Checker-Kontrollen hin. Niemand verglich die zu zertifizierenden öffentlichen Schlüssel mit denen, die die Ceremony hätte liefern sollen, und niemand prüfte vor der Signatur durch den Root Schlüsselgröße oder Zufälligkeit auf Plausibilität.

03Die übersehene Warnung

Das unangenehmste Detail ist ein Vorläufer aus dem Jahr 2025. Mozillas Fragen an eMudhra beziehen sich auf Bug 1970728 vom Juni 2025. Dort passte der Schlüssel, mit dem bestimmte CRLs signiert wurden, nicht zum öffentlichen Schlüssel im zugehörigen CA-Zertifikat. eMudhra fand das zweite Schlüsselpaar, das passte, und signierte die CRLs damit neu. Den Betrieb zu stoppen und zu klären, warum es zwei Paare gab, unterblieb. Eine CRL ist die signierte Liste gesperrter Zertifikate, die eine CA veröffentlicht. Eine CA, deren CRL die Prüfung nicht besteht, hat per Definition ein Problem mit der Schlüsselintegrität.

Nach eMudhras späterer Erklärung wurden die CRLs zunächst mit den ursprünglichen, starken Schlüsseln signiert. Diese Signaturen schlugen fehl, weil die Zertifikate über die schwachen Schlüssel ausgestellt worden waren, also wurden die CRLs mit den fehlerhaften neu signiert. Ein Anbieter von Threat Advisories gibt an, der Fehler habe etwa 17 Monate und zwei Audit-Zyklen überdauert. Das ist eine Sekundärbehauptung, und die Audit-Details habe ich nicht verifiziert. Was auch immer die Audit-Unterlagen zeigen: Der Vorfall von 2025 bot einen diagnostischen Pfad, der das Problem aufgedeckt hätte, und wurde als Konfigurationsfehler abgeschlossen.

Die Entdeckung war billig. Berichten zufolge testete der Forscher den CCADB-Bestand öffentlich vertrauter Zwischenzertifikate, und laut einem Bericht kamen die quelloffenen Prüfungen von Googles paranoid_crypto zum Einsatz. Das Durchsuchen öffentlicher Zertifikate nach schwachen Schlüsseln ist eine alte Technik. Öffentliche Belege dafür, dass dafür etwas Exotisches nötig war, gibt es nicht.

04Sperrung – und warum damit nicht Schluss war

Die Eindämmung bei den Browsern ging schnell. Chrome lieferte am 17. Oktober ein CRLSet-Update aus, und Mozilla übertrug OneCRL-Einträge, ohne dass ein Browser-Neustart nötig war. eMudhra sperrte am 18. Oktober alle acht Zwischenzertifikate (Grund: caCompromise). Sectigo sperrte die Cross-Zertifikate am 19. Oktober. Apple und Microsoft folgten in den nächsten Tagen, wobei einige Berichte bei den genauen Daten um ein bis zwei Tage abweichen. Der frühe Bericht von Ars Technica, der von ein bis zwei Tagen für die Browsersperren spricht, ist langsamer als die primäre Zeitleiste. Er vermerkte außerdem, dass sich Edge unter Windows 10 zum Zeitpunkt der Veröffentlichung noch mit verwundbaren Hosts verband. Microsoft äußerte sich dazu nicht näher.

Das schwierigere Problem sind Clients, die Sperrdaten gar nicht auswerten. Mozilla beschloss den Notfallentzug des Vertrauens für das übergeordnete Root-Zertifikat emSign ECC Root CA - G3, um Clients zu schützen, die Sperrinformationen ignorieren oder einzelnen Zwischenzertifikaten das Vertrauen nicht entziehen können. Chrome kündigte an, nachzuziehen. Berichten zufolge erreicht Chromes Entfernung alle Geräte am 27. Oktober, also heute. Die Go- und NSS-Fixes von Mozilla erschienen am 20. Oktober.

Filippo Valsorda, ein Maintainer der Go-Kryptografie, sagte gegenüber Ars, die Bereinigung werde einen sehr langen Schwanz haben. Er verwies auf IoT-Geräte, Container, vergessene Linux-Rechner und Tools, die eigene Root-Stores mitbringen, und verglich das Ausmaß mit Heartbleed. Dieser Vergleich ist sein Urteil und bleibt unbewiesen. Cloudflare wiederum berichtete, die Schlüssel seien innerhalb des eigenen Stacks vertraut gewesen, und lieferte Client-Updates aus.

Der Vertrauensentzug hat Kollateralkosten. Daten von Certificate Transparency zeigten Stand 21. Oktober rund 30.800 nicht abgelaufene Precertificates, die auf den entzogenen Root zurückgehen. eMudhra schätzte, dass etwa 97 % davon über ACME ausgestellt wurden. Das Unternehmen migriert seine Kunden in die eigene RSA-G1-Hierarchie. Einige davon sind legitime Zertifikate, die nun wegen eines davon unabhängigen Fehlers weiter oben in der Kette ersetzt werden müssen.

05Erkennung und was sie über die Aufsicht zeigt

Ob jemand die Schlüssel missbraucht hat, ist nicht abschließend geklärt, aber die bisherigen Hinweise sind beruhigend. Ars berichtete von keinerlei Belegen für böswillige Nutzung in den Transparenzlogs. Ein Sekundärbericht besagt, Google habe vor der Sperrung keine TLS-Zertifikate gefunden, die zu den sechs Zwischenzertifikaten geloggt waren. Red Sift fand nach der Offenlegung eine Handvoll geloggter Zertifikate, die von Forschern stammten, die die wiederhergestellten Schlüssel testeten. eMudhra erklärt, nur ein Zwischenzertifikat sei in Produktion gegangen, und keines habe Kundenzertifikate ausgestellt. Transparenzlogs erkennen nur Zertifikate, die tatsächlich geloggt werden, und Clients, die CT nicht erzwingen, könnten ungeloggte Fälschungen erhalten haben. Dieses Restrisiko lässt sich nicht ausschließen, und mehrere Analysten sagen das auch.

Drei Lehren stechen hervor:

1. Audits prüfen Prozesse, nicht Ergebnisse. Eine Ceremony, die eine beobachtete Checkliste besteht, kann trotzdem den falschen Schlüssel zertifizieren. Ein mechanischer Abgleich, ob der zertifizierte öffentliche Schlüssel dem vorgesehenen HSM-Schlüssel entspricht, sowie eine Mindestentropie-Prüfung hätten das erkannt.
2. Auffälligkeiten brauchen eine Ursachenanalyse. Die CRL-Abweichung von 2025 war ein kostenloses Signal. Mozillas veröffentlichte Fragen zielen direkt darauf, warum sie übertüncht wurde.
3. Eine Sperrung ist nur so gut wie ihre Verteilung. Browser können binnen Stunden blockieren. Alles andere braucht Software-Updates, und der Vertrauensentzug für einen ganzen Root ist das grobe Instrument, das den langen Schwanz erreicht.

Der Vorstand von eMudhra kündigte am Donnerstag an, aus dem globalen TLS-Geschäft auszusteigen. Der Vorsitzende nannte Compliance-Kosten und eine Sparte, die rund 1 Prozent des Umsatzes erwirtschafte. Das Unternehmen überprüft weiter seine Key Ceremonies, und die Ursachenanalyse ist unvollständig. Auch die Entscheidungen von Chrome und Mozilla zum verbleibenden RSA-Root stehen noch aus. Es fehlen die vollständigen Ceremony-Logs, der Code-Diff und eine Erklärung, warum der Auffälligkeit von 2025 nicht nachgegangen wurde. Sie würden zeigen, ob es sich um ein einzelnes fehlerhaftes Skript handelte oder um ein Kontrollumfeld, das einen privaten Schlüssel von einem Byte nicht erkennen konnte.