ブロックチェーンの署名鍵をHSM・MPCで守るとき｜不正な承認と二重送金の防ぎ方

目次（タップで折りたたみ）

ある決済サービスの会社が、署名に使う鍵をHSMに移しました。対象は、スマートコントラクトの管理者鍵、relayer（利用者に代わって取引を送り、ガス代を払う中継サービス）の鍵、決済ウォレットの鍵です。どれも、システムが自動または半自動で署名します。

経営会議では「これで鍵は安全になった」と報告されました。ところが、署名サービスの責任者には気になることが残っています。

承認のシステムが乗っ取られ、「承認済み」の不正な送金が回ってきたら、HSMはそのまま署名してしまうのではないか。
署名や送信が時間切れになったとき、担当者が作り直して送ったら、同じ送金が二重に出ていかないか。

どちらも、鍵そのものは盗まれていないのに資産を失う事故です。HSMもMPCも、鍵を外に出さずに、渡されたデータへ署名する仕組みです。渡されたデータが誤っていれば、正しい鍵で誤った取引に署名してしまいます。つまり、鍵を守ることと、何に署名するかを確かめることは、別の仕事です。

そこで、鍵の保護とは別に設計するものがあります。何に署名するのか、損失の上限、承認者、要求の有効期限、障害のときに復旧する権限です。そしてそれを、オンチェーンの権限の制約とつなぎます。この設計は、HSMとMPCのどちらを使っても共通です。

この記事で使う言葉

HSM（Hardware Security Module）：暗号鍵を保護し、装置の内部で署名する専用基盤
MPC（Multi-Party Computation）：秘密情報を明かさずに、複数者で共同計算する技術
閾値署名：鍵を複数に分け、決めた数がそろったときだけ署名できる方式
マルチシグ：複数の鍵の署名がそろわないと実行できないアカウント
タイムロック：重要な操作を、決めた待機時間の後でしか実行できなくする仕組み

署名で起こせる損失を、用途ごとに分ける

1つのアドレスに何でもできる権限を集めると、その鍵が1回破られただけで、被害が次々に広がります。最初にやるのは、署名で何ができてしまうかの洗い出しです。

資産を送る、コントラクトをアップグレードする
役割（ロール）を付け替える、一時停止を解除する
Oracleを更新する、ガス代を払う

これらを別々の権限として扱います。権限ごとに、次のことを決めます。

1回・1日あたりの上限、送付先、対象チェーン、トークンのコントラクト
実行できる時間帯と、取り消せる時点
止まっていてもよい時間

冒頭の会社の3つの鍵に、一時停止用の鍵を加えると、次のように分けます。

用途（署名の頻度）	破られたときの主な損失	別に用意する守り
コントラクト管理者鍵（アップグレード・役割変更）／頻度は低い	コントラクト全体の乗っ取り、全資産の移転	高い閾値のマルチシグ、タイムロック、通常業務と別の承認者
一時停止用の鍵／非常時のみ	サービスの停止（悪用時の損失は限定的にする）	停止だけに限った権限。解除は管理者鍵の側へ戻す
relayer・定型送信の鍵／頻度は高い	ガス代用の残高の流出、不正な送信	残高上限、送信先・関数の許可リスト、自動補充の上限
決済ウォレットの鍵／中〜高	送金額の範囲での流出	1回・1日の上限、宛先の登録、業務承認との突き合わせ

毎日の大量の署名と、アップグレードや資産回収のような、まれだが影響の大きい操作。この2つを同じ鍵・同じルールに載せていると、どちらかで問題が起きて鍵を止めたとき、両方が止まります。2つを分けることが、止まる範囲を小さくする第一歩になります。

承認・署名・送信を、誰が受け持つか

次に、署名の運用を3つの役割に分けます。承認する仕組み、署名する装置、送信する仕組みです。

役割	受け持つこと	1つだけに任せないこと
承認する仕組み（制御面）	要求者の認証、リスク判定、承認、上限、変更管理	秘密鍵・シェア（MPCで分散した鍵の断片）の直接利用
署名する装置（署名面）	許可済みのダイジェスト（署名対象のハッシュ値）への署名、鍵・シェアの隔離	送金してよいかの業務判断を自分で下すこと
送信する仕組み（実行面）	nonceの管理、送信、受領記録（receipt）の取得、確定（finality）の確認、突き合わせ	時間切れだけを理由にした再署名・再送

それぞれが残す証拠は、後半の「実装する人向けの詳細」にまとめました。

冒頭の1つ目の心配への答えがここにあります。署名する装置が「承認済み」という印を信じるだけでは、分けた意味がありません。署名する側でも、中身を確かめます。

チェーンID、送付先、呼び出す関数（function selector）
金額、nonce、期限
承認ID

こうしておけば、承認の仕組みが改ざんされても、そのまま何にでも署名してしまうことを防げます。

さらにオンチェーン側にも、役割、上限、一時停止、タイムロックを置きます。オフチェーンのルールをすり抜けた署名があっても、影響を限られた範囲にとどめられます。

HSMとMPCは「どこが壊れたら困るか」で選ぶ

2つの違いを短くまとめると、次のとおりです。

HSM：鍵を、壊して取り出しにくい装置か、マネージドのクラスタの中に置く。署名もその中で行う。
MPC（閾値署名）：秘密情報を複数の参加者に分け、必要な数が参加して署名を作る。通常は、秘密鍵の全体を1か所に戻さない（NIST Multi-Party Threshold Cryptography project）。
どちらも防げないこと：正しい鍵で、誤った取引に署名すること。

選ぶときの注意が3つあります。

1つ目は、標準の状況です。NIST IR 8214Cは、2026年1月に参考資料づくりのための提案を募集した段階の文書です。そのため、「MPC」という名前だけでは、標準への準拠も、実装の安全性も示せません。

2つ目。製品の中の複数人承認にも範囲があります。AWS CloudHSMのような製品の複数人承認は、申請が妥当か、送金先が許可リストにあるか、取引の上限、オンチェーンの役割までは確かめません。

3つ目。MPCでも、すべての参加者を同じクラウドアカウントと、同じCI用の認証情報で動かすとどうなるか。1か所が破られたり止まったりすれば全体に及ぶ、単一障害点に戻ってしまいます。

信頼の境界、可用性、移行・復旧、承認、採用しない条件で比べた表は「機関投資家向け暗号資産カストディ設計」にまとめています。マルチシグを含めた3方式の責任の分け方も、同じ記事で扱っています。MPCの基本は「秘密鍵管理にMPCが必要な理由」を参照してください。ここからは、どちらを選んでも必要になる署名サービス側の設計を続けます。

時間切れのとき、二重に送らないためには

冒頭の2つ目の心配です。署名や送信が時間切れになっても、実際には署名ができていて、取引も送られていることがあります。そこで作り直して送れば、同じ送金が二重に出ていきます。時間切れを、失敗と決めつけてはいけません。

そのため、本番で頼りにする記録は「署名済みかどうか」の二択ではありません。要求から確定までの、どの段階にいるかです。どの要求にも、次のものを持たせます。

一意な要求ID（request_id）と、署名するデータを整えたうえでのハッシュ
チェーンID、nonce、ルールの版
有効期限

1本の要求は、作成、検証、承認、署名中、署名済み、送信済み、取り込み済み、確定、と進みます。途中で却下・期限切れになることもあります。段階の一覧と、やり直してよい条件は後半の表にまとめました。

署名中に時間切れになったら、先に記録を突き合わせます。HSMの監査ログ、MPCの取りまとめ役（coordinator）と各参加者、署名のデータベースです。署名が存在しないと確かめられるまで、計算し直しません。

送信の時間切れも同じです。ノード、mempool（未処理の取引の待合所）、nonce、受領記録を確かめてから動きます。同じ操作が二重に実行されるのを防ぐためです。送金全体の状態管理と、突き合わせまでの流れは、カストディ設計の記事で詳しく扱っています。

オンチェーンには何を置き、何を置かないか

個人情報、承認のコメント、社内のリスク評価、組織図を、オンチェーンに置く必要はありません。

一方で、コントラクトが最後に拒否できなければ、守りが残りません。オフチェーンのルールが破られたときに、止めるものがなくなるからです。OpenZeppelinのAccessControlでは、役割を分けられます。TimelockControllerでは、提案から実行までの待機時間を強制できます。

オンチェーン：管理者・アップグレード担当・一時停止担当などの役割、マルチシグの閾値、重要な操作のタイムロック、上限、nonce、一時停止の状態、実行イベント。
オフチェーン：人の所属、承認理由、リスク判定、申請チケット、端末・ネットワーク情報、シミュレーション結果、インシデントの記録。
両者を結ぶ値：操作ID、calldata（コントラクトへ渡す入力データ）のハッシュ、ルールの版または承認記録のハッシュ。機密情報そのものは公開しない。

緊急停止を、通常のアップグレード鍵と同じ道にしていたとします。その鍵が破られると、攻撃者を止める手段まで一緒に失います。そのため、緊急停止は別の道にします。

一時停止の権限は、被害を限るだけの狭いものにします。解除、資産移転、アップグレードは、より高い閾値とタイムロックの側に戻します。

1つの外部所有アカウント（EOA：普通の秘密鍵で動くアカウント）を、最上位の所有者として残す場合もあります。その鍵が破られると、ほかの守りを迂回できてしまいます。移行の期間と、廃止する条件をはっきり書いておきます。

待機時間の長さや、緊急権限の決め方は「マルチシグ・タイムロックによる本番権限管理」で詳しく扱っています。MPCとAccount Abstractionの層の違いは「MPCウォレット×Account Abstraction」をご覧ください。

どんな障害を平時に試しておくか

復旧のための権限も、本番の権限と同じくらい大事に扱います。次の5つの障害を、平時に再現しておきます。

障害	損失を広げない動き	復旧できたと言える証拠
ルールを判定するサービスの乗っ取り	署名する側の独立した検証とオンチェーンの上限で拒否	改ざんされた要求が署名・実行されない
HSMクラスタ／MPC参加者の停止	待ち行列を保持し、閾値に足りなければ署名しない	目標復旧時間内に復旧し、重複署名や順序の逆転がない
鍵・シェアが漏れた疑い	影響する役割を一時停止し、新しい鍵へ権限を移す	旧鍵が無効、残った要求を再承認、全チェーンで突き合わせ
クラウド・製品提供者の全停止	非常用の復旧経路（break-glass）を隔離環境で起動	文書だけでなく、実際の署名と役割の移行までやり切る
チェーンの混雑・再編成	nonceと置き換えを1か所で管理し、確定を待つ	二重実行がなく、期待したイベントと業務台帳が一致

再編成（reorg）は、チェーンの直近のブロックが別のものに置き換わることです。

目標復旧時間（RTO）と、どの時点までのデータ損失を許すか（RPO）は、鍵の基盤だけに決めるものではありません。承認のデータベース、nonce、処理待ちの行列、ルール、監査ログにも決めます。

AWS CloudHSMは、クラスタ内の鍵の同期とバックアップを提供しています。ただ、バックアップがあることと、目標時間内に復旧できることは別の話です。復旧には、権限管理、ネットワーク、アプリケーションも含まれます。

PoCで確かめる10の証拠

PoCでは、署名の速さより先に、次の10項目を確かめます。

許可した楕円曲線、ハッシュ、署名形式が、対象チェーンのテストベクター（検証用の入出力例）と一致する。
署名の前に、人が読める操作内容と、生のcalldataのハッシュを突き合わせられる。
要求者、承認者、ルール変更者、署名基盤の管理者、監査者が分かれている。
同じクラウドアカウント、端末、認証基盤（IdP：ログインを受け持つ仕組み）、秘密情報の保管庫が、閾値全体を同時に破れない。
上限超過、未知のコントラクト、誤ったチェーン、期限切れ、nonceの競合を拒否する。
署名・送信が時間切れになった後も、二重に実行しない。
HSM／MPCの一部が止まっても、決めた可用性を満たす。足りないときは署名しない（判断できないときは止まる）。
鍵の更新、参加者の交代、鍵が漏れた疑い、全リージョンの喪失、製品提供者からの退出を、実地で試す。
オンチェーンのイベント、取引の受領記録、署名ログ、承認ログ、業務台帳を、要求IDで追える。
非常用の復旧経路を使った後に旧経路を無効にし、通常運用へ安全に戻せる。

応答時間と処理量は、この安全条件を満たしたうえで測ります。前半で見たとおり、鍵とルールを分けた方が、止まる範囲を小さくできます。同じ理由で、毎日の大量の署名と、まれだが影響の大きい操作は、サービス水準（SLA）も分けます。

ウォレット方式の全体像は「ブロックチェーンウォレットの導入・開発と運用設計」で解説しています。脅威分析と監査を含むセキュリティの全体像は「Web3セキュリティ」を参照してください。DeFiの操作ごとに承認内容を固める方法は「機関DeFiの取引承認とウォレット権限」で扱っています。

実装する人向けの詳細

3つの役割が残す証拠

承認する仕組み（制御面）：要求ID、承認者、ポリシーの版、署名対象データのハッシュ
署名する装置（署名面）：鍵ID、アルゴリズム、署名時刻、装置の真正性の証明（attestation）・監査ログ
送信する仕組み（実行面）：チェーンID、nonce、トランザクションハッシュ、受領記録、確定したブロック

署名要求の状態

時間切れと失敗を分けるため、要求を次の状態で管理します。

状態	完了条件	やり直してよい条件	禁止事項
作成（`DRAFT`）	目的、対象、金額、期限を作成	編集できる	署名面へ送らない
検証済み（`VALIDATED`）	事前実行（シミュレーション）、許可リスト、残高、nonceを確認	入力が変わったら再検証	シミュレーション結果だけで承認しない
承認済み（`APPROVED`）	必要な独立した承認とポリシーの版が一致	期限内で、署名対象データが同一の場合だけ	承認後のcalldataの差し替え
署名中（`SIGNING`）	HSM／MPCへ一意なダイジェストの署名を依頼	署名記録を照会した後	時間切れの直後に別の要求を作る
署名済み（`SIGNED`）	公開鍵で検証し、low-sなどチェーンの要件を確認	同じ署名を再利用できるか判定	検証していない署名を送信する
送信済み（`SUBMITTED`）	トランザクションハッシュと送信先ノードを記録	同じnonceで、置き換えの規則の範囲内	新しいnonceで同じ操作を二重に送る
取り込み済み（`CONFIRMED`）	受領記録と、期待したイベント・状態を確認	チェーンの再編成（reorg）の監視を続ける	HTTPの成功を業務完了とみなす
確定（`FINAL`）	定義した確定条件とオフチェーンの照合を満たす	やり直さない	履歴の上書き
却下・期限切れ（`REJECTED / EXPIRED`）	理由、取り消した人、時刻を保存	新しい要求として申請し直す	古い承認の流用

XTELAができること

私たちXTELAは、署名対象と権限の棚卸し、HSM・MPCを含む構成の比較、ポリシーと署名要求の状態管理、監視の仕組み、スマートコントラクト側の権限設計を一続きで設計・開発しています。relayerや管理者鍵の署名サービスについて、障害と復旧を含むPoCの受入試験から本番運用まで一緒に組み立てます。貴社の署名基盤を見直したい場合は、お問い合わせからご連絡ください。

参考資料

資料の確認日と注意：仕様・一次資料は2026年8月12日に最終確認しました。一般的な技術・運用設計の解説です。カストディへの該当性や、法令・契約上の責任、会計・税務の判断は、弁護士・会計士等の専門家にご確認ください。

記事一覧

管理者鍵やrelayer、決済ウォレットの鍵をHSMやMPCに移した決済サービスの担当者へ。鍵が盗まれなくても資産を失う2つの事故、承認・署名・送信の受け持ちの分け方、HSMとMPCの選び方、時間切れで二重に送らない手順、オンチェーンの守り、障害の試験を解説します。