Lindell17 Abbruch-Sicherheitslücke [CVE

Diese Schwachstelle ermöglicht es einem Angreifer, einen vollständigen privaten Schlüssel aus einer Wallet zu extrahieren, die das Lindell17 2PC-Protokoll implementiert, indem er bei jedem Signaturversuch (insgesamt 256) ein einzelnes Bit extrahiert. Coinbase WaaS, Zengo und andere Bibliotheken wurden gepatcht.

Das Forschungsteam von Fireblocks hat eine Schwachstelle in realen Einsätzen des Lindell17-Schwellenwert-ECDSA-Protokolls entdeckt. Die Schwachstelle wurde an der Schnittstelle zwischen dem Protokoll und der weiteren Sicherheitsinfrastruktur gefunden und alle auf Lindell17 basierenden Sicherheitsprodukte sind potenziell betroffen. Wir haben mehrere Wallet-as-a-Service-Anbieter, Einzelhandels-Wallets und Open-Source-Bibliotheken gefunden, die für diesen Angriff in unterschiedlichem Ausmaß anfällig waren.

Der Exploit geht auf Lindell17-Implementierungen zurück, die von der Spezifikation der wissenschaftlichen Arbeit abweichen und Abbrüche bei fehlgeschlagenen Signaturen ignorieren oder falsch handhaben. Unter der Annahme eines privilegierten Zugriffs seitens des Angreifers kann die Schwachstelle ausgenutzt werden, um den Schlüssel nach etwa 200 Signaturanfragen auszuschleusen. Die Sicherheitslücke hat sich als praktisch erwiesen und wurde in beliebten Open-Source-Bibliotheken und einigen realen Systemen validiert.

Praktische Implementierungen des Protokolls für Wallets stoßen häufig auf ein schwieriges Dilemma: Entweder wird der Betrieb nach einer fehlgeschlagenen Signatur angehalten, was möglicherweise zur Sperrung von Geldern führen könnte, oder mit dem Signierungsprozess fortgefahren werden, wodurch das Risiko besteht, dass bei jeder Signatur zusätzliche Schlüsselbits offengelegt werden.

Die Schwachstelle wurde zunächst im ZenGo-Wallet entdeckt und dann in der Coinbase Wallet as a Service (WaaS)-Bibliothek überprüft, wobei weitere Wallet-Anbieter und Bibliotheken betroffen waren. Es wurde auch mit einem funktionierenden POC in einer gemeinsamen Open-Source-Implementierung des Protokolls validiert (Link unten). Sowohl Coinbase als auch ZenGo haben das Problem im Rahmen unseres Prozesses zur verantwortungsvollen Offenlegung umgehend behoben und uns versichert, dass sie überprüft haben und keine Wallets ausgenutzt wurden.

Die Schwachstelle ermöglicht die vollständige Extraktion des privaten Schlüssels, sodass Angreifer alle Gelder aus der Krypto-Wallet stehlen können. Es handelt sich jedoch um eine asymmetrische Schwachstelle, was bedeutet, dass der Angreifer eine bestimmte Partei korrumpieren muss, um den Angriff durchzuführen (dh die Parteien sind im Hinblick auf den Angriff nicht ununterscheidbar).

Um es näher zu erläutern: Das Lindell17-Protokoll wird typischerweise für Wallets verwendet, an denen ein Wallet-Anbieter und ein Endbenutzer beteiligt sind, wobei der zugrunde liegende geheime Schlüssel zwischen den beiden verteilt wird. Darüber hinaus gibt es zwei mögliche Konfigurationen für das Wallet: Entweder schließt der Wallet-Anbieter (Dienst) die Signatur ab, oder der Endbenutzer (Client) erledigt dies am Ende des Protokolls. Die mit der Fertigstellung der Signatur beauftragte Partei ist gefährdet, und ein Angreifer kann diese Schwachstelle ausnutzen, indem er die Gegenpartei kompromittiert.

Fall 1.Der Server schließt die Signatur ab

In diesem Fall kann der Angreifer den Schlüssel exfiltrieren, indem er den Client kompromittiert und in seinem Namen bösartige Nachrichten sendet. Konkret kann der Angreifer zweihundert Transaktionen initiieren, sodass der Angreifer in jeder Signatursitzung eine andere bösartige Nachricht erstellt, die nur dann zu einer gültigen Signatur führt, wenn ein gezieltes Bit des geheimen Anteils des Servers gleich Null ist.

Je nachdem, ob der Server die Signatur finalisiert oder nicht (der Angreifer erhält diese Informationen entweder, weil die Signatur in der Blockchain erscheint oder nicht, oder der Server selbst den Angreifer benachrichtigt), erhält der Angreifer einen Teil des Anteils des Servers . Nach 256 Signaturen kann der Schlüssel schließlich vollständig wiederhergestellt werden.

Wir sollten beachten, dass der obige Angriff beschleunigt werden könnte, wenn Signaturanfragen „schnell“ (schnell nacheinander initiiert) werden können, was normalerweise möglich ist, da der Server normalerweise automatisiert ist und die Anzahl der Signaturen nicht wesentlich begrenzt.

Fall 2.Der Kunde schließt die Signatur ab

Im zweiten Fall kann der Angreifer den Schlüssel auf analoge Weise extrahieren, indem er den Server kompromittiert und den oben genannten Angriff in umgekehrter Reihenfolge ausführt.

Es ist erwähnenswert, dass möglicherweise zusätzliche Schutzmaßnahmen vorhanden sind, um die Ausnutzbarkeit des Angriffs einzuschränken. Beispielsweise kann das Signieren von Transaktionen eine mehrstufige Authentifizierung des Benutzers erfordern. Folglich könnten häufige Authentifizierungsanfragen Verdacht erregen und die Effizienz eines schnellen „Blitz“-Angriffs verringern. Bleibt der Server jedoch über einen längeren Zeitraum kompromittiert, könnte sich der Angreifer für einen langsameren Angriff entscheiden, wodurch seine Erkennbarkeit für Benutzer verringert wird, die möglicherweise bereit sind, einen „Wiederholungsversuch“ durchzuführen und stattdessen einfach davon ausgehen, dass das System nicht sehr stabil ist sie werden angegriffen.

Beachten Sie, dass der obige Angriff vom Server aufgrund der fehlgeschlagenen Signatur identifiziert werden kann. Nach dem Datenverarbeitungsschritt rekonstruiert der Server nämlich eine Zeichenfolge, die gemäß dem ECDSA-Verifizierungsalgorithmus nicht verifiziert werden kann. Dieses Ereignis sollte niemals eintreten, es sei denn, das System wird angegriffen (oder es liegt ein schwerwiegender Fehler vor). Wir empfehlen, diese Ereignisse zu verfolgen und sie von anderen Abbruchereignissen, z. B. Timeouts, zu unterscheiden.

Wenn Sie das Protokoll als Selbstimplementierung oder als Open Source des Protokolls verwenden, sollten Sie ein Upgrade auf eine nicht anfällige Version durchführen oder Ihren eigenen Abbruchschutzmechanismus implementieren, der es einem Angreifer nicht erlaubt, nach der ersten fehlgeschlagenen Transaktion zusätzliche Bits zu extrahieren.

Ein alternativer Ansatz besteht darin, einen ZK-Proof für die letzte Nachricht des Kunden zu verwenden.

Das Lindell17-Protokoll verwendet homomorphe Verschlüsselung (insbesondere Paillier-Verschlüsselung) zur Generierung von ECDSA-Signaturen im Client-Server-Modell, bei dem jede Partei einen Anteil am geheimen ECDSA-Schlüssel besitzt. Für die Zwecke dieser Präsentation gehen wir davon aus, dass der Server die Signatur finalisiert. Im Kern besteht das Protokoll darin, dass der Client eine Teilsignatur berechnet, die mit dem öffentlichen Paillier-Schlüssel des Servers verschlüsselt ist, und den resultierenden Chiffretext an den Server sendet. Der Server wiederum finalisiert die Teilsignatur in eine vollständige Signatur, indem er den Chiffretext entschlüsselt und einige Datenverarbeitungen durchführt.

Beim Einsatz für sicherheitsorientierte Anwendungen muss besonders auf sogenannte Abort-Ereignisse geachtet werden, dh was soll der ehrliche Server tun, wenn er die Signatur nicht abschließen kann? Das Papier beschreibt keinen Mechanismus zur Behandlung von Abbrüchen und weist die Unterzeichner ausdrücklich an, in einem solchen Fall den Unterzeichnungsvorgang abzubrechen.

Wir zeigen, dass das Ignorieren fehlgeschlagener Signaturen zu einem anfälligen Protokoll führt, das von einem beschädigten Client wie folgt ausgenutzt werden kann. Unter Verwendung der Notation aus dem Bild berechnet der Client C so, dass C nur dann eine Verschlüsselung von sig* ist, wenn das niedrigstwertige Bit (LSB) von x Null ist, und andernfalls ist C eine Verschlüsselung einer Zufallszahl (wenn das LSB von x ist). eins). Wenn der Server also C erhält, wird der Signaturgenerierungsprozess nur dann erfolgreich beendet, wenn der lsb von x Null ist, und diese Informationen werden unbeabsichtigt an den Angreifer weitergegeben. Wenn die Signaturvorgänge dann nicht beendet werden, kann dieser Angriff wiederholt werden, um die höherwertigen Bits zu erhalten. Durch die Kombination mit Brute-Force-Techniken kann der Schlüssel nach etwa 200 Signaturversuchen vollständig wiederhergestellt werden.

Wir erinnern daran, dass (Standard-)ECDSA-Signaturen wie folgt berechnet werden:

1.Beispiel für einen kurzlebigen Schlüssel k

(eine Zufallszahl zwischen 1 und q, wobei q eine ECDSA-Konstante ist)

2.Berechnen Sie die öffentliche Nonce r, die eine Funktion von k und öffentlichen Parametern ist

3.Stellen Sie s = (HASH(msg) + rx ) * k^(-1) % q ein, wobei msg die Nachricht zum Signieren und x der private ECDSA-Schlüssel ist.

4.Ausgabe (r,s)

Im Lindell17-Protokoll wird das geheime Material (d. h. k und x) zwischen den beiden Parteien aufgeteilt, so dass k = k1*k2 und x = x1+x2 und jede Partei das relevante Geheimnis besitzt (sagen wir, der Client besitzt k1, x1). und der Server hält k2, x2)

Nachdem die Parteien r berechnet haben, wird der Client außerdem angewiesen, dem Server den folgenden Wert zu senden, der unter dem Paillier-Schlüssel des Servers verschlüsselt ist (der Client berechnet diesen Wert durch homomorphe Bearbeitung von Enc(x2)):

C = Enc(HASH(msg)+r* x1 * (k1^(-1) % q)+ x2 *r * (k1^(-1) % q))

Sobald der Server C empfängt, berechnet er s = k2^(-1)*dec(C) \mod q und gibt (r,s) aus, wenn es sich um eine gültige Signatur handelt.

Erhalten des LSB (niederwertigstes Bit)

Um das niedrigstwertige Bit zu erhalten, setzt der Client k1 = 2 und setzt es in böswilliger Absicht

C = Enc(HASH(msg) + r* x1 * (k1^(-1) % q)+ x2 * \rho * (k1^(-1) % N))

Wobei N der öffentliche Schlüssel des Verschlüsselungsschemas ist und \rho = r, wenn r ungerade ist, und \rho = r + q andernfalls. Am Ende des Signaturvorgangs verliert die lsb die Gültigkeit der Signatur.

Den Angriff wiederholen, um die nächsten Bits zu erhalten

Angenommen, der böswillige Client kennt bereits die i-1 niedrigstwertigen Bits (dh y = x2 % 2^{i-1}). Um das niedrigstwertige Bit zu erhalten, setzt der Client k1 = 2^i (die i-te Zweierpotenz) und setzt es in böswilliger Absicht

C = Enc(HASH(msg) + r* x1 * (k1^(-1) % q)+ x2 * \rho * (k1^(-1) % N) + Offset))

Wobei N und \rho wie oben sind und Offset = y*rho*((k1^(-1) % q) – (k1^(-1) % N)). Am Ende des Signaturvorgangs geht die Gültigkeit der Signatur durch das i-te Bit verloren.

Wir haben die Schwachstelle im April 2023 bei einem einzelnen Wallet-Anbieter gefunden.

Anfang Mai 2023 haben wir bestätigt, dass die Schwachstelle mehrere Wallets und Bibliotheken betrifft, und haben eine 90-tägige verantwortungsvolle Offenlegung bei mehreren Wallet-Anbietern eingeleitet, die als anfällig befunden wurden.

Am 9. August 2023 haben wir unsere Ergebnisse öffentlich veröffentlicht und einen CVE für dieses Problem angehängt: CVE-2023-33242.

POC:https://github.com/fireblocks-labs/zengo-lindell17-exploit-poc

CVE-Link:https://www.cve.org/CVERecord?id=CVE-2023-33242

Wissenschaftliche Arbeit (Kryptographie der Exploits):https://github.com/fireblocks-labs/mpc-ecdsa-attacks-23