商用環境でのアテステーション検証
概要
本ドキュメントでは、FIDO2 アテステーション検証を商用環境で運用する際の考慮事項を解説します。
このドキュメントで学べること:
- アテステーション検証を導入する前に決めるべきポリシー
- 認証器の多様性による問題と対処法
- 証明書関連のトラブルシューティング
- ユーザー影響を考慮した設計
- 運用時のベストプラクティス
対象読者:
- システム設計者
- インフラ/運用担当者
- セキュリティ担当者
📖 アテステーションの基礎については Attestation - 認証器の信頼性証明 を参照してください。
事前に決めておくべきポリシー
アテステーション検証を導入する前に、以下のポリシーを決定しておく必要があります。
ポリシー決定マトリクス
| 項目 | 内容 | 選択肢 | 推奨（一般） | 推奨（高セキュリティ） |
|---|---|---|---|---|
| Attestation Conveyance | 認証器に attestation 送信を要求するか | none / indirect / direct / enterprise | none | direct |
| Self Attestation | 証明書なしの自己署名を許可する か | 許可 / 拒否 | 許可 | 要検討 |
| fmt="none" | attestation なしの登録を許可するか | 許可 / 拒否 | 許可 | 拒否 |
| FIDO 認定レベル | 要求する最低認定レベル | 不問 / L1以上 / L2以上 | 不問 | L1以上 |
| 未知の認証器 | MDS に存在しない認証器を許可するか | 許可 / 拒否 | 許可 | 拒否 |
| 検証失敗時 | 検証エラー時の挙動 | 拒否 / 警告のみ | 警告のみ | 拒否 |
| 証明書検証方式 | ルート CA の管理方法 | TrustStore / MDS / 併用 | MDS | 併用 |
Attestation Conveyance の選択
┌─────────────────────────────────────────────────────────────────────────────┐
│ Attestation Conveyance の選択基準 │
├─────── ──────────────────────────────────────────────────────────────────────┤
│ │
│ 【none を選ぶべきケース】 │
│ - 一般消費者向けサービス │
│ - ユーザーのプライバシーを最優先 │
│ - 認証器の種類を制限したくない │
│ - パスワードレス認証の普及が目的 │
│ │
│ 【direct を選ぶべきケース】 │
│ - 企業の社内システム │
│ - 金融・医療など規制業界 │
│ - 特定の認証器のみを許可したい │
│ - 監査で認証器の種類を証明する必要がある │
│ │
│ 【enterprise を選ぶべきケース】 │
│ - 認証器を会社資産として管理 │
│ - 紛失・盗難時に個体を特定したい │
│ - 従業員の同意のもとで使用 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
Attestation とプライバシー
「ユーザーのプライバシーを最優先」とは、認証器に関する情報を RP に送信しないことを意味します。
┌─────────────────────────────────────────────────────────────────────────────┐
│ Attestation で RP に伝わる情報 │
├──────────────────────────────────────────────────────────────────────── ─────┤
│ │
│ 【AAGUID から分かること】 │
│ - 認証器のモデル・製品名 │
│ - 例: 「このユーザーは YubiKey 5 NFC を使っている」 │
│ │
│ 【証明書チェーンから分かること】 │
│ - 製造元（Yubico、Apple、Google 等） │
│ - 製造時期・バッチ（証明書のシリアル番号等から推測可能な場合） │
│ - enterprise attestation の場合、認証器の個体識別情報 │
│ │
│ 【プライバシーリスクの具体例】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ │
│ 1. クロスサイトトラッキング │
│ - 複数のサイトで同じ AAGUID が観測される │
│ - 「サイト A とサイト B に同じ認証器でアクセスしている」と推測可能 │
│ │
│ 2. ユーザー属性の推測 │
│ - YubiKey → セキュリティ意識が高い、または企業ユーザー │
│ - 古いモデルの認証器 → 長期間使用している、または経済的理由 │
│ - 特定企業の認証器 → その企業の従業員である可 能性 │
│ │
│ 3. 標的型攻撃への悪用 │
│ - 認証器の既知の脆弱性を狙った攻撃 │
│ - 特定モデルを使うユーザーを狙ったフィッシング │
│ │
│ 【attestation="none" が保護するもの】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ - Attestation データを送信しない │
│ - AAGUID が 00000000-0000-0000-0000-000000000000 になることがある │
│ - RP は認証器の種類を知ることができない │
│ - ユーザーは「どの認証器を使っているか」を秘匿できる │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
一般消費者向けサービスでは、認証器の種類を知る必要がないケースが多いため、ユーザーのプライバシーを尊重して attestation="none" を選択することが推奨されます。
Self Attestation の扱い
┌─────────────────────────────────────────────────────────────────────────────┐
│ Self Attestation とは │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ Self Attestation は、認証器が生成した鍵ペアの秘密鍵自身で署名する方式 │
│ - x5c（証明書チェーン）が含まれない │
│ - 認証器の製造元を証明できない │
│ - AAGUID は含まれるが、偽装される可能性がある │
│ │
│ 【許可する場合】 │
│ - より多くの認証器をサポートできる │
│ - 一部の正規認証器も Self Attestation を使用する │
│ │
│ 【拒否する場合】 │
│ - 認証器の正当性を検証できないリスクを排除 │
│ - ソフトウェア認証器の悪用を防止 │
│ - ただし、利用可能な認証器が減る │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
未知の認証器の扱い
MDS に登録されていない認証器をどう扱うかは重要な決定事項です。
| 方針 | メリット | デメリット |
|---|---|---|
| 許可 | 新しい認証器にも対応できる | セキュリティレベルが不明 |
| 拒否 | 信頼できる認証器のみに限定 | 新製品への対応が遅れる |
| 警告付き許可 | バランスが取れる | ユーザー体験が複雑になる |
検証失敗時の挙動
┌─────────────────────────────────────────────────────────────────────────────┐
│ 検証失敗時の挙動設計 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【拒否（Strict モード）】 │
│ - 検証に失敗した場合、登録を拒否 │
│ - セキュリティは高いが、ユーザーが登録できないケースが発生 │
│ - 企業環境や高セキュリティ環境向け │
│ │
│ 【警告のみ（Permissive モード）】 │
│ - 検証に失敗しても登録は許可 │
│ - ログに警告を記録、監査用データとして保存 │
│ - 後からポリシーを厳格化する際のデータ収集に有用 │
│ - 一般消費者向けサービスの初期導入に適切 │
│ │
│ 【段階的導入の推奨】 │
│ Phase 1: 警告のみ（データ収集） │
│ Phase 2: 分析結果に基づきポリシー調整 │
│ Phase 3: 必要に応じて Strict モードへ移行 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
証明書検証方式の選択
証明書チェーン検証に使用するルート CA の管理方式を決定します。
┌───────────────────────────────────────────────────────────────────── ────────┐
│ 証明書検証方式の選択基準 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【TrustStore のみ】 │
│ - 手動でルート CA 証明書を収集・登録 │
│ - オフラインで動作可能 │
│ - 許可する認証器を厳格に管理したい企業環境向け │
│ - 新しい認証器への対応に手動作業が必要 │
│ │
│ 【MDS のみ】 │
│ - MDS から AAGUID に対応するルート CA を動的に取得 │
│ - 新しい認証器に自動対応 │
│ - MDS への依存（障害時に影響） │
│ - 多様な認証器をサポートしたい一般向けサービス向け │
│ │
│ 【併用（推奨）】 │
│ - 主要なルート CA は TrustStore に事前登録 │
│ - TrustStore にないものは MDS から取得 │
│ - MDS 障害時も主要な認証器は動作 │
│ - 高可用性が求められる本番環境向け │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
| 方式 | 運用負荷 | 可用性 | 新認証器対応 | 推奨ケース |
|---|---|---|---|---|
| TrustStore のみ | 高（手動更新） | 高 | 遅い | 認証器限定の企業環境 |
| MDS のみ | 低 | MDS依存 | 即時 | 一般向けサービス |
| 併用 | 中 | 高 | 即時 | 本番環境（推奨） |
認証器の多様性による問題
"direct" を要求しても "none" が返る
┌─────────────────────────────────────────────────────────────────────────────┐
│ Attestation が返らないケース │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ RP が attestation="direct" を要求しても、認証器やブラウザが │
│ fmt="none" を返すケースがある │
│ │
│ 【原因】 │
│ 1. ブラウザのプライバシー設定 │
│ - 一部のブラウザは attestation を自動的に削除する設定がある │
│ │
│ 2. 認証器の実装 │
│ - 一部の認証器は attestation をサポートしていない │
│ - プラットフォーム認証器はプライバシー保護のため none を返すことがある │
│ │
│ 3. ユーザーの選択 │
│ - ブラウザが「認証器情報を送信しますか？」と確認し、ユーザーが拒否 │
│ │
│ 【対処法】 │
│ - fmt="none" を許可するかどうかを事前に決定しておく │
│ - 許可しない場合、ユーザーに別の認証器を使うよう案内 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
プラットフォーム認証器の特性
| 認証器 | Attestation Format | 特記事項 |
|---|---|---|
| Windows Hello (TPM) | tpm | TPM 2.0 固有の構造。Microsoft の証明書チェーン |
| Windows Hello (非TPM) | none | TPM なしの環境では attestation なし |
| macOS Touch ID | apple | Apple 固有の形式。Safari でのみ動作 |
| iOS Face ID / Touch ID | apple | iCloud Keychain 経由の場合は異なる |
| Android | android-key または packed | デバイスにより異なる |
| Chrome プロファイル同期 | none | ソフトウェアベースのため attestation なし |
認証器のファームウェアバグ
実際の運用で報告されている問題例：
| 問題 | 影響 | 対処法 |
|---|---|---|
| 証明書の有効期限が不正 | チェーン検証失敗 | 該当 AAGUID を例外リストに追加 |
| AAGUID がゼロ埋め | 認証器を特定できない | fmt で判断、または許可 |
| 中間証明書の順序が不正 | チェーン構築失敗 | 証明書ソートロジックを実装 |
| 署名アルゴリズムの不一致 | 署名検証失敗 | アルゴリズム自動検出を実装 |
証明書関連のトラブル
よくある証明書エラー
┌─────────────────────────────────────────────────────────────────────────────┐
│ 証明書エラーの種類と対処 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【エラー1: ルート CA が TrustStore にない】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ 原因: 新しい認証器のルート CA が未登録 │
│ 症状: "Certificate chain validation failed: no trusted root" │
│ 対処: │
│ - MDS から最新のルート証明書を取得して TrustStore に追加 │
│ - または該当認証器を一時的に許可リストに追加 │
│ │
│ 【エラー2: 中間証明書の欠落】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ 原因: 認証器が x5c に中間証明書を含めていない │
│ 症状: "Unable to build certificate path" │
│ 対処: │
│ - MDS から中間証明書を取得してキャッシュ │
│ - 証明書パス構築時に MDS の証明書も参照するよう実装 │
│ │
│ 【エラー3: 証明書の有効期限切れ】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ 原因: ルート CA または中間 CA の証明書が期限切れ │
│ 症状: "Certificate has expired" │
│ 対処: │
│ - TrustStore の証明書を更新 │
│ - 認証器側の問題の場合、ベンダーに問い合わせ │
│ │
│ 【エラー4: 署名検証失敗】 │
│ ────────────────────────────────────────────────────────────────────────── │
│ 原因: attestation signature が不正、または検証ロジックのバグ │
│ 症状: "Signature verification failed" │
│ 対処: │
│ - 署名対象データの構築方法を確認 │
│ - 認証器のファームウェアバグの可能性を調査 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
証明書有効期限の監視
TrustStore 内の証明書の有効期限を監視し、事前にアラートを上げる仕組みを構築します。
┌─────────────────────────────────────────────────────────────────────────────┐
│ 証明書有効期限監視 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【監視項目】 │
│ - TrustStore 内の全ルート CA 証明書 │
│ - MDS BLOB の署名証明書 │
│ - キャッシュしている中間証明書 │
│ │
│ 【アラート閾値の例】 │
│ - 90日前: 情報通知（更新計画を開始） │
│ - 30日前: 警告（更新作業を実施） │
│ - 7日前: 緊急（即時対応が必要） │
│ │
│ 【対応フロー】 │
│ 1. ベンダーまたは MDS から新しい証明書を入手 │
│ 2. ステージング環境で TrustStore を更新してテスト │
│ 3. 本番環境に TrustStore をデプロイ │
│ 4. 古い証明書は猶予期間後に削除 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
運用中に発生するイベント
認証器の脆弱性が発覚した場合
┌────────────────────────────────── ───────────────────────────────────────────┐
│ 脆弱性発覚時の対応フロー │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────┐ │
│ │ MDS statusReports │ │
│ │ で脆弱性を検知 │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ 影響範囲を特定 │ │
│ │ - 該当 AAGUID の │ │
│ │ 登録済みユーザー │ │
│ │ を抽出 │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ ┌─────────────────────────────────────────┐ │
│ │ 脆弱性の深刻度を │────>│ 深刻: 即座に該当認証器をブロック │ │
│ │ 評価 │ │ 中程度: 新規登録を停止、既存は猶予期間 │ │
│ └──────────┬──────────┘ │ 軽微: 監視継続、次回登録時に警告 │ │
│ │ └─────────────────────────────────────────┘ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ ユーザーへの通知 │ │
│ │ - 脆弱性の説明 │ │
│ │ - 推奨アクション │ │
│ │ - 代替認証器の案内 │ │
│ └──────────┬──────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────┐ │
│ │ クレデンシャル │ │
│ │ の再登録を促す │ │
│ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
MDS の statusReports 値
| Status | 意味 | 推奨アクション |
|---|---|---|
FIDO_CERTIFIED | FIDO 認定済み | 許可 |
FIDO_CERTIFIED_L1 | Level 1 認定 | 許可 |
FIDO_CERTIFIED_L2 | Level 2 認定（ハードウェア保護） | 許可 |
NOT_FIDO_CERTIFIED | 未認定 | ポリシーに基づき判断 |
USER_VERIFICATION_BYPASS | UV バイパスの脆弱性 | 警告または拒否 |
ATTESTATION_KEY_COMPROMISE | 鍵漏洩 | 即座にブロック |
USER_KEY_REMOTE_COMPROMISE | リモート攻撃で鍵漏洩の可能性 | 即座にブロック |
USER_KEY_PHYSICAL_COMPROMISE | 物理攻撃で鍵漏洩の可能性 | リスク評価後に判断 |
REVOKED | 失効 | 即座にブロック |
新しい認証器モデルへの対応
┌─────────────────────────────────────────────────────────────────────────────┐
│ 新しい認証器への対応フロー │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【シナリオ】 │
│ ユーザーが新しい認証器で登録しようとしたが、 │
│ - AAGUID が MDS に存在しない │
│ - ルート CA が TrustStore にない │
│ │
│ 【対応オプション】 │
│ │
│ オプション A: 自動許可（Permissive） │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 未知の認証器でも登録を許可 │ │
│ │ - ログに記録して後から分析 │ │
│ │ - 定期的に MDS を更新して追認 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ オプション B: 手動承認（Strict） │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 未知の認証器は登録を拒否 │ │
│ │ - 管理者が AAGUID を許可リストに追加後、再試行を依頼 │ │
│ │ - 企業環境で認証器を厳格に管理する場合に適切 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ オプション C: 段階的許可（Hybrid） │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 未知の認証器は「制限付き」で登録 │ │
│ │ - 一部機能を制限（例: 高額取引は不可） │ │
│ │ - MDS で確認後、制限を解除 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
ユーザー影響の考慮
認証器が拒否された場合のユーザー体験
┌─────────────────────────────────────────────────────────────────────────────┐
│ ユーザー向けエラーメッセージ設計 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【悪い例】 │
│ "Attestation verification failed: AAGUID not in allowlist" │
│ → ユーザーには意味不明 │
│ │
│ 【良い例】 │
│ "お使いのセキュリティキーはこのサービスではご利用いただけません。 │
│ 以下の対応をお試しください: │
│ - 別のセキュリティキーをお持ちの場合は、そちらをお試しください │
│ - 会社支給のセキュリティキーをお使いください │
│ - ご不明な場合はサポートまでお問い合わせください" │
│ │
│ 【エラーコードの提供】 │
│ "エラーコード: AUTH-4001" │
│ → サポートが原因を特定しやすい │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
代替手段の提供
| シナリオ | 代替手段の例 |
|---|---|
| 認証器が拒否された | 別の認証器を案内、または SMS/メール OTP にフォールバック |
| 認証器の脆弱性で無効化 | 新しい認証器での再登録を案内、一時的に別の認証方式を許可 |
| 認証器を紛失 | バックアップコード、リカバリーフロー |
サポート対応フロー
┌─────────────────────────────────────────────────────────────────────────────┐
│ サポート担当者向け情報 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ ユーザーからの問い合わせ時に確認すべき情報: │
│ │
│ 1. エラーコード │
│ 2. 使用している認証器の種類（YubiKey、Windows Hello 等） │
│ 3. 使用しているブラウザとバージョン │
│ 4. 使用している OS │
│ │
│ サポート担当者が確認すべきログ: │
│ │
│ - AAGUID（認証器の識別子） │
│ - Attestation Format（packed, tpm, none 等） │
│ - 検証エラーの詳細 │
│ - 証明書チェーンの状態 │
│ │
│ よくある問い合わせと回答: │
│ │
│ Q: 「会社の PC では登録できるのに、自宅 PC ではできない」 │
│ A: Windows Hello の TPM 有無、ブラウザ設定の違いを確認 │
│ │
│ Q: 「昨日まで使えていたのに、急に使えなくなった」 │
│ A: 認証器の脆弱性によるブロック、証明書期限切れを確認 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
既存システムとの整合性
既存ユーザーの扱い
┌─────────────────────────────────────────────────────────────────────────────┐
│ 既存ユーザーへの影響 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【シナリオ】 │
│ attestation="none" で運用していたシステムに │
│ attestation 検証を導入する場合 │
│ │
│ 【問題】 │
│ - 既存ユーザーのクレデンシャルには attestation データがない │
│ - AAGUID が 00000000-0000-0000-0000-000000000000 の可能性 │
│ - 認証器の種類を後から特定できない │
│ │
│ 【対応オプション】 │
│ │
│ オプション A: 既存ユーザーは対象外 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 新規登録のみ attestation 検証を適用 │ │
│ │ - 既存クレデンシャルは従来通り使用可能 │ │
│ │ - 徐々に新しいポリシーに移行 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ オプション B: 再登録を促す │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 既存ユーザーにクレデンシャルの再登録を依頼 │ │
│ │ - 猶予期間を設けて段階的に移行 │ │
│ │ - 再登録完了まで古いクレデンシャルも有効 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
│ オプション C: 強制移行 │
│ ┌─────────────────────────────────────────────────────────────────────┐ │
│ │ - 期限を設けて古いクレデンシャルを無効化 │ │
│ │ - セキュリティインシデント対応時などに使用 │ │
│ │ - ユーザー影響が大きいため慎重に判断 │ │
│ └─────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
段階的な導入アプローチ
| Phase | 期間 | 内容 | attestation 設定 |
|---|---|---|---|
| Phase 1 | 1-2ヶ月 | データ収集 | none（ログのみ記録） |
| Phase 2 | 1-2ヶ月 | Permissive モード | direct（警告のみ） |
| Phase 3 | - | Strict モード | direct（検証失敗時は拒否） |
TrustStore と MDS の運用
📖 MDS の詳細（BLOB 構造、署名検証、実装パターン等）については FIDO Metadata Service (MDS) を参照してください。
TrustStore と MDS の関係
TrustStore と MDS は異なる役割を持ちますが、密接に関連しています。
┌─────────────────────────────────────────────────────────────────────────────┐
│ TrustStore と MDS の役割 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【TrustStore】 │
│ - 「信頼するルート CA 証明書」を格納したファイル │
│ - 証明書チェーン検証に使用 │
│ - 自分で管理する必要がある（手動で証明書を追加） │
│ │
│ 【MDS (FIDO Metadata Service)】 │
│ - FIDO Alliance が運営する認証器メタデータの配布サービス │
│ - AAGUID ごとにメタデータを提供: │
│ - attestationRootCertificates（ルート CA 証明書）← ここがポイント │
│ - statusReports（FIDO認定レベル、脆弱性情報） │
│ - description、icon 等 │
│ │
│ 【関係性】 │
│ - MDS は「ルート CA 証明書の配布元」として機能する │
│ - MDS から取得したルート CA を TrustStore に登録する、または │
│ - MDS を直接参照してルート CA を動的に取得する │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
証明書チェーン検証の2つのアプローチ
┌─────────────────────────────────────────────────────────────────────────────┐
│ 【アプローチ A: TrustStore を手動管理】 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 各ベンダーから個別にルート CA を収集して TrustStore に登録 │
│ │
│ Yubico サイト ──→ Yubico Root CA ──┐ │
│ Apple サイト ──→ Apple Root CA ──┼──→ TrustStore ──→ 証明書チェーン検証 │
│ Google サイト ──→ Google Root CA ──┘ │
│ │
│ メリット: シンプル、オフラインで動作 │
│ デメリット: 新しい認証器に対応できない、手動更新が必要 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ 【アプローチ B: MDS をルート CA のソースとして使用】 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ MDS から AAGUID に対応するルート CA を動的に取得 │
│ │
│ ┌─────────────────┐ │
│ │ MDS │ │
│ │ (FIDO Alliance)│ │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ 認証器から ┌──────────────────────┐ │
│ x5c を受信 ──→ │ AAGUID で MDS を検索 │ │
│ │ ↓ │ │
│ │ attestationRoot │ │
│ │ Certificates を取得 │──→ 証明書チェーン検証 │
│ └──────────────────────┘ │
│ │
│ メリット: 新しい認証器に自動対応、常に最新 │
│ デメリット: MDS への依存、ネットワーク必要（キャッシュで軽減） │
│ │
└───────────────────────────────── ────────────────────────────────────────────┘
アプローチの選択
| 方式 | TrustStore | MDS | 用途 |
|---|---|---|---|
| TrustStore のみ | 手動管理 | 使わない | 許可する認証器が限定的な企業環境 |
| MDS のみ | 使わない | ルートCA取得に使用 | 多様な認証器をサポートしたい場合 |
| 併用（推奨） | フォールバック用 | メイン | MDS障害時も動作、かつ最新に対応 |
ポイント: MDS は「ルート CA 証明書を集めた TrustStore を自動生成してくれるサービス」とも言えます。TrustStore を手動管理する代わりに、MDS から動的にルート CA を取得することで、新しい認証器への対応が容易になります。
TrustStore の初期構築
# 1. FIDO MDS から主要なルート CA を取得
# MDS BLOB をダウンロードして、各認証器の attestationRootCertificates を抽出
# 2. 個別のベンダーからルート CA を取得（必要に応じて）
# - Yubico: https://developers.yubico.com/
# - Apple: https://www.apple.com/certificateauthority/
# - Google: Android Key Attestation Root
# 3. TrustStore を作成
keytool -importcert -alias yubico-root \
-file yubico-root-ca.crt \
-keystore fido-truststore.p12 \
-storetype PKCS12 \
-storepass changeit
# 4. 追加の証明書をインポート
keytool -importcert -alias apple-webauthn-root \
-file apple-webauthn-root-ca.crt \
-keystore fido-truststore.p12 \
-storetype PKCS12 \
-storepass changeit
MDS BLOB の定期取得
┌─────────────────────────────────────────────────────────────────────────────┐
│ MDS 運用のベストプラクティス │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【取得頻度】 │
│ - 日次での取得を推奨 │
│ - MDS は週次程度で更新されるが、脆弱性情報は随時追加される │
│ │
│ 【署名検証】 │
│ - MDS BLOB は JWT 形式で FIDO Alliance が署名 │
│ - 必ず署名を検証してから使用する │
│ - 検証に失敗した場合は古いキャッシュを使用 │
│ │
│ 【キャッシュ戦略】 │
│ - メモリキャッシュ: 起動時にロード、定期的にリフレッシュ │
│ - ディスクキャッシュ: MDS 取得失敗時のフォールバック │
│ - キャッシュの有効期限: BLOB の nextUpdate フィールドを参照 │
│ │
│ 【障害時の挙動】 │
│ - MDS 取得に失敗した場合: │
│ - 直近のキャッシュを使用 │
│ - アラートを発報 │
│ - 一定期間（例: 7日）を超えたら警告レベルを上げる │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
パフォーマンスへの影響
証明書チェーン検証のコスト
| 処理 | 概算時間 | 備考 |
|---|---|---|
| CBOR デコード | < 1ms | |
| 署名検証（ECDSA） | 1-5ms | CPU 依存 |
| 証明書チェーン構築 | 1-10ms | チェーンの深さによる |
| 証明書検証（有効期限等） | < 1ms | |
| MDS 参照 | < 1ms | メモリキャッシュ時 |
| 合計（キャッシュあり） | 5-20ms |
最適化のポイント
┌──────────────────────── ─────────────────────────────────────────────────────┐
│ パフォーマンス最適化 │
├─────────────────────────────────────────────────────────────────────────────┤
│ │
│ 【MDS のキャッシュ】 │
│ - 起動時にメモリにロード │
│ - AAGUID → MetadataStatement のハッシュマップを構築 │
│ - 参照は O(1) │
│ │
│ 【証明書のキャッシュ】 │
│ - パース済みの X509Certificate オブジェクトをキャッシュ │
│ - TrustStore の証明書は起動時にパース │
│ │
│ 【証明書チェーン検証の最適化】 │
│ - AAGUID が既知の場合、MDS からルート CA を直接取得 │
│ - チェーン全体を構築せずに、直接ルート CA との照合を試みる │
│ │
│ 【並列処理】 │
│ - attestation 検証は登録フローの一部 │
│ - 他の検証（clientDataJSON、authData）と並列実行可能 │
│ │
└─────────────────────────────────────────────────────────────────────────────┘
本番デプロイ前チェックリスト
ポリシー決定
- Attestation Conveyance を決定（none / indirect / direct / enterprise）
- Self Attestation の許可/拒否を決定
- fmt="none" の許可/拒否を決定
- FIDO 認定レベルの要件を決定
- 許可する AAGUID リスト（必要な場合）を作成
- 未知の認証器の扱いを決定
- 検証失敗時の挙動（拒否/警告）を決定
- 証明書検証方式を決定（TrustStore / MDS / 併用）
技術的準備
- TrustStore を構築し、必要なルート CA を登録
- MDS BLOB の定期取得ジョブを設定
- MDS 署名検証を実装
- 証明書有効期限の監視アラートを設定
- エラーログのフォーマットを定義
- パフォーマンステストを実施
運用準備
- ユーザー向けエラーメッセージを準備
- サポート担当者向けドキュメントを作成
- 脆弱性発覚時の対応フローを文書化
- 既存ユーザーの移行計画を策定（必要な場合）
- ロールバック手順を準備
監視・アラート
- attestation 検証失敗率の監視を設定
- 未知の AAGUID の検出アラートを設定
- MDS 取得失敗アラートを設定
- 証明書有効期限アラートを設定