文/林妍溱|2026-03-31發表
資安廠商Palo Alto分析Google Authenticator的Passkey（通行密鑰）使用雲端、硬體裝置的混合架構，雖然省去硬體金鑰的麻煩，但他們認為卻衍生出可能讓攻擊者冒充裝置、接管Google帳號以取得Passkey的漏洞。
Palo Alto旗下的Unit 42安全研究小組指出，Google的Passkey生成及驗證過程是一個跨越Google雲端（Cloud Authenticator、Google Password Manager、密鑰儲存處）、硬體裝置、瀏覽器的混合式架構。利用這個架構，使用者先註冊其裝置，產生公私鑰，以及在macOS、Windows或Linux、ChromeOS裝置間的Google帳號同步Passkey，未來即以裝置無密碼完成驗證及安全登入網站。
當用戶在某個網站建立passkey時，網站會先透過WebAuthn API向Chrome發出請求。瀏覽器接手後，不是直接在本地產生金鑰，而是把這個請求轉交給Google的雲端Passkey系統。接著，Google雲端系統會為該網站產生一組公私鑰。然後一方面，它會私鑰加密儲存在用戶Google帳號同步系統，另一方面把「公鑰」回傳給網站保存。這樣網站之後只需要用公鑰驗證使用者是否持有對應的私鑰。
簡而言之，整個過程中，使用者透過硬體裝置上的生物辨識或PIN完成一次身份確認，但實際的金鑰管理與後續跨裝置使用，是建立在Google帳號的雲端同步機制之上，而不是完全侷限在單一裝置內。
但研究人員指出這架構有多個弱點。第一，在註冊過程中，系統會建立一個「security domain」，並產生一個關鍵的主金鑰SDS（Secure Domain Secret），用來加密所有Passkey，一旦SDS被取得或濫用，而得以解密整個帳號的所有Passkey。其次，新裝置加入帳號的security domain的過程仰賴Google帳號驗證和Google Password Manager PIN，攻擊者可能透過接管Google帳號，再將其裝置註冊，就能取得同步的Passkey。這是研究人員認為最可能發生的情形。
第三，研究指出一個元件enclave.ua5v.com（Cloud Authenticator endpoint），該元件負責管理裝置、封裝/解密金鑰及處理簽章請求。但問題是它不在FIDO標準中，也幾乎沒有公開文件，無法驗證其安全機制。最後，雖然系統仍使用TPM來保護裝置金鑰，但整體流程中仍需雲端參與關鍵操作。研究人員指未來可能出現遠端冒充「已註冊裝置」的攻擊，若能模擬合法裝置或操控用戶端到雲端的互動，即使不具備實體裝置或不破解FIDO，也可能取得合法簽章。
Palo Alto表示這是負責任研究，並已將研究發現分享給Cyber Threat Alliance成員。不確定Google方面是否已經得知。
線