イントロダクション — パスキーは終着点か、それとも新たな検証対象か
FIDO2／パスキーの普及はフィッシング耐性を大きく改善しますが、「移行の過程」「運用オプション（クラウド同期 vs デバイス固有）」「実装の差異」が新たな攻撃面を生み出しています。本稿では、実際の侵害シナリオを想定した攻撃パターンの分類と、それらを赤チームが安全かつ再現性高く検証するための手順を提示します。
特に注目するポイントは次の3点です：フォールバック（パスワード／回復フロー）、パスキーの同期（クラウド/バックアップ）に起因するリスク、実装上の盲点（RP側／ブラウザ／IDプロバイダ連携）。これらは運用方針によりリスクが大きく変わります。
主要な攻撃シナリオと技術的解説
1) フォールバック／回復フローの悪用
パスキーを導入していても、ユーザーがアカウントにアクセスできなくなった場合に備えて用意される“パスワード再設定”“メール／SMS回復”“サポートによる本人確認”といった回復経路は、しばしば最もスケーラブルな侵害ルートになります。運用でパスキー登録後も回復を容易にする実装が残存していると、攻撃者は従来型のアカウント乗っ取り手法（社会工学、SIMスワップ、メール侵害）でアクセスを再獲得できます。
テスト手順（赤チーム向け）
- 対象RPの回復フローをマッピング：メール、SMS、電話、サポートチケット、管理者承認など。
- 回復手順を段階的に実行（ペネトレーション環境でのみ）：回復用メールアドレスの乗っ取り、セッション固定や社会工学的チャネルを用いたサポート承認の試行など。
- 回復成功時にパスキーの有効性がどう扱われるかを検証（既存パスキーの無効化、再登録挙動）。
2) クラウド同期（同期型パスキー）のリスク
プラットフォームの「同期パスキー」は利便性が高い一方、同期プロバイダ（iCloud Keychain、Google Password Manager、Microsoft Password Manager 等）に依存する形になります。同期の設計と復旧メカニズム、復号鍵の管理方式が問題になることがあり、プラットフォーム側や同期設定を標的にした攻撃で複数端末へ横展開され得ます。
テスト手順（赤チーム向け）
- 同期を有効にしたテストアカウントを用意し、別端末での復元プロセスを観察。
- 同期プロバイダのアカウント乗っ取り（合法的な検証環境での再現）や、同期設定変更時の通知／承認フローを検査。
- 同期鍵のバックアップと復元がRPにどの程度影響するかを検証。
3) 実装ミス（RP/IDP/ブラウザ）と仕様誤解
WebAuthn／FIDO2の仕様には多くのオプション（アタッチメント、トランスポート、要求するユーザー検証レベル、RP IDの解釈など）があり、誤実装や仕様理解不足が脆弱性につながります。RP側の不適切なRP ID処理、誤ったオリジン検証、弱い再登録ロジックは攻撃者の足がかりになります。
テスト手順（赤チーム向け）
- 登録／認証要求のパラメータを改変し、RPがどのように検証するかを確認（rpId、challenge、userVerificationなど）。
- ブラウザ拡張やプロキシで登録フローを中間操作し、意図しないCredentialが受け入れられるかを検査。
- IDプロバイダ連携（OAuth/OIDC）での条件付き仲介（conditional mediation）が不適切に設定されていないかを検査。
赤チーム検証の実務フレームワーク
安全で再現性のある検証を行うために、以下の環境と手順を最低限用意してください。
準備
- 検証用組織アカウント・テストユーザー群（低リスクサンドボックス）。
- 複数の認証モデル：デバイス绑定型（セキュリティキー／Windows Hello 等）と同期型（iCloud/Google/Microsoft 等）を両方用意。
- 監査ログ・テレメトリの取得体制（認証ログ、IP、UA、ブラウザ拡張ログ、IDプロバイダイベント）。
実行フェーズ
- リコン（フローと依存関係の把握）：回復チャネル、IDP、管理者ワークフロー。
- 低損害プローブ：パラメータ改変、UIフローの省略、トークン期限テスト。
- スケールテスト：社会工学／シミュレートされたメール侵害を用いた回復フローの横展開（必ず許可を得た環境で実行）。
- 同期の復元・横展開テスト：別端末での復元、同期停止からの復元手順を検証。
観測すべき指標
- 成功したアカウント復旧の経路と所要時間
- 認証関連ログの有無（challenge/responseの失敗理由、rpIdミスマッチ）
- 管理者承認やサポート介入時の記録と二要素要求の有無
これらは単に『侵入できた／できない』だけでなく、どのフローが最もスケーラブルでコスト効率の良い攻撃経路かを明らかにします。研究でも実運用での回復フローが主要リスクであると指摘されています。
検出・緩和策（実務チェックリスト）と結論
赤チームの結果を踏まえ、実務的に推奨される対策は以下の通りです。
- フォールバック最小化：パスキー導入時はパスワード／SMS回復の優先度を引き下げ、回復フローには複数の強い保証（多要素の人証／管理者の追加検証）を要求する。
- 高権限アカウントにはデバイス結びつき型を必須化：同期型パスキーではなく、ハードウェアセキュリティキーやAuthenticatorアプリバウンドを推奨（高リスクアカウント向け）。
- 同期サービスの保護強化：同期プロバイダ（iCloud/Google/Microsoft等）のアカウント保護を強化し、復元操作に対するアラート／承認を厳格化。
- 実装ガイドラインの厳守：rpId・オリジン検証、要求パラメータの検証、アテステーションポリシーの適用など、WebAuthn/FIDOの推奨実装を確認する。自社RPの実装差異は必ずテストに含める。
- 定期的な赤チーム／レッドブルーチーム演習：回復フロー・同期復元・実装差異を含むレパートリーで年1回以上の検証を推奨。
結論として、パスキーへの移行はセキュリティ向上につながりますが、その安全度は“どのオプションを採用し、回復をどう設計するか”次第です。赤チームによる実務的検証は、導入初期と運用フェーズ双方でのリスク可視化に不可欠です。最後に、実践的な検証を行う際は必ず組織内での許可手順と法令順守を徹底してください。
参考資料：FIDO Alliance の実装ガイダンス、各プラットフォームの同期機能の設計説明、学術研究による攻撃ベクトル分析を参照して本稿を作成しました。