這篇文章要討論的是一個關於 Google 密碼管理員（Google Password Manager）在 Windows 環境下，針對 Passkey（通行金鑰）認證機制的安全性分析。首先，我們需要釐清一個核心前提：這是一次後滲透（Post-compromise）攻擊分析。也就是說，攻擊者已經成功在受害者的 Windows 電腦上執行了惡意軟體，且該軟體擁有普通使用者的權限。
這項研究由 Unit 42 提出，他們發現即便 Passkey 號稱能取代密碼並提供強大的安全性，但如果實作層面的邏輯有漏洞，攻擊者依然可以在使用者完全不知情的情況下，繞過生物辨識（如指紋）或 PIN 碼，直接接管受保護的帳號。
這裡要強調的是，這次攻擊並沒有破解任何加密演算法，而是針對 Chrome 瀏覽器儲存金鑰的方式、設備重新註冊的流程，以及網站端（Relying Party）對驗證結果的檢查邏輯進行漏洞利用。
研究人員將這三種攻擊路徑分別命名為 Pass-ta-key、Silver Pass-ta-key 與 Golden Pass-ta-key。
第一階段：Pass-ta-key 繞過使用者驗證
在 Passkey 的機制中，有一個關鍵標記叫做 UV（User Verified，使用者已驗證）。當你掃指紋或輸入 PIN 碼後，認證伺服器會收到一個 UV 標記為 True 的回應，證明這台設備背後確實有一個真人。
研究發現，Chrome 在 Windows 上使用 TPM（可信平台模組，一種硬體安全晶片）儲存設備識別金鑰時，為了避免金鑰被永久寫入磁碟，採取了一種將金鑰導出為不透明二進位塊（Opaque Blob）並在需要時重新載入的方式。
攻擊者可以利用 Windows 的 CNG（Cryptography API: Next Generation，下一代加密 API）直接呼叫 TPM，使用這個被導出的金鑰塊來簽署認證請求。雖然這樣能產生有效的認證結果，但因為沒有經過使用者的生物辨識，回傳的 UV 標記會是 False。
這時安全性就取決於網站端。如果網站（如 GitHub）嚴格要求 UV 必須為 True 才會允許登入，攻擊就失敗；但如果網站（如早期的 eBay）僅檢查認證是否有效而忽略了 UV 標記，攻擊者就能在使用者螢幕上沒有任何提示的情況下，直接登入帳號。
第二階段：Silver Pass-ta-key 偽造驗證金鑰
如果第一種方法被網站端擋住，攻擊者可以嘗試更深層的操縱。他們會強制 Chrome 觸發設備的重新註冊（Re-enrollment）流程。
在 Chrome 重新註冊設備的過程中，存在一個時間差，系統不會立即建立使用者驗證金鑰。攻擊者可以趁虛而入，在此窗口期內註冊一個由攻擊者控制的驗證金鑰。
由於伺服器端當時可能沒有檢查新註冊的金鑰是否來自安全的硬體（缺乏硬體證明 Attestation），這導致攻擊者可以用自己的金鑰簽署認證請求，且這次回傳的 UV 標記會是 True。這意味著攻擊者甚至可以在自己的設備上，持續地偽造使用者已驗證的狀態來登入帳號。
第三階段：Golden Pass-ta-key 竊取主金鑰
這是最嚴重的攻擊路徑。其目標是 SDS（Security Domain Secret，安全域秘密），這是一個 32 位元的秘密金鑰，用於解密同步在雲端的所有 Passkey 私鑰。
研究發現，當 Chrome 執行重新註冊或同步操作時，這個 SDS 會短暫地以明文形式出現在瀏覽器的進程記憶體（Process Memory）中。攻擊者只要在正確的時間點讀取記憶體，就能將 SDS 竊取出來。
一旦拿到了 SDS，攻擊者就可以在自己的環境中解密受害者的所有同步 Passkey 私鑰。這相當於拿到了所有房間的萬能鑰匙，且這種權限在 SDS 變更之前是持久且不可逆的。
對工程師與開發者的實務啟示
這次分析給了我們幾個重要的安全教訓。首先，對於開發認證系統的工程師來說，絕對不能只檢查認證是否有效，必須強制要求 UV 標記（userVerification: required），並在後端驗證該標記。
其次，對於金鑰管理實作，應該強化設備註冊時的硬體證明（Hardware Attestation），確保金鑰確實儲存在 TPM 等安全硬體中，而非由軟體模擬。
最後，對於客戶端軟體開發，敏感金鑰（如 SDS）在記憶體中的生命週期應縮到最短，並採取記憶體保護措施，避免被同權限的惡意進程讀取。
總結來說，Passkey 雖然解決了密碼被盜刷的問題，但它將攻擊面轉移到了端點設備的實作細節上。如果本地端的金鑰管理邏輯存在缺陷，即便有硬體加密保護，依然可能被繞過。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。