Pass-ta-key 拆解：Windows Chrome 中招後，passkey 仲保唔保得住？

Passkey 冇突然變成任人破解

Unit 42 公開嘅 Pass-ta-key 研究，重點係一部支援 TPM、用緊 Windows Chrome 同 Google Password Manager 同步 passkey 嘅電腦，已經俾 malware 入侵之後會發生咩事。攻擊者要先用受害者帳戶嘅權限執行程式，先可以讀 Chrome 本機資料、操控 TPM 簽署或者抽取記憶體。乾淨電腦唔會隔空中招，研究亦冇破解 WebAuthn 密碼學，仲唔代表 Android、macOS、iCloud Keychain、Windows Hello 或硬件保安匙都有同一問題。

呢個前提好重要。Passkey 依然擋到假登入頁面、撞密碼同重用外洩密碼，對付傳統 phishing 確實好過密碼。不過同步 passkey 要兼顧跨裝置復原，背後多咗雲端、瀏覽器、本機狀態同復原流程。Pass-ta-key 揭開嘅缺口就藏喺呢幾層之間：當 Chrome 所信任嗰部電腦已失守，硬件保護仍然可以俾惡意程式借用。

圖片：Unit 42

第一條路：借受害者部 TPM 簽名

Chrome 會為裝置建立一條 TPM 保護嘅 identity key。研究指，磁碟上存放嘅係經 TPM 包裝嘅私鑰資料，唔係一條可以直接複製去另一部機用嘅裸私鑰。不過同一部電腦入面嘅 malware 可以抽出呢份資料，再經 Windows CNG API 叫原本嗰粒 TPM 簽署攻擊者準備好嘅登入要求。全程唔使管理員權限、Windows Hello、指紋或者用戶撳確認。

呢條基本 Pass-ta-key 路徑仲有一道關卡：網站要檢查 WebAuthn 回應入面嘅 User Verified（UV）旗標。identity key 產生嘅回應雖然有有效簽名，但 UV 係 0；網站如果強制驗證 UV，就應該拒絕登入。Unit 42 示範 eBay 當時漏咗呢個檢查，所以攻擊成功，eBay 收到報告後已經修正。研究亦話發現其他網站有同類問題，但冇公開名單。

圖片：Unit 42

Silver：換走驗證用嗰條匙

Silver Pass-ta-key 針對 Chrome 重新登記裝置嘅流程。Malware 可以刪除本機 passkey_enclave_state，或者用 identity key 發出忘記裝置指令，逼 Chrome 下次使用 passkey 時重新加入 Google Password Manager 嘅 security domain。Windows 版 Chrome 為免連續彈出 Google Password Manager PIN 同 Windows Hello，首次重新加入時會暫緩建立 user verification key，裝置短暫處於 uv_key_pending 狀態。

研究人員發現，Google Cloud Authenticator 當時冇核實新 UV key 係咪真係來自受保護硬件。攻擊者可以趁呢段空檔登記自己控制嘅匙，之後喺另一部電腦產生 UV=1 嘅有效回應。去到呢一步，就算受害者部機已經離線，強制檢查 UV 嘅服務都可能失守。呢條路利用嘅係重新登記流程同 key attestation 缺口，唔係估中用戶 PIN。

圖片：Unit 42

Golden：攞走解密同步 passkey 嘅主匙

Golden Pass-ta-key 影響最深。Google Password Manager 用一條 32-byte Security Domain Secret（SDS）加密帳戶內同步 passkey 嘅私鑰。Unit 42 發現，Chrome 重新加入 security domain 時，SDS 曾經以明文出現喺 chrome://device-log/FIDO；Google 收到報告後已移除呢段記錄。不過研究指 SDS 仍會短暫出現喺 Chrome process memory，malware 可以逼裝置重新登記，再 dump 記憶體抽走主匙。

有咗 SDS，攻擊者可以解開 Chrome sync database 入面現有 passkey，研究亦指同一 security domain 日後新增嘅 passkey 會沿用呢條主匙。報告發表時，Google Password Manager 冇畀用戶輪換或撤銷 SDS 嘅方法，所以單靠改 Google Password Manager PIN，未有證據顯示可以清走呢種長期風險。呢個結論來自研究人員嘅概念驗證；暫時未見報告提出 CVE、列出確實受影響 Chrome 版本，亦冇證據顯示三種手法已喺野外大規模使用。

Google 修咗幾多？

Unit 42 研究同 9to5Google 原文刊出嗰陣，已確認嘅改動有兩項：Google 移除 device log 入面嘅明文 SDS，eBay 補返 UV 旗標驗證。至於 Silver 嘅新 UV key 登記同 Golden 嘅記憶體 SDS，Unit 42 仍以現行風險描述，Google 亦未公開一個涵蓋全部路徑嘅 Chrome 修正版本。研究團隊話已負責任披露所有攻擊，但呢點唔等於每條路徑都有補丁；用戶暫時亦冇一個簡單畫面，可以查到 SDS 曾經有冇外洩。

一般用戶點減低風險

最實際嘅防線仍然係避免電腦先中 malware：保持 Windows、Chrome 同保安軟件更新，唔好亂開來歷不明嘅安裝檔、破解軟件同 script，日常避免用管理員帳戶。正常使用期間突然再問 Google Password Manager recovery PIN，或者反覆要求重新登記裝置，都值得先停低，檢查 Chrome profile 同電腦有冇異常。

如果懷疑部機已經中招，唔好只改密碼或者 PIN 就當完成。應該用另一部可信裝置終止可疑登入、檢查重要帳戶活動，清理或重裝受感染電腦，再逐個高價值服務刪除舊 passkey、建立新憑證。公司 IT 仲要確認網站設成 userVerification=required，server 亦有實際檢查 UV 旗標。特別敏感嘅帳戶可考慮獨立硬件保安匙，減少同步主匙帶來嘅集中風險，但 endpoint 中招後，瀏覽器 session 同其他本機資料依然保唔住。

參考來源

• 9to5Google — Google Password Manager passkeys could be at risk with new ‘Pass-ta-key’ attack — original report
• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication — Unit 42 技術披露，詳細交代 Pass-ta-key、Silver、Golden、修正狀態同研究範圍。
• Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication — 研究系列嘅架構分析，解釋 identity key、UV key、SDS 同同步 passkey 點運作。
• Manage passkeys in Chrome — Google 官方說明支援平台、Google Password Manager PIN、Windows Hello 同跨裝置同步安排。
• Web Authentication: An API for accessing Public Key Credentials — WebAuthn 官方規格背景，包括 user verification 同 authenticator data。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。