384-Bit-Kurve, aber das Geheimnis war schlicht die Zahl 4
Am Samstag, dem 17. Oktober 2026, schlugen Sicherheitsforscher bei Apple, Google, Microsoft, Mozilla und der indischen Zertifizierungsstelle eMudhra Alarm: Die privaten Schlüssel von acht Intermediate-Zertifikaten (Zwischen-CAs) ließen sich auf einem handelsüblichen Laptop in weniger als einer Sekunde ermitteln.
Diese Zertifikate nutzten die elliptische Kurve NIST P-384. Gemäß kryptografischer Spezifikation sollte ein solcher privater Schlüssel eine 384-Bit-Zufallszahl aus einem Raum von rund 10^115 Möglichkeiten sein. Wie sah der tatsächliche Schlüssel aus? 47 Null-Bytes, gefolgt von einem einzelnen Byte. Die acht geheimen Schlüssel lauteten 4, 56, 115, 155, 156, 230, 66 und 237. Einer von ihnen war tatsächlich einfach nur die 4.
Das Brechen eines solchen Schlüssels erfordert höchstens 255 Punktadditionen auf der elliptischen Kurve – eine Rechenaufgabe, die moderne Standard-Hardware in Millisekunden bewältigt. Aus den 16 in Mozillas Bekanntmachung aufgeführten Zertifikaten rekonstruierten Forscher alle acht privaten Schlüssel vollständig. In der Praxis waren diese Schlüssel seit der Ausstellung der Zertifikate im April 2025 de facto öffentlich zugänglich.
Bild: Ein kompromittiertes Vorhängeschloss. Quelle: Ars Technica
Sämtliche Formatprüfungen bestanden: Wo lag der Fehler?
Eine HTTPS-Vertrauenskette (Chain of Trust) wird hierarchisch von der Stammzertifizierungsstelle (Root CA) nach unten signiert. Jede Zwischenebene durchläuft dabei strenge Konformitätsprüfungen: mathematisch gültige Kurvenparameter, standardkonforme ASN.1-Kodierung und saubere Signaturstrukturen. Die acht Zertifikate von eMudhra – sechs ausstellende TLS-CAs (je zwei Generationen für DV, OV und EV) sowie zwei Code-Signing-CAs – wurden im April 2025 generiert und im Mai über die Stamm-CA AAA Certificate Services von Sectigo querbeglaubigt (cross-signed). Jede formale Prüfung verlief fehlerfrei.
Kein einziger dieser Standardtests prüft jedoch, ob der private Schlüssel tatsächlich echt zufällig erzeugt wurde. Die Schlüsselgenerierung verbleibt vollständig in der internen Hoheit der Zertifizierungsstelle; externe Prüfer sehen ausschließlich den öffentlichen Schlüssel. Die enorme mathematische Festigkeit von P-384 mit seinen 10^115 Zuständen schützt Systeme nur dann, wenn der Schlüssel wirklich gleichverteilt gewürfelt wird. Die Katastrophe bei eMudhra ereignete sich an der einzigen Schnittstelle, an der keine externe Automatisierung die Einhaltung kontrollieren kann.
In technischen Communitys wurde über die genaue Ursache spekuliert: Vielleicht vertauschte ein fehlerhaftes Skript Übergabeparameter nach Position, oder Code wählte via key[0] versehentlich nur das erste Byte eines Wrappers aus. Andere Experten wiesen auf einen noch gravierenderen Kontrollverlust hin: Kryptografische Schlüssel müssen zwingend innerhalb eines Hardware-Sicherheitsmoduls (HSM) erzeugt werden. Dass Schlüssel außerhalb entstehen und derart trivial ausfallen konnten, belegt ein grundlegendes Versagen der Sicherheitsarchitektur vom ersten Tag an.
Browser reagieren binnen Stunden: Vier Tage Ausnahmezustand
Bereits am Abend des 17. Oktober rollte Google ein außerplanmäßiges CRLSet-Update aus, um die betroffenen acht Zertifikate umgehend zu sperren; Mozilla zog wenige Stunden später mit OneCRL nach. Am 20. Oktober machte Mozilla den Vorfall publik und warf das Root-Zertifikat von eMudhra im Zuge einer NSS-Aktualisierung komplett aus dem Vertrauensspeicher. Google bestätigte das endgültige Ausmustern der Wurzel im Chrome Root Store v43.
Warum reagierte die Branche mit solcher Härte? Der Sicherheitsforscher Ian Carroll brachte es auf den Punkt: „Es handelt sich im Grunde um 1-Byte-Schlüssel, die jeder sofort faktorisieren kann – dieser Vorfall lässt sich nicht eingrenzen.“ Da es keinen konkreten Einbruchszeitpunkt gab, hätten Angreifer über einen Zeitraum von 17 Monaten jederzeit unbemerkt gefälschte Zertifikate für beliebige Domains generieren können.
Chrome-Entwickler ergänzten ein wichtiges Detail: Da diese Zwischenzertifizierungsstellen niemals ausgestellte TLS-Zertifikate in Certificate-Transparency-Logs (CT) protokolliert hatten, wurden gefälschte Zertifikate in Chrome standardmäßig nicht als vertrauenswürdig eingestuft. Doch während CT Fehlgriffe sichtbar macht, verhindert es das Signieren gefälschter Zertifikate nicht – und ein Großteil aller Software außerhalb von Browsern wertet CT-Logs überhaupt nicht aus.
Bild: Jede Ebene der Vertrauenskette stützt sich auf formale Prüfungen der vorherigen Stufe, doch die Entropie der Basisschlüssel prüft niemand. Quelle: Keytos
Warum curl | sh Skripte ganz oben auf der Risikoliste stehen
Für gewöhnliche Browsernutzer bestand dank schneller Sperrlisten und strikter CT-Vorschriften kaum Gefahr. Die tatsächliche Angriffsfläche befindet sich jenseits des Browsers.
TLS-Clients wie curl, Python, Node.js, Go, Java, git und diverse System-Paketmanager vertrauen standardmäßig auf statische CA-Pakete des Betriebssystems. Sie fragen in der Regel weder Widerrufslisten (OCSP/CRL) ab, noch verifizieren sie CT-Logs. Für diese Werkzeuge blieben die Widerrufsankündigungen wirkungslos: Sobald sie das eMudhra-Zertifikat im System-Bundle vorfinden, akzeptieren sie die mit einem 8-Bit-Schlüssel signierten Zwischen-CAs weiterhin als legitime Instanz.
Zwei Einsatzszenarien sind extrem gefährdet: Zum einen Software-Autoupdater und Setup-Skripte nach dem Muster curl | sh, bei denen ein gefälschtes Zertifikat Angreifern sofortige Remote-Code-Ausführung mit Benutzer- oder gar Root-Rechten ermöglicht. Zum anderen moderne CI/CD-Pipelines, deren Build-Container regelmäßig hochsensible Cloud-Zugangsdaten, Registry-Tokens und Signierschlüssel beherbergen. Einem Angreifer genügten ein gewöhnlicher Laptop und ein Wimpernschlag an Rechenzeit, um entsprechende Man-in-the-Middle-Angriffe durchzuführen.
eMudhras Rechtfertigung und Rückzug
Am 22. Oktober zog eMudhra die Konsequenz und gab den vollständigen Rückzug aus dem weltweiten SSL/TLS-Geschäft bekannt. Das Unternehmen nannte drei Gründe: Das globale Zertifikatsgeschäft habe lediglich rund 1 % des Gesamtumsatzes ausgemacht; regulatorische Auflagen zur Datensouveränität seien gestiegen, während große Konzerne kostenlose Zertifikate anböten; und nicht zuletzt sei „die öffentliche Kritik und die mediale Zuspitzung rund um den Vorfall völlig unverhältnismäßig zur realen Bedeutung dieses Geschäftsbereichs“. Zugleich betonte eMudhra, die betroffenen Zwischenzertifikate innerhalb von 14 Stunden widerrufen zu haben, niemals Endnutzer-Zertifikate ausgestellt zu haben und keinem externen Hacking-Angriff zum Opfer gefallen zu sein.
Die Entwickler-Community wies die Klage über „unverhältnismäßige Kritik“ entschieden zurück. Die zentrale Frage blieb unbeantwortet: Warum fiel in 17 Monaten keinem internen Prüfmechanismus auf, dass den Schlüsseln jede Entropie fehlte? Dass kryptografisches Material außerhalb geschützter HSMs generiert und verarbeitet werden konnte, entlarvte eMudhras Sicherheitsversprechen als reine Fassade.
Das letzte Glied ist der Mensch – ohne automatische Fangnetze
An keinem Punkt hat die zugrundeliegende Mathematik versagt. Die elliptischen Kurven waren sicher, die Kodierung entsprach den Standards, die Datenstrukturen waren fehlerfrei, und renommierte Trust-Center wie Sectigo hatten die Kette mit ihren Signaturen besiegelt. Acht Zertifikate passierten 17 Monate lang jede automatisierte Konformitätsprüfung. Das Desaster beruhte einzig darauf, dass niemand eine manuelle Plausibilitätsprüfung vornahm, die weder Maschinen noch statische Audits standardmäßig vorsehen: Hat sich eigentlich jemals jemand vergewissert, ob der angebliche 384-Bit-Schlüssel nicht in Wahrheit eine 8-Bit-Ganzzahl war?
Das Ende der HTTPS-Vertrauenskette mündet zwar im Webbrowser, doch die Qualität der privaten Schlüssel von Zwischenzertifizierungsstellen lässt sich von außen nur über aufwendige Rückrechnungen der öffentlichen Schlüssel überprüfen. Im Fall von eMudhra dauerte diese Entdeckung 17 Monate und erforderte die Wachsamkeit unabhängiger Forscher. Die Sicherheitsgrenze von PKI-Infrastrukturen basiert letztlich auf menschlicher Disziplin und gelebten Prozessen. Und für Disziplin gibt es keinen simplen curl-Befehl, der automatisiert grünes Licht gibt. eMudhra beendete das Drama durch Geschäftsaufgabe – doch beim nächsten ähnlichen Vorfall steht vielleicht keine Sparte mit vernachlässigbarem Umsatzanteil bereit, die man einfach opfern kann.
Weiterführende Quellen:
- Mozilla Bugzilla Bekanntmachung und NSS-Release-Notes
- Ankündigung zum Chrome Root Store v43
- Erklärung von eMudhra zum Rückzug aus dem globalen SSL/TLS-Markt
- Stellungnahme und Analyse von Ian Carroll
- Hacker-News-Diskussion (item?id=50177916)
