パスキー構造・保存場所・制度設計・初回登録・本人確認・多端末管理についてまとめた。
1. 認証構造：パスキーの技術設計
パスキーはFIDO2/WebAuthnを基盤とする認証方式である。端末ごとに生成される公開鍵・私有鍵のペアによって構成され、認証時には端末内の私有鍵で署名を行い、サービス側は登録済みの公開鍵で署名の妥当性を検証する。
flowchart TD
Step1[① ユーザーがログイン要求] --> Step2[② サービスがチャレンジ送信]
Step2 --> Step3[③ 端末が私有鍵で署名]
Step3 --> Step4[④ 署名＋公開鍵をサービスへ返送]
Step4 --> Step5[⑤ サービスが署名を検証]
Step5 --> Step6[⑥ 認証成功]私有鍵は端末のセキュア領域（Secure Enclave / TPMなど）に格納され、外部に漏れることはない。
2. OS別：保存場所の構造比較
| プラットフォーム | 保存場所 | 同期方式 | 備考 |
|---|---|---|---|
| Android | Googleパスワードマネージャー（Secure Hardware） | Googleアカウント | Android 9以降、画面ロック必須 |
| iOS / iPadOS | iCloudキーチェーン（Secure Enclave） | Apple ID | iOS18以降は「パスワード」アプリで管理 |
| macOS | iCloudキーチェーン（Secure Enclave） | Apple ID | Sonoma以降は「パスワード」アプリで表示可能 |
| Windows PC | TPM / Windows Hello / FIDO2セキュリティキー | Microsoftアカウント（一部制限あり） | Windows 11以降でFIDO2ネイティブ対応 |
| Ubuntu | ローカルファイル or セキュリティキー | 同期なし | OSレベル統合管理なし。FIDO2認証は可能 |
保存場所はOSの設計方針・セキュリティモデルに依存し、クラウド同期・ローカル格納・セキュリティキー型のハイブリッド構成となる。
3. マイナンバーカードとの比較：保存方式・制度背景
パスキーが民間標準に基づく認証技術である一方、マイナンバーカードは法制度に基づく公的な本人確認手段である。両者の保存場所と技術基盤を以下に構造的に比較する。
| 項目 | パスキー | マイナンバーカード（スマホ版含む） |
|---|---|---|
| 保存対象 | 私有鍵（FIDO2） | 電子証明書（署名・利用者証明） |
| Android端末 | Googleパスワードマネージャー | GP-SE（GlobalPlatform Secure Element） |
| iOS / macOS | iCloudキーチェーン | Appleウォレット（Secure Enclave） |
| Windows端末 | TPM / セキュリティキー | ICカードリーダー一時利用（スマホ未対応） |
| Ubuntu等 | ローカルファイル / セキュリティキー | 非対応（JPKIクライアントはWindows中心） |
| 技術基盤 | WebAuthn / FIDO2 | JPKI / X.509証明書構造 |
| 認証方式 | 生体認証＋公開鍵署名 | PIN＋電子証明書＋生体認証（スマホ版） |
| 制度的背景 | 民間標準（FIDO Alliance） | 法制度準拠（住基法・JPKI法） |
| 利用目的 | Webログイン | 本人確認・署名・証明書取得 |
4. 初回登録時の脆弱性：信頼できない端末と制度的担保
パスキーは端末依存の構造であるため、初回登録が信頼できない端末で行われた場合、私有鍵が攻撃者の端末に格納される。その結果、以後の認証要求が攻撃者の端末から正当とされる構造上のリスクが存在する。
この問題に対して、技術側では以下の対応が限定的に行われている：
- 生体認証や端末ロックによる私有鍵アクセス制限
- OSのSecure Enclave / TPMによる鍵領域保護
しかし、端末乗っ取りや、初回登録時点でのなりすましリスクに対して、制度的対応は不足している。
5. 登録時の本人確認：OTP／公的証明の必要性
現在の多くのサービスでは、パスキー登録時に以下のような本人確認手段が使われている：
- OTP（SMSによる確認コード）
- 既存のパスワードやメール認証
これらは制度的な本人確認とは異なり、技術的トークンによる帰属確認に過ぎない。FIDO2自体には登録フェーズでの本人性担保機能が内在していないため、外部の認証手段による補完が必要になる。
制度的強度を持たせるには以下の設計が必要。
- 登録時にマイナンバーカードによるJPKI本人認証を要求
- 登録済みパスキーに「制度的本人証明済」の属性を付与
- 端末情報・登録履歴の制度的管理・監査ログの確保
6. 多端末運用と制御：登録数・同期・削除
パスキーはユーザーが複数端末に登録可能。OSのクラウド同期機能（Apple ID、Googleアカウント）により共有される場合もあれば、手動登録（QRコード経由、既存端末からの承認）となる場合もある。
| 管理項目 | 運用構造 |
|---|---|
| 登録数の上限 | 多くのサービスは10件前後に制限可能 |
| 削除操作 | OSやサービス側で個別に削除可能 |
| 登録履歴 | 一部サービスで閲覧可能（例：CloudGate UNO） |
| 異なるOS間の同期 | 手動登録（自動同期不可） |
制度的対応としては、以下の制御が必要。
- 端末追加時の当人確認（JPKI・SMSなど）
- 登録履歴の表示と失効管理
- 制度的ラベルや有効期限の設定
7. 技術と制度の融合による認証設計の方向性
現行のパスキー設計は操作負担の軽減と利便性を重視しており、制度的な本人確認の機能を内包していない。一方、公的個人認証は制度的信頼性を担保するが、操作面での負荷が高く普及に課題がある。
これらの特徴を踏まえた設計案。
- パスキーによる操作性と、JPKIによる本人証明のハイブリッド設計
- パスキー登録時にJPKIを用いた本人確認フローの義務化
- 生体認証ログインと電子証明書署名を役割分担させた認証基盤
制度と技術の融合設計により、本人確認・署名・認証を統合した信頼性の高いデジタルサービス基盤が形成される。
