Eine Zertifizierungsstelle lieferte die XKCD-Pointe
Eine bemerkenswerte Enthüllung des Sicherheitsforschers „Wayne“ am 17. Oktober deckte ein tiefgreifendes Versagen der Public-Key-Infrastruktur auf: Acht eMudhra-Zwischenzertifikate, darunter TLS- und Codesignierungs-Autoritäten, wurden kompromittiert. Die zugrunde liegenden Private Keys für diese Zertifikate, denen große Browser und Betriebssysteme 17 Monate lang vertrauten, waren trivial kleine Ganzzahlen – einer buchstäblich die Zahl 4.
Diese Keys basierten auf der P-384 Elliptic Curve, die normalerweise erfordert, dass ein private scalar (d) eine große, unvorhersehbare 384-Bit-Zahl ist, was etwa $10^{115}$ Möglichkeiten bietet. Stattdessen wiesen die kompromittierten Keys von eMudhra 47 führende Null-Bytes auf, wobei das letzte Byte einen Wert enthielt, der klein genug war, um ihn mit maximal 255 Kandidaten per Brute-Force zu knacken.
Diese katastrophale Schwachstelle ermöglichte die sofortige Wiederherstellung der Private Keys. Die identifizierten Werte waren:
- 4
- 56
- 66
- 115
- 155
- 156
- 230
- 237
Trotz ihrer winzigen Größe erzeugen diese Ganzzahlen immer noch mathematisch gültige Public-Key-Punkte auf der Kurve. Das bedeutet, dass die Zertifikate standardmäßige strukturelle Prüfungen bestanden und die zugrunde liegende kryptografische Fragilität maskierten. Google Chrome und Firefox blockierten diese Zertifikate schnell, Apple und Microsoft folgten diesem Beispiel.
Der Fehler hinterließ eine Papierspur – und einen übersehenen Alarm
Die gemeldete Ursache geht auf eine April 2025 key ceremony zurück, bei der eMudhra ein Skript zum Testen von Key-Exporten änderte. Dieses Skript generierte versehentlich schwache zusätzliche Key-Paare auf dem Hardware Security Module (HSM). Die Bediener, durch ähnliche Bezeichnungen in die Irre geführt, verwendeten dann diese kompromittierten Keys für Zertifikatsanfragen anstelle der beabsichtigten kryptografisch starken Keys.
Entscheidend ist, dass im Juni 2025 eine Warnung auftauchte. Sectigo, der Cross-Signer, meldete ungültige Signaturen auf den Certificate Revocation Lists (CRLs) von eMudhra. Diese Diskrepanz trat auf, weil eMudhra versuchte, die CRLs mit seinen ursprünglichen, starken Keys zu signieren, die nicht mit den schwachen Keys in den ausgestellten Zertifikaten übereinstimmten.
Anstatt die zugrunde liegende Diskrepanz zu untersuchen, signierte eMudhra die Sperrlisten mit den schwachen Keys neu. Dieser Workaround verbarg das Symptom effektiv und ließ die grundlegende Sicherheitslücke für weitere 16 Monate bestehen.
Operativ unterstreicht dieser Vorfall zwei kritische Lektionen. Key Ceremonies erfordern independent identity and strength checks für alles generierte kryptografische Material. Darüber hinaus muss jede Signatur-Diskrepanz, insbesondere im Kontext einer Public-Key-Infrastruktur, eine sofortige Incident-Response auslösen, anstatt einen oberflächlichen Workaround zu wählen.
Browser hatten Leitplanken. Build-Systeme oft nicht
Sectigo signierte die eMudhra-Zwischenzertifikate per Cross-Signing und verschaffte ihnen so eine breite Reichweite in den Trust Stores der Plattformen. Der Forscher Wayne demonstrierte die Kontrolle, indem er eine Beweisnachricht: „We have a problem here“ mit jedem der acht kompromittierten Keys signierte. Dies bestätigte die Kompromittierung der Keys und verdeutlichte das weit verbreitete Missbrauchspotenzial.
Browser wie Google Chrome und Mozilla Firefox widerriefen die Zertifikate umgehend, oft innerhalb weniger Stunden. Sie erzwingen Certificate Transparency (CT)-Logs, in denen alle vertrauenswürdigen TLS-Zertifikate öffentlich aufgezeichnet werden. Browser lehnen normalerweise Zertifikate ab, die nicht in diesen Logs vorhanden sind – eine kritische Schutzmaßnahme, die eine direkte Ausnutzung im Browser verhinderte.
Nicht-Browser-Clients fehlen jedoch oft diese robusten Schutzmechanismen. Tools wie curl, Python, Node, Go und Git verlassen sich häufig auf lokale CA-Bundles und überspringen CT- oder Widerrufsprüfungen vollständig. Dies macht sie anfällig für Machine-in-the-Middle (MITM)-Angriffe.
Die praktischen Auswirkungen sind erheblich. Ein Angreifer, der einen dieser gefälschten Schlüssel besitzt, könnte folgende Ziele angreifen:
- API-Aufrufe
- Installationsskripte
- CI-Runner
- Cloud-Anmeldedaten
Die beiden kompromittierten Code-Signing-Schlüssel gaben zudem Anlass zur Sorge über gefälschte Software, die möglicherweise bösartige Updates oder Anwendungen verbreiten könnte. Weitere technische Details finden Sie im Mozilla Bugzilla: eMudhra Private Key Compromise of Intermediate Certificates.
Gefällt Ihnen der Artikel? Erhalten Sie jeden Morgen einen wie diesen per E-Mail.
eine E-Mail pro Tag · Abmeldung mit zwei Klicks · kein Tracking durch Dritte
Patchen Sie den Trust Store und testen Sie anschließend die gesamte Pipeline
Browser-Anbieter und Plattformbetreiber reagierten schnell, um das Vertrauen in die betroffenen Zertifikate zu entziehen. Apple, Google Chrome, Microsoft und Mozilla blockierten die kompromittierten Intermediates innerhalb weniger Tage, während Sectigo seine Cross-Signing-Vereinbarung mit eMudhra beendete. Go veröffentlichte ein gezieltes Notfall-Release, Version 1.27.3, das diese acht Intermediates direkt in seiner Standardbibliothek blockiert.
Die Abdeckung von Geräte- und Software-Updates kann variieren, insbesondere bei eingebetteten Systemen. Um das Risiko zu mindern, aktualisieren Sie Ihr Betriebssystem und Ihre CA-Pakete umgehend. Aktualisieren Sie Sprach-Runtimes wie Go auf 1.27.3 und das Python-Paket certifi auf 2026.10.19. Erstellen Sie Container-Images und CI/CD-Runner neu, um sicherzustellen, dass alle Abhängigkeiten aktuell sind.
Testen Sie Ihre Clients gegen den veröffentlichten Incident-Test-Endpunkt DV G3B eMudhra.we-have-a-problem.com. Wenn Ihr Client die Zertifikatskette mit einem Fehler ablehnt, ist er sicher. Dieser Validierungsschritt ist entscheidend für alle Systeme, die sich auf das Zertifikatsvertrauen verlassen.
Der Vorfall unterstreicht eine wichtige PKI-Lektion: Formatprüfungen können weder Zufälligkeit noch Absicht beweisen. Automatisieren Sie Schlüsselstärkenprüfungen als Teil von Key-Ceremonies. Validieren Sie, dass öffentliche Zertifikatsschlüssel exakt mit den beabsichtigten HSM-Schlüsseln übereinstimmen und nicht nur strukturell gültig sind. Überwachen Sie Certificate Transparency (CT)-Logs und behandeln Sie ungültige Widerrufssignaturen – wie die Warnung von Sectigo im Juni 2025 – als schwerwiegende Sicherheitsnotfälle.
Häufig gestellte Fragen
Was war das Problem mit den privaten Schlüsseln von eMudhra?
Acht Intermediate-CA-Zertifikate verwendeten winzige private Schlüsselwerte, darunter 4, anstelle von unvorhersehbaren 384-Bit-Werten. Die entsprechenden Schlüssel konnten durch das Testen nur weniger Möglichkeiten wiederhergestellt werden.
Waren normale Browser-Nutzer gefährdet?
Die Certificate Transparency-Anforderungen moderner Browser halfen dabei, nicht protokollierte gefälschte Zertifikate zu blockieren, obwohl Schutzmaßnahmen und Updates variierten. Nicht-Browser-Software fehlt es oft an gleichwertigen Prüfungen.
Warum waren CI-Pipelines ein Problem?
Tools und Dienste in Build-Pipelines vertrauen möglicherweise lokalen CA-Bundles, ohne Certificate Transparency oder den Widerruf von Zertifikaten zu prüfen, wodurch sie möglicherweise ein gefälschtes Serverzertifikat akzeptieren.
Was sollten Entwickler tun?
Aktualisieren Sie die Trust Stores von Betriebssystemen und Sprach-Runtimes, erstellen Sie betroffene Container neu und testen Sie das Zertifikatsvalidierungsverhalten von Nicht-Browser-Clients und CI-Runnern.