Autor: enze

Bearbeiter: Liz

Einführung

Kürzlich wurde festgestellt, dass die im JavaScript-Ökosystem weit verbreitete elliptische Verschlüsselungsbibliothek eine schwerwiegende Sicherheitslücke aufweist (GHSA-vjh7-7g9h-fjfh). Durch die Konstruktion spezifischer Eingaben und das Extrahieren des privaten Schlüssels nach einmaliger Signierung kann ein Angreifer die vollständige Kontrolle über die digitalen Vermögenswerte oder Identitätsdaten des Opfers erlangen.

Die Hauptursache dieser Sicherheitslücke liegt in einem Verarbeitungsfehler der elliptischen Bibliothek bei der Eingabe von Nicht-Standardwerten, der dazu führen kann, dass die Zufallszahl k in der ECDSA-Signatur wiederholt wird. Da die Sicherheit des ECDSA-Algorithmus stark von der Eindeutigkeit von k abhängt, kann der private Schlüssel bei Wiederholung von k direkt abgeleitet werden, was irreversible Sicherheitsrisiken verursacht.

In diesem Artikel werden die Prinzipien, Ursachen und Auswirkungen der Sicherheitslücke analysiert und Reparaturvorschläge unterbreitet, die Entwicklern dabei helfen, Sicherheitsrisiken zu reduzieren.

Hintergrund zur Sicherheitslücke

Einführung in die elliptische Bibliothek

elliptic ist eine im JavaScript-Ökosystem weit verbreitete Kryptografiebibliothek für elliptische Kurven, die mehrere Kurven unterstützt (wie secp256k1, ed25519). Diese Bibliothek wird von einer großen Anzahl von Kryptowährungs-Wallets, Identitätsauthentifizierungssystemen, Web3-Anwendungen usw. verwendet.

Auswirkungen

• Betroffene Versionen: elliptic<= 6.6.0

• Betroffene Kurven: secp256k1, ed25519 usw.

• Auswirkungsszenarien: Alle Anwendungen, die externe Eingaben für ECDSA-Signaturen akzeptieren (insbesondere Systeme, die externe Eingaben für Signaturen akzeptieren)

Von dieser Sicherheitsanfälligkeit sind höchstwahrscheinlich Anwendungen betroffen, die für die ECDSA-Signierung auf Elliptic angewiesen sind und Benutzern die Bereitstellung ungefilterter Nachrichten als Signaturinhalt ermöglichen.

Verletzlichkeitsprinzip

Die Zufallszahl k in der ECDSA-Signatur

Stellen Sie sich vor, Sie haben ein einzigartiges Siegel (privater Schlüssel) und müssen es jedes Mal, wenn Sie ein Dokument unterschreiben, in ein einzigartiges Stempelkissen (Zufallszahl k) tauchen. Das gestempelte Zeichen erzeugt zwei Zahlen r und s, die das Signaturergebnis darstellen.

Dieser Prozess umfasst mehrere wichtige Punkte:

• Das Siegel (privater Schlüssel) ändert sich nie – es repräsentiert Ihre Identität.

• Für jede Unterschrift muss ein neues Stempelkissen verwendet werden (die Zufallszahl k darf sich nie wiederholen).

• Auch beim Signieren des gleichen Dokuments müssen die Signaturergebnisse (r, s) unterschiedlich sein.

• Dass der Abdruck mit Ihrem Siegel erfolgte, ist für jedermann nachweisbar (Public-Key-Verification-Signatur).

• Aber niemand kann Ihr Siegel (privater Schlüssel) vom Abdruck ableiten, solange k sicher ist.

Um die Sicherheit von k zu gewährleisten, übernimmt ECDSA die RFC 6979-Spezifikation und verwendet einen deterministischen Zufallszahlengenerator (HMAC_DRBG oder HKDF) zur Berechnung von k. Verwenden Sie beim Generieren von k den privaten Schlüssel d und die Nachricht m als Seeds, um sicherzustellen, dass k unter derselben Eingabe festgelegt ist. Der Berechnungsprozess ist wie folgt:

Wichtige Punkte:

1. k muss zufällig und eindeutig sein, sonst wird der private Schlüssel weitergegeben.

2. Wenn k in beiden Signaturen gleich ist, kann der Angreifer den privaten Schlüssel d einfach direkt über die beiden Signaturen (r, s1) und (r, s2) wiederherstellen.

Mathematische Herleitung:

Angenommen, ein Benutzer signiert zwei unterschiedliche Nachrichten m1 und m2, die Zufallszahl k ist jedoch zufällig dieselbe, dann lauten die Signaturergebnisse wie folgt:

Ein Angreifer kann die Differenz zwischen s1 und s2 berechnen:

Da m1, m2, s1 und s2 alle bekannt sind, kann der Angreifer nach k auflösen:

Setzen Sie dann k in die ursprüngliche Signaturgleichung ein und lösen Sie den privaten Schlüssel d auf:

Schwachstellenanalyse

Die elliptische Bibliothek hätte HMAC_DRBG (einen deterministischen Zufallszahlengenerator) verwenden sollen, um sicherzustellen, dass k für jede Signatur eindeutig ist. Aufgrund von Fehlern bei der Eingabeverarbeitung können jedoch in einigen Fällen unterschiedliche Nachrichten dasselbe K generieren, was zur Offenlegung des privaten Schlüssels führt.

k Code generieren

In der sign()-Methode der elliptischen Bibliothek wird k vom Pseudozufallszahlengenerator HMAC_DRBG generiert. Der relevante Code lautet wie folgt:

elliptisch/lib/elliptisch/ec/index.js

Die Eingabeparameter von HMAC_DRBG umfassen hauptsächlich:

• Entropie → Der private Schlüssel bkey wird hier verwendet, um sicherzustellen, dass HMAC_DRBG über ausreichend Zufälligkeit verfügt.

• Nonce (Zufallszahlen-Seed) → Wird aus msg berechnet, beeinflusst den endgültig generierten Wert von k.

Da HMAC_DRBG deterministisch ist, erzeugen dieselbe Entropie und dieselbe Nonce dasselbe k. Wenn der Nonce bei verschiedenen Signaturvorgängen derselbe ist, ist auch k derselbe, was zur Offenlegung des privaten Schlüssels führt.

Ursache der Sicherheitslücke: BN-Konvertierung führt zur Wiederverwendung von Nonce

Bei der elliptischen Implementierung wird msg in BN (Big Number) umgewandelt und anschließend der Nonce mit msg.toArray() berechnet:

Problem:

• msg ist eine BN-Instanz, aber nonce ist ein Array.

• Verschiedene BN-Instanzen können nach der Konvertierung dasselbe Array erzeugen.

• Dies bedeutet, dass derselbe Nonce für verschiedene Nachrichten generiert werden kann, was letztendlich zu einer Wiederverwendung führt.

Wenn k für zwei verschiedene Nachrichten msg1 und msg2 wiederverwendet wird, kann der private Schlüssel d mit der oben genannten mathematischen Formel wiederhergestellt werden.

Ein Angreifer kann eine spezielle Nachricht erstellen, um den Nonce gleich zu machen und so eine Wiederverwendung von k zu bewirken. Sie müssen lediglich ein Paar (r, s1) und (r, s2) erhalten, um den privaten Schlüssel d durch mathematische Berechnung wiederherzustellen. Noch schwerwiegender ist, dass der Angreifer eine solche bösartige Nachricht für jedes bekannte Nachrichten-/Signaturpaar erstellen kann. Das bedeutet, dass der Angreifer, sofern er das Opfer einmal dazu bringt, eine bösartige Nachricht zu signieren, den privaten Schlüssel vollständig wiederherstellen und jede beliebige Signatur fälschen kann.

Ausnutzung (PoC)

Die elliptische Bibliothek erlaubt hexadezimale Zeichenfolgen als einen der Eingabetypen. Beim Signieren wird msg in eine BN-Instanz und dann in einen Array-Typ konvertiert. Wenn zwei verschiedene Nachrichten nach der Konvertierung dasselbe Array generieren, ist auch der Nonce derselbe, was letztendlich zu einer Wiederverwendung führt.

Codebeispiel:

Laufende Ausgabe:

msg1 = "message" und msg2 = "-message" generieren nach der BN-Konvertierung denselben Nonce (das Design von elliptic akzeptiert hexadezimale Zeichenfolgen als einen der möglichen Eingabetypen). Da der Nonce derselbe ist, ist auch das von HMAC_DRBG generierte k derselbe. Aus den Signaturergebnissen können wir erkennen, dass der R-Wert genau derselbe ist, was ein direkter Ausdruck der K-Wiederverwendung ist.

Vollständiger Angriffsverlauf:

1. Simulieren Sie, dass das Opfer eine normale Nachricht signiert und erhalten Sie die Nachricht msg0 und die Signatur sig0.

2. Der Angreifer erstellt eine bösartige Nachricht msg1 und veranlasst das Opfer, diese zu signieren, um sig1 zu erhalten.

3. Nutzen Sie die k-Wiederverwendungsschwachstelle aus und berechnen Sie k aus (r, s1) und (r, s2).

4. Berechnen Sie mit k weiter den privaten Schlüssel d, und der Angriff ist erfolgreich.

Codebeispiel:

Laufende Ausgabe:

Restaurierungsvorschläge

1. Aktualisieren Sie Elliptic auf 6.6.1+. Das offizielle Update hat dieses Problem behoben.

2. Vermeiden Sie das direkte Signieren nicht verifizierter Nachrichten und stellen Sie sicher, dass die Nachricht standardisiert ist.

3. Ersetzen Sie die möglicherweise betroffenen privaten Schlüssel.

Zusammenfassen

Diese Sicherheitslücke in Elliptic zeigt die extreme Empfindlichkeit von ECDSA-Signaturen gegenüber der Zufallszahl k. Sobald k wiederverwendet wird, kann der private Schlüssel direkt wiederhergestellt werden und der Angreifer kann die Vermögenswerte und die Identität des Benutzers vollständig kontrollieren. Entwickler sollten Schwachstellen zeitnah beheben und die Eingabeverarbeitung streng regulieren, um die Sicherheit der ECDSA-Signaturen zu gewährleisten. Abschließend möchte ich Rabby Wallet für die Bereitstellung von Informationen zu Schwachstellen danken.

Verweise

[1] https://github.com/indutny/elliptic/security/advisories/GHSA-vjh7-7g9h-fjfh
[2] https://paulmillr.com/posts/deterministic-signatures