Die indische Zertifizierungsstelle eMudhra Limited gibt an, dass sie das globale Geschäft mit SSL/TLS-Zertifikaten aufgibt. Die Entscheidung folgt auf die Entdeckung von acht TLS-Zwischenzertifikaten, deren private Schlüssel so schwach waren, dass sie nahezu sofort wiederhergestellt werden konnten. Wer einen dieser Schlüssel wiederhergestellt hatte, konnte TLS-Zertifikate für jede beliebige Website oder jeden beliebigen Mailserver ausstellen. Ein Schlüssel hatte lediglich den Wert 4.
Das Unternehmen gab die Entscheidung in einem Beitrag vom Donnerstag bekannt, zwei Tage nachdem Forscher das Problem offengelegt hatten, wie Ars Technica berichtet. Verwaltungsratschef V. Srinivasan nannte steigende Kosten und wachsende Compliance-Anforderungen als Gründe. Außerdem sagte er, SSL/TLS mache nur etwa 1 Prozent des Umsatzes des Unternehmens aus, und kostenlose TLS-Zertifikatsanbieter hätten die Rendite des Geschäfts im Vergleich zu anderen Produkten und Dienstleistungen von eMudhra verringert. In dem Beitrag erklärte eMudhra, die Aufmerksamkeit in den sozialen Medien habe den Vorfall in einem Maße in den Fokus gerückt, das in keinem Verhältnis zur Rolle von TLS im Geschäft stehe. Der Verwaltungsrat sei zu dem Schluss gekommen, dass der Rückzug für das Unternehmen und seine Aktionäre die richtige Entscheidung sei.
Schlüssellängen weit unter der erwarteten Stärke
Die Forscher stellten fest, dass die acht Zertifikate mit privaten Schlüsseln zwischen 3 und 8 Bit ausgestellt worden waren. Die Schlüssel sollten NIST-P-384-Elliptic-Curve-Schlüssel sein, die etwa 384 Bit Entropie haben müssten. Die fehlerhaften Schlüsselwerte lauteten 4, 56, 66, 115, 155, 156, 230 und 237. Der stärkste davon ließ höchstens 256 Möglichkeiten zu, verglichen mit den rund 2^384 Möglichkeiten, die ein korrekter Schlüssel bieten sollte – eine Zahl mit 116 Stellen.
Laut den Angaben der Forscher war die Schwachstelle leicht auszunutzen. Das Wiederherstellen eines Schlüssels dauerte nur Millisekunden. Sobald ein Schlüssel wiederhergestellt war, konnte ein Angreifer damit Zertifikate erstellen, denen große Browser vertrauen würden. Diese Zertifikate könnten wiederum von einer großen und unbekannten Zahl an E-Mail-Servern, IoT-Geräten, Docker-Containern, alten Linux-Rechnern und nicht mehr gepflegten Kommandozeilenwerkzeugen akzeptiert werden, die eigene Kopien der Root-Zertifikate mitführen.
Browserhersteller sperrten Zertifikate, die unter den betroffenen Zwischenzertifikaten ausgestellt worden waren, innerhalb von ein bis zwei Tagen nach der Entdeckung. Ars Technica wies darauf hin, dass andere Geräte, die auf dieselben Zertifikate angewiesen sind, deutlich länger brauchen könnten, um denselben Schritt zu vollziehen, und dass manche eingebetteten Geräte sie womöglich nie blockieren können. Ars schrieb außerdem, eMudhra dürfte die Möglichkeit gegenübergestanden haben, dass das CA/Browser Forum, die Branchenorganisation, die die Regeln für das TLS-Zertifikatsprogramm festlegt, die Zulassung entziehen könnte. Dabei handelt es sich um die Einschätzung von Ars und nicht um eine erklärte Entscheidung.
Die Erklärung von eMudhra
Am Mittwoch veröffentlichte eMudhra eine kurze Erklärung. Die Zertifikate seien unter der ECC-Root während einer am 30. April 2025 abgehaltenen Schlüsselerzeugungszeremonie (Key Generation Ceremony, KGC) erstellt worden, unter Verwendung von Hardware Security Modules (HSMs) nach FIPS 140-2 Level 3. Laut dem Unternehmen habe ein Fehler in der KGC dazu geführt, dass ein Wrap/Unwrap-Schritt neben den ursprünglichen starken Schlüsseln einen zweiten Satz schwacher Schlüssel erzeugte. Ausgerechnet diese schwachen Schlüssel seien in die Root-Speicher der Browser übernommen worden. eMudhra erklärte, man arbeite noch an der Ermittlung der Grundursache.
HSMs sind dedizierte Geräte zur Speicherung von Verschlüsselungsschlüsseln und anderen sensiblen Daten, und sie sind normalerweise von den meisten Teilen eines Netzwerks isoliert. Wrapping und Unwrapping ist das Verfahren, mit dem ein Schlüssel zwischen HSMs verschoben wird: Das sendende Gerät verschlüsselt den Schlüssel mit einem separaten Wrapping-Schlüssel, und das empfangende Gerät entschlüsselt ihn bei Ankunft.
In einem Thread in Mozillas Bugzilla gab eMudhra weitere Details bekannt. Das an diesem Tag verwendete KGC-Skript habe einen Fehler enthalten. Die ursprünglichen ECC-Schlüssel seien wie erwartet auf dem Gerät erzeugt worden. Eine genehmigte Änderung des üblichen Verfahrens, die einen Wrap/Unwrap für zum Export vorgesehene Schlüssel testen sollte, sei eingeführt worden. Ein Codefehler habe dann dazu geführt, dass auf dem Gerät ein zweites, schwächeres Schlüsselpaar erzeugt wurde. Da die Schlüsselbezeichnungen ähnlich waren, sei das schwächere Paar irrtümlich für die Erstellung des Certificate Signing Request (CSR) verwendet worden, den die Root anschließend signierte. eMudhra erklärte, der aus den schwachen Schlüsseln erstellte CSR sei außerdem zur Cross-Signierung an Sectigo geschickt worden, und man habe die übermittelten Dateien überprüft.
Außerdem erklärte eMudhra, seine Sperrlisten (Certificate Revocation Lists, CRLs) seien zunächst mit den ursprünglichen, korrekt erzeugten privaten Schlüsseln signiert worden. Diese Signaturen seien fehlerhaft gewesen, weshalb die CRLs mit den fehlerhaften Schlüsseln neu signiert wurden. Ars Technica fragte, warum das Unternehmen die Ursache dieses Signierfehlers nicht früher untersucht habe. Das Unternehmen sagte, menschliche Fehler an mehreren Stellen hätten erhebliche Schwächen in der Integrität des Schlüssellebenszyklus bei dieser Zeremonie verursacht. Es prüfe Codefehler, Prozesslücken und Maker-Checker-Kontrollen und werde in der folgenden Woche jede Schlüsselzeremonie, die es durchgeführt habe, erneut überprüfen.
