先月Cryptography and Securityという学術誌に投稿された”Flood & Loot: A Systemic Attack On The Lightning Network"という論文においてLNにおける資金の盗難につながる脆弱性が記されていました。

今日の記事では、その脆弱性についてわかりやすく解説し、2月にも解説したLNの残高の大部分を数日間ロックさせる攻撃との類似点などに触れ、どのような影響があるか軽く考察します。

FLOOD & LOOTの概要

おそらく読者の皆さんの多くは、LNでの送金はHTLCという２者間取引のバケツリレーで成り立っていることをご存知かと思います。Flood & LootはHTLCの仕組みと、HTLCを解決できない場合の最終手段であるオンチェーン決済の仕組みを悪用した攻撃です。

①　まず、攻撃者は２つのライトニングノードを用意します。これを「送金元ノード」「送金先ノード」とします。送金先ノードは送金元ノードで使用する金額と同程度のインバウンドリクイディティ(受け取り可能額)が必要です。

②　攻撃者は、送金元ノードから多数のチャネルを開き、なるべく様々なノードを経由するような経路で自身の持つ送金先ノードへ大量の少額送金を開始します。この際、経由する各ノードでそれぞれの送金についてHTLCが作成されていきます。

③　攻撃者は送金先ノードからそれぞれの取引に関する最後のHTLCに対応するプレイメージを返すことで各送金を受け取り、送金先ノードのチャネルを全て決済します。ここまでは通常のLNトランザクションと同じ流れです。送金先ノードが正常に取引を完了しオンチェーンに決済することで、攻撃者は元本(－少額の手数料)を確保しました。

④　HTLCが送金の逆順に解決されていき、それぞれのチャネルの残高が更新されていきますが、最後に攻撃元ノードと直接チャネルで繋がっているノード(被害者ノード)がプレイメージを送ってきても、攻撃元ノードは無視をします(反応を返さない)。HTLCが期限を迎えるともらえるはずだった残高が攻撃元ノードのものとなってしまう(*)ため、被害者ノードはHTLCが期限(LNDなら通常10ブロック)を迎える前にプレイメージを使ってオンチェーンで強制決済する必要があります。

*…HTLCが期限切れになると、この場合は攻撃者がHTLCタイムアウトというトランザクションを発行して、そのHTLCの送金を巻き戻すトランザクション(攻撃者が資金を取り戻す)がブロックチェーンに決済されます。

⑤　実は攻撃者は自身が関わる大量のHTLCについて、全てが同時に期限を迎えてオンチェーン決済になるように期限を設定していたので、被害者ノードたちによるオンチェーン決済トランザクションが同時に大量発生することによってメモリプールが混雑し、HTLCの期限到達までにブロックチェーンで承認されない取引が出てきます。
攻撃者は期限切れを待ち、未承認のHTLC決済についてHTLCタイムアウトトランザクションを発行し、被害者より手数料をほんの少し多く支払うことで、そのHTLCで送金先ノードに送ったはずの金額を自分のものにできます。

根本的な原因

この攻撃を可能にする根本的な原因はいくつかあります。

まず、ブロックサイズが限られているため、同時に期限を迎えるHTLCに関する大量のオンチェーン決済トランザクションが発生すると時間内に捌けないことです。特に、手数料水準が高い場合は、攻撃のタイミングによっては多くが承認されないでしょう。

【追記7/3】ちなみにブロックサイズが無制限だったとしても、捌けるトランザクション数には実質的な上限があるので、それを超えるオンチェーン決済を発生させれば同じ問題が発生します。

次に、LNはこの攻撃者にとって非常に有利な仕組みになっており、チャネルを開設した攻撃者側が被害者によるオンチェーン決済時の手数料の設定を一方的に提案することができたり、攻撃者が使うHTLCのタイムアウトによる決済トランザクションは攻撃者単独で行えて手数料も自由に決められるのに対し、被害者が使うオンチェーン決済は攻撃者とのマルチシグであり単独でReplace-by-fee(手数料を高めて再配信)することができないことが挙げられます。

被害者の選択肢は「何もせず、HTLCの期限切れで攻撃者に盗まれる」か「HTLCをオンチェーン決済しようとするが、承認が間に合わなければ期限切れで攻撃者に盗まれる」の２択しかないわけですね。

かなりLNとビットコインの根本に関わる部分なので、対策が難しいことが想像されます。

残高の大部分をロックさせるLNの脆弱性との比較
おさらい：
２月に紹介した攻撃は、攻撃者がとても長い送金経路を持つ自分自身への送金を大量に行い、送金先においてプレイメージを返さないことで多くのチャネルのHTLC数を上限に到達させてしまい、新たな送金の経路として働くことができないようにし続けるという攻撃でした。
この場合も、HTLCが期限切れを迎えても、結局攻撃者に返金されるだけなので、攻撃者は複数のノードを使い繰り返しチャネルを開いて同様の行為を繰り返すことで、合計0.25BTC程度のオンチェーン手数料で3日間に渡り650BTCもの流動性をロックすることに成功しうる、というものでした。

攻撃者が自身に対して送金を行い、プレイメージを返さないことでネットワークに特定の動作をさせる(動作をさせない)という点で非常に似ています。

一方で、２月に紹介した攻撃はDoS攻撃でありネットワークの大部分が単純に被害者であるのに対し、６月に投稿された攻撃は、攻撃元ノードと直接チャネルを開いているノードが資金の盗難に遭う可能性のある被害者であり、残りのノードに大きな影響はないという点は大きく異なります。
(なんなら被害者ノード以外の経由ノードはルーティング手数料をもらっています)また、LNに対するDoS攻撃による攻撃者のメリットは不透明なのに対し、大量のHTLCの期限切れを引き起こす攻撃は、最大で攻撃に使用した金額とほぼ等しい金額を得ることができる上、攻撃の最初の段階で送金先ノードで元金をほとんど回収しているためリスクが小さいことが挙げられます。

自分の資金を置いているノードが要求されても自動的にチャネルを開かない設定であれば、今回紹介した手法では被害には遭いません。(攻撃元ノードからチャネルを開かれないため)
しかし、研究者らが調べると、チャネル開設を持ちかけると95%のノードがaccept_channelという「受け入れ可能」を通知する設定になっていたため、ライトニングノードの大半が攻撃対象となりうると考えられます。(残り5%は接続のタイムアウトやブロックチェーン同期中が理由で断った模様)

他のノードからのチャネル開設を受け入れるパブリックノードと、プライベートチャネルしか持たないプライベートノードがありますが、パブリックノードがあえてチャネル開設を断る設定は特になかったように思うので、パブリックノードはおそらく全て今回の攻撃手法の対象となり得ます。
改善策と影響

今回の論文を投稿した研究者たちは、根本的な解決とはならないと前置きをして、次のものを含むいくつかの提案をしています：・各ライトニング実装によって定められている、HTLCの期限切れまでのブロック数をもっと長くするか、未解決のHTLCの数や総額など、ノードの状況によって変動できるようにする
・チャネルごとに相手のノードの信頼度によって設定を変える

自分も、今回の攻撃手法は不特定のノードからチャネルの開設を受けて大量の取引を取り次ぐことにリスクがあるということなので、信頼するノード以外からのチャネルは区別して厳重に運用できるようにすることが一番しっくりくる対策かなと思います。ある意味"LN Trust Chain"という言葉がしっくりくる形式ですね。自分のノードに向けてチャネルを開設されることにはコストがかからなくてもリスクはある、ということです。

(HTLCの仕組みを変えるような抜本的な対策があるかもしれませんが、それ自体のリスク評価、実装と普及もけっこう難しい問題だと思います)

様々なDefiやLiquidと比較して小さいと揶揄されることもあるライトニングネットワークの資金総額ですが、このような攻撃ベクトルが洗い出されて対策されていくまでは大きな金額を預けることには慎重にならざるを得ないな、と感じます。

なお、プライベートチャネルしかないいわゆるNon-routing nodeの場合は、今回紹介した攻撃手法の被害に遭うことはありません。