ウォレットインフラとセキュリティモデル
業界の背景
ウォレットシステムは通常、秘密鍵を保護するために、1つ以上の基礎的な暗号方式に依存しています。これらのアプローチを理解することで、本ドキュメントで説明するセキュリティモデルの文脈が得られます。
Shamir's Secret Sharing (SSS)
SSS は秘密鍵を複数のシェアに分割し、元を復元するには最低限の閾値が必要です。完全な秘密性を提供します — 閾値未満のシェアのいくつであっても、鍵について何も明かしません。SSS は成熟しており、ツールが豊富で、高速です（署名 20–40ms）。トレードオフは、署名のために秘密鍵を完全に再構成する必要があり、再構成の瞬間に単一障害点が生じることです。
Threshold Signature Schemes (TSS)
TSS（一般に MPC として知られる）は、複数の当事者が秘密鍵を再構成しないまま共同で署名を生成できます。これにより SSS の再構成リスクがなくなります。トレードオフは未成熟さ — 最初の効率的な二当事者 ECDSA プロトコルは 2017 年に登場したばかり — と性能です。各署名にはネットワークの往復が伴い、遅延は数秒に達することがあります。
Trusted Execution Environments (TEE)
TEE はハードウェアのエンクラベ内で暗号操作を実行し、鍵素材が露出しないこと、認可されたコードのみが動作することを保証します。クライアントはアテステーションを通じて操作を検証できます。TEE はスケールしやすく、TSS の往復遅延を避けられますが、そのセキュリティはエンクラベの整合性に依存し、歴史的にサイドチャネル攻撃に脆弱でした。
WebAuthn PRF 拡張
WebAuthn PRF（Pseudo-Random Function）拡張は、ユーザーのパスキー用ハードウェアから — Apple デバイスでは Secure Enclave、Windows では TPM、Android では Titan chip — 決定論的な秘密を導出します。この秘密はデバイスとユーザーの生体認証または PIN に紐付けられ、認証時にデバイス上で計算され、決して送信されません。サーバーが一度も見たことがない秘密で鍵素材を暗号化できるウォレット設計のクラスを可能にします。
三者による鍵保護
概要
本システムでは秘密鍵は完全な形で保存されません — ユーザーのデバイスにも、当社のサーバーにも、どこにもありません。代わりに、鍵素材は 3-of-3 secret sharing 方式により、3つの独立した当事者間で暗号的に分割されます。鍵を復元するには3者すべての協力が必要です。3未満では、秘密鍵について数学的にゼロの情報しか得られません。
これはハイブリッドモデルです：パスキーに基づくクライアント側暗号化（PRF-as-KEK）、秘密分散、分離されたサーバー側のエンクラベを1つのアーキテクチャに組み合わせています。得られる構成は、Shamir's Secret Sharing と同じ情報理論的セキュリティ保証 — 閾値未満の当事者の部分集合は鍵について一切の情報を得ない — を達成しつつ、1つのシェアをユーザーの物理的な認証器ハードウェアに紐付けるため、サーバー側の侵害だけでは鍵を再構成できません。
これは、すべてのモダンなデバイス（iOS、macOS、Android、Windows の主要ブラウザすべて）におけるデフォルトのセキュリティモデルです。
三者
当事者1 — ユーザーの認証器
ユーザーのパスキー用ハードウェアは、そのデバイスとユーザーの生体認証または PIN に紐付いた決定論的な秘密を計算します。この出力 — PRF output と呼ばれます — は認証時にデバイス上で生成され、どこにも送信されません。保存もされず、ログにも残りません。署名操作の間だけ RAM 上に存在します。
この秘密は、鍵復元におけるユーザーの寄与です。これがなければ、他の2者は利用可能な秘密鍵を生成できる素材を何も持ちません。
当事者2 — API
API はユーザーの鍵素材の暗号化コピーを保存しています。それはユーザーの PRF 由来の秘密で暗号化されており、API はその秘密を一度も見ていません。API はアクセスを制御します — ユーザーが登録したパスキーで署名された有効な WebAuthn アサーションを提示したリクエストに対してのみ、この暗号化ペイロードを開示します。ただし、API 自身はペイロードを復号できません。
API は認証付きの配送メカニズムとして機能し、鍵の保管者ではありません。
当事者3 — 暗号エンクラベ
API とは独立して動作し、独自の暗号鍵とインフラを持つ、別の分離システムがサーバー側のキーシェアを保持しています。このシェアは、エンクラベのみが知る秘密で保存時に暗号化されています。エンクラベは、アサーション検証を通過したリクエストに対してのみ復号済みシェアを開示し、最終署名ステップでユーザーのシェアと結合するためだけに開示します。
エンクラベは、ユーザーの PRF 出力、ユーザーのキーシェア、または組み立てられた秘密鍵のいずれも見ることはありません。
セキュリティ特性
単一障害点なし
| シナリオ | 結果 |
|---|---|
| ユーザーのデバイス盗難 | 攻撃者は生体認証／PIN を再現できない；PRF output は取得できない |
| API が完全侵害 | 攻撃者が得られるのは、一度も見たことのない秘密で暗号化された暗号文のみ |
| エンクラベが完全侵害 | 攻撃者は鍵の1シェアを得る；もう1つのシェアは侵害された両システムのいずれにもない |
| API とエンクラベの両方が侵害 | 攻撃者は暗号化されたユーザーペイロードとサーバーシェアを得る — それでも物理的な認証器からの PRF output なしにはユーザーペイロードを復号できない |
最後のシナリオが決定的です。サーバー側インフラの完全な侵害であっても、秘密鍵の再構成には不十分です。ユーザーの認証器は、サーバー側の侵害では迂回できない暗号学的ゲートです。
情報理論的セキュリティ
ハイブリッドモデルは、Shamir's Secret Sharing と同種のセキュリティ保証を継承します：鍵の分割は計算上安全なだけではなく — 情報理論的に安全です。無限の計算能力を持つ攻撃者が、3者のうち任意の2者の素材を保持していても、秘密鍵についての情報は得られません。時間やハードウェアをいくら費やしても、2者のデータだけから鍵を導くアルゴリズムは存在しません。これはワンタイムパッドが提供するのと同じ保証です。
設計上ノンカストディアル
当社は API とエンクラベの両方を運用しています。それでも、一方的にユーザーの資金にアクセスすることはできません。ユーザーの PRF output が欠けたピースです — ユーザーのハードウェア内で生成され、決して送信されません。資金にアクセスできないことはポリシーや利用規約上の約束ではありません。内部アクセス制御、規制上の圧力、インフラの侵害に関係なく成り立つ、数学的制約です。
トランザクションの署名方法
すべての署名はユーザーのデバイス上で行われます。秘密鍵はいかなるサーバー上でも組み立てられません。
- ユーザーがアプリでトランザクションを承認します。デバイスが生体認証または PIN でユーザーを認証します。
- デバイスがハードウェアに紐付いた PRF 秘密をローカルで計算します。この秘密はデバイスから外に出ません。
- アプリが API から暗号化されたユーザーペイロードを、エンクラベからサーバーシェアを取得します。どちらも単体では利用できません。
- ユーザーのデバイス上、RAM 内で：ハードウェア秘密がユーザーペイロードを復号し、ユーザーのキーシェアが得られます。2つのシェアが完全な秘密鍵に結合されます。
- 秘密鍵がトランザクションに署名します — すべてデバイス上で。
- 秘密鍵は直ちに RAM から消去されます。キャッシュも永続化もログもされません。
完全な秘密鍵はミリ秒単位の間だけ存在し、ユーザーのデバイス上のみ、署名操作中のみです。サーバーはそれを一度も見ません。
秘密鍵のエクスポート
ユーザーが秘密鍵をエクスポートする場合 — 例えば別のウォレットへ移行するため — も同じ原則が適用されます。鍵の復元と受け渡しはすべてユーザーのデバイス上で行われます。 サーバーは暗号化されたシェアを提供しますが、復号と組み立てはローカルで行われます。エクスポートの過程で、秘密鍵がいかなるサーバーを通過したり、サーバーから見えたりすることはありません。
パスキーの同期とクロスデバイスアクセス
モダンなプラットフォーム — Apple の iCloud Keychain、Android の Google Password Manager — は、ユーザーのデバイス間でパスキーを同期します。鍵復元に用いるハードウェアに紐付いた秘密は、同期されたパスキー素材の一部であるため、ユーザーの同期グループ内の任意のデバイスで同じ PRF output を再現できます。これにより、デバイスをまたいでも三者セキュリティモデルが維持されます：同期されたデバイスはいずれも署名に参加でき、サーバー側アーキテクチャを変える必要はありません。
パスキーがクラウドアカウントに同期されているかどうかはユーザーに通知されるため、ウォレットの復元可能性を常に把握できます。
PRF は iOS 18+、macOS Sequoia 15.4+、Android 14+、および YubiKey 5 シリーズで利用できます。PRF をサポートしないプラットフォームでは、サーバー側署名のフォールバックが用いられます。
従来のウォレットセキュリティとの比較
| モデル | 秘密鍵の所在 | 資金にアクセスできる者 |
|---|---|---|
| 標準的なセルフカストディ（シードフレーズ） | ユーザーが保管 | シードフレーズを持つ者 |
| 取引所／ホットウォレットのカストディ | 事業者が保管 | 事業者（および事業者を侵害した者） |
| ハードウェアウォレット | デバイス上 | 物理デバイスと PIN を持つ者 |
| 本システム | 完全な形では保存されない | ユーザーのライブな認証器とサーバーインフラが同時に必要 |
まとめ
このハイブリッドモデル — PRF に基づくクライアント側暗号化、秘密分散、分離されたエンクラベの組み合わせ — は、信頼を実質的に独立した3当事者に分散し、2者の部分集合では秘密鍵を再構成できず、Shamir's Secret Sharing と同じ情報理論的セキュリティ保証をもたらします。ユーザーの生体認証に紐付いたハードウェア秘密が、システム全体の暗号学的アンカーです。サーバー側インフラがどれほど徹底的に侵害されても、ユーザーの物理的な参加なしに有効な署名を生成することはできません。