Zusammenfassung der 64-Byte Bitcoin-Transaktionsanfälligkeit
Abstract: Eine 64-Byte Bitcoin-Transaktion kann fälschlicherweise mit einem Zwischenschritt des Hashing in Bitcoins Merkle-Baum verwechselt werden, da auch dieser 64 Byte misst. Wir untersuchen, wie diese Schwachstelle möglicherweise ausgenutzt werden kann, um Simple Payment Verification (SPV)-Clients in die Irre zu führen, sodass sie glauben, eine Zahlung erhalten zu haben, obwohl dies nicht der Fall ist, sowie weitere Probleme, die durch diese Schwachstelle verursacht werden. Obwohl einige dieser Angriffe sehr kompliziert sind und die Schwachstelle nicht als gravierend gilt, gibt es eine relativ einfache Lösung: das Verbot aller 64-Byte-Transaktionen ohne Zeugen in einem Softfork.
Überblick
Dieser Artikel ist Teil einer Serie über die vier Sicherheitsanfälligkeiten, die durch das BIP 54, dem Consensus Cleanup Softfork, behoben werden sollen. Bisher haben wir bereits zwei der Sicherheitsanfälligkeiten behandelt:
In diesem Artikel konzentrieren wir uns auf die Probleme der „64-Byte-Transaktionen“. Der Trick besteht darin, dass die Daten in den inneren Zweigen der Merkle-Bäume, die Bitcoin-Blöcke bilden, 64 Byte betragen. Der Hash einer Bitcoin-Transaktion, der TXID, misst 32 Byte. Die inneren Äste der vorletzten Reihe des Merkle-Baums hashen zwei aneinander gereihte Bitcoin-TXIDs. Dies ergibt 64 Byte. Das Sicherheitsproblem besteht darin, dass diese 64 Byte-Daten mit einer 64-Byte-Bitcoin-Transaktion verwechselt werden könnten. Ein Angreifer könnte beispielsweise eine 64-Byte-Bitcoin-Transaktion oder etwas, das wie eine solche aussieht, erstellen, um eine potenzielle Zielperson dazu zu bringen, eine eingehende Zahlung zu akzeptieren. Im Folgenden werden wir einige dieser Angriffe näher betrachten.
Merkle-Baum-Illustration
Eine Darstellung des Merkle-Baums innerhalb eines Bitcoin-Blocks
Illustration von Sergio Lerner, die die Position der Fake-Transaktion anzeigt
Quelle: Bitslog
Im Allgemeinen bewerten wir das Risiko, das mit dieser Schwachstelle verbunden ist, als moderat bis niedrig, da die Komplexität der Angriffe im Gegensatz zum Timewarp-Angriff relativ hoch ist, den wir als schwerwiegender erachten. Dennoch ist es eine interessante Schwachstelle, die es wert ist, untersucht und behoben zu werden.
Verbergen einer Transaktions-ID innerhalb einer anderen Transaktion
Eine möglicherweise schwerwiegende Form eines Angriffs, der diese Schwachstelle ausnutzt, besteht darin, jemanden, der eine einfache Zahlungsbestätigung (SPV) verwendet, dazu zu bringen, eine ungültige eingehende Transaktion zu bestätigen. Wir haben unten ein Beispiel zur Veranschaulichung des Angriffs bereitgestellt. Der Angriff funktioniert wie folgt:
- Der Angreifer erstellt eine tatsächlich gültige Bitcoin-Transaktion, die genau 64 Byte groß ist. Diese 64 Byte umfassen keine segregierten Zeugen.
- Der Angreifer erstellt eine gefälschte ungültige Bitcoin-Transaktion, die beispielsweise 1.000 BTC an das Opfer sendet, eventuell 1.000,002 BTC von einem gefälschten Input, der im UTXO-Set nicht existiert.
- Der Angreifer hat eine Wechseladresse für die gefälschte Bitcoin-Input-Transaktion und arbeitet mit Brute-Force, um verschiedene Wechseladressen auszuprobieren, bis die 32 Byte TXID für die gefälschte Transaktion genau mit den letzten 32 Bytes der echten 64-Byte-Transaktion übereinstimmt.
- Sobald eine Übereinstimmung vorliegt, sendet der Angreifer den SPV-Nachweis an die Brieftasche des Opfers, der einen gültigen Pfad vom tatsächlichen Block-Header zur gefälschten Transaktion enthält. Das Opfer wird in die Irre geführt und glaubt, dass die unterste Reihe des Merkle-Baums die vorletzte Reihe ist, mit einer weiteren Transaktion darunter. Das Opfer ist nun überzeugt, 1.000 BTC erhalten zu haben, während der Arbeitsnachweis der Miner durch den Angreifer gestohlen wurde, um das Opfer zu täuschen. Natürlich kann ein vollständiger Knoten so nicht getäuscht werden, aus mehreren Gründen, aber ein SPV-Knoten kann hinters Licht geführt werden.
Angriffsdiagramm
Diagramm, das die beiden im Angriff verwendeten Transaktionen veranschaulicht
Hinweis: Dieser Angriff wurde von Peter Todd am 7. Juni 2018 und von Sergio Lerner am 9. Juni 2018 erklärt.
Der oben beschriebene Angriff scheint rechnerisch nicht umsetzbar zu sein, da er eine vollständige 32-Byte-SHA-256-Kollision erfordert, was als rechnerisch unfeasibel gilt. Es ist sicherlich schwieriger, als einfach einen gefälschten Block zu minen, um einen SPV-Client zu täuschen, was heute nur etwa 2^84 Versuche erfordert, deutlich weniger als 2^256 für eine vollständige Kollision. Der trickreiche Aspekt besteht jedoch darin, dass die 64-Byte-Transaktion so manipuliert werden kann, dass es nicht notwendig ist, 32 Bytes rein durch Brute-Force abzugleichen.
Komponenten der letzten 32 Bytes der 64-Byte-Transaktion
| Element | Beschreibung | Größe | Größe für Kollision |
|---|---|---|---|
| Input TXID | Dies ist der Transaktionshash einer vorherigen Bitcoin-Transaktion. Er ist daher zufällig und kann nicht vernünftig manipuliert werden. Brute Force ist erforderlich. | 5 Bytes in der zweiten Hälfte | 5 Bytes |
| Input-Index | Man könnte eine Setuptransaktion mit Tausenden von Inputs erstellen. Der Input-Index lässt sich bis zu einem gewissen Grad manipulieren. | 4 Bytes | 0 |
| Input-Größe | Dies ist schwer zu manipulieren, gegeben die anderen Einschränkungen der Transaktion. Daher ist Brute Force erforderlich. | 1 Byte | 1 Byte |
| Output-Anzahl | Die Transaktion erfordert genau einen Output, ansonsten ist es schwer zu erkennen, wie die Transaktion 64 Byte messen könnte. Dieser Feld kann daher nicht manipuliert werden. | 1 Byte | 1 Byte |
| Output-Wert | Der Angreifer kann so viel Bitcoin ausgeben, wie er möchte, solange er den Bitcoin hat und bereit ist, ihn zu verlieren. | 8 Bytes | 0 |
| Output-Größe | Dies ist schwer zu manipulieren, gegeben die anderen Einschränkungen der Transaktion. Brute Force ist daher erforderlich. | 1 Byte | 1 Byte |
| Output-Skript PubKey | Da die Mittel dieser Transaktion nicht rückholbar sind, kann dies einfach manipuliert werden. | 8 Bytes | 0 |
| Locktime | Die Locktime kann manipuliert werden, indem beispielsweise eine Blockhöhe von bis zu 500 Millionen gewählt wird. | 4 Bytes | 0 |
Die obige Tabelle zeigt, dass der Angreifer nur eine Kollision für 8 Bytes finden muss, im besten Fall, vorausgesetzt, er kann alle anderen Manipulationen durchführen. 8 Bytes oder 2^64 erfordert nicht viele Rechenressourcen und ein gewöhnlicher Laptop könnte dies relativ schnell bewerkstelligen. In der Realität könnte es jedoch etwas über 2^64 liegen, da nicht alle oben genannten Felder vollständig manipuliert werden können.
Dieser Angriff scheint nicht allzu schlimm zu sein. Die Vorbereitung ist äußerst kompliziert und könnte eine Setup-Transaktion mit Tausenden von Inputs erforden, was zehntausende Dollar kosten könnte, nur um Entropie für den Wert des Outputs zu erhalten. Außerdem sind SPV-Wallets nicht mehr so beliebt. Personen, die große Zahlungen erwarten, wissen in der Regel, dass sie einen vollständigen Knoten benötigen, um eingehende Zahlungen zu verifizieren. Dennoch ist dieser Angriff durchaus machbar, insbesondere wenn entsprechende Werkzeuge verfügbar sind, und daher sollte man sich dessen bewusst sein und versuchen, die Risiken zu minimieren.
Merkle-Root-Hash-Kollision
Eine weitere verwandte Bitcoin-Sicherheitsanfälligkeit wurde 2012 entdeckt und behoben. Die Schwachstelle bestand darin, dass zwei unterschiedliche Bitcoin-Blöcke, ein gültiger und ein ungültiger, denselben Merkle-Root-Hash haben konnten. Es gab mehrere Möglichkeiten, dies zu erreichen, unter anderem durch die Verwirrung einer 64-Byte-Zwischenschritte mit einer 64-Byte-Transaktion.
Das Problem bestand darin, dass Bitcoin-Knoten den Block-Hash ungültiger Blöcke speichern, um zu vermeiden, Ressourcen damit zu verschwenden, sie erneut zu validieren. Wenn jedoch zwei Blöcke mit demselben Block-Hash existieren, könnte ein Bitcoin-Knoten dazu verleitet werden, der weniger arbeitsintensiveren feindlichen Kette zu folgen, statt der gültigen Kette. Diese Problemstellung wurde 2012 behoben, indem die Knoten zusätzliche Prüfungen durchführen mussten, bevor sie den Hash eines ungültigen Blocks cachen.
Ein verwandtes Problem trat 2019 erneut auf, als der Bitcoin-Entwickler Suhas Daftuar feststellte, dass ein ähnlicher Fehler unbeabsichtigt in Bitcoin Core 0.13.0 (veröffentlicht im November 2016) eingeführt wurde, bevor er im Februar 2017 erneut behoben wurde. Es gibt auch andere Schwachstellen, die mit diesem Problem in Verbindung stehen und potenziell andere unentdeckte Ausbeutungen darstellen könnten.
Vorgeschlagene Lösung
Die Behebung dieses Problems erfordert keinen Softfork, zumindest nicht für den SPV-Trick. Die Methodologie, die SPV-Wallets verwenden, könnte einfach aktualisiert werden, zum Beispiel um zu überprüfen, dass jede Transaktion sich in derselben Zeile im Merkle-Baum wie die Coinbase-Transaktion befindet. Das Problem besteht jedoch darin, dass SPV-Wallets dies nicht tun und das Wissen über dieses Problem nicht weit verbreitet ist. Dadurch sind die Nutzer anfällig. Neue Protokolle wie BitVM könnten ebenfalls betroffen sein und die Entwickler haben möglicherweise dieses Problem nicht in Betracht gezogen.
Die im BIP 54 vorgeschlagene Softfork würde alle Transaktionen mit einer witness-stripped Größe von 64 Byte vollständig verbannen. Dies scheint eine relativ einfache und unkomplizierte Lösung zu sein. Es gibt auch wenig Grund, 64-Byte-Transaktionen zu erstellen. Zum Beispiel wurde die oben genannte 64-Byte-Größe erreicht, indem die Mittel nicht rückholbar gemacht wurden. In einer E-Mail von 2019 erwähnte Suhas Daftuar, dass er die Blockchain durchsucht hat und keine 64-Byte-Transaktionen gefunden wurden. Dies sollte jeden Softfork reibungsloser gestalten und die Konsensbildung erleichtern, da das Verbot von etwas, das ohnehin nicht geschieht, als weniger riskanter und weniger konfrontativer Weg angesehen wird. Allerdings würde dies Bitcoin mit einer etwas skurrilen neuen Regel zurücklassen, bei der 63-Byte- und 65-Byte-Transaktionen in Ordnung sind, aber 64-Byte-Transaktionen verboten wären.
