デジタルウォレットは、暗号資産を表示する画面だけを意味しない。デジタル署名に必要な鍵やVerifiable Credentialsを管理し、利用者の意思に基づいて署名・提示する役割を持つ。本記事では、鍵管理とMPCの位置付けを整理する。
1. 基礎概念
公開鍵暗号では、秘密鍵で署名し、対応する公開鍵で署名を検証する。秘密鍵を失えば署名できなくなり、第三者に奪われれば本人になりすまして署名される可能性がある。
Walletの管理方式は、大きく次のように分けられる。
- Custodial：事業者が利用者に代わって鍵を管理する
- Non-custodial：利用者側が鍵を管理する
- Hybrid：利用者と事業者、複数端末などで管理責任を分ける
Custodial方式は復旧やサポートを提供しやすいが、管理事業者へ権限とリスクが集中する。Non-custodial方式は利用者の制御を強められる一方、端末紛失やバックアップ管理の負担が大きい。
MPC（Multi-Party Computation）は、複数の参加者が各自の秘密情報を公開せずに共同計算を行う暗号技術である。Walletでは、秘密鍵を一か所へ完成形で保存せず、複数のKey Shareを使って署名するThreshold Signature方式などに利用される。
MPCとMulti-signatureは同じではない。Multi-signatureは複数の独立した秘密鍵で複数署名を作り、台帳や検証側が必要数を確認する。MPCベースのThreshold Signatureは、複数のShareから通常形式の単一署名を共同生成できる場合がある。
2. 技術フロー
2-of-3のThreshold構成を概念的に表すと、次のようになる。
利用者端末：Key Share A ─┐
├─ 2者以上が署名計算に参加
復旧用端末：Key Share B ─┤
│
事業者側 ：Key Share C ─┘
│
▼
完成した署名
│
▼
公開鍵で検証署名時に一つの場所へ完全な秘密鍵を復元する必要がない構成なら、単一端末の侵害だけでは署名を完成できない。ただし、安全性はMPCプロトコルだけでなく、Shareの生成・保存場所、参加者認証、通信路、端末セキュリティ、復旧手続きに依存する。
Credential Walletの場合、鍵管理に加えて、Credentialの暗号化保存、提示前の同意確認、どのClaimを開示するか、バックアップ時にCredentialをどう扱うかも設計対象になる。
3. 何を解決できる技術か
MPCを使った鍵管理は、秘密鍵の単一障害点を減らし、セキュリティと復旧性の両立を図る手段になる。利用者端末と事業者側へShareを分ければ、事業者単独または端末単独での不正署名を難しくできる。端末交換時に所定の本人確認を経てShareを再構成する設計も可能になる。
しかし、MPCはWalletのすべての問題を解決しない。端末上で利用者が不正な署名内容を承認させられる問題、事業者によるサービス停止、複数Shareの同時侵害、復旧手続きへのなりすましは残る。また、方式によって性能、対応署名アルゴリズム、実装複雑性が異なる。
鍵管理方式は「自己主権性が高いほど優れている」と一方向に決めるものではない。保護対象、想定利用者、復旧要件、事業者への信頼、操作性を踏まえて選ぶ必要がある。
鍵管理をシステムとして捉える
Walletは鍵の保管庫だけでなく、何に署名するかを示すTrusted User Interfaceでもある。暗号が安全でも、「ログイン」と表示しながら資産移転を署名させれば利用者を守れない。署名対象、送信先、権限、有効期間を構造化して表示する必要がある。
鍵の保護にはSecure Enclave、Trusted Execution Environment、Hardware Security Moduleも使われる。これらはMPCと排他的ではない。各Shareを保護領域へ置き、端末認証後だけProtocolへ参加させる構成も可能である。
Seed Phraseは単語列から鍵を復元できるが、取得者がWalletを複製できる。MPCではSeed Phraseを見せずに復旧を構成できる場合があるが、参加者と復旧Policyへの依存が生まれる。
`2-of-3`は三つのShareのうち二つで署名できる。可用性は高まるが、攻撃者も二つを侵害すればよい。`3-of-3`は単独侵害に強い一方、一つを失うと署名不能になる。Thresholdはセキュリティと可用性のPolicyである。
鍵生成には完成鍵を作って分割する方法と、Distributed Key Generationで共同生成する方法がある。後者は完成した秘密鍵を一か所へ存在させないが、Protocolは複雑になる。
署名時には全参加者が同じメッセージ、鍵ID、取引文脈へ合意する必要がある。悪意ある参加者、通信改ざん、Nonce再利用を考慮しなければ、Share漏えいや不正署名につながる。
端末紛失時には、失われたShareを無効化し、新端末へ再配布する。復旧担当者が単独でなりすませないよう、本人確認、待機期間、通知、既存端末からの拒否機会を組み合わせる。
Credentialと鍵のバックアップ要件も異なる。鍵を復旧しても端末だけに保存したCredentialは戻らず、Credentialを復元してもHolder Bindingされた鍵を失えば提示できない。鍵移行、再発行、失効を一つの復旧フローとして扱う。
事業者側Shareがなければ署名できない設計では、鍵を分散してもサービス依存は残る。MPCは実装難度も高いため、監査済み実装、鍵生成から廃棄までのThreat Model、端末侵害と内部不正を含む試験が必要になる。
Wallet設計で先に決めること
最初に保護対象を定義する。資産移転、ログイン署名、Credential提示では、誤署名時の損害と取り消し可能性が異なる。高額移転には複数人承認や待機時間が必要でも、日常ログインで毎回同じ操作を求めれば利用不能になる。
次に攻撃者を定義する。端末泥棒、マルウェア、事業者内部者、クラウド管理者、フィッシングサイトでは対策が異なる。Shareを二か所へ置いても、同じクラウド管理権限で双方へアクセスできるなら実質的な分離ではない。
生体認証は多くの場合、端末内の鍵利用を解放する操作であり、生体情報自体が外部へ送信されるわけではない。端末ロック解除に成功した事実と、署名内容へ利用者が同意した事実も同一ではない。
監査では秘密情報を残さず、どの鍵Policyで、どの端末群が、いつ、どの要求へ参加したかを追跡できるようにする。不正疑い時はShare停止、鍵更新、Credential失効、利用者通知を連動させる。
評価指標には署名成功率、処理時間、復旧完了率、誤拒否、端末移行率、サポート件数を含める。暗号強度だけでなく、正規利用者が安全に使い続けられるかを測る必要がある。
参考資料
- [NIST Multi-Party Threshold Cryptography](https://csrc.nist.gov/projects/threshold-cryptography)
- [Web Authentication: An API for accessing Public Key Credentials Level 2](https://www.w3.org/TR/webauthn-2/)
