Schwache private Schlüssel bei eMudhra führen zu sofortigem Blockieren von Zertifikaten

a dark room with a red light and a warning sign — Aditya Vyas / Unsplash

Die indische Organisation eMudhra hat acht private Schlüssel für ihre Zwischenzertifikate verwendet, die aus sehr kleinen Zahlen bestanden. Diese Schwachstelle ermöglichte es potenziellen Angreifern, gefälschte HTTPS-Zertifikate zu erstellen, um die Identität beliebiger Websites zu übernehmen. Die betroffenen Schlüssel wiesen die Werte 4, 56, 66, 115, 155, 156, 230 und 237 auf. Sechs dieser Zertifikate dienten für TLS-Verbindungen, während zwei für die Signatur von Software genutzt wurden. Die Entdeckung führte dazu, dass die Browser Chrome und Firefox die entsprechenden Zertifikate am 17. Oktober 2026 sofort blockierten.

Der kryptografische Standard P-384 bietet normalerweise fast 2 hoch 384 mögliche Werte für Schlüssel, was ein Raten praktisch unmöglich macht. Die bei eMudhra eingesetzten Zahlen waren jedoch kleiner als 256. Dadurch konnten sie aus den öffentlichen Zertifikaten nahezu sofort abgeleitet werden. Ein Forscher, der unter dem Namen Wayne bekannt ist, hat diese Schwachstelle gemeldet. Er lieferte eine Demonstration, indem er eine Nachricht mit jedem der acht kompromittierten Schlüssel digital signierte. Diese Signaturen konnten mit den öffentlichen Schlüsseln verifiziert werden, was den Besitz der geheimen Schlüssel bewies.

Die Blockierung der Zertifikate erfolgte in mehreren Schritten. Mozilla verteilte den Schutz für Firefox-Nutzer mit Standardeinstellungen in weniger als drei Stunden, ohne dass ein Neustart des Browsers erforderlich war. Am 19. Oktober wurden die Blockierungen auf Apple-Geräten implementiert, gefolgt von den Microsoft-Plattformen am 20. Oktober. Diese Maßnahmen schützen jedoch nicht automatisch alle installierten Softwarepakete. Das mit macOS ausgelieferte Verbindungstool curl nutzt eine separate Zertifikatsliste und konnte die kompromittierten Zertifikate trotz der Apple-Blockierung weiterhin akzeptieren. Andere Anwendungen müssen daher separat aktualisiert werden, da ein geschützter Browser nicht sicherstellt, dass alle Verbindungen auf demselben Gerät geschützt sind.

Ein Experte für Kryptographie verglich den Aufwand für die Behebung dieser Lücke mit der Heartbleed-Schwachstelle von 2014. Er wies auf die Vielfalt der Systeme hin, die korrigiert werden müssen, einschließlich vergessener Maschinen und nicht mehr gewarteter Werkzeuge. Bislang ist keine böswillige Ausnutzung der Lücke bestätigt. Google berichtete, dass vor der Blockierung kein TLS-Zertifikat, das auf die sechs betroffenen Zwischenzertifikate zurückgeht, in den öffentlichen Transparenzprotokollen registriert war. Dies verhinderte deren Nutzung gegen Software, die diese Registrierung verlangt. Angriffe auf Systeme, die diese Prüfung nicht durchführen, können jedoch nicht ausgeschlossen werden.

Ein Verantwortlicher bei eMudhra erklärte die Ursache als einen Fehler im Programm zur Schlüsselgenerierung. Dieser Fehler habe einen zweiten Satz schwächerer Schlüssel erzeugt, die aufgrund ähnlicher Beschriftungen versehentlich verwendet wurden. Die Empfehlung an Nutzer lautet, Browser, Betriebssysteme und Anwendungen sofort zu aktualisieren, sobald Patches verfügbar sind. IT-Verantwortliche müssen zudem Software und Geräte überprüfen, die keine automatischen Updates erhalten. Die Verschlüsselungsalgorithmen von TLS selbst wurden nicht gebrochen; das Problem betrifft ausschließlich die Identifizierung des Servers.