Liquid Network セキュリティインシデント評価

読者への注意: この報告書に含まれる情報は、公開日現在のものであり、調査の進展に伴い更新される可能性があります。技術的な主張は、内部および外部の文書、サポート資料、およびオンチェーン分析から引き出されています。Liquid Federation Boardおよび機能ノードオペレーターの緊密な連携、および広範なBitcoin開発コミュニティの精査とサポートに感謝します。目次1. エグゼクティブサマリー2. Liquidアーキテクチャとセキュリティ不変量3. 脆弱性分析4. インシデントタイムライン5. 緩和策、修正、および復旧6. 教訓と是正措置7. 謝辞セクション1: エグゼクティブサマリー2026年9月6日 13:53 UTC（Liquidブロック4,050,336）に、攻撃者はElementsのrangeproof検証キャッシュの脆弱性を悪用し、単一のトランザクションがその出力値が入力によって裏付けられていないにもかかわらず検証を通過することを可能にしました。Liquidノード（機能ノードを含む）は、そのトランザクションを受け入れました。これにより、LBTCの供給量が約4,000 LBTC、裏付けとなるビットコインなしでインフレしました。攻撃者はその後、SideSwapを介してLiquidの標準的なペッグアウトプロセスを通じて、アンバックドLBTCを移動させました。SideSwapは、ペッグアウト承認キー（PAK）を保持するFederationメンバーです。これにより、約4,000 BTCの引き出しが発生し、Bitcoinブロック965,783で確認されました。ネットワークが停止する前に確認された小規模なペッグアウトにより、Liquidリザーブは約4,205 BTCから197 BTCに減少しました。Liquid発行の他のすべての資産（USDt、DePix、その他のトークン化された資産）は、インシデントの影響を受けませんでしたが、ネットワークが一時停止中は利用できませんでした。攻撃者はインシデント発生から数時間以内にオンチェーンで自身を特定し、数回の交渉の後、3,400 BTC（9月7日 16:09 UTC、Bitcoinブロック965,950）を返還しました。約602 BTCが未回収のままです。Blockstreamは、攻撃直後にLiquidブリッジノード（ユーザーが接続する公開ノード）の停止を調整し、数時間以内に緊急の暫定パッチを展開し、数日以内に完全にレビューされた強化リリースであるElements v23.3.4を出荷しました。この報告書の目的は、何が起こったのか、そしてBlockstreamとLiquid Networkがこの前例のない攻撃にどのように対応したのかを概説することです。セクション2: Liquidアーキテクチャとセキュリティ不変量Liquidは、Blockstreamによって開発されたオープンソースブロックチェーンプラットフォームであるElements上に構築された、本番環境のBitcoinサイドチェーンです。Liquidは、独自のチェーンパラメータ、コンセンサス構成、およびアクティブなフェデレーションを備えたElements Coreを実行し、15の地理的に分散された機能ノードによって運用されています。ブロックを受け入れるには、少なくとも15の機能ノードのうち11の署数が必要です。9月6日のセキュリティインシデントとその影響を理解するために、特に3つのアーキテクチャ上の特性が重要です。1) 1:1 BTCの裏付け。ペッグインを通じてBitcoinチェーンにロックされたBTCは、Liquidで発行されたLBTCと1:1で対応します。BTCは、対応するLBTCのバーンに対するペッグアウト時にのみリリースされます。これは、対応する、証明可能な有効なトランザクションなしにLBTCが作成されないことをコンセンサスが正しく検証することに完全に依存しています。ペッグアウト時には、個別のオフチェーンリザーブチェックはありません。ペッグアウトメカニズムは、サイドチェーン自身の検証済み状態に依存します。2) 機密取引とrangeproof検証。Liquidは、Pedersenコミットメントを使用してトランザクションの金額と資産タイプをブラインドします。各機密出力に添付されたゼロ知識rangeproofは、値を明らかにすることなく、コミットされた値が有効な範囲内にあることを証明し、surjection proofは出力の資産ジェネレーターを有効な入力資産に結び付けます。それ自体では、rangeproofは値が範囲内にあることしか証明しません。コンセンサスルールは、それをトランザクションの資産ジェネレーターとscriptPubKeyと組み合わせるため、その証明はその正確な出力、その正確な場所でのみ意味があります。Elementsは、これらの計算負荷の高いチェックの結果をキャッシュし、mempoolおよびブロック検証全体で同一の証明の再検証を回避します。3) PAKベースのペッグアウト承認。Liquid Federation Member CharterおよびPAK Entry Creation Instructionsによると、各PAKエントリには2つのキーがあります。各キーは異なる役割を果たします。A) オフラインキー。これは、メンバーのコールドウォレットから派生したBitcoin拡張公開鍵（xpub）です。これにより、機能ノードのHSMは、ウォレットの秘密鍵を必要とせずに、ペッグアウト先が登録済みのPAKエントリに属していることを検証できます。ペッグアウトの進行は、このキーから派生した受信アドレスに行われます。Charterは、メンバーに「ビットコイン受信ウォレットをオフラインで安全に保管する」よう指示しています。これにより、攻撃者が他の防御を突破した場合でも、ビットコインの裏付けが安全に保たれます。これは、資金をコールドストレージから取り出して移動させるために、手動での操作が必要です。この遅延により、Federationは問題を発見し、BTCがアクセス可能な管理下から離れる前に対応するためのウィンドウが得られます。B) オンラインキー。これはsecp256k1キーです。その秘密鍵部分は、実行中のElementsノード内のノードのペッグアウトウォレットに存在します。ペッグアウトリクエストに署名するため、オンライン状態を維持します。つまり、PAK承認は2つのことを行います。BTCがどこに行くかを制御し（オフラインキー）、誰がBTCの送信を要求できるかを制御します（オンラインキー）。オフラインキーは、アップストリーム障害に対するセーフティネットとして存在します。例えば、コンセンサス検証が誤って不正なLBTCを受け入れた場合、実際にオフラインの受信ウォレットは、その後リリースされたBTCを保持します。セクション3: 脆弱性分析2つの異なる問題が、攻撃者がLiquidからBTCを盗むことを可能にしました。（1）Elementsにおけるコンセンサスの脆弱性（以下、バグAおよびBとして説明）、および（2）あるメンバーのPAK署名プロセスが構成されていた方法のギャップです。両方について以下で詳しく説明します。バグAおよびBバグAは、2018年4月のコミットに由来し、Elements PR #335に含まれ、2018年5月30日にElements v0.14.1でマージされました。この変更により、rangeproofキャッシュのキーが簡略化され、資産コミットメントまたはscriptPubKeyが含まれなくなりました。これは、キャッシュされた結果がrangeproofを検証するために使用されたすべてのコンテキストにバインドされていなかったことを意味します。これは重大なコンセンサスバグでした。適切な条件下では、ノードは以前にキャッシュされた結果を再利用し、実際には無効なコンテキストでrangeproofを受け入れることができましたが、そのキャッシュ結果を持たない別のノードは同じトランザクションを拒否しました。コンセンサスでは、ノードがブロックを検証する際に同じ結果に到達する必要があるため、この違いはネットワークの分割を引き起こし、通常のブロック生成を中断または停止させる可能性があります。rangeproofキャッシュキーはSHA256(nonce ‖ rangeproof ‖ value_commitment)として計算され、資産コミットメントとscriptPubKeyは省略されていましたが、両方とも基になるrangeproof検証の一部でした。その結果、一度（rangeproof、value commitment）のペアが正常にキャッシュされると、ノードはrangeproof検証を再度実行することなく、異なる資産コミットメントまたはスクリプトが提示された場合に同じペアを既に有効であると見なすことができました。したがって、そのキャッシュエントリを持つノードは、コールドキャッシュを持つノードが拒否するトランザクションを受け入れることができ、チェーンの分割またはブロック生成の停滞を引き起こす可能性のあるコンセンサスマッチングを引き起こしました。この欠陥は2018年に導入され、基になるキャッシュキー設計は、2019年のリファクタリング中に後続のConfidential Assets検証実装に引き継がれました。その後、関連する動作は2026年まで実質的に変更されませんでした。この種の欠陥の微妙さと深く埋め込まれた性質は、業界でよく認識されています。広範なブロックチェーンエコシステム全体で、暗号およびコンセンサスコードにおける潜在的な脆弱性は、徹底的に監査されたプロジェクトであっても、同等の期間検出されないまま存続しています。セキュリティレビューは、性質上、新しいコードまたは変更されたコードに最も密接に焦点を当てます。過去のレビューを通過し、インシデントなしで運用されてきた安定した長期間実行されているコードは、標準的な監査フレームワークでは低リスク層を占めます。これは、広く受け入れられているソフトウェアセキュリティプラクティスと一致する優先順位付けアプローチです。AI支援分析ツールの出現は、変化を開始しています。