安全な保管を超えて、第1部：安全な決済・署名ワークフローの設計

Binanceによる2026年10月30日のインシデントに関する暫定的な説明では、盗まれたデプロイトークンを足掛かりに内部の署名サービスへアクセスされ、通常の出金プロセスを経ない取引が行われたとされています [1]。公表されたこの経路では、攻撃者はウォレットの秘密鍵を読み取らずに署名を要求できました。

ここで攻撃者が狙ったのは、システムの署名能力です。暗号化やハードウェアによる隔離を含む安全な保管は、鍵を保護できても、支払いに有効な業務上の承認があるかどうかは判断できません。そこで問題となるのは、権限のない操作が、どうして有効な署名を得られるのか？ という点です。

この問いに答えるには、業務上の要求がどのように署名済みの取引となり、実行されるかを追う必要があります。ウォレットを通じて実行される支払いは、業務上の承認、取引の構築、署名、実行と決済という段階を経ます [2, 3]。図は、このワークフローの悪用と並べて、署名能力を得るもう一つの経路、すなわち暗号実装の欠陥を突いて鍵を復元する経路を示しています。

Beyond Secure Storage シリーズでは、実際のインシデントから、これらのリスクに対処するための設計・実装上の原則を導き出します。第1部の Designing Secure Payment and Signing Workflows では、攻撃者が秘密鍵を入手せずに、元のシステムの署名能力を悪用する方法を検討します。第2部の Implementing Wallet Cryptography Securely では、攻撃者が鍵を復元して独自に署名できるようになる実装上の欠陥を検討します。どちらの経路でも、保護された秘密情報を直接盗む必要はありません。

セクション1では、実際のインシデントを用いて支払いワークフロー上のリスクと見落とされがちな前提を検討し、それらに対処するための設計・実装上の確認事項を導き出します。セクション2では、これらの確認によって権限のない操作を防げなかった場合を想定し、結果として生じる損失をどう抑えるかを検討します。セクション3では、設計レビュー、監査、ペネトレーションテスト、演習によって、予防と損失の抑制の両方をどう検証できるかを説明します。

1. 権限のない操作を防ぐための設計

同じ支払いワークフローでも、異なる業務目的に利用できます。図では、カストディ業務の代表的な操作を3つ取り上げています。入金はアカウントの残高に対する権利を確定し、出金は顧客の指示に基づいて行われ、資金管理上の送金は組織の資金配分の決定を実行します。

検証済みの入金によって生じるのはアカウントへの残高計上であり、自動的な支払い指示ではありません。出金には別途、顧客からの依頼と承認が必要です。資金管理上の送金は、組織による資金配分の決定を起点とします。出金と資金管理上の送金はいずれも、取引の構築、署名、実行、決済を経ます。資産をまとめて保管するカストディでは、顧客ごとに専用のアドレスへ資産を置かなくても、台帳に顧客の権利が記録されます。

カストディ業務における代表的な3つの操作。機能が分かれているだけでは、独立した主体や権限の境界が確立されているとはいえません。

これらの操作では、資金を移動する理由が異なります。ほかの業務上の操作も同じ段階をたどることがありますが、必要な証拠や承認は異なり得ます。各段階で問うべきなのは、支払いの根拠、取引、署名権限の使用、決済が、意図された操作と引き続き一致しているかどうかです。

どの段階も、攻撃者が署名または実行される内容に影響を与える接点になり得ます。偽造された依頼は見かけ上の支払い義務を生み、取引の構築時には未承認の操作が差し込まれ、権限が侵害されれば署名へのアクセスが可能になり、実行や決済の不備によって望ましくない権限が使える状態で残ったり、根拠のない支払いが引き起こされたりします。

以下の表は、リスクをワークフローの各段階と、それを検討するために用いる事例に対応付けたものです。

ワークフローの段階	セキュリティ上の問い	検討する事例
1.1 · 支払いの根拠と承認	支払いには、真正な依頼、資金を支出する権利、有効な承認があるか？	Bitgetでの出金依頼の偽造 [4]、BigONEでのアカウント／リスク管理ロジックの侵害 [5, 6]
1.2 · 取引の構築と検証	ペイロード全体が、承認された操作を表しているか？	Bybitでの欺瞞的な送金を経た制御権の奪取 [7, 8]、Kiln/SwissBorgでの取引レスポンスの改変 [9, 10]
1.3 · 署名の承認と鍵の使用	誰が署名でき、誰が署名を許可される者を変更できるか？	Resolvでの鍵ポリシーの乗っ取り [11]、Binanceが報告した署名サービスへのアクセス [1]
1.4 · 実行と決済	署名によって付与された権限はいつ実行可能になり、次の支払いは何を根拠とするか？	Driftでの実行の遅延とChainflipでの誤った返金 [12, 13, 14]

1.1 支払いの根拠と承認

支払いを取引の構築と署名に進める前に、機関は、真正な依頼、依頼者がその資金を移動する権利、指定された操作に対する有効な承認を確認しなければなりません。顧客残高や認証済みの内部依頼だけでは、この3つすべてが確認されたことにはなりません。

失敗事例：支払い根拠の捏造

Bitget の2026年9月24日のインシデントでは、攻撃者はサードパーティーのセキュリティ製品を悪用して、高い権限を持つ内部認証情報を入手しました。Bitgetの公式説明によると、その認証情報を使ってウォレットシステムに不正な出金コマンドが送られ、既存のリスク管理を回避した送金が行われました [4]。コマンドは内部アクセスを通じて支払いプロセスに到達しましたが、そのアクセスは正当な顧客の指示や資金管理上の決定があったことを示すものではありませんでした。

BigONE は2025年7月16日に、権限のないホットウォレットからの資金移動を公表し、秘密鍵は安全なままだったと述べました。BigONE Eurasiaは、グローバルプラットフォームで起きたこのインシデントの原因を、本番環境のアカウントおよびリスク管理ロジックの変更に求めています [5, 6]。これは、支払いの正当性を判断するために使う記録やルール自体が改変され得るという、関連する懸念を示しています。公表された説明には、依頼の詳細な記録や署名APIは示されていないため、Bitgetと同じ攻撃手法だったとまではいえません。

これらの事例は、内部アクセスやアカウント記録を支払いの十分な根拠とみなすことのリスクを示しています。攻撃者は、その判断が依拠する認証情報、記録、ルールを改変する可能性があります。

検証すべき対策

したがって、設計・実装レビューでは、各依頼を真正な業務上の根拠までたどれるか、また依頼の提出者が裏付けとなる記録を捏造したり、自ら承認したりできないかを確認する必要があります。

依頼の出所、完全性、承認を検証する。 すべての支払いについて、真正な顧客の指示、業務上の事象、または組織の決定までたどれるようにし、資金を支出する権利と承認の証拠を備えなければなりません。依頼とその裏付けとなる記録への変更を追跡できること、また、捏造・改変された証拠が、内部サービスから届いたりアカウント残高と一致したりするだけで承認の根拠にならないことを確認します。
検証と承認を依頼の作成から独立させる。 依頼の提出者が、その裏付けとなる証拠を捏造したり、自ら依頼を承認したりできてはなりません。運用上の権限と管理権限の両方で、この分離を維持します。手動の例外対応や復旧手順を含め、記録、承認ルール、役割の割り当てを変更することで、一者が依頼と、それを拒否するためのチェックの両方を支配できないか確認します。

支払いの根拠が独立して確認されたら、次に問うべきなのは、取引が承認された操作を表しているかどうかです。

1.2 取引の構築と検証

支払い依頼が承認されると、取引の構築処理によって、署名に提出する未署名データへと変換されます。送金先、金額、操作、ウォレットの制御権に対する変更を含むペイロード全体が、承認された依頼を表していなければなりません。送金の承認は、追加の操作まで許可するものではありません。検証では、インターフェース上の説明だけでなく、実際に署名されるデータを確認する必要があります。

失敗事例：署名された操作が承認内容から逸脱する

Bybitは、コールドウォレットからウォームウォレットへETHを移転する予定でした。同社の公式発表によると、侵入はSafeの開発者認証情報が侵害され、プロバイダーのインフラへのアクセスと署名者を欺く行為が可能になったことに起因します [7]。Safeは、execTransactionを通じて、to、value、data、operationを含むトランザクションのフィールドに対する署名を検証します [15]。しかし、侵害されたインターフェースは予定されていた移転の外観を保ちながら、署名前に悪意のあるフィールドへ差し替えていました。署名は、その差し替え後のバイト列に対して有効でした [7]。

その結果生じたトランザクションは、DELEGATECALLを使ってウォレットの実装を変更し、攻撃者が元の所有者から新たな承認を得ずに資産を流出させられるようにしました [7, 8]。承認された業務上の操作は資産の移転でしたが、署名された操作はウォレットを制御できる主体を変えるものでした。画面に表示された受取先やトランザクションの直接的な送金額を確認するだけでは、操作全体が承認内容と一致することは確認できませんでした。

Kiln/SwissBorgの事例は、稼働中のトランザクション構築サービスを改変することでも、悪意のあるトランザクションを紛れ込ませられることを示しています。Kilnによると、侵害されたGitHubトークンを起点に、CIワークフローを経て本番環境の認証情報が取得されました。攻撃者はデプロイ済みのイメージを変更せずに稼働中のKubernetes podを改変し、正規のSolanaステーク無効化トランザクションとともに、引き出し権限を変更するトランザクションを返すようにしました。顧客のカストディサービスの署名者は、追加されたトランザクションを承認しました。Kilnは、署名が8月31日に行われ、検知は2025年9月8日だったとしています [9]。SwissBorgも、トランザクションの改ざんはプロバイダーのインフラに起因するとしました。当時利用可能だったデコードツールの使いやすさと統合状況については、両者の見解が異なっていました [10]。

検証すべき制御

BybitとKiln/SwissBorgの事例は、トランザクションが署名者の承認意図からどのように逸脱し得るかを示しています。設計上、承認は操作全体に結び付ける必要があり、検証では、トランザクションを構築または表示したサービスとは独立して、実際のトランザクションを確認する必要があります。

承認を操作全体に結び付ける。 承認は、資産の制御権の変更や実行権限の委譲を含め、トランザクションの効果すべてを対象とする必要があります [16]。その範囲外の変更には新たな承認が必要です。差し替えられた操作や追加された操作に正規の支払いの承認を流用できないこと、また、再試行によって一つの承認を追加の支払いの承認に再利用できないことを検証します。
トランザクションとその効果を独立して検証する。 署名のために実際に提出されるデータを、承認された業務上の操作と照合し、バッチ内のすべてのトランザクションと、それぞれが資産や権限に及ぼす効果を確認します。検証は、トランザクションを構築または表示するサービスから独立している必要があります。そのサービスが検証機能を変更したり検査を回避したりできないか、また、誤解を招く表示や改変されたトランザクションが拒否されるかを確認します。

ここまでの検査は、トランザクションが承認された要求と一致するかを対象としています。署名段階では別の問いが生じます。必要な業務上の承認を得ずに、直接、またはアクセス権限を変更することで、誰かが鍵を使用できるでしょうか。

1.3 署名の承認と鍵の使用

検証済みのトランザクションは、承認された呼び出し元を通じて署名サービスに届く必要があります。鍵のポリシーと管理者ロールによって、誰が該当する鍵を使用でき、誰がそのアクセス権を変更できるかが決まります。署名を呼び出す権限は、すべてのトランザクションを承認するものではありません。また、サービスの管理権限によって、検査を受けない署名経路が生じてはなりません。したがって、この段階では、承認された操作のための鍵の使用と、鍵へのアクセスを管理する権限の両方を扱います。

失敗事例：署名アクセスの侵害

Resolvの2026年3月22日の事例は、鍵へのアクセスポリシーを変更することで、署名の経路が開かれ得ることを示しています。同社の発行プロセスでは、ユーザーが担保を預け入れ、権限を持つオフチェーンサービスが発行を完了させる必要がありました。公式の事後分析によると、攻撃者はリポジトリとクラウドへのアクセスを足掛かりに、より高い権限を持つロールに到達し、それまでのアクセス試行が拒否された後、署名鍵のアクセスポリシーを変更しました。この変更により、ID単位の権限と鍵単位のアクセスポリシーの両方を必要とするクラウドの鍵管理サービスで、攻撃者に署名権限が付与されました [11]。

署名できる主体を変更したことで、攻撃者は元の署名者を説得することなく、担保との本来の対応関係から外れた発行を承認できました。この報告で確認できるのは署名権限の掌握であり、生の秘密鍵データの抽出ではありません。

Binanceによる2026年10月30日の事例に関する暫定報告は、署名権限に至る別の経路を説明しています。Binanceによると、侵害された従業員のデバイスと社内AIツールによってウォレットエンジニアのデバイスへのアクセスが可能になり、その後、盗まれたコンテナのデプロイトークンを使ってコンテナがデプロイされ、悪意のあるスクリプトが実行されました。攻撃者は社内のウォレット署名サービスに不正アクセスし、通常の出金プロセスの外でトランザクションを開始しました [1]。この報告はデプロイ権限と署名サービスへのアクセスを結び付けていますが、回避された社内の権限チェックの詳細は明らかにしていません。Resolvで報告された鍵のポリシー変更とは異なり、ここで開示された侵入経路は署名サービスの実行環境を通るものでした。

検証すべき制御

これらの事例は、想定された業務フローの外で署名アクセスを獲得または使用するリスクを浮き彫りにしています。レビューでは、ポリシー変更やデプロイ権限によって開かれる経路も含め、すべての署名経路で業務上の承認が強制されるかを確認する必要があります。

すべての署名経路で業務上の承認を強制する。 鍵を使用する権限があっても、特定の操作が承認されたことにはなりません [17, 18, 19]。鍵の使用を承認された業務範囲に限定し、別の呼び出し元や直接アクセスによってその制限を回避できないことを検証します。承認の強制は、任意の署名要求を送信できる呼び出し元から独立していなければなりません。この要件を強制できない経路がある場合は、その不足を記録し、セクション2に従って影響を評価します。
署名権限の変更を管理する。 当初のIDには署名権限がなくても、管理権限やデプロイ権限によって署名アクセスを作り出せます [20, 21, 22]。鍵の使用権限と、署名ポリシー、ID、デプロイ済みコードを変更する権限を分離し、それらの変更には独立した承認を求めます。いずれの主体も、保有する権限を組み合わせて自らに署名アクセスを付与したり、そのアクセスを管理する業務上の検査を取り除いたりできないことを検証します。

承認の検査は、署名の発行時点で終わりにはできません。トランザクションは承認された条件の範囲内で実行され、その結果が正しく決済処理される必要があります。

1.4 実行と決済処理

承認は署名後も、ブロードキャスト、実行、関連する業務記録と残高の引当ての決済処理まで有効である必要があります。署名は支払い完了の証明ではありません。実行は承認の範囲と有効条件を守らなければならず、決済処理では、どの債務が履行されたか、追加の支払いが実際に必要かを確定しなければなりません。既存の署名や観測された資産移転だけでは、新たな支払義務は成立しません。

失敗事例：署名済み権限の悪用と決済処理へのフィードバック

Driftの事例は、誤解を招く署名要求によって、後から使用できる権限が残り得ることを示しています。2026年4月1日の事例では、事前に得た承認がSolanaのdurable nonceを使用したトランザクションに保持され、後にそのトランザクションが送信されて管理権限が奪取されました [12]。durable nonceはトランザクションの有効性を制御するもので、暗号署名に使われる秘密のnonceとは異なります。通常の直近のブロックハッシュによる有効期限に制約されず、オフラインでの署名や遅延した送信を可能にしますが、アカウントやプログラムの状態が変わると実行できなくなる場合もあります。durable nonceを進めると、古い値に紐付くトランザクションは無効になります [23]。

Driftは4月16日の復旧状況に関する発表で、専用の署名デバイス、主要な署名インターフェースの外での検証、重要な管理操作へのタイムロックの設定、署名者によるdurable nonceの使用停止を提案しました [24]。これらの対策は、署名者が何を承認するかと、署名済みの操作をいつ実行できるかの両方に対処するものです。これらは復旧計画として発表されたものであり、発表からは導入済みであることは確認できません。

Chainflipは、顧客によるスワップ、流動性提供者（LP）の出金、そしてfetchと呼ばれる内部の入金回収処理を区別しています[25]。Tronでは、トランザクションのメモにスワップの指示を含めることができます。Chainflipが9月15日に示した、2026年9月12日のインシデントに関する説明によると、攻撃者はバリデーターが署名したfetchを、攻撃者が制御する不正な形式のメモとともに送信しました。監視レイヤーはその文脈を失敗したスワップと誤認し、通常のLP出金に加えて返金を行ったため、6件の出金に対する支払いが二重に行われました[13, 14]。

この誤りにより、内部での資産移動が、顧客に対する新たな支払義務の根拠として扱われました。Chainflipは、保管庫への送金が別のコントラクト呼び出しに包まれている場合でも、メモを解釈していました。修正後はスワップのメモを解釈する対象を、単純なTRX送金または直接のTRC-20送金に限定し、別の呼び出しに包まれたものを除外しました[14]。正当に署名されたfetchには固有の目的があり、その実行は追加の返金を正当化するものではありませんでした。

検証すべき統制

署名済みトランザクションは想定より長く実行可能な状態が続くことがあり、実行結果が新たな支払義務と誤認されることもあります。そのため、レビューでは実行条件が実際に強制されていること、また各支払い・返金が真正かつ未履行の義務に対応していることを確認する必要があります。

承認された実行条件を強制する。 署名済みトランザクションにも、承認された対象範囲、有効期間、取り消し条件が適用され続けなければなりません。期限切れ、取り消し、または承認内容の変更後も、古いトランザクションを実行できるか確認します。関連する条件を署名対象の操作に結び付け、チェーンのルールまたはウォレットの実行ロジックによって強制されることを検証します。業務システム上の記録だけでは不十分です。
真正かつ未履行の義務に対してのみ支払いを行う。 各支払い・返金は、まだ履行されていない実際の義務に対応していなければなりません。元の業務上の事象、支払いの試行、確認済みの結果のつながりを維持します。再試行、重複通知、結果が不確かな処理、内部送金によって正当な根拠のない支払いが生じないこと、また実行を示す証拠の解釈ルールを変更してこれらの確認を回避できないことを検証します。

2. 損失の抑制とインシデント対応を可能にする設計

セクション1では、インシデントの証拠を基にワークフロー上のリスクと、それに対処するために必要な設計・実装上の確認事項を特定しました。ここでは、見落とし、実装ミス、回避のいずれかによって、それらの確認が不正な操作を防げなかったと仮定します。その場合、設計では攻撃者が移動できる資産の量を制限し、なおリスクにさらされている資金を把握するとともに、不正を検知してさらなる資金流出を止める能力を確保しなければなりません。こうした損失抑制策は、予防的な統制と並行して、インシデントが起きる前に設計・テストしておく必要があります。

以下の表に、損失の抑制とインシデント対応を可能にするための3つの設計目標をまとめます。

設計目標	セキュリティ上の問い	検証の重点
2.1 · 独立して強制される支出上限	不正な支払いが発生した場合に、累積の資金流出を抑えられるか。	独立した強制、累積額の一貫した計上、上限の変更・回避に対する保護
2.2 · 保有資金、補充、未実行の署名済みトランザクション	攻撃を封じ込めるまでに、どれだけの損失が生じ得るか。	利用可能な残高とその後の流入、補充に関する制約、未行使の署名済み権限によってリスクにさらされる資金
2.3 · 独立した監視とインシデント対応	不正な操作を検知し、さらなる資金流出を止められるか。	信頼できる証拠、対応につながるアラート、有効かつ独立して利用できる対応用の統制

2.1 独立して強制される支出上限

不正な支払いが前述の確認を通過したとしても、システムはその支払いと後続の支払いで移動できる資産の量に上限を設けるべきです。そのためには、攻撃者が制御できると想定される範囲の外で、個々のトランザクションと累積支出の両方に適用される予算を強制する必要があります。侵害された承認サービスや署名者が上限を無効化または回避できるなら、設定済みの上限では損失を抑えられません。

支払いの承認とは独立して上限を強制する。 承認の確認を通過した支払いにも、攻撃者が制御できると想定される範囲の外で強制される支出上限を適用しなければなりません。代替の実行経路[26, 27]を含め、すべての署名・実行経路が上限を守り、攻撃者がその強制を変更・無効化できないことを検証します。独立した上限を強制できない場合、設定済みの予算を損失の上限として示してはいけません。
個々の支払いだけでなく、累積支出を制限する。 各予算の対象範囲、期間、評価額の算定基準を定め、完了した支払いと引当額を一貫して計上します。要求の繰り返し、同時実行、再試行によって合計額が上限を超えたり、引当が早期に解除されたりしないことを検証します。上限が資産価格に依存する場合は、操作された価格、古い価格、取得できない価格によって許容支出額が膨らまないことを検証します。

2.2 保有資金、補充、未実行の署名済みトランザクション

次に問うべきは、決済機関が攻撃を検知して封じ込めるまでの間、どの資金がリスクにさらされ続けるかです。ウォレット残高、補充、未行使の署名済み権限が、インシデント開始後に流入する資金も含め、その範囲を決めます。これらはセクション2.1の強制可能な上限と併せて評価してください。現在の残高だけでは損失額の推定にはなりません。

攻撃者がアクセスできる資金を制限する。 影響を受けた署名権限で扱える資産の全範囲を、ほかのウォレット、チェーン、コントラクトも含めて評価します。既存の残高とその後の資金流入を含めます。資金の補充には独立した承認と累積の上限が必要です。資金流出が繰り返されてもトレジャリーから継続的に補充されないこと、また、なお到着する入金を見落とすことなく、新たな資金供給を別の宛先に振り向けるか停止できることを検証します。
未行使の署名済み権限によってリスクにさらされる資金を含める。 新たな署名を停止しても、発行済みのトランザクションや承認が必ずしも無効になるわけではありません。同じ資産を二重計上しないようにしながら、それらによってなお移動可能な資金を特定します。確認済みの支払いは支出済みとして記録して引当額と照合し、未実行のトランザクションについては、もはや実行できないことを信頼できる証拠で確認するまで引当を維持することを検証します。ローカルでのタイムアウトや取り消し要求だけを理由に、記録上のリスク額を減らしてはいけません。

2.3 独立した監視とインシデント対応

上限と資金供給の統制は潜在的な損失を制約します。一方、監視と対応は、攻撃者が操作を続けられる期間を左右します。決済サービスが操作を有効と扱っていても不正を明らかにできる証拠と、通常の運用環境が利用できないか侵害されている場合にも使える対応経路が、決済機関には必要です。

Binanceの暫定的な説明は、アプリケーションの停止だけでは目的を達成できない場合がある理由を示しています。アプリケーションを停止しても、既存のEIP-7702デリゲーションは消えませんでした。その取り消しにはオンチェーンのトランザクションが必要であり、同社のMPC環境では別途設計した手順も必要でした[1]。これはその環境に固有の制約であり、MPCでは本質的に権限を取り消せないという意味ではありません。したがって、検知と封じ込めは別々に検証する必要があります。信頼できる証拠から、実際に損失につながる経路を断つ行動へとつなげなければなりません。

独立して保護された証拠を用いて不正な活動を検知する。 業務上の承認と署名活動・実行結果を照合し、権限や統制ルールの変更を監視します。影響を受けたサービスが、監視の根拠となる証拠を書き換えられてはなりません。ローカルの記録が欠落または改ざんされていても、ワークフローが受け付けた操作が業務上の承認と一致しない場合には、対応につながるアラートを発せられることを検証します。
対応用の統制を利用可能かつ有効に保つ。 新たな署名と資金供給を停止するための独立した権限を維持し、対応している場合には未実行のトランザクションを無効化するか、継続する権限を取り消せるようにします。通常の運用アクセスが利用できない、または侵害されている場合にも対応が可能であり、その措置によってさらなる資金流出が実際に阻止されることを検証します。残るリスクと外部との調整の必要性を特定します。アプリケーションを停止するだけでは署名済みの権限は取り消されず、資産を回収できるとも限りません。

3. 設計と実装の検証

前のセクションでは、ワークフロー上のチェックによって不正な操作を防げるか、また防げなかった場合に損失を抑えられるかを問いかけました。検証では、資金の流れ全体にわたる各制御の相互作用も含め、稼働中のシステムでこの両方の目標を調べる必要があります。以下の方法は、相互に補完し合う証拠を提供します。

アーキテクチャとセキュリティ設計の評価では、資金の流れ、権限の境界、制御間の依存関係が、意図した不正操作の防止と損失の抑制という目標を支えられるかを確認します。制御の独立性と損失の上限に関する前提を明確にする必要があります。
コードと設定の監査では、稼働中のコード、設定、権限が意図したチェックを実装しているかを検証します。チェックを回避し得る例外や代替経路も対象に含めます。
ペネトレーションテストでは、アプリケーションとインフラの複数の弱点を組み合わせ、承認や損失抑制の制御を回避できるかを調べます。個々のコンポーネントで調査を止めず、資金の経路全体を対象にする必要があります。
攻撃・対応演習では、監視が迅速な対応につながること、および支出上限、一時停止、権限の取り消しが連携して機能することを検証します。なおリスクにさらされる資金がどれだけ残るか、有効な封じ込めまでにどれだけ時間がかかるかを明らかにする必要があります。

各検証シナリオでは、想定する攻撃者の能力とともに、拒否すべき操作または抑制すべき損失を指定します。観察された結果、残存するエクスポージャー、主張する損失上限の前提条件を記録します。コード、設定、権限に重要な変更を加えた後は、関連するチェックを繰り返します。

第三者のセキュリティチームや専門家は、こうした評価、監査、テスト、演習において社内チームを補完できます。そのレビューでは、決済ロジック、署名インフラ、運用上の権限がどう相互作用するかを対象とし、システムの不正操作防止能力と損失抑制能力を裏付ける証拠を提供する必要があります。

4. 結論

ここで検討した攻撃は、最初の決済リクエストからトランザクションの構築、署名、実行、決済に至るまでの承認上の不備を明らかにしています。また、攻撃者が防御を突破した後に損失を抑えるために、システムに何が必要かも示しています。そこから導かれる設計原則は、不正操作の防止、損失の封じ込め、そして実際の運用でその両方を評価するために必要なテストを対象とします。

中心となる結論は、秘密鍵を保護するだけでは、署名された操作が承認済みであるとは保証できないということです。実際に実行される操作は、正当な業務上の決定と一致していなければなりません。また、ワークフロー上のチェックで不正な操作を防げなかった場合には、独立した制御によってその影響を抑える必要があります。そのためには、チェックを変更できる権限や、さらなる損失を検知して止めるために必要なツールを含め、ワークフロー全体を見直す必要があります。

この分析では、元のシステムの署名機能の悪用に焦点を当てました。第2部「ウォレットの暗号技術を安全に実装する」では、別の経路を取り上げます。保護された秘密情報を直接盗むことなく、実装上の欠陥を利用して秘密鍵を予測または復元し、元のワークフローの外で署名する経路です。