Am vergangenen Montag enthüllte der Lightning-Entwickler Antoine Riard eine neuartige Angriffsmethode auf das Sicherheitsmodell des Lightning-Netzwerks. Mit "Replacement Cycling", dem geschickten und wiederholten Ersetzen von bestimmten Bitcoin-Transaktionen, soll man eine Lightning-Node, die eine Zahlung im Netzwerk weiterleitet, bestehlen können. Die Schwachstelle wird außerdem als recht besorgniserregend eingestuft, da es sich nicht um einen trivialen Programmierfehler handelt, der sich schnell beheben lässt, sondern auf eine grundlegende Eigenschaft von Bitcoin-Transaktionen zurückzuführen ist.
Es sei aber gleich vorweggesagt, dass es sich hier weder um das katastrophale Ende des Lightning-Netzwerks, noch um eine komplett irrelevante Schwachstelle handelt. Tatsächlich ist die von Riard vorgestellte Methode praktisch umsetzbar, wenn auch nicht ganz einfach und sie zeigt eindrucksvoll die aktuellen Grenzen des Lightning-Netzwerks auf. Betreiber von Lightning-Nodes müssen sich aber keine akuten Sorgen um ihre Bitcoin oder gar dem Netzwerk im Gesamten machen. Die Schwachstelle wurde zwar erst letzte Woche veröffentlicht, ist aber bereits seit Ende 2022 in enger Absprache mit Entwicklern der gängigsten Lightning-Implementationen bekannt. In den folgenden Versionen sind bereits diverse Maßnahmen zur Abschwächung umgesetzt, die den Angriff fast schon wieder in den Bereich von "theoretisch möglich, aber sehr unwahrscheinlich" rücken – dazu aber später mehr.
- LDK v0.0.118
- Eclair v0.9.0
- LND v.0.17.0-beta
- Core-Lightning v.23.08.01
In der Realität, zumindest innerhalb der letzten 10 Monate, konnte man keine aktive Ausübung des Angriffs im Lightning- und Bitcoin-Netzwerk beobachten. Umsetzbar ist er aber auf jeden Fall, was Riard in einer Antwort auf seine ursprüngliche Veröffentlichung gestern bestätigte. Doch um das alles besser einordnen zu können, müssen wir den Ansatz von Replacement Cycling erstmal konkret verstehen.
Antoine Riard hat in der gestrigen Nachricht außerdem verkündet, sich als Lightning-Entwickler zurückzuziehen. Wahrscheinlich war dies ohnehin schon geplant und hat sich mit der finalen Bekanntgabe der Schwachstelle nun einfach so ergeben. Nach einer Pause möchte er sich dann mehr auf Bitcoin Core fokussieren – komplett aus der Welt ist er also nicht!
Update 22.10: In einer Rundmail hat Riard mittlerweile verkündet, in den nächsten Monaten doch noch zur Lösung des Problems beitragen zu wollen und sich erst danach mehr der Core-Entwicklung zu widmen.
Während ich mich weiterhin darauf konzentrieren werde, die oben genannten Probleme im Base-Layer zu lösen, wo sie am besten gelöst werden können, werde ich zumindest noch ein paar Monate dabei bleiben und den Wechsel mit der jüngeren Generation der LN-Entwickler vollziehen.
Antoine Riard
Lese-Tipp | Sind kleine Zahlungen im Lightning-Netzwerk sicher?
HTLCs und RBF
Zunächst müssen wir einen Schritt zurückgehen und kurz wiederholen, wie Zahlungen im Lightning-Netzwerk überhaupt funktionieren und worauf ihre Sicherheit basiert. Ein Hash Time Locked Contract (HTLC) ist ein für Bitcoin-Verhältnisse recht komplexer Smart Contract, der mithilfe der Bitcoin-Script Sprache konkrete Regeln, zur Ausgabe eines bestimmten Bitcoin-Outputs festlegt. An dieser Stelle werden wir recht stark vereinfachen, um uns nicht an technischen Details aufzuhängen.
Ein solcher HTLC ist das Herzstück einer jeden Lightning-Zahlung, die über mehrere Zahlungskanäle hinweg geschickt wird. In ihm werden Bedingungen so festgelegt, dass sämtliche Teilnehmer entlang der Zahlungsroute bei unkooperativem Verhalten wieder an ihre Bitcoin gelangen können. Eine Lightning-Zahlung ist im Grunde nichts anderes als eine Reihe von unterschriebenen Bitcoin-Transaktionen, die allerdings nicht veröffentlicht werden. Im Ernstfall kann das Bitcoin-Netzwerk dann jederzeit als "Richter" hinzugezogen werden, um einen Disput zu lösen. Konkret kann ein HTLC in diesem konkreten Szenario entweder ausgegeben werden, wenn man in Besitz einer bestimmten Information, also so etwas wie einem "Geheimnis" ist, oder innerhalb eines festgelegten Zeitrahmens. Diese Information wird später wichtig!
Lese-Tipp | Upgrade für Bitcoin & Lightning: Was sind Eltoo und SIGHASH_ANYPREVOUT?
Zum Zweiten müssen wir uns klarmachen, was es überhaupt bedeutet, wenn eine Bitcoin-Transaktion unbestätigt im Mempool einer Bitcoin-Node liegt. Für die meisten wenig überraschend, aber später für den Angriff entscheidend, ist die Möglichkeit, unbestätigte Bitcoin-Transaktionen ersetzen zu können. Sie stehen schließlich noch nicht in der Bitcoin-Blockchain und sind damit alles andere als final. Das gängige Verfahren für eine solche Ersetzung heißt Replace-By-Fee und wird eingesetzt, um Transaktionen im Nachhinein mit einer neuen, höheren Gebühr zu versehen, um beispielsweise die Wartezeit zu verkürzen. Als Voraussetzung muss hierfür lediglich eine höhere absolute Gebühr und eine höhere Gebührenrate festgelegt werden – zumindest nach der weit verbreiteten Regelung aus BIP-125. Doch neben diesem offensichtlichen Anwendungsfall sind mit RBF auch andere "Tricks" möglich. Beispielsweise könnte man den Empfänger einer Transaktion ändern und damit eine Transaktion auch effektiv abbrechen. Ein ähnlicher "Trick" kommt gleich auch bei unserem Angriff zum Einsatz.
Das entscheidende Fazit aus dieser kurzen "Wiederholungs-Stunde" ist also:
- Eine Lightning-Zahlung ist nur dann sicher, wenn die Beteiligten im Notfall mithilfe von Bitcoin-Transaktionen Anspruch auf ihre Bitcoin erheben können.
- Eine Bitcoin-Transaktion ist nur dann bestätigt, wenn sie in einem Block bestätigt ist. Vorher gibt es kaum bis keinerlei Sicherheit, da unter anderem mithilfe von RBF, diverse Tricks mit Ersetzungen im Mempool durchgeführt werden können.
Replacement Cycling
Stellen wir uns Bob vor, der jeweils einen Lightning-Kanal mit Oscar und Mallory verwaltet. Bei Oscar und Mallory kann es sich auch um ein und dieselbe Person handeln, das spielt erstmal keine Rolle. Wichtig ist nur, dass der Angreifer eine Zahlung über Bob hinweg schickt, und die Kontrolle über den nächsten Teilnehmer hat. Mallory muss jetzt nämlich einfach die Kooperation mit Bob verweigern, sodass dieser auf seinem HTLC sitzen bleibt. So weit, so gut. Denn auf diesen Sonderfall ist Bob schließlich vorbereitet. Er veröffentlicht die aktuelle Commitment-Transaktion seines Zahlungskanals im Bitcoin-Netzwerk, welche auch bestätigt wird, um dann im Anschluss den HTLC ausgeben zu können und sich seine Bitcoin wiederzuholen.
Bob veröffentlicht also nun die Transaktion, welche den HTLC über die bereits erwähnte zeitliche Bedingung ausgeben möchte. Dafür hat er nicht unendlich viel Zeit, der Rahmen hierfür ist schließlich bereits festgelegt (und beträgt in der Regel ungefähr 30 Blöcke). Da er den Konflikt mit Mallory schnell bemerkt, ist dies zunächst kein Problem. Genau hier kommt Replacement Cycling ins Spiel. Mallory kann nämlich auch versuchen, den HTLC auszugeben und mithilfe von Replace-By-Fee die Transaktion von Bob ersetzen. Zunächst ergibt dieser "Angriff" wenig Sinn, da Mallory somit das entscheidende Geheimnis des HTLC an Bob verraten würde. Doch um das zu verhindern, hat Mallory ein Ass im Ärmel.
Bereits zuvor hat Mallory im Bitcoin-Netzwerk eine andere Transaktion veröffentlicht, die erstmal überhaupt nichts mit unserer Lightning-Zahlung zu tun hat und außerdem noch unbestätigt (!) ist. Die Regeln von RBF erlauben es, beim Ersetzen einer Transaktion auch weitere Inputs zur Transaktion hinzuzufügen. Das bedeutet für Mallory: Sie kann die Gültigkeit der gerade angesprochenen HTLC-Transaktion an die andere, noch unbestätigte, Transaktion knüpfen, vergleichbar mit dem Konzept von Child Pays For Parent, nur dass die Motivation hier eine völlig andere ist. Der ein oder andere dürfte an dieser Stelle bereits das Problem sehen.
Denn wenn Mallory die andere, unbestätigte Transaktion nun ebenfalls mit RBF ersetzt, wird damit auch die HTLC-Transaktion, die von jener Transaktion abhängt, ungültig und fliegt aus dem Mempool. Das mag zunächst sehr verwirrend klingen, daher hier noch einmal der Ablauf in Stichpunkten:
- Mallory veröffentlicht eine komplett belanglose Transaktion im Bitcoin-Netzwerk, die erstmal nicht bestätigt wird (z.B. durch eine sehr niedrige Gebühr).
- Bob veröffentlicht die Transaktion, mit der er den HTLC rechtmäßig ausgeben möchte, da Mallory nicht mit ihm kooperiert.
- Mallory ersetzt Bobs Transaktion und macht die Gültigkeit dieser neuen Transaktion von der Transaktion aus Schritt 1 abhängig.
- Nahezu gleichzeitig ersetzt Mallory die Transaktion aus Schritt 1, womit die Transaktion aus Schritt 3 ungültig wird und aus sämtlichen Mempools fliegt.
Mallory hat jetzt erfolgreich verhindert, dass die Transaktion von Bob bestätigt wird, ohne dabei das Geheimnis des HTLC (dauerhaft) zu veröffentlichen. Mit jedem unwissenden Versuch von Bob, seine Transaktion erneut zu veröffentlichen, kann sie die Schritte von oben einfach wiederholen, bis der festgelegte Zeitraum abgelaufen ist und Bob mit leeren Händen dasteht.
Gegenmaßnahmen
Einige Stimmen sagen nun triumphierend den Untergang des Lightning-Netzwerks voraus, was eine völlig unverhältnismäßige und unsachliche Einordnung des oben beschriebenen Angriffes ist. Zwar kann man den fundamentalen Mechanismus nicht einfach so verhindern, ohne grundlegend etwas an der Funktionsweise von Bitcoin zu verändern, man kann ihn allerdings deutlich erschweren. Und genau das ist bereits passiert.
Aggressives Neuveröffentlichen
Bisher hätte die Lightning-Node von Bob die entscheidende Transaktion von oben nur in größeren Zeitabständen (z.B. für jeden Block) neu veröffentlicht, sollte sie, warum auch immer, aus dem Mempool geflogen sein. Doch jetzt, wo der Angriff bekannt ist und man nach ihm Ausschau halten kann, ist ein viel aggressiveres Veröffentlichen der besagten Transaktion natürlich eine naheliegende Gegenmaßnahme. Denn für jeden "Zyklus" muss Mallory schlussendlich umso mehr Transaktionsgebühren zahlen, da die RBF-Regeln wie erwähnt immer eine höhere Gebühr für eine Ersetzung verlangen. Je häufiger der Angriff also wiederholt werden muss, desto teurer und damit unattraktiver wird er für Mallory.
Ein Auge auf den Mempool
Zusätzlich kann die Lightning-Node von Bob den eigenen Bitcoin-Mempool einfach sehr viel genauer im Auge behalten und aktiv nach dem potenziellen Geheimnis des HTLC, welches schließlich zumindest kurzzeitig durch das Bitcoin-Netzwerk geistert, Ausschau halten – und damit den Angriff abwenden. Theoretisch wäre es auch möglich, sämtliche eingehende Transaktionen für eine gewisse Zeit zwischenzuspeichern, egal ob sie nach den definierten Regeln im Mempool bleiben würden, oder nicht.
Mehr Zeit
Ein weiterer logischer Schritt ist es, das angesprochene Zeitfenster für Bob einfach zu vergrößern, um ihm noch mehr Chancen zu geben, Mallory an ihrem Angriff zu hindern. Ganz allgemein sei gesagt, dass mit jedem Ersetzungs-Zyklus, ein ernstzunehmendes Risiko für Mallory besteht, dass Bob entweder das Geheimnis kennenlernt oder seine Transaktion durch einen glücklichen Zufall einfach in den nächsten Block rutscht. Das Ersetzen von Transaktionen mit RBF ist schließlich kein perfekt zuverlässiger Prozess, sondern lediglich ein Vorschlag, wie man mit solchen Transaktionen umgehen sollte.
Diese Maßnahmen wurden entweder vollständig oder teilweise in den gängigen Lightning-Implementation umgesetzt. Der Angriff ist damit zwar theoretisch immer noch genauso möglich, in der Praxis aber um einiges schwieriger umzusetzen. Ein Angreifer müsste viel Sorgfalt und Planung in eine effektive Umsetzung investieren und geht dabei stets die angesprochenen Risiken ein.
Fazit
Der neue Replacement Cycling Angriff zeigt deutlich, dass Skalierung stets mit Sicherheits-Kompromissen einhergeht. Als Nutzer des Lighting-Netzwerks sollte man sich bewusst sein, dass man nie die gleiche Sicherheit wie direkt auf der Bitcoin-Blockchain genießen kann. Das ist allerdings keine Neuigkeit, sondern war natürlich schon immer so. Die bereits implementierten Gegenmaßnahmen in diversen Lightning-Clients machen aus einem praktisch durchaus umsetzbaren Angriff, ein eher theoretisches und unwahrscheinliches Szenario. Sicherlich wird man noch weiter an dieser Schwachstelle arbeiten müssen um die gerade genannten Gegenmaßnhamen noch weiter zu optimieren.
Doch von einem ernsthaften oder gar existenziellen Problem für das Lightning-Netzwerk ist der Angriff dann doch etwas weit entfernt. Bisher gab es schließlich auch keinen tatsächlichen Angriff. Natürlich sollte man hier nichts auf die leichte Schulter nehmen, aber auch das Gegenteil davon, also überzogenes Panikschüren, ist unangebracht und stört die eigentlich wichtigen, rationalen Debatten.
