Liquid Networkセキュリティインシデントの報告

読者への注記：本レポートの情報は公開日時点のものであり、調査の進展に応じて更新される場合があります。技術的な記述は、社内外の文書、裏付け資料、オンチェーン分析に基づいています。調査期間を通じて緊密に連携いただいたLiquid Federation Board、functionaryノード運用者、ならびに精査と支援をいただいたビットコイン開発コミュニティに感謝します。

目次

1. エグゼクティブサマリー
2. Liquidのアーキテクチャとセキュリティ不変条件
3. 脆弱性の分析
4. インシデントのタイムライン
5. 緩和策、修正、復旧
6. 教訓と是正措置
7. 謝辞

セクション1：エグゼクティブサマリー

2026年9月6日13:53 UTC（Liquidブロック4,050,336）、攻撃者はElementsのrangeproof検証キャッシュにある脆弱性を悪用しました。これにより、出力値が入力によって裏付けられていない単一トランザクションが検証を通過しました。Federationのfunctionaryノードを含むLiquidノードはこのトランザクションを受理し、裏付けとなるビットコインのない約4,000 LBTCが供給量に追加されました。

攻撃者は、Peg-out Authorization Key（PAK）を持つFederationメンバーであるSideSwapを経由して、裏付けのないLBTCをLiquidの通常のペグアウト処理へ移しました。これにより、ビットコインブロック965,783で確定した約4,000 BTCの出金が生じました。ネットワーク停止前に確定した小規模なペグアウトもあり、Liquidの準備金は約4,205 BTCから197 BTCへ減少しました。

USDt、DePix、その他のトークン化資産を含む、Liquidで発行された他のすべての資産はこのインシデントの影響を受けませんでしたが、ネットワーク停止中は利用できませんでした。

攻撃者は、インシデントから数時間以内にオンチェーンで身元を示し、複数回の交渉の後、3,400 BTCを返還しました（9月7日16:09 UTC、ビットコインブロック965,950）。約602 BTCは未返還です。

Blockstreamは攻撃直後、Liquidのブリッジノード（ユーザーが接続する公開ノード）の停止を調整し、数時間以内に緊急の暫定パッチを導入しました。数日以内には、完全なレビューを経た強化版リリースElements v23.3.4を提供しました。

本レポートは、何が起きたか、そしてBlockstreamとLiquid Networkがこの前例のない攻撃にどう対応したかを説明するものです。

セクション2：Liquidのアーキテクチャとセキュリティ不変条件

Liquidは、Blockstreamが開発したオープンソースのブロックチェーンプラットフォームElements上に構築された、本番運用中のビットコインサイドチェーンです。Liquidは独自のチェーンパラメーター、コンセンサス設定、アクティブなFederationを持つElements Coreを稼働させ、地理的に分散された15台のfunctionaryノードにより運用されています。ネットワークがブロックを受理するには、15台中少なくとも11台のfunctionaryノードによる署名が必要です。

9月6日のセキュリティインシデントとその影響を理解するうえで、次の3つのアーキテクチャ特性が特に重要です。

1）1:1のBTC裏付け。ペグインによってビットコインチェーン上でロックされたBTCには、Liquid上で1:1のLBTC発行が対応します。BTCは、対応するLBTCのバーンに対してのみペグアウトで放出されます。これは、対応し証明可能に有効なトランザクションなしにLBTCが作成されないことをコンセンサスが正しく検証することに全面的に依存します。ペグアウト時に別個のオフチェーン準備金照合はなく、ペグアウト機構はサイドチェーン自身の検証済み状態に依存します。

2）Confidential Transactionsとrangeproof検証。LiquidはPedersenコミットメントを使い、トランザクションの金額と資産種別を秘匿します。各秘匿出力に付随するゼロ知識rangeproofは、値を開示せずにコミットされた値が有効範囲にあることを証明します。surjection proofは出力の資産ジェネレーターを有効な入力資産に結び付けます。rangeproof単体は値が範囲内であることしか証明しません。コンセンサス規則はこれをトランザクションの資産ジェネレーターおよびscriptPubKeyと組み合わせるため、証明はその正確な場所にある正確な出力についてのみ意味を持ちます。Elementsは、mempoolとブロック検証で同一の証明を再検証しないよう、これらの高コストな検査結果をキャッシュします。

3）PAKに基づくペグアウト認可。Liquid Federation Member CharterおよびPAK Entry Creation Instructionsに従い、各PAKエントリーには2つの鍵があります。両者の役割は異なります。

• A）オフライン鍵。メンバーのコールドウォレットから導出されたビットコイン拡張公開鍵（xpub）です。ウォレットの秘密鍵を必要とせずに、functionaryノードのHSMがペグアウト先が登録済みPAKエントリーに属することを検証できます。ペグアウトの受取先はこの鍵から導出されます。Charterはメンバーに「ビットコイン受取ウォレットをオフラインかつ安全に保つ」よう指示しています。これは他の防御を突破されても、LBTCを裏付けるビットコインを保護します。
• B）オンライン鍵。secp256k1鍵です。その秘密部分は稼働中のElementsノードのペグアウトウォレットにあり、ペグアウト要求に署名するためオンラインに保たれます。

つまりPAK認可は、BTCをどこへ送れるかをオフライン鍵で、BTCの送付を誰が要求できるかをオンライン鍵で制御します。

オフライン鍵は上流障害への安全網です。たとえばコンセンサス検証が誤って不正なLBTCを受理しても、真にオフラインの受取ウォレットには放出されたBTCが残ります。コールドストレージから資金を手動で取り出して動かす必要があるため時間がかかり、FederationはBTCが到達可能なカストディから離れる前に問題を検知し行動する時間を得られます。

セクション3：脆弱性の分析

攻撃者がLiquidからBTCを奪うことを可能にした問題は2つありました。（1）Elementsのコンセンサス脆弱性（以下、Bug AおよびBug B）と、（2）あるメンバーのPAK署名プロセスの設定上のギャップです。

Bug AおよびBug B。Bug Aは、Elements PR #335に含まれ、Elements v0.14.1で2018年5月30日にマージされた2018年4月のコミットに由来します。この変更によりrangeproofキャッシュキーからasset commitmentとscriptPubKeyが除外され、キャッシュ結果はrangeproof検証に用いるすべての文脈に束縛されなくなりました。

これは重大なコンセンサスバグでした。適切な条件下では、あるノードは以前にキャッシュされた結果を再利用して、実際には有効でない文脈でrangeproofを受理できます。一方、当該キャッシュ結果のない別のノードは同じトランザクションを拒否します。コンセンサスではブロック検証時にノードが同じ結果へ到達する必要があるため、この差異はネットワーク分断を引き起こし、通常のブロック生成を妨げたり停止させたりする可能性があります。

rangeproofキャッシュキーはSHA256(nonce ‖ rangeproof ‖ value_commitment)として計算され、基礎となるrangeproof検証の一部であるasset commitmentおよびscriptPubKeyが除外されていました。その結果、(rangeproof, value commitment)の組が一度正常にキャッシュされると、異なるasset commitmentまたはスクリプトで同じ組が提示された場合も、ノードはrangeproof検証を再実行せず、すでに有効であると扱うことができました。したがって、このキャッシュエントリーを持つノードは、コールドキャッシュのノードなら拒否するトランザクションを受理でき、チェーン分断またはブロック生成停止につながるコンセンサス不一致を生み得ました。

欠陥は2018年に導入され、そのキャッシュキー設計は2019年のリファクタリングで後のConfidential Assets検証実装にも引き継がれました。その後、関連する動作は2026年まで実質的に変わりませんでした。暗号およびコンセンサスコードの深く埋め込まれた欠陥は、厳重に監査されたプロジェクトでも長期間未検出で残り得ます。セキュリティレビューは本質的に新規または変更中のコードへ最も注意を向け、安定して長期間稼働してきたコードは標準的な監査枠組みでは低リスク層となります。AI支援分析ツールは、大規模コードベースの探索、履歴変更の比較、悪用経路の試験を従来の手作業だけより効率的に行えるようにし始めています。BlockstreamとLiquid Networkは、本件を踏まえて継続的なレビューへこれらの能力を取り込み続けています。

Bug A：開示、検証、是正。外部研究者は2026年8月2日、同日に2つの修正案を報告しました。1つは直接のバイト連結、もう1つはより包括的な長さプレフィックス付きシリアライズです。8月3日にBlockstreamは直接バイト連結でキャッシュキーを拡張する社内修正を開始し、同日にブリッジノードとテストネットのブリッジノードへ展開しました。8月4日にはBlockstream Liquidチームが追加のAI支援レビュー（Kimi-K3）を行い、8月5日にはLiquid testnet上でキャッシュ汚染トランザクションに対して修正を検証しました。この試験はBug Aを解消したものの、当時未知だったBug Bのバイト境界条件は検査対象ではありませんでした。8月7日には外部セキュリティレビューが、動作する概念実証と直接バイト連結の方法を独自に特定しました。

外部研究者の報告、Blockstreamの社内レビュー、Bitcoin Red Teamとの独立した外部レビューという3つの検証は、5日以内に同じ根本原因へ到達しました。外部研究者stutxoは、欠落フィールドを追加する直接連結方式と、フィールド間をより強く分離する長さプレフィックス付きシリアライズ方式を提案しました。Blockstreamは報告された脆弱性に対する適切な是正として直接連結方式を選択しました。8月11日までに15台中13台のfunctionaryノードが更新を稼働し、残りもその後に追随しました。Blockstreamは9月1日、修正を公開し、9月3日には外部報告とその是正を追跡する社内項目を解決済みにしました。

Bug B：根本原因と展開前レビュー。Bug Aを閉じた修正はasset commitmentとscriptPubKeyをキャッシュキーへ加えました。欠陥は追加したフィールドではなく、結合方法にありました。

この実装は、長さプレフィックスも区切り文字もなく、各フィールドの生バイトを順にハッシュへ書き込みます。これがBug Bです。value commitmentとasset commitmentはそれぞれ33バイトで固定ですが、rangeproofとscriptPubKeyは長さが可変です。rangeproofには長さを符号化する埋め込みヘッダーがありますが、その確認はrangeproof検証の一部であり、検証キャッシュはその検証を省略するため、キャッシュから見ればrangeproofは区切りのないバイト列として機能しました。攻撃者はrangeproofを切り詰めまたは延長し、補償するようscriptPubKeyを調整して、検証キャッシュが有効と主張する不正なrangeproofを持つトランザクションを作れました。

Bitcoin Coreの一見類似したコードは、可変長の公開鍵と可変長の署名を連結して署名有効性をキャッシュしますが、これらのオブジェクトの埋め込み長さプレフィックスは検証キャッシュを呼ぶ前に確認されるため脆弱ではありません。実際には攻撃者は、すでに検証済みで正当にキャッシュされたトランザクションと同じasset commitment、および同じ宛先スクリプトの最後の1バイトを使いました。攻撃者の「長いproof＋変更したvalue commitment＋再利用したasset commitment＋短いscript」というバイト列は、基となる証明とコミットメント値が異なるにもかかわらず、元のキャッシュエントリーと1バイト単位で同じになりました。キャッシュヒットは検証を完全に省略するため、偽造されたrangeproofは実際に検証を通る必要がなく、対応するバイト列を作るだけで済みました。

内部・外部を問わず、悪用前にこのリスクを特定したレビューアはいませんでした。社内QAサイクルのAI支援コードレビュー、testnetでの機能試験、PremAI経由で当時利用できたKimi-K3を使う補助的で独立したAI支援スキャンはいずれも、Bug Bがすでに存在するコードを検査しました。しかし各検証は既知のBug Aに対する修正を対象としており、バイト境界衝突モードは誰にも特定されていなかったため、検出されませんでした。

悪用の仕組みと伝播。攻撃者のトランザクション（txid f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f）は9月6日13:53 UTC、Liquidブロック4,050,336で確定しました。これは入力に実際には裏付けられない秘匿出力を作成しました。rangeproof検査はまさにこれを防ぐためにあり、Bug Bにより検証を通過しました。各ノードが経験した結果は、その瞬間のキャッシュ内容に依存しました。15台のfunctionaryはこの時点で同じ固定ビルドを稼働していましたが、以前の正当な検証エントリーを持つノードだけがブロックを受理し、コールドキャッシュのノードまたはBug Aが残るノードは実際の検査を行って拒否しました。

約4,000 LBTCが受理済みチェーン状態へ入ると、他のすべてのノードにとって本物のLBTCと区別できませんでした。Confidential Transactionsは金額と資産種別を秘匿しますが、アドレスやトランザクショングラフは秘匿しません。後からチェーンを合理的に確認できても、当時は目視検査だけで異常を検出できませんでした。裏付けのないLBTCはSideSwapが処理するペグアウト要求に入り、元のトランザクションから約36分後の14:28 UTCにビットコイン上で確定しました。元の不正出力2件と追跡された子孫4件に基づく下流トランザクションは、後述の復旧中に正規チェーン状態から除去されました。

SideSwapのPAKとペグアウト制御。SideSwapはPAKエントリーを持つLiquid Federationメンバーであり、サイドチェーンから事前登録済みのビットコインアドレスへLBTCを移せます。SideSwapのPAK自体は侵害、偽造、窃取されていません。ペグアウトが完了したのは、ペグアウト要求を評価する前にSideSwapのノードとFederationのfunctionaryノードが裏付けのないLBTCを有効と受理していたためです。PAK機構は、コンセンサスが誤って本物と受理したLBTCに対する実在の署名要求を認証しました。

インシデント後、SideSwapは声明を公表し、影響を与えたペグアウトサービス上の2つの運用上の選択を説明しました。第一に、Federation Charterがオフライン保管を求めるペグアウト署名鍵をオンラインに保持し、ペグアウトと同じビットコインブロック内で要求した顧客へ自動転送していたことを認めました。第二に、ペグアウト注文にサイズ上限、速度制御、ウォレット履歴確認がなく、発行済み供給の大きな割合に当たる約4,000 LBTCの注文が人手の確認なしに通過しました。

セクション4：インシデントのタイムライン

時刻はUTCです。オンチェーン事象では利用可能な場合に確定ブロックのタイムスタンプを使用します。社内運用事象はBlockstreamの記録、公開更新は更新に記された「Status as of」時刻（未記載の場合は公開時刻）を使います。9月6日14:00および14:05の項目はSideSwapが公開したインシデントタイムラインに基づきます。

セクション5：緩和策、修正、復旧

即時封じ込め（2026年9月6日）。Blockstreamは18:26 UTCにLiquidブリッジノードをオフラインにすることを調整し、ペグアウトを含むさらなるトランザクション確定を停止しました。同時に取引所へLBTCの入出金を停止するよう通知しました。これらの措置によりインシデントを封じ込め、さらなる不正な資金移動を防ぎました。

緊急パッチ（2026年9月7日01:09 UTC）。Blockstreamは完全版23.3.4リリースに先立ち、特定された脆弱性経路を閉じる修正をブリッジノードへ展開・調整しました。

Bug Bの根本原因修正（2026年9月8日マージ、9月9日にv23.3.4としてリリース）：commit 9400096（Elements PR #1600）は、range-proofおよびsurjection-proofキャッシュのハッシャーを、生のCSHA256連結からCHashWriter（SER_GETHASH）へ切り替えます。各フィールドは長さプレフィックス付きでシリアライズされるため、生の連結が同じバイト列になる異なる引数組が、同じキャッシュキーへ衝突することはありません。

可変長の2フィールドだけでなく全4フィールドへ長さプレフィックスを加えることで、現在固定長のフィールドが将来可変長になった場合や内部長さプレフィックスの検証が変わった場合も、周辺文脈にかかわらず正しさを維持します。CHashWriter（SER_GETHASH）ではすべてのフィールドのバイト列の前に明示的な長さマーカーがあり、どのバイト列も2通りに読めません。異なる(proof, commitment, asset_commitment, scriptPubKey)入力が同じシリアライズストリームを作ることはありません。修正は、運用者が必要に応じてキャッシュを完全に無効化できる-norangeproofcache起動オプションも追加します。

チェーン復旧。本件はキャッシュ脆弱性に依存していたため、Blockstreamはrangeproofキャッシュを使わず影響チェーンを再生・検証して不正なインフレーションを特定できました。キャッシュを無効化すると、ElementsはBug AまたはBug Bに依存するトランザクションを、以前のキャッシュ結果を再利用せず正しく拒否しました。チームはrust-elementsで独立して結果を照合しました。オンチェーンレビューは元の不正出力2件と子孫4件を特定し、現在のLiquidチェーンにBug AまたはBug Bによるインフレーションが残らないことを検証しました。

Blockstreamは並行して試験した段階的復旧を実施しています。1）ペグアウト操作を停止したままブロック生成を再開する。2）独立して有効と検証されたトランザクションを再生する。3）ネットワーク状態が完全に復元された後にペグ操作を再開する。

準備金会計。Liquid準備金は不正トランザクションと、インシデント時点ですでに進行中だった通常のペグアウトの影響を受けました。不正トランザクションに起因する金額のうち3,400 BTCは返還済みで、約602 BTCは継続中の回収努力の対象です。直近の公開更新（2026年9月17日21:05 UTC）時点で、復旧計画は引き続き能動的に試験され、改訂される可能性があります。各段階は独立して安全と判断されるまで進められません。

セクション6：教訓と是正措置

Blockstreamは最初の報告から24時間以内にBug Aを受理、トリアージ、是正し、1週間以内にさらに2つの経路で独立確認しました。見逃された報告、無視された警告、侵害された鍵はありませんでした。それでもBlockstreamはエンジニアリングとセキュリティのプロセスを包括的にレビューしました。

1）コンセンサスに重要な問題の是正選択。長さプレフィックス付きシリアライズを用いる、より包括的な第2の修正は、結合されるフィールドをより強く分離します。今後はコンセンサスに重要な問題で複数の是正策がある場合、より広い変更を必要とする場合でも、最も強い構造的安全保証を提供する方法を既定とします。この既定から外れるには根拠と承認が必要です。また本番コンセンサスソフトウェアに影響する重要な修正について、リリース前に独立したセキュリティ監査人のレビューを求めます。

2）コンセンサスに重要なコードの継続的レビュー。リリースブランチへマージされる変更はセキュリティスキャンを起動し、重要なコンセンサスコードは最近変更されていなくても継続的レビューを受けます。エンジニアリングチームは、変更または所見が必要とする場合に補助的AIスキャンを委託できる恒常的なリソースも持ちます。

3）敵対的テスト能力。Blockstreamはrangeproofキャッシュ衝突を過去チェーンデータとmempoolから検索するツール、および以前のキャッシュ結果に依存せず検証するゼロキャッシュ再検証ツールを開発しました。これらを恒久化し、手作業・AI支援技法による内部red-team能力、fuzz testing、mutation testing、symbolic execution、該当する場合の形式検証、異常なトランザクション活動のオンチェーン監視を強化します。

4）文脈依存の証明について、文脈を再導出せず裸の検証結果をキャッシュすること自体が脆弱なパターンです。正しいキー構築は本件を閉じますが、文脈を再導出せずキャッシュされたbooleanを信頼する基礎パターンにはリスクが残ります。Blockstreamは、文脈依存キャッシュにバージョン付きスキーマタグと、検索時の必須文脈再確認を持たせる多層防御を実装します。

5）外部研究者の役割。重要なオープンソース基盤には、脆弱性が悪用される前に責任を持って報告する明確な経路が必要です。BlockstreamはElementsおよび保守する他の重要オープンソース基盤向けに、構造化されたインセンティブ、定義済みの対象範囲、善意のセキュリティ研究に対する明確なセーフハーバー保護を備えた専用バグバウンティプログラムを設立します。

Federationのガバナンスと運用レビュー。Liquid Federation BoardとBlockstreamは、ガバナンス、セキュリティ、運用面のより広い変更をレビューしています。この作業はインシデント前から進められ、過去のLiquid Summitでも議論されたガバナンス近代化を基礎とします。Liquid Federationは正式採択に応じて更新を提供します。

セクション7：謝辞

本インシデントとその対応には、Blockstream以外の多くの人々が貢献しました。セキュリティメールボックスを通じて最初にBug Aを報告し、調査に必要な情報を提供した外部研究者stutxoに感謝します。このような責任ある開示はオープンソース基盤のセキュリティに不可欠であり、適切な経路を通じて報告するという同氏の判断は、セキュリティ研究コミュニティの最高水準を示すものです。また、独立レビューで問題を確認し、コードベースを改善する追加の所見を特定したBitcoin Red Team、ならびにElements v23.3.4のリリース前に複数回の精査を支援したAlpen Labsなどの独立レビューアにも感謝します。

脆弱性を当初悪用した個人への注記。システムの欠陥を特定したことは認識しています。あなたの行動が永続的な損害を与えるためではなく弱点を明らかにする意図によるものだったなら、未返還のBTCを返却するよう求めます。脆弱性が責任を持って明らかにされるとき、Liquid Networkのセキュリティは強化されます。Blockstreamは善意で行動する研究者と発見者が認められるよう尽力します。

自身の役割と自発的に特定・開示した運用上の問題について詳細で透明性のある説明を提供したSideSwapに感謝します。その透明性は本レポートの正確性を高め、将来の取り組みに直接反映されています。封じ込め、パッチ展開、継続中の復旧で迅速に連携したLiquid Federationとfunctionaryノード運用者、ガバナンスとセキュリティレビューで協力を続けるLiquid Federation Board、そしてこの困難な期間に辛抱強く精査し関与を続けたLiquidおよびビットコインの開発コミュニティに感謝します。

BlockstreamはLiquid Networkのセキュリティと、本レポートが目指す透明性に引き続き取り組みます。復旧の進展とセクション6の是正措置の正式採択に応じて、技術的な更新を公開します。

技術的な質問、要望、またはセキュリティ上の懸念の報告先：security@blockstream.com

原文：Liquid Network Security Incident Assessment