デジタルカストディを導入する金融機関は、不正な取引が正規の承認を通ったとき、誰が止めるのでしょうか。
海外の大手交換業者Bybitでは2025年2月、署名者全員が通常の移転と認識して承認した取引で、約15億ドル相当の暗号資産が流出しました。調査会社の説明では、改変された取引が正規の署名手続を通っており、その手前でウォレットを提供するSafeの開発者の端末が侵害され、署名者が使うWeb画面のプログラムが改変されていました。
不正送金の防止編では、承認した内容と署名するデータの照合、権限の変更の統制、委託先を経由した侵害の防ぎ方、銀行の事務の型との対応を、確認項目と試験の条件まで整理します。保管方式の設計は保管設計編で、提供元が止まったときの返還は外部委託と事業継続編で扱います。制度の説明は資金決済法上の暗号資産を対象にします。
保管方式だけでは承認と署名の間を守れない
保管設計編では、HSM（鍵の生成・保管と暗号処理を行う専用装置）、MPC（鍵を複数の参加者で分担して署名を作る方式）、マルチシグ（複数の署名を取引の実行条件にする仕組み）はいずれも鍵と署名の成立条件を守る仕組みで、どの取引を許すかは別に強制する必要があることを示しました。Bybitに加え、インドの交換業者WazirX、ステーキング（暗号資産を預けて報酬を得る仕組み）の提供元Kilnの事例でも、改変された取引や不正な取引が正規の署名手続を通り、複数人が承認した取引そのものが実装や権限を変えたと報告されています。破られたのは承認と署名の間で、BybitとKilnではそこへ画面やAPIを届ける委託先も侵害されていました。WazirXでは、改変が自社と基盤の提供元のどちら側で起きたかについて、当事者の見解が分かれています。
1. 改正法と指針は何を求めているのか
改正法はシステムの提供者と、その選び方にも規制を加えた
再委託先を含む委託先への指導等は、資金決済法63条の9がすでに交換業者に義務づけています。2026年7月に成立した改正法は、これに3つの規制を加えました。
①システムの提供者を届出制にする
顧客の暗号資産の管理に必要な情報システムを継続的に利用させる業務などを「暗号資産管理関係業務」とし、提供者に事前の届出、業務管理体制の整備、検査への対応を求めます。対象のシステムの範囲は内閣府令で決まります。
②届出のない提供者を使えなくする
交換業者などは届出をした提供者以外から提供を受けてはならず、提供者を選ぶ基準と手続の整備、指導などの措置も義務になります。既存の交換業者には、移行期間中これを適用しない経過措置があります。
③届出の対象外のシステムと委託も管理させる
売買等の業務に必要な情報システムを他社から継続的に利用する場合も選定基準と手続の整備や指導が要り、再委託先を含む委託先への指導も引き継がれます。
右の時系列のうち、2026年8月12日に施行されたのは罰則と犯則調査の規定だけです。
カストディに関わる規定の施行期限は2027年7月22日です。
指針が示すのは方向で、試験の中身は各社が決める
金融分野におけるサイバーセキュリティに関するガイドライン（2024年10月策定）は、主要行等、中小・地域金融機関、暗号資産交換業者などが対象です。委託先の管理では、サプライチェーン全体のリスク評価、選定時の確認、契約への明記、継続的なモニタリング、取引終了時の対応を挙げ、望ましい事項として出口戦略の策定と代替手段のテストも示しています。どの構成で、誰が、どの証拠を確かめ、どの異常試験に合格すればよいかは、提供する金融機関が決めます。決める対象は4つで、海外の事例がどこに当たるかもこの4つで分かります。①②③の設計は以下の章で、④は外部委託と事業継続編で扱います。
①署名する内容の確認
承認した指図と実際に署名するデータの一致です。BybitとWazirXでは、画面の表示と署名した内容の不一致が報告されています。Kilnでは、APIが不正な権限変更の取引を返し、顧客の署名者がそのまま承認しました。
②権限の変更
承認ルール、署名者、ウォレットの実装を変える操作で、Bybitでは実装が、Kilnでは引出権限が変えられました。
③委託先を経由した侵害
画面、API、配信を担う提供元の端末とクラウドです。侵入の起点は、BybitではSafeの開発者端末、KilnではエンジニアのGitHubのトークンでした。
④委託先が止まったときの返還
提供元の停止、受託者の倒産、自社の事業終了の後に顧客へ資産を返す段階です。
では、自社では何を決め、何を試験で確かめればよいのでしょうか。
2. 署名する内容は誰が確かめるのか
承認内容を独立に保全し、署名対象と結び付ける
海外の事例で操作されたのは、承認と署名の間でした。この区間の原則は、承認した内容を侵害されうる経路とは別に保全し、実際に署名するデータから取り出した内容と照合し、照合できなければ署名を拒否することです。例えば、承認システムが承認記録に電子署名を付け、署名環境がその署名を検証してから照合に使います。
暗号資産の保管について業界団体C4がまとめたセキュリティ基準CCSSの第9版は、Level II以上の要求として、鍵を使う前に送付先と金額を承認済みの通信経路で検証するよう求めています。この項目だけではスマートコントラクトへの呼出しの意味まで確かめる設計は定まらず、Bybitで置き換えられたのはその外側にある実装でした。
照合の独立性は、端末の数ではなく、照合するシステムの入力を誰が変えられるかで決まります。Bybitの署名者は全員が同じSafeのWeb画面で内容を確かめていたため、画面の改変で確認が同時に崩れました。WazirXの署名者も、基盤の提供元の画面で内容を確かめていました。照合用の承認記録が取引データと同じ経路を通れば、改ざんされたデータと記録が一致してしまいます。
確認する項目は資産の種類によって違う
照合する項目は、送付先、数量、資産とチェーン、操作の種類（通常の送金か、権限や実装の変更か）、呼出しデータ（スマートコントラクトに渡す命令の中身）です。ビットコインでは送付先、金額、手数料、自社に戻るお釣りを、元の取引の情報と鍵の導出情報を含むデータ（PSBT）を渡された署名機器が追加の照会なしに計算できるため、すべての出力、お釣り、手数料と、署名が取引のどの部分を拘束するかの指定を機械で照合できます。
イーサリアムのSafeでは、取引に宛先、送金額、呼出しデータ、操作の種類が含まれ、署名の対象には取引ごとの通し番号（nonce）とチェーンの識別子も入ります。トークンの移転では宛先がトークンのコントラクトになるので、実際の移転先と数量は呼出しデータから取り出して照合します。
デロイトの報告の概要は、内容を十分に確認しないまま署名することをブラインド署名と呼び、送信先がスマートコントラクトの場合に留意が要るとしています。署名機器に表示されれば人が気付けると思われがちですが、Bybitでは不正な内容が表示されたまま署名されました。解釈できない呼出しや許可していない操作は、人の目ではなく仕組みで止めます。
オフラインでの照合は一例で、止まることを試験で確かめる
オフラインの署名環境の中で承認記録ともう一度照合してから署名する構成は、一例です。外の画面やサーバが侵害されても最後の照合は影響を受けにくくなりますが、承認記録を同じ送付先と数量の別の取引に使い回せれば、二重に払い出されます。承認記録に承認ID、有効期限、送出元のウォレット、チェーンを持たせ、一度使った承認は再び使えないようにし、真正性、鮮度、未使用であること、対象の取引との一致の4点を確かめます。
試験では、送付先を差し替えたデータ、delegatecall＊1を加えたデータ、数量が異なるデータ、使用済みの承認記録を添えたデータを持ち込みます。合格の条件は、署名が行われず、拒否の記録が残り、停止を判断する責任者に通知が届くことです。署名機器や画面のプログラムを更新したら、同じ試験をやり直します。
As-Isは提供元の画面だけを見て署名する構成、To-Beは独立に保全した承認内容と照合して不一致なら止める構成で、下段が資産ごとの確認項目です。
3. 権限の変更はどう止めるのか
権限の変更は仕組みの側で検知して別の承認にする
権限の変更を「設定変更」という申請区分にして承認者を増やしても、Bybitのように通常の送金に見せかけた権限変更には効きません。区分を決めるのが申請者や画面である限り、偽装された取引は区分ごと偽装されるためです。通常の送金として許す操作を限定し、権限変更、実装変更、署名者の追加を取引データから仕組みで検知して、送金とは別の管理権限者の承認に回します。
Safeの通常の署名経路では、署名者の追加やGuardの付け替えも、普通の取引と同じ形で署名されます。Guardは署名の必要数の判定に加えて取引ごとの制限を掛ける追加の検査機能で、公式のチュートリアルはdelegatecallをすべて拒否するGuardを例にしています。Safeは不具合のあるGuardがウォレットそのものを使えなくすると注意しており、Guardを外す取引や、追加機能（モジュール）から署名を集めずに実行する経路のようにGuardを通らない経路も試験の対象にします。
変更に待機時間を設けるなら、どの操作に掛け、待機中に誰が中止できるかを決めます。夜間に変更が通知されても中止できる人が対応できなければ、待機時間は異常を止める時間になりません。
止める手段が効く段階は4つに分かれる
止める段階は、署名前の拒否、署名済みのデータの送信の保留、チェーン上での実行の拒否、実行の確定後の4つです。送信の保留は署名済みのデータを送信前に自社で止めておく段階ですが、署名済みのデータが外へ漏れれば第三者でも送れるため、自社の送信サーバを止めても効きません。Guardやチェーン上の待機時間は3つ目の段階で効き、署名を止める段階の代わりにはなりません。実行が確定した後は移転を取り消す手段がなく、被害の上限と返還の手順で受け止めます。
下段は、通常の送金や権限・署名者の変更などの経路ごとに、どの段階で止められるかを示します。
では、委託先の画面やAPIそのものが改変されたら、どう防げばよいのでしょうか。
4. 委託先を経由した侵害はどう防ぐのか
更新の受入れ試験だけでは配信経路の改変を防げない
外部のソフトウェアは、新しい版を受け入れる前に試験するのが通常の管理です。Bybitでは提供元のクラウド上で画面のプログラムが改変され、流出の取引の後に元へ戻されました。暗号資産事業者SwissBorgが使っていたステーキングの提供元Kilnでは、APIを提供するサーバにコードが注入されました。いずれも利用者が新しい版を受け入れる手続を経ておらず、提供元のクラウドで実行中に差し替えられたプログラムは受入れ試験の対象に入りません。
提供元の開発と配信の管理を確認対象にする
米国のNISTが定める安全なソフトウェア開発の枠組み（SSDF）は、開発環境の分離、開発端末の保護、最小権限、リリースの完全性を検証する仕組みを挙げています。Safeの開発者端末とKilnのエンジニアのGitHubのトークンは、いずれも侵入の起点でした。提供元に確かめるのは、開発端末の管理、CI/CD（コードを自動で検証・配布する仕組み）の秘密情報の管理、本番環境への特権アクセス、本番変更の承認、配信経路の改変の検知です。
利用する金融機関の側では、自社の端末が受け取る画面のプログラムのハッシュ値を承認済みの版と照合できます。提供元のサーバ内部の処理は利用者から観測できないため、本番変更の監視の証拠を提供元に求めます。権限変更を取引データから検知する仕組みは、委託先のAPIが組み立てた取引にも掛けます。
提供元の開発端末から利用者の署名までの5地点ごとに、攻撃の例と確認手段を対応させています。