プロンプトとコンテキスト
この質問は、フロントエンドエンジニアがWebAuthn拡張機能を実際のエンドツーエンド暗号化フローに統合できるかどうかをテストするものです。PRFは、クライアント側の鍵素材を導出するための認証情報にバインドされた擬似ランダム出力を提供できます。これはログイン署名ではなく、複数デバイスでの使用、バックアップ、削除、ブラウザの互換性を解決するものではありません。優れた回答には、ブラウザAPI、暗号学的境界、ユーザーエクスペリエンス、リカバリリスクが含まれます。
面接官が評価している点
- パスキー認証とPRF鍵素材の使用を区別できているか。
- 拡張機能のサポート、ユーザー検証、ソルト、導出、サーバーストレージを切り離して考えられているか。
- デバイス登録、認証情報の削除、同期、回復不能な喪失を適切に処理できているか。
- フォールバック、エラー状態、鍵素材をサーバーから隔離する境界を定義できているか。
最初に確認すべき明確化のための質問
脅威モデルを明確にします：サーバーは信頼されていないのか、クライアントのサプライチェーンはスコープに含まれるか、デバイス間同期は必要か？ データは全体として暗号化されるのかフィールド単位か、ユーザーは認証情報喪失後の恒久的なデータ損失を受け入れられるか？ 対象となるブラウザやWebViewは制御されているか、ユーザーは複数のパスキーを登録できるか？ サーバーが保存する必要がある暗号文、ソルト、認証情報ID、バージョンはどれか？
30秒の回答フレームワーク
私はPRFをクライアント側の鍵素材のソースとして扱い、ログインアサーションを暗号化鍵として使用しません。登録時には、PRF対応の認証情報を作成または選択し、目的ごとに予測不可能なソルトを生成します。ロック解除時には、PRF入力を使用してアサーションを実行し、ブラウザ内で標準KDFを用いてラッピング鍵を導出し、データ鍵をアンラップします。サーバーは公開鍵、ソルト、暗号文、バージョンを保存し、PRF出力は絶対に保存しません。実際の拡張機能の結果とユーザー検証をチェックし、複数認証情報によるリカバリまたは明確なデータ損失の警告を用意し、PRFが利用できない場合はエンドツーエンド暗号化を謳わないようにします。障害、リカバリ、互換性を測定した後にのみサポートを拡大します。
ステップバイステップの詳細解説
1. 認証と暗号化鍵の分離
WebAuthnログインは、認証情報の所持を証明するためにチャレンジに対する署名を返します。PRF拡張機能は、入力から認証情報に関連付けられた擬似ランダム出力を生成します。署名、認証情報ID、またはクライアント拡張JSONを直接AES鍵として使用してはなりません。設計には独立したデータ鍵と、明示的な導出およびラッピング関係が必要です。
2. 登録とソルトの設計
登録時にPRF拡張機能をリクエストし、ユーザー検証を必須とします。暗号化ドメインまたは鍵バージョンごとにランダムなソルトを生成し、ソルト、認証情報ID、アルゴリズムバージョンを公開メタデータとして保存します。ソルトは秘密情報ではありませんが、目的を分離する必要があります。目的を変更したり鍵をローテーションしたりする場合は、新しいソルトが必要です。リクエストからサポートを推測するのではなく、返されたクライアント拡張出力をチェックします。
3. ロック解除と導出の設計
サーバーからソルトと暗号文メタデータを取得し、PRF入力を使用してアサーションを実行します。ブラウザ内で返された拡張機能の構造と長さを検証し、標準KDFでラッピング鍵を導出し、ランダムに生成されたデータ鍵をアンラップしてコンテンツを復号します。PRF出力および中間鍵は必要な間だけメモリ内に保持し、ログやテレメトリには絶対に出力しません。
4. 機能検出と互換性の処理
文書化された機能チェックとgetClientExtensionResults()を使用して実際の結果を検査します。サポートされていない拡張機能、ユーザーによるキャンセル、未初期化の認証情報、ネットワーク障害を区別します。W3Cの実装状況は、対象のブラウザ、オペレーティングシステム、WebView全体で依然として検証が必要です。単一のブラウザで成功しても、プラットフォーム全体の保証にはなりません。ロールアウトポリシーに互換性マトリクスと最小バージョンを記録します。
5. 複数デバイスとリカバリの設計
デバイスごとに個別の認証情報を登録し、それぞれに対して同じデータ鍵の個別にラップされたコピーを保持します。新しいデバイスでデータ鍵を再ラップするには、既にロック解除されたデバイス、リカバリキー、または制御された招待が必要です。サーバーへのログインだけで復号できるようにしてはなりません。すべての認証情報が削除され、リカバリ素材が存在しない場合は、データが復旧不可能であることを明確に伝え、機能を有効にする前に確認を取得します。
6. フォールバックと移行の計画
PRFが利用できない場合は、脅威モデルに応じて、サーバーが読み取り可能な暗号化モードを維持するか、サポートされているブラウザにユーザーを誘導するか、エンドツーエンドモードをブロックします。フォールバックには明示的にラベルを付け、1つのUIでセキュリティレベルを混在させないようにします。将来の移行や古い認証情報の失効を可能にするために、アルゴリズム、ソルト、暗号文フォーマットにバージョンを付与します。
質の高い模範解答
私はWebAuthn PRFをクライアント側の鍵素材として使用し、ログイン署名や認証情報IDを暗号化鍵として扱うことは決してしません。登録時にはPRFをリクエストし、ユーザー検証を要求し、暗号化ドメインごとにランダムなソルトを生成して、認証情報ID、ソルト、アルゴリズムバージョンを保存します。ロック解除時にはメタデータを取得し、PRF入力でアサーションを実行し、ブラウザ内で標準KDFを使用してラッピング鍵を導出し、ランダムに生成されたデータ鍵をアンラップして復号します。サーバーは公開鍵、暗号文、公開メタデータを保存し、PRF出力、中間鍵、平文はクライアント側にとどまります。getClientExtensionResults()を検査して、未サポート、未初期化、キャンセル、ネットワークエラーの状態を区別します。各デバイスは独自の認証情報とラップされたデータ鍵コピーを取得します。デバイスの追加にはロック解除されたデバイスまたはリカバリ素材が必要であり、すべての認証情報を失うと明示的に復旧不能になります。PRFが利用できない場合は、明示的なフォールバックを表示するかアクティベーションをブロックし、ブラウザマトリクス、失敗率、リカバリ成功率に基づいてサポートを拡大します。
よくある間違い
- WebAuthn署名、認証情報ID、クライアント拡張JSONを共通鍵として直接使用すること。
- 実際の出力や初期化をチェックせず、リクエストにPRFパラメータが含まれていることだけを確認すること。
- ソルトを秘密情報として扱ったり、複数の目的で1つのソルトを再利用したりすること。
- PRF出力をサーバーに送信したり、鍵素材をログ、トレース、アナリティクスに記録したりすること。
- 登録、削除、リカバリを考慮せず、単一デバイスの正常系のみを設計すること。
- エンドツーエンド暗号化と表記したまま、より強度の低いモードにサイレントに切り替えること。
フォローアップの質問と回答
PRF出力をAES-GCM鍵として直接使用できますか？
まず標準KDFとドメイン分離を使用し、固定長のラッピング鍵を導出します。プロトコルの出力を複数の暗号化目的に晒さないでください。ランダムなデータ鍵を生成してそれをラップします。すべての暗号文鍵を認証情報の直接の関数にしないでください。
サーバーはログイン後に別のデバイス上のユーザーのロックを解除できますか？
サーバーはソルト、暗号文、認証情報メタデータを提供することはできますが、ログインからPRF出力を再構築することはできません。ロック解除されたデバイス、リカバリキー、または明示的に設計された鍵共有フローによって、新しいデバイス用にデータ鍵をラップする必要があります。
ブラウザがPRFを実際にサポートしているかどうかをどのように確認しますか？
拡張機能を宣言し、アサーションからクライアント拡張出力を読み取り、期待されるフィールド、長さ、エラー状態をチェックします。対象のブラウザ、オペレーティングシステム、WebViewの実測マトリクスを維持します。機能APIは拡張機能をリクエストできることを示すだけであり、実際のセレモニーに代わるものではありません。
サーバー配信スクリプトがインジェクションされた場合でも、エンドツーエンド暗号化は安全ですか？
PRFは、フロントエンドスクリプトのアクティブな改ざんを解決しません。コンテンツセキュリティポリシー（CSP）、依存関係およびリリースの完全性、機密操作の分離、監査も必要です。「サーバーが過去の暗号文を読み取れないこと」と「クライアントランタイムが信頼されていること」は異なる前提であることを明確に述べる必要があります。