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

Liquidネットワークセキュリティインシデント評価

読者への注意: 本レポートに含まれる情報は、公開日現在のものであり、調査の進展に伴い更新される可能性があります。技術的な主張は、内部および外部の文書、支援資料、オンチェーン分析に基づいています。調査中、緊密に連携していただいたLiquid Federation Boardおよびファンクショナリノードオペレーター、そしてその精査と支援を提供してくださった広範なBitcoin開発コミュニティに感謝いたします。

目次

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

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

2026年9月6日 13:53 UTC（Liquidブロック 4,050,336）に、攻撃者はElementsのレンジプルーフ検証キャッシュにおける脆弱性を悪用し、単一のトランザクションが、その出力値が入力値によって裏付けられていないにもかかわらず、検証を通過することを可能にしました。Liquidノード（ファンクショナリノードを含む）はこのトランザクションを受け入れました。これにより、LBTCの供給量が約4,000 LBTCにまでインフレしましたが、その裏付けとなるBitcoinはありませんでした。

攻撃者はその後、Peg-out Authorization Key（PAK）を保有するFederationメンバーであるSideSwapを経由して、Liquidの標準的なペッグアウトプロセスを通じて、裏付けのないLBTCを移動させました。これにより、Bitcoinブロック 965,783で確認された約4,000 BTCの引き出しが発生しました。ネットワークが停止される前に確認された少額のペッグアウトにより、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ネットワークがこの前例のない攻撃にどのように対応したのかを概説することです。

セクション 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) 機密取引とレンジプルーフ検証。 Liquidは、Pedersenコミットメントを使用してトランザクションの金額と資産タイプをブラインドします。各機密出力に添付されたゼロ知識レンジプルーフは、値を明らかにすることなく、コミットされた値が有効な範囲内にあることを証明し、サージョン証明（surjection proof）は出力の資産ジェネレータを有効な入力資産に紐付けます。レンジプルーフ単体では、値が範囲内にあることしか証明しません。コンセンサスルールは、それをトランザクションの資産ジェネレータとscriptPubKeyと組み合わせて、プルーフがその正確な出力、その正確な場所でのみ意味を持つようにします。Elementsは、これらの計算負荷の高いチェックの結果をキャッシュし、メモリプールとブロック検証全体での同一プルーフの再検証を回避します。

3) PAKベースのペッグアウト認証。 Liquid Federation Member CharterおよびPAKエントリー作成手順に従い、各PAKエントリーには2つのキーがあります。各キーは異なる役割を果たします。

• オフラインキー。 これは、メンバーのコールドウォレットから派生したBitcoin拡張公開鍵（xpub）です。これにより、ファンクショナリノードのHSMは、ウォレットの秘密鍵を必要とせずに、ペッグアウト先が登録済みのPAKエントリーに属していることを検証できます。ペッグアウトの進捗は、このキーから派生した受信アドレスに向かいます。チャーターは、メンバーに「Bitcoin受信ウォレットをオフラインかつ安全に保つ」よう指示しています。これにより、攻撃者が他の防御を突破した場合でも、LBTCを裏付けるBitcoinは安全に保たれます。
• オンラインキー。 これはsecp256k1キーです。その秘密鍵の半分は、実行中のElementsノード内のノードのペッグアウトウォレットに存在します。ペッグアウトリクエストに署名するため、オンライン状態を維持します。

言い換えれば、PAK認証は2つのことを行います。それは、BTCがどこに行けるかを制御し（オフラインキー）、BTCの送信を誰が要求できるかを制御します（オンラインキー）。

オフラインキーは、アップストリーム障害に対するセーフティネットとして存在します。例えば、コンセンサス検証が誤って不正なLBTCを受け入れた場合でも、真にオフラインの受信ウォレットが後続の解放されたBTCを保持します。誰かが手動でコールドストレージから資金を取得し、移動させる必要があります。この遅延により、BTCが到達可能な管理下を離れる前に、フェデレーションが問題を発見し、行動を起こすためのウィンドウが与えられます。

セクション 3: 脆弱性分析

攻撃者がLiquidからBTCを盗むことを可能にしたのは、2つの異なる問題でした。(1) Elementsにおけるコンセンサスの脆弱性（以下、Bug AおよびBとして説明）、および(2) あるメンバーのPAK署名プロセス構成におけるギャップ。両方について以下で詳しく説明します。

Bug A & B

Bug Aは、2018年4月のコミットに由来し、Elements PR #335に含まれ、2018年5月30日にElements v0.14.1でマージされました。この変更により、レンジプルーフキャッシュのキーが簡略化され、アセットコミットメントまたはscriptPubKeyが含まれなくなりました。これは、キャッシュされた結果がレンジプルーフ検証に使用されるすべてのコンテキストにバインドされていないことを意味します。

これは重大なコンセンサスバグでした。適切な条件下では、あるノードが以前にキャッシュされた結果を再利用し、実際には有効ではないコンテキストでレンジプルーフを受け入れる可能性がありましたが、そのキャッシュ結果を持たない別のノードは同じトランザクションを拒否しました。コンセンサスは、ブロックを検証する際にノードが同じ結果に到達することを要求するため、この違いはネットワークの分割を引き起こし、通常のブロック生成を中断または停止させる可能性がありました。

レンジプルーフキャッシュキーは SHA256(nonce ‖ rangeproof ‖ value_commitment) として計算され、アセットコミットメントとscriptPubKeyは省略されていました。これらはレンジプルーフ検証の基盤となる部分でしたが、省略されていました。その結果、(rangeproof, value commitment)のペアが一度キャッシュされると、ノードは異なるアセットコミットメントまたはスクリプトが提示された場合でも、レンジプルーフ検証を再度実行することなく、同じペアを既に有効であると見なすことができました。そのキャッシュエントリを持つノードは、コールドキャッシュを持つノードが拒否するトランザクションを受け入れることができたため、チェーンの分割やブロック生成の停止を引き起こす可能性のあるコンセンサス不一致が発生しました。

この欠陥は2018年に導入され、基盤となるキャッシュキー設計は、2019年のリファクタリング中に後続の機密資産検証実装に引き継がれました。その後、この関連する動作は2026年まで実質的に変更されませんでした。

この種の欠陥の微妙さと深く埋め込まれた性質は、業界でよく認識されています。より広範なブロックチェーンエコシステム全体で、暗号化およびコンセンサスコードにおける潜在的な脆弱性は、十分に監査されたプロジェクトであっても、同等の期間検出されずに存続しています。セキュリティレビューは、その性質上、新しく変更されたコードに最も密接に焦点を当てます。過去のレビューを通過し、インシデントなく運用されてきた安定した長期間実行されているコードは、標準的な監査フレームワークにおいて低リスクティアを占めます。これは広く受け入れられているソフトウェアセキュリティプラクティスに沿った優先順位付けアプローチです。

AI支援分析ツールの出現は、レガシーコードベースのレビューの状況を変え始めています。これらのツールは、大規模なコードベースを検索し、過去の変更を比較し、従来の人的レビューだけでは不可能なほど効率的に潜在的なエクスプロイトパスをテストできます。このインシデントを踏まえ、BlockstreamとLiquidネットワークは、これらの機能を継続的なレビュープログラムに組み込み続けています（セクション6を参照）。

Bug A: 開示、検証、および修正

3つの別々のレビュー（外部研究者のレポート、Blockstreamの内部レビュー、およびBitcoin Red Teamとの別の外部契約）が5日以内に同じ根本原因に到達しました。これにより、BlockstreamはBug Aが現実的かつ深刻であることを強く確認できました。修正作業は、最初の報告から1日以内に開始されました。

外部研究者（stutxo）は、問題の解決策として2つの方法を提案しました。1つ目は、欠落フィールドをキャッシュキーに追加する直接連結アプローチでした。2つ目は、長さプレフィックス付きシリアライゼーションを使用した、より広範なアプローチであり、各フィールド間のより強力な分離を提供しました。

Blockstreamは2026年8月3日に、直接連結アプローチを使用した内部修正をオープンしました。当面の目標は、アセットコミットメントとscriptPubkeyをキャッシュキーに追加することでBug Aを修正することでした。この修正は同日、Liquidのブリッジノードに展開され、ファンクショナリに対する即時の保護を提供しました。ほとんどのトランザクションは、ブロック生成ノードに到達する前にブリッジノードを通過します。

この修正は、Blockstreamの標準QAプロセスの一部として、手動エンジニアリングレビューと別途AI支援レビューを受けました。これらのレビューにより、正しいフィールドが追加されたことが確認され、それは正確でした。後にBug Bとなったバイトレベルの組み合わせ問題は、別個の独立した脆弱性クラスであり、外部研究者自身の分析を含む、3つの独立したレビューストリームのいずれによってもフラグが立てられませんでした。

外部研究者のより広範なシリアライゼーション修正は、非本番ブランチを対象としていました。Blockstreamのエンジニアリングチームは両方のアプローチを評価し、報告された脆弱性に対する適切な修正として直接連結方法を選択しました。長さプレフィックス付きアプローチは、修正対象の特定の欠陥の範囲を超えた、より広範なシリアライゼーションパターンに対処していました。どちらのアプローチも、報告された問題に対する合理的なエンジニアリング上の選択でした。後にBug Bとして表面化したバイト境界脆弱性は、当時どのレビューアによっても特定されなかった別の欠陥でした。

テストとレビューは並行して継続されました。8月4日から、Blockstreamは通常のQAサイクルを超えてElementsブランチをスキャンするために、追加のサードパーティAI支援レビュー能力を展開しました。その結果もエンジニアによって手動でレビューされました。その作業は非本番ブランチで最初に到達しましたが、そのブランチには既に本番にデプロイされた修正と同じ直接連結アプローチが含まれていました。バイト境界欠陥（Bug B）は既にレビュー中のコードに潜んでいましたが、AIスキャンもそれに付随する人的レビューもそれを特定しませんでした。これは、外部研究者を含む他のどのレビューアもこの脆弱性クラスを特定しなかったという事実と一致しています。

8月5日、Blockstreamは別途、Bug Aを再現するように設計されたキャッシュポイズニングトランザクションを使用して、Liquidテストネットで修正をテストしました。修正は攻撃を正しく拒否し、Bug Aによって引き起こされたウォーム/コールドキャッシュのコンセンサス分割を解決しました。テストは、既知の脆弱性に対して修正を検証するように設計されていました。Bug Bを構成するバイト境界衝突モードは、どの当事者によっても特定されておらず、したがってテストの範囲外でした。

これらのチェックが完了するにつれて、デプロイメントは継続されました。8月11日までに、15のファンクショナリノードのうち13がアップデートを実行しており、残りのノードもそれに続きました。

Blockstreamは2026年9月1日に、Elementsリポジトリで修正を公開しました。9月3日、外部レポートとその修正を追跡するすべての内部項目（この修正を含む）は解決済みとしてマークされました。

Bug B: 根本原因とデプロイ前レビュー

Bug Aをクローズした修正は、アセットコミットメントとscriptPubKeyを含めるようにキャッシュキーを拡張しました。欠陥は、どのフィールドが追加されたかではなく、それらがどのように結合されたかにありました。

［画像］

コミット 212c43fからのGit diff。

これは、長さプレフィックスや区切り文字なしに、各フィールドの生のバイトを順番にハッシュに書き込みます。これがBug Bです。

これらのフィールドのうち2つ（値コミットメントとアセットコミットメント）はそれぞれ33バイトで固定されています。他の2つ（レンジプルーフとscriptPubKey）は長さが可変です。レンジプルーフには長さがエンコードされたヘッダーが埋め込まれていますが、scriptPubKeyは最後のフィールドとしてエンコードされていたため、他のすべてのフィールドが長さプレフィックス付きであれば長さプレフィックスは不要でした。

しかし、レンジプルーフに組み込まれた長さプレフィックスは、検証キャッシュがスキップするように設計されていたレンジプルーフ検証の一部としてのみチェックされていました。したがって、検証キャッシュの観点からは、レンジプルーフは区切り文字のないバイトシーケンスとして機能しました。攻撃者はレンジプルーフを切り詰めたり拡張したりして、scriptPubKeyを調整して補償することで、検証キャッシュがそれでも有効性を主張する無効なレンジプルーフを持つトランザクションを作成することができました。

Bitcoin Coreの類似コードでは、署名の有効性が（可変長）公開鍵と（可変長）署名の連結に基づいてキャッシュされますが、これらのオブジェクトに埋め込まれた長さプレフィックスは検証キャッシュが呼び出される前にチェックされるため、脆弱ではありません。

実際には、攻撃者は同じアセットコミットメントと、既に検証済みの正規にキャッシュされたトランザクションの最後のバイトの宛先スクリプトを使用しました。これにより、問題はレンジプルーフとキャッシュキーの残りの部分との衝突に還元されました。結果として生じたバイトストリーム（攻撃者の（より長いプルーフ + 変更された値コミットメント + 再利用されたアセットコミットメント + より短いスクリプト））は、基盤となるプルーフとコミットメントの値が異なっていても、元のキャッシュエントリのストリームとバイト単位で同一でした。キャッシュヒットは検証を完全にスキップするため、偽造されたレンジプルーフは実際に検証する必要はなく、一致するバイトを生成するだけでよかったのです。

これがBug Bです。長さプレフィックスがハッシュ入力のどこにも存在しないことによって可能になった、意図的に構築されたバイトアラインメントマッチです。

どのレビューアも、内部か外部かを問わず、このリスクを悪用前に特定しませんでした。

修正の開発から悪用までの間に、3回の別々のチェックが、それぞれ内部エンジニアによる手動レビューを伴って実行されました。

• Blockstreamの内部QAサイクルの一部として、AI支援コードレビューにより、正しいフィールド（アセットコミットメントとscriptPubKey）がキャッシュキーに含まれていることが確認されました。このレビューは、報告された脆弱性に対して修正を検証するために適切にスコープされていました。
• テストネットでの機能テストにより、修正がキャッシュされたプルーフのクロスコンテキスト再利用をブロックすることが確認されました。バイト境界衝突モードは、どの当事者によっても特定されておらず、したがってテストの範囲外でした。
• 当時の利用可能な新しいオープンウェイトモデル（Kimi-K3）を使用した補足的な独立AI支援スキャンは、Blockstreamの通常のAIスキャンサイクルを超えた、より広範なレビューの一部としてElements 29.xブランチをレビューしました。エンジニアもスキャンの結果を手動でレビューしました。そのコードには既にBug Aの修正が含まれており、それは後に23.x本番ブランチに引き継がれ、同じプレフィックスなしのフィールド連結も含まれていました。スキャンとそれに付随する人的レビューは、Bug Bが既に存在するコードを調べましたが、欠陥は特定されませんでした。これは、外部研究者を含む他のすべてのレビューアの経験と一致しています。

エクスプロイトメカニズムと伝播

攻撃者のトランザクション（txid f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f）は、2026年9月6日 13:53 UTCのLiquidブロック 4,050,336で確認されました。このトランザクションは、その値が実際には入力によって裏付けられていない機密出力を作成しました。これはレンジプルーフチェックが存在する理由です。Bug Bにより、それは検証を通過しました。

トランザクションのキャッシュキーフィールドは、長さフレーミングなしに連結され、以前に正しく検証されたレンジプルーフキャッシュエントリと同じバイト文字列を生成しました。そのエントリを持つファンクショナリまたはノードは、実際のチェックを実行せずに、新しいプルーフを既に検証済みと見なしました。

すべてのノードがこれを同じように経験したわけではありません。この分割は、その時点での各ノード自身のキャッシュ内容（どのプルーフを既に検証・保存していたか）を反映しており、実行していたソフトウェアバージョンの違いではありません。15のファンクショナリすべてが、この時点で同じ修正済みビルドを実行していました。キャッシュが偽の「有効」結果を返すのは、ノードが以前の正当な検証から一致するエントリを既に保持している場合のみです。そのエントリを持つノードはブロックを受け入れました。コールドキャッシュを持つノード、またはBug Aがまだ存在するノードは、実際のチェックを実行し、失敗してブロックを拒否しました。

約4,000の裏付けのないLBTCが受け入れられたチェーン状態に入ると、他のすべてのノードにとって、それは本物のLBTCと区別がつかなくなりました。機密取引は、アドレスやトランザクショングラフではなく、金額と資産タイプをブラインドします。したがって、チェーンは事後に合理的にレビューできますが、異常は検査だけではその時点ではフラグを立てることができませんでした。

裏付けのないLBTCは、SideSwapによって処理されたペッグアウトリクエストに移動され、元のトランザクションから約36分後の14:28 UTCにBitcoinで確認されました。これは、Blockstreamが18:26 UTCにブリッジノードの停止を調整するずっと前でした。

2つの元の無効な出力（合計4つの下流トランザクション）に構築されたすべての後続トランザクションは、セクション5で説明されている回復プロセス中に、直接無効であるか、無効な出力から完全に派生していたため、後で正規チェーン状態から削除されました。

SideSwap PAKとペッグアウト制御

SideSwapは、Liquid Federationメンバーであり、PAKエントリーを保有しており、サイドチェーンから事前に登録されたBitcoinアドレスにLBTCを移動させることができます。SideSwapのPAK自体は侵害、偽造、または盗難されていませんでした。ペッグアウトが完了したのは、ペッグアウトリクエストが評価される前に、SideSwapのノードとFederationのファンクショナリノードが既に裏付けのないLBTCを有効であると受け入れていたためです。PAKメカニズムは、コンセンサスが誤って既に有効と受け入れていたLBTCに対して、実際の署名リクエストを認証しました。

インシデントの後、SideSwapは声明を発表しました。これは、ペッグアウトサービスを運用する上でインシデントに影響を与えた2つの運用上の選択についてです。

第一に、SideSwapは、Federation Charterがオフラインで保持することを要求しているにもかかわらず、ペッグアウト署名キーをオンラインに保っていたこと、および支払いを同じBitcoinブロックで顧客に自動転送していたことを認めました。SideSwapは、遅延した手動レビュー付き転送プロセスであれば、解放されたBTCを回収可能に保つだろうと述べました。

第二に、SideSwapは、ペッグアウト注文にサイズ制限、速度制御、またはウォレット履歴チェックを適用しませんでした。未回収供給量の大部分を占める約4,000 LBTCの注文が、人的レビューなしに処理されました。

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

時刻はUTC。オンチェーンイベントは確認されたブロックタイムスタンプを使用。内部運用イベントはBlockstreamの記録を使用。公開アップデートはアップデートに記載されている「ステータス（～時点）」時間を使用。ステータス時間が提供されていない場合は、公開時間を使用。9月6日の14:00および14:05のエントリは、SideSwapが公開したインシデントタイムラインに基づいています。

セクション 5: 緩和策、修正、および復旧

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

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

Bug Bの根本原因修正（2026年9月8日マージ、2026年9月9日v23.3.4としてリリース）：

レンジプルーフおよびサージョンプルーフのキャッシュハッシャーを、生のCSHA256連結からCHashWriter（SER_GETHASH）に変更。これにより、各フィールドが長さプレフィックス付きでシリアライズされ、バイト単位で同一の生の連結を持つ異なる引数タプルが、同じキャッシュキーに衝突しなくなります。

4つのフィールドすべて（可変長のものだけでなく）に長さプレフィックスを追加することで、新しいコードが、固定サイズのフィールドが将来可変長になる場合や、それらの内部長さプレフィックスの検証が変更される場合であっても、周囲のコンテキストに関係なく正しい状態を維持することが保証されます。CHashWriter（SER_GETHASH）を使用すると、すべてのフィールドがバイトの前に明示的な長さマーカーを付けてシリアライズされるため、どのバイトシーケンスも2つの異なる方法で読み取られることはありません。もはや、異なる(proof, commitment, asset_commitment, scriptPubKey)入力のペアが同じシリアライズストリームを生成することはありません。この修正では、オペレーターが選択した場合にキャッシュを完全に無効にできる-norangeproofcache起動オプションも追加されます。

この修正は、リリース前に、セクション6で説明されている、今後コンセンサスにクリティカルな、または暗号化関連の変更すべてに対するBlockstreamのレビュー基準に沿って、複数回の内部および外部レビューを受けました。

チェーン復旧。 インシデントはキャッシュの脆弱性に依存していたため、Blockstreamはレンジプルーフキャッシュを使用せずに影響を受けたチェーンをリプレイ・検証することで、無効なインフレを特定することができました。キャッシュを無効にすると、Elementsは、以前にキャッシュされた結果を再利用するのではなく、Bug AまたはBug Bに依存するトランザクションを正しく拒否しました。チームはその後、rust-elementsを使用して結果を独立してクロスチェックしました。

これにより、Blockstreamは無効なトランザクションとその子孫を特定するための決定論的な方法を得ました。オンチェーンレビューにより、2つの元の無効な出力と4つの子孫が特定され、復旧再編成の共通の検証可能な基盤が提供されました。その結果、BlockstreamはBug AまたはBug Bによって引き起こされたインフレが現在のLiquidチェーン上に残っていないことを確認しました。

Blockstreamはその後、並行してテストされた段階的な復旧（現在も進行中）を実施しました。

1. ペッグアウト操作を一時停止した状態でブロック生成を再開。
2. 独立して有効と検証されたトランザクションを再プレイ。
3. ネットワーク状態が完全に復元されたらペッグ操作を再開。

リザーブ会計。 Liquidリザーブは、不正なトランザクションと、インシデント発生時に既に進行中だった通常のペッグアウトの両方によって影響を受けました。不正なトランザクションに起因する金額のうち、3,400 BTCが返還されました。約602 BTCは、継続的な回収努力の対象となっています。

最新の公開アップデート（2026年9月17日 21:05 UTC）現在、復旧計画は引き続きアクティブにテストされており、改訂される可能性があります。独立して安全と判断されるまで、どの段階も進行しません。

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

Blockstreamは、Bug Aを最初の報告から24時間以内にトリアージおよび修正し、さらに2つのチャネルを通じて1週間以内に独立して確認しました。報告の見落とし、警告の無視、鍵の侵害は一切ありませんでした。それにもかかわらず、Blockstreamはエンジニアリングおよびセキュリティプロセスに関する包括的なレビューを実施しました。以下の行動は、そのレビューを反映しています。

1) コンセンサスにクリティカルな問題に対する修正選択。

Bug Aを最初に報告した外部研究者は、後に長さプレフィックス付きシリアライゼーションを使用した、より包括的な修正を提出しました。このアプローチは、結合されるフィールド間のより強力な分離を提供しました。また、より大規模で複雑な変更であり、異なる非本番ブランチを対象としていました。当時、Blockstreamの内部レビューアは、このより広範な変更が報告された問題に必要な範囲を超えていると評価しました。より狭い修正は、当時の入手可能な情報に基づいて、本番ブランチの修正として選択されました。

行動: コンセンサスにクリティカルな問題に対して複数の修正が存在する場合、たとえより広範な変更が必要であっても、最も強力な構造的安全保証を提供するアプローチがデフォルトとなります。このデフォルトからの逸脱には、正当化と承認が必要になります。さらに、Blockstreamは、本番コンセンサスソフトウェアに影響を与えるクリティカルな修正のリリース前に、独立したセキュリティ監査人によるレビューを義務付けることを実施しています。

2) コンセンサスにクリティカルなコードの定期的なレビュー。

Bug Aがコードベースに長期間残っていた一因は、影響を受けたコードパスが安定していたことです。Blockstreamのセキュリティレビュープログラムは、業界全体のプログラムと同様に、新しく変更されたコードに注意を集中していました。これはAIスキャンにも同様に適用されました。Blockstreamの内部スキャンプログラムは、固定ローテーションで製品全体を実行しています。修正がマージされる前に、そのローテーションは通常のサイクルで他のリポジトリに移行していました。しかし、QAローテーションとは別に、Blockstreamエンジニアリングは、インシデント前に、標準的な頻度を補完するものとして、アドホックなAIスキャンを検討し始めていました。セクション3で説明されている独立スキャンは、このイニシアチブの一部として実行されました。これは、補足スキャンの価値が内部的に特定され、対応が進められていたことを示しています。

行動: コンセンサスにクリティカルなリポジトリは、2つのトラックでレビューされるようになります。第一に、リリースブランチにマージされた変更はすべてセキュリティスキャンをトリガーします。第二に、クリティカルなコンセンサスコードは、最近変更されていなくても、定期的なレビューを受けます。エンジニアリングチームはまた、変更または発見がそれを必要とする限り、補足AIスキャンを委託するための常設リソースを持つようになります。

3) 敵対的テスト機能。

Bug Aはまた、誰かが積極的に仮定を破ろうとしない限り、休眠中の欠陥が隠れたままになる可能性があることを示しています。コードレビューは、エンジニア、監査人、またはAIシステムによって実行されるかどうかにかかわらず、防御の1つの層にすぎません。このインシデント対応中、Blockstreamは、履歴チェーンデータとメモリプール両方でレンジプルーフキャッシュ衝突を検索するツール、およびキャッシュされた結果に依存せずに検証をチェックするゼロキャッシュ再検証ツールを開発しました。これらのツールは元々インシデント対応中に構築されました。これらは同様の条件を早期に検出するのに役立ち、永続化されます。

行動: Blockstreamは、手動およびAI支援技術を使用して本番ソフトウェアを定期的にテストするために、内部レッドチームの能力を強化し続けています。この期間中に開発されたインシデント対応ツールは、適切であれば永続化されます。Blockstreamは、コンセンサスにクリティカルなコードに対して、ファズテスト、ミューテーションテスト、シンボリック実行、および（該当する場合）形式検証の使用を拡大し、異常なトランザクションアクティビティの広範なオンチェーン監視と並行して実施します。

4) コンテキスト依存のプルーフの生の検証結果をキャッシュすることは、キャッシュキーの構築方法とは別に、それ自体が脆弱なパターンである。

正しいキー構築はこの特定のインシデントをクローズしますが、基盤となるパターン（コンテキストを再導出せずにキャッシュされたブール値を信頼する）は、Blockstreamが特定し、外部レポートなしに積極的に対処することを選択したリスク源であり続けます。

行動: Blockstreamは、このようなコンテキストセンシティブなキャッシュにバージョン化されたスキーマタグと、ルックアップ時の必須コンテキスト再チェックを運ぶ、防御深度強化を実装しています。この第2層の防御は、キー構築とは独立して動作し、Blockstreamが単一の開示されたインスタンスに対処するだけでなく、潜在的な問題のクラス全体を排除することへのコミットメントを反映しています。

5) 外部研究者はオープンソースセキュリティにおいて貴重な役割を果たしており、Blockstreamは彼らに利用可能な経路を強化しています。

クリティカルなオープンソースインフラストラクチャは、脆弱性が悪用される前に、研究者が責任を持って報告するための明確な方法を持つことから恩恵を受けます。Blockstreamは長年セキュリティ報告チャネル（security@blockstream.com）を維持しており、そこから受け取った報告に迅速に対応してきた実績がありますが、Bug Aの発見につながった開示は、それらの経路を正式化し拡大することの価値を強調しています。

行動: Blockstreamは、Elementsおよび維持している他のクリティカルなオープンソースインフラストラクチャのための専用バグバウンティプログラムを設立しています。このプログラムは、構造化されたインセンティブ、定義されたスコープ、および善意のセキュリティ研究のための明確なセーフハーバー保護を提供します。

フェデレーションガバナンスと運用レビュー

Liquid Federation BoardとBlockstreamは、より広範なガバナンス、セキュリティ、および運用変更のレビューを行っています。この作業は、インシデント前に既に進行中であったガバナンス近代化を基盤としており、以前のLiquidサミットで議論されていました。

Liquid Federationは、正式に採用され次第、アップデートを提供します。

セクション 7: 謝辞

このインシデントとそれへの対応には、Blockstream以外の多くの人々の貢献が含まれており、それらを直接認識したいと思います。

私たちのセキュリティメールボックスを通じてBug Aを最初に報告し、調査に必要な情報を提供してくれたstutxoに感謝します。このような責任ある開示は、オープンソースインフラストラクチャのセキュリティに不可欠であり、stutxoが（脆弱性を悪用するのではなく）適切なチャネルを通じて報告するという決定は、セキュリティ研究コミュニティの最高水準を反映しています。また、独立したレビューで問題を確認し、対処の必要性を強化し、コードベースを改善するいくつかの追加発見を特定した外部セキュリティチームであるBitcoin Red Teamにも感謝します。最後に、リリース前にElements v23.3.4の複数回のレビューを支援したAlpen Labsのような独立レビューアに感謝します。

脆弱性を最初に悪用した個人への注意。 あなたがシステムの欠陥を発見したことを認識しています。あなたの行動が、永続的な損害を引き起こすためではなく、弱点を暴露することを目的としていたのであれば、残りのBTCを返還するよう強く求めます。脆弱性が責任を持って表面化されると、Liquidネットワークのセキュリティは強化され、Blockstreamは善意で行動する研究者や発見者が認識されることを保証することにコミットしています。

SideSwapが、インシデントにおける自身の役割に関する詳細で透明性のある公開アカウントを提供してくれたことに感謝します。これには、自発的に特定・開示された運用上の問題も含まれます。その透明性は、本レポートの正確性を向上させ、将来の開発に直接影響を与えています。

Liquid Federationとそのファンクショナリノードオペレーターが、封じ込め、パッチ展開、および進行中の復旧プロセス中に迅速に連携してくれたことに感謝します。また、上記で説明したガバナンスおよびセキュリティレビューにおける継続的なパートナーシップに対してLiquid Federation Boardに感謝します。最後に、この困難な時期に、LiquidおよびBitcoin開発コミュニティ全体が、忍耐、精査、そして継続的な関与をしてくれたことに感謝します。

Blockstreamは、Liquidネットワークのセキュリティと、本レポートが反映しようとしている透明性へのコミットメントを維持します。復旧が進むにつれて、またセクション6の是正措置が正式に採用されるにつれて、技術的なアップデートを公開し続けます。

技術的な質問、リクエスト、またはセキュリティ上の懸念の報告については、以下まで連絡してください：security@blockstream.com