ライトニング、攻撃報告を受け請求書ルールを厳格化　出金済み取引が未払いに見える問題

ライトニングの開発者は10月19日、ライトニング・ネットワークの請求書標準であるBOLT11を改定し、曖昧な支払いハッシュ欄と支払いシークレット欄を含む請求書を拒否するよう義務付けた。この改定は、完了したビットコインの出金が未払いに見える状態になった攻撃について、開発者が説明したことを受けたものだ。マージされた改定は、単一の署名済み支払いリクエストをソフトウエアの構成要素ごとに異なる形で解釈する問題に対処する。支払いハッシュは、構成要素が追跡する支払いを識別する。Bitcoin Optechは10月23日、この改定に注目した。

開発者のRoasbeef氏は、提案に関する9月10日の声明で、テレグラムのピアツーピア・ボットが最近ハッキングされたと報告した。Roasbeef氏によると、攻撃では請求書から異なるハッシュを選択するライブラリーが悪用された。一部は最初の支払いハッシュ欄を選び、他は最後の欄を選んだという。Roasbeef氏は、事件の日付も損失額も明らかにしなかった。サービスがあるハッシュに出金を記録する一方、ノードは別のハッシュに対して支払いを実行する可能性がある。その結果、サービスは完了した出金を未払いと判定し、追加の支払いを可能にすることがある。障害は、支払いの実行とサービスの会計処理をつなぐ部分で起きる。

現行のBOLT11仕様では、pで示される支払いハッシュ欄と、sで示される支払いシークレット欄をそれぞれ1つだけ認めている。いずれかの欄が欠けている場合も、重複している場合も、支払いを失敗させなければならない。この要件は両方の欄の曖昧さに対処するものだが、報告された出金攻撃に関係したのは、相反する支払いハッシュだった。請求書を読み取るソフトは、異なる値の数だけでなく、欄の出現回数を数える必要がある。提案には、同じハッシュが重複する場合と異なるハッシュが記載される場合の無効なテスト用請求書が含まれている。したがって、同一のハッシュを1つの値にまとめるだけでは、拒否すべき請求書を特定できない。

ライトニング・ノードソフトウエアのlndは、仕様改定に先立つ9月23日に重複ハッシュを拒否する修正をマージした。現在入手できるlndのリリース、v0.20.5-betaとv0.21.4-betaには、支払いハッシュの修正が含まれている。より広範な支払いシークレットの検証に対応する別のlnd提案は、10月27日時点で未決着だった。この提案は、支払いシークレットの検証や、s欄の重複拒否を含むその他のデコーダー検査を強化するものだ。提案の作成者は、デコーダーが受け入れた請求書の一部には、後続の支払い処理段階ですでに検査が適用されると説明している。したがって、デコードに成功しただけでは、支払いが成功するとは限らない。

今回明らかになった障害を踏まえると、決済事業者は曖昧な請求書を拒否する必要がある。出金の会計処理では、ノードが使用する支払いハッシュを使う必要もある。