Liquid, Ark & Co. – Die Illusion des Layer 2

Am Sonntag, dem 6. September, fügte jemand diese Nachricht in eine Bitcoin-Transaktion ein. Rund vier Stunden zuvor hatte seine Adresse fast 4.000 Bitcoin durch einen Exploit von Liquid erhalten.
Liquid, Ark & Co. – Die Illusion des Layer 2

„Wir sind White Hats. Kontaktiert uns on-Chain.“

Liquid ist die von Blockstream entwickelte Sidechain, auf der L-BTC zirkulieren – Token, die eins zu eins durch Bitcoin gedeckt sein sollen, die von der Federation verwahrt werden. Der Mechanismus ermöglicht es, Werte über ein Netzwerk mit anderen Eigenschaften zu transferieren, darunter vertrauliche Transaktionen und häufigere Blöcke, während die Bindung an hinterlegte BTC erhalten bleibt.

Die Angreifer hatten es geschafft, rund 4.000 L-BTC zu erzeugen, ohne die entsprechenden Bitcoin zu hinterlegen. Anschließend nutzten sie SideSwap, um sie in BTC umzuwandeln. In seinem Incident Report gab Liquid an, dass die Reserve vor dem Exploit rund 4.205 BTC enthielt. Nach dem Abfluss und weiteren vor der Sperrung verarbeiteten Peg-Outs verblieben 197 BTC.

In derselben Stellungnahme wurde betont, dass keine privaten Schlüssel kompromittiert zu sein schienen.

Um zu verstehen, wie dies möglich war, muss man den Geldfluss betrachten:

Bei einem Peg-In werden Bitcoin auf der Mainchain hinterlegt und ihr Gegenwert auf Liquid gutgeschrieben. Der umgekehrte Vorgang, der Peg-Out, verbrennt L-BTC und gibt BTC aus der Reserve frei. Diese Reserve wird von den Functionaries gehalten – Federation-Servern, die am Netzwerkbetrieb und der Verwaltung der Verbindung zu Bitcoin teilnehmen.

Das Federation-Multisig erfordert elf von fünfzehn Signaturen. Die Schlüssel werden in speziellen Hardware-Geräten, HSMs, gespeichert. Eine Ausgabe der Bitcoin erfordert daher Signaturen von einer ausreichenden Anzahl von Functionaries.

Es gibt zudem eine Beschränkung der Ziele: Peg-Outs können nur an Adressen erfolgen, die durch einen Peg-Out Authorization Key (PAK) autorisiert wurden. SideSwap besitzt einen dieser Schlüssel. Der Dienst empfängt die L-BTC, verbrennt sie, erhält die Zahlung von der Federation an eine seiner autorisierten Adressen und leitet die BTC an den Kunden weiter.

Die Zahlung vom 6. September enthält 83 Inputs, jeder mit den elf Signaturen des Standard-Pfads. Das Script enthält auch einen Notfall-Pfad mit einer anderen Signaturschwelle und einem Timelock, der in diesem Fall nicht genutzt wurde. Die anschließende Weiterleitung von knapp 3.996 BTC an die Adresse der Angreifer wurde im selben Bitcoin-Block bestätigt.

Die Software hatte die zur Anforderung dieser Zahlung verwendeten L-BTC als gültig erkannt. Das Multisig autorisierte die Ausgabe also auf Basis einer fehlerhaften Buchhaltung.

Die Ursache des Problems lag in Elements, der Software, auf der Liquid aufbaut, und betraf die Überprüfung von Range Proofs. Diese kryptografischen Beweise ermöglichen es zu verifizieren, dass die verborgenen Beträge in vertraulichen Transaktionen innerhalb bestimmter Grenzen liegen, und verhindern, dass unmögliche Werte zur Geldschöpfung genutzt werden.

Ihre Überprüfung erfordert Rechenarbeit, daher speichert Elements positive Ergebnisse zwischen (Caching). Stößt die Software auf einen bereits als verifiziert betrachteten Beweis, vermeidet sie die erneute Berechnung. Der Fehler lag in der Identifikation der geprüften Daten: Verschiedene Felder wurden aneinandergereiht, ohne ihre Grenzen korrekt zu unterscheiden. Unterschiedliche Kombinationen konnten daher denselben Cache-Eintrag erzeugen.

Laut der Analyse von CertiK nutzten die Angreifer diese Mehrdeutigkeit aus, um eine inflationäre Transaktion durch die Wiederverwendung eines positiven Ergebnisses zu genehmigen. Die Prüfung, die sie hätte zurückweisen müssen, wurde übersprungen.

Nach eigener Darstellung installierte SideSwap am 13. August einen Security Build, der Liquid-Mitgliedern privat zur Verfügung gestellt worden war. Diese Version akzeptierte die Exploit-Transaktion dennoch. Es bleibt unklar, welche Binärdateien von den einzelnen Functionaries ausgeführt wurden und in welchem Zustand sich ihre Caches zum Zeitpunkt des Angriffs befanden.

Der Notfall-Fix, veröffentlicht mit Elements 23.3.4 am 9. September, stellt die Trennung der vom Cache verwendeten Felder eindeutig her und erlaubt zudem, den Cache zu deaktivieren.

SideSwap räumte zwei eigene Verantwortlichkeiten ein: Der PAK war online und Zahlungen wurden automatisch weitergeleitet; zudem fehlten angemessene Kontrollen der Größe und Häufigkeit von Abhebungen. Eine Order über rund 4.000 L-BTC wurde ohne menschliche Prüfung verarbeitet.

In der Zwischenzeit kommunizierten Blockstream und die Angreifer über OP_RETURN. Einige der Nachrichten waren verschlüsselt. Am 7. September veröffentlichte Blockstream eine signierte Bestätigung, dass Bridge-Nodes aktualisiert worden waren; die Signatur kann mit dem öffentlichen PGP-Key von Blockstream verifiziert werden.

Am Nachmittag desselben Tages wurden 3.400 BTC zurückgegeben. Rund 598,5 BTC verblieben bei den Angreifern. Am 9. September folgte eine Klartext-Anfrage: eine Belohnung von 10 %, gezahlt aus Blockstream-Mitteln, begleitet von der Drohung, L-BTC-Halter mit einem Verlust von 15 % zurückzulassen.

Am 11. September lehnte Blockstream die Lösegeldforderung öffentlich ab, bestritt die Bezeichnung als White Hats und kündigte an, sich an Behörden und Branchenakteure zu wenden, um die Gelder zurückzuerhalten. Die rund 598,5 BTC, die einbehalten blieben, sind von einer vereinbarten Prämie unabhängig: Eine öffentliche Vereinbarung in diesem Sinne scheint nicht dokumentiert zu sein.

Zum Zeitpunkt dieses Texts hat Liquid die Bestätigung von Transaktionen wieder aufgenommen, und SideSwap hat Peg-Ins wieder geöffnet. Peg-Outs bleiben ausgesetzt. Adam Back hat versprochen, die 1:1-Deckung wiederherzustellen, ohne jedoch zu spezifizieren, wie oder wann.

Selbst wenn der Peg zurück zu 1:1 findet

Wer Liquid nutzte, akzeptierte eine Federation und ihre Abwägungen. Vertrauen umfasste jedoch auch eine Einschätzung der Kompetenz derer, die die Software entwickeln, Updates verteilen und Abhebungen verwalten. Diese Einschätzung hat die Katastrophe zerstört.

Eine unrechtmäßige Ausgabe passierte die Validierung, erhielt die erforderlichen Signaturen und verwandelte fast die gesamte Reserve in eine Zahlung an die Hacker. Die Rückgewinnung des Großteils der Bitcoin gelang dank ihrer Entscheidung, sie nach einer Verhandlung zurückzugeben. Das Glück, das in dieser Rückgabe steckt, lastet schwer auf dem endgültigen Ergebnis.

Ich hoffe, dass jeder Nutzer seine Mittel vollständig zurückerhält. Die Arbeit derer, die die Software reparieren und den Dienst wieder aufbauen, verdient Anerkennung. Meine Einschätzung der Zuverlässigkeit des Projekts ist jedoch nun erschüttert.

Eine Reserve kann wieder aufgefüllt werden. Seine Bitcoin denselben Prozessen erneut anzuvertrauen, erfordert ein Maß an Vertrauen, das Liquid nach meinem Dafürhalten erschöpft hat.

Der Blick auf die Alternativen

Und wenn man sich umschaut: Die Alternativen, mit denen wir Bitcoin zu einem alltäglichen Zahlungsmittel, einem echten Tauschmittel machen sollen, verlangen von den Nutzern weiterhin weit mehr Kompromisse, als ihre Marketingkampagnen zuzugeben bereit sind.

In Stop #313 analysierte ich Spark, das von Wallets wie Wallet of Satoshi, Primal, Cake, Glow und anderen übernommen wurde. Schnelle Zahlungen, Empfang im Offline-Modus, kein Kanalmanagement durch den Nutzer. Das Problem zeigt sich, wenn Nutzer ihren Saldo während eines Ausfalls des Betreibers wiederherstellen wollen.

Ein Wallet, das die On-Chain-Wiederherstellung von Geldern von Betreibern abhängig macht, bleibt in der praktischen Nutzung de facto verwahrend – selbst wenn es dem Nutzer einen Seed gibt.

Bei Bark, der von Second entwickelten Ark-Implementierung, nimmt das Problem eine andere Form an.

Der Saldo wird durch VTXOs repräsentiert – virtuelle Outputs, die durch vorab signierte Transaktionen erzeugt werden. Laut Seconds Dokumentation haben solche, die durch einen On-Chain-Eintritt oder ein Refresh auf seinem Server erstellt wurden, eine Lebensdauer von 28 Tagen. Bei solchen, die aus empfangenen Lightning-Zahlungen stammen, beträgt die Lebensdauer 1–3 Tage. Dies sind konfigurierbare Parameter; ein empfangenes VTXO kann bereits einen Teil seiner Lebenszeit verbraucht haben.

Vor Ablauf müssen VTXOs aufgefrischt oder der Rückweg on-chain abgeschlossen werden. Nach Ablauf erhält der Server die Möglichkeit, die Bitcoin über den Timelock-Pfad des Protokolls zu beanspruchen. Der Nutzer kann zwar noch versuchen, auszusteigen, solange die Gelder verfügbar sind, aber die alleinige Kontrolle ist verloren.

Das Telefon kann zwischen den Vorgängen offline bleiben. Es muss jedoch rechtzeitig wieder online kommen, damit das Wallet die Wartungsarbeiten durchführen kann. Seconds AGB, Abschnitt 1.6, besagen, dass das Unternehmen Gelder aus abgelaufenen VTXOs beanspruchen kann und keine Verpflichtung zur Rückgabe übernimmt.

Self-Custody – mit Kalendererinnerungen, die hoffentlich funktionieren.

Die Ausnahme

Ich werde nicht über die Welt des E-Cash sprechen, einschließlich Fedimint, denn dies sind offen und explizit verwahrende Lösungen.

In dieser Landschaft ist die Ausnahme, die ich bereit bin zu befürworten, Phoenix, das Lightning-Wallet von ACINQ.

Das Modell ist das des Lightning Service Providers (LSP): Ein Betreiber stellt Konnektivität und Liquidität bereit, während das Wallet Lightning betreibt und den Kanal des Nutzers verwaltet. Splicing ermöglicht es, diesen Kanal jederzeit zu vergrößern oder zu verkleinern, wenn Gelder hinzugefügt oder abgezogen werden müssen. ACINQ übernimmt die Infrastrukturarbeit, die den Dienst nutzbar macht.

Das Problem ist, dass bei Lightning die Größe zählt. Zum Zeitpunkt dieses Texts meldet der ACINQ-Node-Explorer rund 361 BTC an öffentlicher Kapazität und 1.836 aktive Kanäle. Kapazität ist der Gesamtwert der beobachteten Kanäle, nicht zu verwechseln mit der in jede Richtung verfügbaren Liquidität. Sie vermittelt dennoch eine Vorstellung von der Infrastruktur, die den Dienst trägt.

Phoenix zeigt das Modell, das ich derzeit für Zahlungen als überzeugend erachte: Lightning, ein LSP mit angemessenen Ressourcen und ein On-Chain-Ausstiegsweg. Kosten und technische Anforderungen bleiben bestehen, aber das tägliche Management wird durch Infrastruktur zugänglich gemacht, die ihren Job macht.

Fazit

Der Rest der Landschaft führt mich zu einem recht harten Urteil: Bitcoin – das echte, ohne Kompromisse bei der Verwahrung konzipierte – ist als Zahlungsmittel für die breite Öffentlichkeit technologisch noch nicht ausgereift.

Der Fixpunkt bleibt bis heute On-Chain. Und vielleicht ist es in dieser Zeit ständiger KI-gesteuerter Angriffe besser, auf Nummer sicher zu gehen und sich auf die Solidität des guten alten UTXO zu verlassen.

Write a comment