eMudhra-CA-Schlüssel durch kritisch schwache private Schlüsselgenerierung kompromittiert

Am 17. Oktober 2026 meldete ein Sicherheitsforscher den großen Technologieunternehmen, dass die privaten Schlüssel für acht eMudhra-Zwischenzertifikate kompromittiert worden waren. Die Schwachstelle resultierte aus einer extremen Schwäche bei der Schlüsselgenerierung, bei der die privaten Schlüssel effektiv als Ein-Byte-Ganzzahlen vorlagen. Bis zum 20. Oktober hatten Mozilla und Google die Sperrung dieser Zertifikate öffentlich angekündigt und das Vertrauen in die zugehörigen Stammzertifizierungsstellen entzogen.

Was ist passiert?

Der Vorfall betrifft acht von eMudhra ausgestellte Zwischenzertifikate, die im April 2025 erstellt wurden. Dazu gehörten sechs TLS-Ausstellerzertifikate für Domain Validation (DV), Organization Validation (OV) und Extended Validation (EV) sowie zwei Code-Signing-Zertifikate. Alle acht Zwischenzertifikate wurden im Mai 2025 zusätzlich vom Sectigo-Stammzertifikat „AAA Certificate Services“ kreuzsigniert. Nach Erhalt des Berichts stellte Chrome noch am selben Tag ein CRLSet-Update bereit, um die Zwischenzertifikate zu blockieren, während Mozilla sie kurz darauf in Firefox über OneCRL sperrte.

Bis Dienstag, den 20. Oktober, veröffentlichte Mozilla eine öffentliche Ankündigung und lieferte ein NSS-Update aus, das das eMudhra-Stammzertifikat vollständig entfernte. Google bestätigte, dass das eMudhra-Stammzertifikat aus dem Chrome Root Store in Version 43 entfernt wird. Das Kernproblem war kein Diebstahl von Schlüsseln im traditionellen Sinne, sondern ein Fehler im Generierungsprozess, der es trivial einfach machte, die privaten Schlüssel aus den öffentlichen Zertifikaten abzuleiten.

Die privaten Schlüssel für diese Zertifikate erwiesen sich als unglaublich kleine Zahlen, wie beispielsweise 4, 56 und 115. In der Kryptografie mit elliptischen Kurven, speziell auf der hier verwendeten P-384-Kurve, ist der private Schlüssel eine große Zufallszahl. Die Sicherheit des Systems beruht darauf, dass diese Zahl groß genug ist, um Brute-Force-Angriffe unmöglich zu machen. Die Schlüssel von eMudhra bestanden jedoch hauptsächlich aus Nullen, gefolgt von einem einzelnen Nicht-Null-Byte. Dies reduzierte den Suchraum auf nur 256 Möglichkeiten, sodass jeder, der Zugriff auf das öffentliche Zertifikat hatte, den privaten Schlüssel auf Standardhardware in Millisekunden wiederherstellen konnte.

Wichtige Details

• Acht Zwischenzertifikate wurden kompromittiert, darunter sechs für TLS und zwei für Code-Signing.
• Die privaten Schlüssel waren Ein-Byte-Werte, wie 4, 56 und 115, anstatt der erforderlichen 384-Bit-Zufallszahlen.
• Die Wiederherstellung der privaten Schlüssel aus den öffentlichen Zertifikaten dauerte auf handelsüblicher Hardware weniger als eine Sekunde.
• Die betroffenen Zertifikate wurden im April 2025 erstellt und im Mai 2025 von Sectigo kreuzsigniert.
• Große Browser wie Chrome und Firefox haben das Vertrauen entzogen, aber viele Nicht-Browser-Clients bleiben verwundbar.
• Das Zeitfenster der Exposition erstreckt sich von April 2025 bis zur Sperrung im Oktober 2026, ohne dass festgestellt werden kann, ob die Schlüssel ausgenutzt wurden.

Hintergrund

Um die Schwere des Problems zu verstehen, hilft es zu wissen, wie die Kryptografie mit elliptischen Kurven funktioniert. Ein privater Schlüssel ist eine geheime Zahl, oft als d bezeichnet. Der öffentliche Schlüssel, der offen in Zertifikaten geteilt wird, wird abgeleitet, indem diese geheime Zahl mit einem festen Punkt auf der Kurve multipliziert wird. Während die Berechnung des öffentlichen Schlüssels aus dem privaten Schlüssel einfach ist, ist der umgekehrte Prozess – die Findung des privaten Schlüssels aus dem öffentlichen Schlüssel – rechnerisch nicht durchführbar, wenn der private Schlüssel groß und zufällig ist.

Für P-384-Kurven sollte der private Schlüssel eine 384-Bit-Zahl sein, was etwa 10¹¹⁵ möglichen Kombinationen entspricht. Dieser riesige Suchraum gewährleistet die Sicherheit. Wenn der private Schlüssel jedoch klein ist, wie ein einzelnes Byte, gibt es nur 256 mögliche Werte. Ein Angreifer kann einfach jeden Wert ausprobieren, bis er denjenigen findet, der zum öffentlichen Schlüssel passt. Genau dies geschah mit den Schlüsseln von eMudhra, wodurch der kryptografische Schutz wirkungslos wurde.

Warum ist das wichtig?

Während moderne Browser wie Chrome, Firefox und Safari geschützt sind, da sie Certificate Transparency erzwingen und ihre Blocklisten schnell aktualisieren, ist das breitere Ökosystem gefährdet. Viele Nicht-Browser-Anwendungen, einschließlich Befehlszeilentools wie curl, Programmiersprachen-Runtimes wie Python und Node.js sowie Paketmanager, prüfen standardmäßig keine Certificate-Transparency-Protokolle oder Sperrlisten. Sie verlassen sich auf lokale Vertrauensspeicher, die möglicherweise nicht sofort aktualisiert werden.

Dies birgt ein erhebliches Risiko für Server-zu-Server-Kommunikation, CI/CD-Pipelines und IoT-Geräte. Beispielsweise könnte ein Skript, das Updates über HTTPS mit einem veralteten Zertifikatsbündel herunterlädt, ein gefälschtes Zertifikat akzeptieren, das mit den kompromittierten eMudhra-Schlüsseln signiert wurde. Dies würde einem Angreifer ermöglichen, den Datenverkehr abzufangen, schädlichen Code einzuschleusen oder sensible Daten zu stehlen. Geräte mit eingefrorener Firmware, wie Router und intelligente Haushaltsgeräte, vertrauen diesen ungültigen Zertifikaten möglicherweise weiterhin, bis ihre Hardware ersetzt oder manuell aktualisiert wird, was Jahre dauern kann.

Was Sie tun können

• Aktualisieren Sie die CA-Zertifikatsbündel auf allen Servern, Workstations und Container-Images sofort.
• Prüfen Sie auf Updates für Sprachruntimes wie Python, Node.js und Go, die oft ihre eigenen Zertifikatsspeicher bündeln.
• Überprüfen Sie CI/CD-Pipelines, um sicherzustellen, dass sie aktuelle Basis-Images verwenden und die Gültigkeit von Zertifikaten streng verifizieren.
• Identifizieren Sie IoT- und eingebettete Geräte, die nicht leicht aktualisiert werden können, und bewerten Sie das Risiko, dass sie kompromittierten Zertifizierungsstellen vertrauen.
• Aktivieren Sie wo möglich eine strenge Prüfung auf Zertifikatswiderruf, obwohl viele Clients dies standardmäßig nicht unterstützen.
• Überwachen Sie ungewöhnliche Aktivitäten in Systemen, die TLS-Verbindungen zu externen Diensten nutzen.