題干與適用場景
這道題考察前端工程師能否把 WebAuthn 擴充接入真實的端到端加密流程。PRF 可以為憑證提供與輸入綁定的偽隨機輸出，適合在客戶端派生加密金鑰；它不等於登入簽章，也不會自動解決多裝置、備份、刪除或瀏覽器相容性。回答需要同時覆蓋瀏覽器 API、密碼學邊界、使用者體驗與復原風險。
面試官考察什麼
- 是否理解 passkey 的驗證用途與 PRF 金鑰材料用途不同。
- 是否把擴充支援、使用者驗證、鹽值、金鑰派生與伺服器儲存分開設計。
- 是否能處理新增裝置、憑證刪除、同步與不可復原的使用者風險。
- 是否明確降級、錯誤回饋與不把金鑰材料送到伺服器的邊界。
回答前需要釐清的問題
先確認威脅模型：伺服器是否視為不可信，客戶端腳本供應鏈是否在範圍內，是否需要跨裝置同步？資料是整庫加密還是欄位加密，使用者能否接受遺失憑證後無法復原？目標瀏覽器與 WebView 是否受控，是否允許使用者註冊多個 passkey？伺服器需要保存哪些密文、鹽值、憑證 ID 與版本資訊？
30 秒回答框架
我會把 PRF 當作客戶端金鑰材料來源，而不是把登入斷言當作加密金鑰。註冊時建立或選擇支援 PRF 的憑證，為每個用途產生不可預測的鹽值；解鎖時透過帶 PRF 輸入的驗證操作取得輸出，在瀏覽器內用標準 KDF 派生包裝金鑰，再解包資料金鑰。伺服器只保存憑證公鑰、鹽值、密文與版本，不接收 PRF 輸出。先偵測擴充結果與使用者驗證，準備多憑證復原或明確不可復原提示；不支援時不靜默宣稱端到端加密，可選擇一般加密或阻止啟用。記錄失敗、復原與相容性指標後逐步擴大範圍。
分步驟深入解答
1. 區分驗證與加密金鑰
WebAuthn 登入返回的是對挑戰的簽章，用來證明憑證持有者；PRF 擴充則根據輸入產生與憑證關聯的偽隨機輸出。不能把簽章、憑證 ID 或客戶端擴充 JSON 直接當作 AES 金鑰。加密方案應有獨立的資料金鑰與明確的派生、包裝關係。
2. 設計註冊與鹽值
註冊時請求 PRF 擴充並讓使用者完成驗證；為每個加密域或金鑰版本產生隨機鹽值，並把鹽值與憑證 ID、演算法版本一起作為公開中繼資料保存。鹽值不是秘密，必須保證用途隔離，換用途或輪換金鑰時使用新鹽值。註冊結果要檢查客戶端擴充輸出，不能僅依請求參數推斷支援。
3. 設計解鎖與派生
解鎖時先從伺服器取得鹽值與密文中繼資料，再發起帶 PRF 輸入的驗證操作。瀏覽器返回擴充結果後，在客戶端驗證結構與長度，再使用標準 KDF 派生包裝金鑰，解包隨機產生的資料金鑰，最後解密內容。PRF 輸出與中間金鑰只在需要的記憶體範圍內存在，日誌與遙測不得記錄它們。
4. 處理能力偵測與相容性
使用公開的能力偵測與 getClientExtensionResults() 判斷實際結果，並區分「不支援擴充」「使用者取消」「憑證沒有 PRF 初始化」與網路失敗。W3C 的實作狀態仍需按目標瀏覽器、作業系統與 WebView 驗證；不能把單一瀏覽器的成功當成全平台保證。把相容性矩陣與最小支援版本寫入發布策略。
5. 設計多裝置與復原
每個裝置可註冊獨立憑證，並為同一資料金鑰保存各自的加密包裝版本。新增裝置需要已解鎖裝置、復原金鑰或受控邀請來重新包裝資料金鑰；不能讓伺服器僅憑登入狀態解密。使用者刪除所有憑證且沒有復原材料時，必須明確資料不可復原，並在啟用前讓使用者確認。
6. 規劃降級與遷移
不支援 PRF 時可以維持伺服器可讀的一般加密方案、引導使用者改用支援的瀏覽器，或阻止啟用端到端模式，取決於威脅模型。降級必須明確標記，不能把不同安全等級混在同一 UI。演算法、鹽值與密文格式都要帶版本，便於未來遷移與撤銷舊憑證。
高品質示範回答
我會把 WebAuthn PRF 視為客戶端金鑰材料來源，不把登入簽章或憑證 ID 當作加密金鑰。註冊時請求 PRF、完成使用者驗證，為每個加密域產生隨機鹽值，並保存憑證 ID、鹽值與演算法版本；解鎖時取得這些中繼資料，發起帶 PRF 輸入的驗證，在客戶端用標準 KDF 派生包裝金鑰，解包隨機產生的資料金鑰，再解密內容。伺服器只保存公鑰、密文與公開中繼資料，PRF 輸出、中間金鑰與明文不離開客戶端。實際讀取 getClientExtensionResults() 區分擴充不支援、未初始化、取消與網路錯誤。每台裝置註冊獨立憑證並分別包裝資料金鑰，新增裝置需要已解鎖裝置或復原材料；所有憑證遺失時明確不可復原。PRF 不可用則明確降級或阻止啟用，並按瀏覽器矩陣、失敗率與復原成功率逐步擴大。
常見錯誤
- 把 WebAuthn 登入簽章、憑證 ID 或客戶端擴充 JSON 直接當作對稱金鑰。
- 只檢查請求是否帶有 PRF 參數，不檢查實際擴充輸出與初始化狀態。
- 把鹽值當秘密，或在多個用途之間重用同一鹽值。
- 讓伺服器接收 PRF 輸出，或在日誌、錯誤追蹤與分析中記錄金鑰材料。
- 只設計單裝置成功路徑，沒有新增裝置、刪除憑證與復原方案。
- PRF 不可用時靜默切換到較弱方案，仍顯示端到端加密。
追問及應對
PRF 輸出可以直接作為 AES-GCM 金鑰嗎？
應先按方案使用標準 KDF 與用途域分離，再得到固定長度的包裝金鑰；不要把協議輸出直接暴露給多個加密用途。資料金鑰應隨機產生並被包裝，而不是由使用者憑證決定全部密文金鑰。
如果使用者在另一台裝置上登入，伺服器能幫他解鎖嗎？
伺服器只能提供鹽值、密文與憑證中繼資料，不能憑登入狀態還原 PRF 輸出。需要已解鎖裝置、復原金鑰或使用者明確配置的金鑰共享流程來包裝新裝置的金鑰。
如何判斷瀏覽器真的支援 PRF？
請求時宣告擴充後，讀取驗證結果的客戶端擴充輸出並檢查預期欄位、長度與錯誤狀態；同時維護目標瀏覽器、作業系統與 WebView 的實測矩陣。能力偵測 API 只能說明可請求，不能取代真實驗證。
伺服器端腳本被注入時，端到端加密還安全嗎？
PRF 不能解決活躍前端腳本被竄改的問題。還需要內容安全政策、依賴與發布完整性、敏感操作隔離與稽核；面試中應明確「伺服器看不到歷史密文」與「客戶端執行環境可信」是不同假設。