Deanonymisierung des Dero-Netzwerks: Sender, Empfänger, Beträge und Nachrichten

Vollständiger Thread: https://twitter.com/kayabaNerve/status/1791485161013694565

Nur der technische Text: https://gist.github.com/kayabaNerve/b754e9ed9fa4cc2c607f38a83aa3df2a

Beweisen Sie folgende Herausforderung: https://twitter.com/techleaks24/status/1791512329722442045

Kopie der vollständigen technischen Beschreibung:

Das Dero-Protokoll

Das Protokoll verwendet ein Ringpaar, einen für die Sender und einen für die Empfänger, dargestellt als einzelner Ring. Bei jeder Übertragung wird eine Liste der ElGamal-Chiffretexte für alle Konten innerhalb des gemeinsamen Rings bereitgestellt. Dieser ElGamal-Chiffretext wird wie folgt gebildet: r * G, (r * K) + (a * G)Wo r ist etwas Zufall, K ist der Schlüssel für das Konto, für das der Chiffretext bestimmt ist, und a ist der Betrag.

Das Dero Wallet-Protokoll

Dero bietet bei jeder Transaktion eine „verschlüsselte Nachricht“ an. Auch wenn der Benutzer dies nicht explizit angibt, ist eine Nachricht vorhanden (entweder mit intern bereitgestellten Werten oder leer gelassen). Für den einzigen definierten Nachrichtentyp wird die Nachricht als Index des Absenders, als CBOR-codiertes Objekt und mit Nullauffüllung codiert. Die Nachricht wird mit dem Chacha20-Stream verschlüsselt, der mit einem Schlüssel von erstellt wurde H(H(r * K) || K) Wo r ist etwas Zufall und K ist der Schlüssel für das Konto, für das der Chiffretext bestimmt ist.

Das Thema

Dero verwendet die Zufälligkeit für die ElGamal-Chiffretexte und die Nachrichtenverschlüsselung wieder. Das heißt, wenn die Menge 0 ist, ist der zweite Teil des ElGamal-Chiffretexts der gemeinsame Schlüssel und die Nachricht kann entschlüsselt werden (wodurch auch der Empfänger preisgegeben wird, da der verwendete ElGamal-Chiffretext für einen bestimmten Empfänger gilt). Wenn der Betrag nicht 0 ist, kann man subtrahieren 1 * G bis der Betragsterm einen Koeffizienten von 0 hat. Wenn die Nachricht tatsächlich entschlüsselt wird, ist die Anzahl der durchgeführten Subtraktionen der Betrag, der die Privatsphäre verletzt.

Da das erste Byte der Nachricht der Absenderindex ist, verrät es auch den Absender. Insgesamt beeinträchtigt dies die Privatsphäre des Absenders, des Betrags, des Empfängers und der Nachricht.

Technische Hinweise

Da die Verschlüsselung nicht authentifiziert ist (soweit der Autor dieser Arbeit das beurteilen kann), können wir nicht explizit wissen, ob eine Entschlüsselung gültig oder ungültig ist. Praktisch können wir das. Die letzten 16 Bytes der Nachricht sind mit sehr hoher statistischer Wahrscheinlichkeit Nullen, wenn die Nachricht diese Bytes nicht ausfüllt und der Entschlüsselungsschlüssel korrekt ist. Ein zufälliger Entschlüsselungsschlüssel sollte dort stattdessen zufälliges Rauschen erzeugen.

Wenn die Nachricht diese Bytes tatsächlich füllt, handelt es sich um einen langen CBOR-Strom, für den sie wahrscheinlich nicht mehr gültig ist, sobald weitere Grenzen hinzugefügt werden. Dero kodiert alle Schlüssel mit einem zusätzlichen Byte für den Typ (wodurch das besagte Byte eine von wenigen Optionen sein muss und der entsprechende Wert von diesem Typ sein muss). Obwohl dies keine strikte Einschränkung ist, bestehen alle vordefinierten Schlüssel aus einem Buchstaben und bieten möglicherweise praktisch die Grenze für Schlüssel, die aus Zwei-Byte-ASCII bestehen (wobei jedoch davon ausgegangen wird, dass kein Aufrufer seine eigenen Schlüssel definiert hat, die entweder nicht ASCII sind oder länger als ein Buchstabe sind). Mit nur bestimmten zusätzlichen Grenzen wird ein CBOR-Objekt, das den gesamten Raum einnimmt, ungefähr einmal in jedem 2**40 Versuch mit zufälligem Rauschen übereinstimmen. Es wäre sinnvoll, CBOR-Objekte zu kennzeichnen, die falsch aussehen (trotz bestandener Prüfung), und wenn ja, mit Brute-Force fortzufahren (das vernünftigste Ergebnis ist das wahrscheinlichste mit drastisch steigender Wahrscheinlichkeit, da es vernünftiger erscheint; jedes Ergebnis, das kürzer als 129 Bytes ist, ist sinnvoll effektiv sicher).

Zusammenfassend prüft der Testentschlüsselungsalgorithmus, ob das Ergebnis ein gültiger Absenderindex ist (weniger als die Ringlänge für einen der potenziellen Absender) und ob ein gültiges CBOR-Objekt vorhanden ist mit den gewissen zusätzlichen Grenzen, und schließlich überprüfen, ob die verbleibenden Bytes alle Nullen sind. Da es an Authentifizierung mangelt (abgesehen von der Einstellung der Ringlänge des Absenders auf 1, was in diesem Zusammenhang ein eigenes Problem darstellt), wird davon ausgegangen, dass der Absender einer Transaktion vorgibt, jemand anderes zu sein (und sich als jemand anderes ausgibt). Dies ist eine deutliche Schwachstelle im Messaging-Protokoll, zumindest da es zur Nutzung angekündigt wird (anstelle bestehender verschlüsselter Messenger).

Das für den Senderindex vorgesehene Byte wurde in der Vergangenheit fälschlicherweise für den Empfängerindex verwendet. Dies wurde erst vor sechs Monaten gepatcht https://github.com/deroproject/derohe/pull/147. Dementsprechend wurde die Privatsphäre des Absenders insbesondere nur bei Transaktionen verletzt, die mit einer Wallet-Software durchgeführt wurden, die mit dem Patch aktualisiert wurde.

Die Menge muss brutal erzwungen werden. Dero-Beträge benötigen 41 Bit (da nur 5 Dezimalstellen verwendet werden und ein Vorrat im niedrigen zweistelligen Millionenbereich liegt) und erfordern bei der maximalen gemeinsamen Ringgröße von 128 (d. h. 64 Empfänger oder 2**6 Kandidaten) einen Aufwand von 47 Bit höchstens (was für Computer durchaus machbar ist). Da die meisten Transaktionen kleinere als größere Beträge haben, können die meisten Transaktionen schneller geknackt werden als mit der maximalen Brute-Force-Zeit, und statistische Analysen könnten verwendet werden, um bestimmte Empfänger zu priorisieren (wodurch die durchschnittliche Zeit für jeden Algorithmus reduziert wird, der sogar etwas mehr richtig als falsch ist). .

Da es sich um einen Angriff auf das Wallet-Protokoll handelt, kann jede Nachricht entschlüsselt werden (da die Nachricht Teil des Wallet-Protokolls ist). Die Wiederherstellung des Betrags, des Empfängers und des Absenders setzt voraus, dass die Transaktion gemäß dem Dero-Wallet-Protokoll durchgeführt wurde. Theoretisch könnte jemand über eine eigene, nicht konforme Dero-Wallet verfügen, deren Privatsphäre entweder nicht beeinträchtigt werden könnte oder die falsche Messwerte liefern könnte (je nachdem, ob sie so programmiert wurde, dass sie in expliziter Vorbereitung für eine Arbeit wie diese unterschiedliche Verschlüsselungsschlüssel verwendet, wodurch dies geschieht). Schwachstelle zuvor entdeckt). Obwohl dem Autor nicht bekannt ist, dass solche Wallets funktionieren, und es äußerst unwahrscheinlich ist, dass sie existieren, muss dies beachtet werden.

Offenlegungszeitplan

Dieses Problem wurde am 14. Mai entdeckt und am selben Tag wurde ein Machbarkeitsnachweis erstellt. Der Proof of Concept wird in einer Woche veröffentlicht (was den Betroffenen etwas Zeit zur Vorbereitung lässt, obwohl dieser Beitrag detailliert genug ist, um eine eigenständige Entwicklung solcher Tools in der Praxis zu ermöglichen). Es ist derzeit nicht in dem Maße optimiert, das erforderlich ist, um jede einzelne Transaktion im Netzwerk zu knacken (da es für GPUs oder möglicherweise idealerweise FPGAs neu erstellt werden müsste), reicht jedoch als Machbarkeitsnachweis aus.

Dero bietet ein Bug-Bounty von 50.000 USD für Schwachstellen an, die die finanzielle Integrität der Blockchain beeinträchtigen. Es enthält jedoch keine Einzelheiten darüber, wie Fehler gemeldet werden können. Der Autor wandte sich anonym an den Betreuer des Dero-Projekts ("Kapitän Dero") über Matrix, um sich zu erkundigen, ob die Bug-Bounty weiterhin gilt, und um ihre Ergebnisse zu melden. Wegen:

1) Keine Antwort vom Betreuer innerhalb von zwei Tagen erhalten (eine angemessene Zeit, um die ursprüngliche Nachricht zu bestätigen, nach Meinung des Autors und der Meinung einer führenden Web3-Sicherheitsplattform) 2) Erfolgreiche Kontaktaufnahme mit einem Entwickler, der dies gesagt hat "Was auch immer Sie sehen, es ist wahrscheinlich ein Missverständnis Ihrerseits" (ohne Kontext, außer dass ein kritisches Datenschutzproblem offengelegt werden soll), der mir dann sagte, ich solle eine PR bei mir einreichen "Vorschlag" (Obwohl es sich um eine Sicherheitsoffenlegung handelt?), und wenn der Wunsch betont wurde, dies dem Betreuer vor der Veröffentlichung vertraulich mitzuteilen, wurde ihm mitgeteilt, dass die Optionen darin bestünden, an die Öffentlichkeit zu gehen oder einfach zu warten, bis der Betreuer dazu kommt. Als wir einen Tag später erneut versuchten, eine erfolgreiche Verbindung mit dem Betreuer herzustellen, stellten wir fest, dass dies bislang nicht der Fall war. "Dann gib es einfach preis, es ist nicht nötig, mich deswegen zu belästigen"
3) Entscheidende Benutzer sollten so schnell wie möglich darauf aufmerksam gemacht werden, damit sie keine Privatsphäre mehr erwarten, obwohl sie zwangsläufig keine Privatsphäre haben würden

Der Autor beschloss, dies zu veröffentlichen, ohne eine erfolgreiche Kommunikation mit dem Betreuer zu erreichen. Damit sind diese Ergebnisse durch das Dero-Projekt zwar nicht bestätigt, doch der Proof of Concept beweist, dass die Theorie funktioniert.

Vorwärts gehen

Würde eine solche Schwachstelle in Signal gefunden, wäre der Autor dieser Arbeit nicht in der Lage, alle gesendeten Nachrichten im Netzwerk zu entschlüsseln, da er keinen Zugriff hätte. Durch das Platzieren von Nachrichten in einem stark replizierten Ledger ist es für einen Angreifer einfach, an die Chiffretexte einer jemals gesendeten Nachricht zu gelangen. Dies bedeutet, dass bei einer kompromittierten Brieftasche noch Jahre nach der Verwendung alle Nachrichten gelesen werden können, und da Dero keinen Post-Quantum-Schlüsselaustausch verwendet, wäre dies letztendlich jedem Angreifer mit einem diskreten Protokollorakel (z. B. einem Quantencomputer) möglich um alle Nachrichten zu entschlüsseln. Hochgradig replizierte Ledger sollten im Allgemeinen nicht zur Speicherung äußerst sensibler Informationen verwendet werden, auch wenn diese verschlüsselt sind. Wenn ein solches Ledger trotzdem verwendet wird, sollte es vorwärtsgeheim sein und bei einer Kompromittierung nur eine begrenzte Teilmenge der Nachrichten lesbar sein.

Die unmittelbare Lösung für dieses spezielle Problem besteht darin, eine eindeutige Zufälligkeit für den Nachrichtenverschlüsselungsschlüssel zu verwenden. Das allein behebt nicht die Vielfalt der Probleme mit diesem Design (wenn es als sicheres Messaging-Protokoll postuliert wird). Den Kontext zur Schwierigkeit sicherer Messaging-Protokolle finden Sie unter https://eprint.iacr.org/2022/376 (eine 94-seitige Analyse von Signal), dem Post-Quantum-Protokoll von Signal https://signal.org/docs/pecifications/pqxdh/die SimpleX-Dokumentation und -Spezifikationen https://github.com/simplex-chat/simplexmq/blob/stable/protocol/overview-tjr.md (was angeblich eine bemerkenswerte Verbesserung gegenüber Signal darstellt) und die umfangreiche Arbeit von iMessage zur Kontaktschlüsselüberprüfung https://security.apple.com/blog/imessage-contact-key-verification. Es handelt sich nicht umsonst um ein umfangreiches Feld der Theorie.

Das Dero-Protokoll (Wallet) ist weitgehend undokumentiert und ohne Peer-Review. Seine Beweise für eine Übertragung verwenden am Ende ein Bulletproofs-Innenprodukt, doch die Konstruktionen auf höherer Ebene sind nicht dokumentiert, abgesehen von ein oder zwei unglaublich vagen Kommentaren, wie zum Beispiel, wie sie „Eins aus vielen“ bilden. Beweise (die eine explizite Sache sind und es ist unbestritten, dass die Absicht dieser Beweise darin besteht, einen zu implementieren. Die Frage ist, was sie implementieren soll). Hoffentlich beginnen die Dero-Entwickler mit der Formalisierung ihres Protokolls und entwickeln bessere Beziehungen zur breiteren kryptografischen Community, um eine Peer-Review zu ermöglichen und dazu beizutragen, Probleme wie dieses in Zukunft zu verhindern.

Den Mitgliedern der Dero-Community und den Menschen im Allgemeinen wird empfohlen, nur sichere Messenger zu verwenden, die über ein von Experten überprüftes Protokoll und FOSS-Clients wie Signal verfügen (wobei Molly der führende FOSS-Client ist). Dieselbe Argumentation gilt auch für Datenschutzprotokolle im Allgemeinen, einschließlich derjenigen, die für Finanztransaktionen gelten. Ein privates, überprüfbares Protokoll für Finanztransaktionen finden Sie bei Monero oder Zcash Orchard (Letzteres bietet theoretisch eine stärkere Privatsphäre, wurde jedoch nur in einem Netzwerk eingesetzt, das nicht erfordert, dass alle Transaktionen privat sein müssen).

Schließlich betreibt die Dero-Community oft ein sehr überhebliches Marketing, das behauptet, dass ihre Technologie die beste sei. Während es für Fans eines Projekts verständlich ist, zu glauben, dass ihr Projekt das Beste ist, hat jedes Projekt harte Grenzen. Mit diesem effektiven vollständigen Verlust der Privatsphäre (mit Ausnahme der Privatsphäre des Absenders bei Transaktionen, die von Wallet-Software durchgeführt werden, die älter als ~6 Monate ist) mögen sie hoffentlich anerkennen, dass niemand perfekt ist, und insbesondere nicht Dero.