介紹
Passkeys如今保護著數十億個帳戶，透過更強大、更安全的無密碼身份驗證，重新定義了全球用戶的登入方式。然而，這場全球變革的深遠意義遠遠超越多數人的想像。儘管Passkeys採用了FIDO聯盟與W3C合作制定的經過嚴格審查的標準，但其全球普及卻受到一個超越開放標準的核心層面的驅動。這個核心層面研究不足，因實現方式而異，常被誤解。
儘管這項技術已存在多年，但真正讓通行密鑰大規模普及到普通用戶的突破性進展，不僅在於其更強大的安全性，更在於其操作的簡單性。透過 Apple Passwords 和 Google Password Manager 等憑證管理器，使用者可以在不同裝置間存取和同步通行金鑰，這實現了一個大膽的願景：「同步通行金鑰旨在被數十億用戶在全球範圍內廣泛採用。」這項創新帶來了所需的易用性，使 FIDO 聯盟「幫助減少全球對密碼的過度依賴」的目標成為現實。
儘管相關協定已擴展以實現同步，但它們並未定義如何同步或保護通行金鑰。這種規範的缺失使得通行密鑰的安全性完全依賴各個提供者的設計和實作。在應用最廣泛的生態系統中，我們發現Google的基礎架構採用了獨特的設計：雲端身分驗證器（Cloud Authenticator），它在後台運行，為數十億用戶提供安全、無縫的通行金鑰體驗。
儘管同步金鑰提高了安全門檻並消除了許多傳統攻擊，但攻擊者仍在不斷調整策略，尋找新的方法來利用新興系統。我們對實際應用的研究揭示了一些漏洞，這些漏洞暴露了新的攻擊途徑。這些發現促成了本系列文章的誕生，我們將深入探討推動全球轉型為無密碼身分驗證背後的架構。
在本系列部落格中，我們將分三部分揭開密碼鎖革命的神秘面紗：
在第一部分：全球突破中，我們將以簡單易懂的語言解釋通行密鑰，說明它們為何能抵禦當今最常見的攻擊，並揭示全球普及背後的創新。
第二部分： Google Cloud Authenticator，我們將揭示同步金鑰背後的隱藏機制及其在 Google 生態系統中的實作。
第三部分：不斷演變的威脅情勢，我們將探討在無密碼環境下出現的新攻擊途徑，以及將定義未來網路安全挑戰的潛在風險。
本文完全基於公開資訊、開源程式碼（包括 Chromium）和可觀察的系統行為。本文詳述的研究旨在進行負責任且符合倫理的安全分析。
通行密鑰簡述
Passkey 是一種基於 FIDO 標準（特別是WebAuthn和CTAP協定）的無密碼加密憑證。與依賴共享金鑰（例如密碼或一次性程式碼，攻擊者可以對其進行釣魚、洩漏或重播攻擊）的傳統多因素身份驗證不同，Passkey 從設計上就消除了這些弱點。 Passkey 就像 SSH 改變了安全的網路通訊一樣，應用了相同的非對稱加密原理來提供安全的身份驗證。在註冊線上服務時，用戶端會產生一個唯一的金鑰對。私鑰安全地儲存在客戶端裝置上，而公鑰則發送給服務提供者進行後續身份驗證。在身分驗證過程中，用戶端透過對服務提供者提供的質詢進行簽章來證明其擁有私鑰。
身份驗證器：密碼的核心
一個名為身份驗證器的可信任元件負責管理加密操作並驗證使用者身分。身份驗證器：
在註冊過程中產生金鑰對，並安全地保護私鑰。
產生一份聲明，證明與服務共享的公鑰是在安全可信任的環境中產生的。 （又稱證明）
使用一個或多個身份驗證因素控制加密操作的存取：
你擁有的某些特質（生物特徵）
你知道的資訊（PIN碼或解鎖圖案）
你擁有的東西（可信任設備、使用者互動或近距離接觸）
它透過對質詢和安全屬性（例如使用者是否已驗證）進行簽章來建立斷言。這為請求的服務提供保證，確保回應來自受信任裝置上的已驗證使用者。
身份驗證器可以採用不同的形式。有些內建於使用者的設備中，而有些則是便攜式硬體設備：
平台驗證器位於您的裝置內部。它們隔離並保護加密操作，通常透過可信任平台模組 (TPM)、安全隔離區 (SE) 或可信任執行環境 (TEE) 等硬體晶片來實現。驗證器可以使用本機平台使用者驗證（生物辨識或 PIN 碼，例如 Windows Hello、Touch ID 或 Face ID）來控制存取權限。
漫遊認證器是一種便攜式設備，可以連接到多個客戶端設備，同時將私鑰鎖定在便攜式硬體內部。最常見的例子是硬體安全金鑰，例如 YubiKey 或飛天密鑰。這類認證器可透過 USB、NFC 或 BLE 連接。
在概述了身份驗證器的作用之後，讓我們來看看 FIDO 註冊和身份驗證的基本流程。
基本註冊－建立通行金鑰：
當使用者造訪支援密碼的網站或應用程式並開始向服務方（依賴方）註冊：
該服務請求建立憑證。
身份驗證器透過生物辨識或知識因素等特徵來驗證使用者身分。
認證器會產生唯一的加密金鑰對。
公鑰會被發送到服務端並儲存在那裡，而私鑰則會安全地保存在身份驗證器上。
圖 1. 基本註冊流程。
每次使用者向新的依賴方註冊時，驗證器都會儲存與該依賴方的網域（RP ID）關聯的新私鑰，而依賴方則會在其伺服器上儲存與新註冊用戶關聯的公鑰。
基本驗證－使用密碼登入：
當使用者返回登入時：
服務（依賴方）發送一個隨機挑戰（長度至少為 16 位元組）。
身份驗證器透過生物辨識或知識因素等特徵來驗證使用者身分。
驗證器檢索與信賴方 ID 相符的私鑰，並使用該私鑰對挑戰進行簽署。
簽名後的挑戰書將發送回伺服器。
該服務在不洩露密碼或一次性代碼等對稱金鑰的情況下驗證使用者憑證。它依靠儲存的公鑰來驗證簽名，而私鑰始終安全地保存在使用者的裝置上。
圖 2. 基本身份驗證流程。
從使用者體驗的角度來看，Passkey 將所有步驟整合為一個步驟，讓雙重認證變得輕鬆方便。您只需解鎖手機或電腦，身份驗證器就會在後台驗證已驗證使用者是否擁有與所造訪的第三方綁定的私鑰。與傳統的 MFA 相比，這種方式提供的登入體驗更安全、更方便。
為什麼密碼金鑰能提供更好的安全性
幾十年來，密碼和其他對稱金鑰（例如令牌和一次性代碼）一直是數位安全中最薄弱的環節。它們可能被竊取、猜測、重複使用或被釣魚攻擊，一旦洩露，就會被重複利用。大量資料外洩事件和地下市場依靠被盜憑證蓬勃發展，導致帳戶盜用和身分盜竊的惡性循環。 Passkey 不僅更實用，而且旨在消除密碼和傳統多因素身份驗證 (MFA) 無法完全抵禦的某些攻擊類型。本文將介紹 Passkey 如何消除三種常見攻擊方式的威脅。
回放攻擊
重播攻擊是指攻擊者截獲有效的身份驗證憑證（例如密碼、雜湊值或令牌），並重播該憑證以取得未經授權的存取權限。 Passkeys 的設計旨在防止此類攻擊，它將每次身份驗證都變成一次性事件。依賴方會為每個身份驗證會話發出新的隨機質詢，客戶端使用私鑰對該質詢進行簽署。由於簽章僅對該特定質詢有效，因此擷取的已簽章回應無法在以後的驗證中重複使用。
網路釣魚
密碼和一次性密碼 (OTP) 容易受到網路釣魚攻擊，因為攻擊者可以誘騙您在虛假網站上輸入它們。然而，通行密鑰只能在其創建時指定的網域上使用。登入時，瀏覽器會驗證使用者存取頁面的來源是否與儲存的憑證關聯的信賴方 ID 相符。這種來源檢查使得通行密鑰本身就具有很強的抗釣魚能力，因為即使是外觀逼真的仿冒網站（例如 G0og1e.com）也無法誘使身份驗證器釋放有效的憑證。
中間人攻擊
如果攻擊者監聽身份驗證連接，他們只能看到非敏感資訊。註冊期間，身份驗證器會共用一個公鑰，攻擊者無法透過計算推導出私鑰。登入期間，身份驗證器會簽署一個與會話綁定的全新質詢，依賴方使用儲存的公鑰驗證該質詢。無論是公鑰還是已簽署的質詢，都不能用於冒充使用者或洩露敏感資訊。
採用障礙：孤立與同步
密碼金鑰之所以安全，正是因為它具備某些特性，而這些特性多年來也成為了阻礙其普及的最大障礙。雖然從理論上來看，密碼金鑰似乎是一個完美的解決方案，能夠提供更流暢的登入體驗和更強的安全性，但一個關鍵的限制因素卻阻礙了它的廣泛應用。
早期的密碼金鑰實現方案設計為私鑰不可匯出，且綁定到單一裝置。這些金鑰通常由可信任平台模組 (TPM) 等硬體保護，防止被複製或提取，並提供加密證明（認證），證明私鑰僅由該特定裝置創建和擁有。不可導出性保護了金鑰免於竊取，並建立了用戶設備的信任，但也帶來了一個限制：身份驗證只能透過特定設備進行。如果裝置遺失或被更換，私鑰和登入權限也會隨之遺失。
FIDO在2020年推出的跨裝置認證（CDA）是其解決單一裝置限制的首個突破性進展。這項創新使智慧型手機能夠作為附近設備的安全認證器，從而將用戶的可信任認證因素擴展到其他硬體。雖然這在可用性方面取得了顯著進步，但它未能解決設備遺失後的恢復問題。由於依賴單一的主認證器，丟失手機仍然會導致繁瑣的恢復過程。
為了實現全球普及，FIDO擴展了WebAuthn 框架，允許私鑰匯出且不再綁定到單一裝置。這項變更使用戶可以在一台裝置上建立密碼金鑰，並將其同步到其他裝置使用。它還支援基於雲端的恢復，即使所有設備遺失，用戶也能恢復存取權限。由於密碼管理器已被廣泛用於跨裝置同步使用者金鑰並提供復原服務，因此將其擴展到支援密碼金鑰是順理成章的一步。然而，使私鑰可匯出並在裝置間存取也帶來了新的安全挑戰。 WebAuthn 標準並未明確規定如何保護這些金鑰免受跨多個節點（包括建立、同步和復原）的未經授權存取。這個缺陷使得私鑰的實際保護依賴於每個憑證提供者的實作。早期曾提出一些加強同步金鑰保護的方案，包括devicePubKey和supplementalPubKeys擴展，但後來這些方案被從協定中移除。
安全同步方法
我們能否在保證金鑰不可導出安全性的同時，實現跨裝置的復原與同步？
近年來，人們探索了多種策略，目前已有三種具體模型投入使用。它們的核心思想都相同：加密通行金鑰的私鑰，以便將其安全地儲存在外部基礎設施上。在備份或同步之前，使用單一對稱金鑰加密使用者的所有通行金鑰。為簡單起見（儘管不同實現方式的術語可能有所不同），本文將使用Google的術語「安全域密鑰 (SDS)」來指稱此主密鑰。
基於這個核心概念，湧現了三種安全同步/備份的實用模型：
分散式信任：將安全資料結構 (SDS) 分割成多個份額，並分發給各個受信任的參與者。只有達到法定人數（即至少一部分參與者共同協作）才能重新組裝此安全資料結構。
可信任引導程式：透過外部身份驗證器使用引導程式金鑰保護 SDS。
雲端認證器：加密作業被轉移到雲端的安全區域。
1. 分散式信任
想像一下，有一個只能用三把不同的鑰匙打開的保險庫。你把每把鑰匙交給不同的親戚。任何人都無法單獨打開它，但當足夠多的人聚集在一起時，保險庫就能打開。這就是分散式信任背後的原理。
使用者產生一個隨機的安全域金鑰 (SDS)，用於解密和加密通行金鑰。此 SDS 使用 Shamir 秘密共享 (SSS) 演算法分割成多個共享份額。 Shamir 秘密共享是一種加密演算法，可以將金鑰分割成若干個獨特的片段。每個共享份額本身不會洩露任何關於原始密鑰的信息，但當組合足夠多的共享份額時，即可重構 SDS。一旦恢復，SDS 即可允許新裝置解密加密的通行金鑰區塊並恢復存取權限。
2. 可信任引導程式（微軟的方法，撰寫本文時僅對 Windows 預覽體驗成員提供預覽版）
想像一下，有一個保險庫，只有透過解鎖你已擁有的另一個保險庫才能打開。第一個保險庫裡藏著打開第二個保險庫所需的特殊鑰匙，如果沒有對第一個保險庫的存取權限，第二個保險庫就永遠無法打開。這就是微軟同步密碼背後的原理。在第一台 Windows 裝置上，會執行一次性引導設定。在此過程中，裝置會在外部身份驗證器（例如手機（透過掃描二維碼）或硬體安全密鑰）中建立一個特殊的引導密碼。在這種情況下，Windows 帳戶充當服務（信賴方），其 RP ID 格式為 <使用者帳戶>@outlook.com。
開機金鑰使用 WebAuthn 偽隨機函數 (PRF) 擴展，使 Windows Hello 能夠安全地衍生安全域金鑰 (SDS)。當使用者稍後新增新的 Windows 裝置時，登入其 Windows 帳戶後，他們將使用相同的外部身份驗證器進行身份驗證，並要求相同的引導金鑰，從而使 Windows Hello 能夠在新裝置中安全地派生完全相同的 SDS。
完成此引導步驟後，Windows Hello 將接手並保護本機 SDS。此後，SDS 會對使用者的密碼進行加密和解密，這些密碼隨後可以在 Windows 帳戶之間安全同步。
圖 3. 使用引導金鑰的 Windows 安全性同步。
這兩種方法各有優缺點：分散式信任在安全恢復方面表現良好，但擴展性較差，因為每個用戶都需要受信任方來維護共享並驗證用戶身份，才能在新設備上幫助恢復 SDS。可信任引導程式 (Trusted Bootstrap) 更容易擴展，但如果使用者的裝置和引導程式驗證器都遺失，則無法確保復原。然而，這兩種方法都存在相同的安全限制：
將通行密鑰的秘密從一個設備備份到另一個設備意味著通行密鑰不再受硬體隔離的保護。
硬體隔離是一項至關重要的安全特性，即使是權限極高的惡意軟體也無法匯出私鑰。然而，這兩種方法也必須依賴軟體層面的保護，這又引入了額外的風險。擁有系統級存取權限的攻擊者有可能取得安全資料表 (SDS) 來解密通行金鑰或取得未加密的私鑰。為了應對這些風險，第三種方法——雲端身份驗證器——引入了一種全新的設計，它結合了強大的隔離能力和跨裝置的無縫同步。
3. 雲端身份驗證器（Google的方案）
身份驗證器有兩個主要任務：驗證使用者身份和執行加密操作——金鑰產生和簽署。在雲端身份驗證器模型中，這兩個任務被分開。使用者驗證在裝置端進行，金鑰產生和簽章則在雲端進行。以下是該模型的四個步驟：
A. 使用裝置綁定金鑰在帳戶裝置上建立信任錨點
在用戶端連接到 Google 帳戶並希望使用該帳戶密碼的每個裝置上，用戶端都會在安全硬體加密處理器（TPM 或 SE）內建立一個裝置綁定的金鑰對。此私鑰保存在硬體中，不可匯出，並受本地平台用戶驗證（例如生物識別、裝置 PIN 碼或解鎖圖案）的保護。用戶端使用此硬體綁定的裝置金鑰對傳送至雲端驗證器的請求進行簽名，證明已驗證使用者正在使用授權裝置。
圖 4. 用戶端向雲端身分驗證器註冊裝置綁定的公鑰，以證明使用者在受信任的裝置上的身分。
B. 安全域金鑰 (SDS)
在用戶端開始使用第一個帳戶的通行金鑰（Google 個人資料通行金鑰）之前，註冊第一個裝置時，用戶端會產生 SDS，它是該帳號通行金鑰的主金鑰。 SDS 的設計目的並非以明文形式儲存。相反，雲端身份驗證器會對 SDS 進行加密：
對於恢復副本：SDS 已加密，用於雲端恢復金鑰存儲，並且只能在恢復服務驗證帳戶知識因素（例如，鎖定螢幕 PIN 碼）後，在帳戶恢復期間使用。
對於已驗證的新帳戶裝置：SDS 已加密，因此只有在註冊新裝置時，使用者使用帳戶的知識因素（例如，鎖定螢幕 PIN 碼）進行驗證後，雲端驗證器才能開啟它。
C. 通行金鑰註冊
當使用者在啟用密碼的網站或應用程式上註冊時，依賴方 (RP) 會要求瀏覽器為帳戶建立密碼。
使用者執行本地驗證，例如輸入 PIN 碼或使用生物識別技術，從而授權設備使用其硬體密鑰對請求進行簽署。
用戶端使用裝置綁定的金鑰對建立訊息的雜湊值進行簽名，並將訊息和簽名傳送到雲端身份驗證器。
雲端身份驗證器：
驗證設備金鑰簽名
建立與目前 RP ID 關聯的新密碼金鑰對
使用SDS加密私鑰
返回公鑰
將加密後的通行密鑰記錄回傳給客戶端。
客戶端將公鑰傳回給RP。
用戶端（或身份驗證器）將加密的通行金鑰記錄同步到帳戶的各個裝置。
圖 5. 使用雲端身份驗證器的基本註冊流程。
D. 通行金鑰認證
RP向客戶端發送隨機挑戰。
使用者執行本機平台手勢（使用者驗證），使用裝置綁定金鑰對身份驗證請求進行簽名，並將其與相關的加密通行金鑰記錄一起傳送到雲端身份驗證器。
雲端身份驗證器：
驗證設備金鑰簽名
使用 SDS 解密密碼記錄。
使用解密後的私鑰對挑戰進行簽名
返回簽名
客戶端將結果轉發給RP，RP使用儲存的公鑰對其進行驗證。
圖 6. 使用雲端身份驗證器的基本驗證流程。
透過這種設計，Passkey 的私鑰始終保存在安全的雲端環境中，所有 Passkey 加密操作均在雲端內部執行，確保私鑰不會離開隔離環境或暴露給使用者裝置上的軟體。 Cloud Authenticator 將本機使用者驗證和裝置綁定金鑰與基於雲端的隔離相結合，解決了 Passkey 全球擴充的核心挑戰，在保持硬體級安全性的同時，實現了無縫同步和復原。
接下來：Google雲端身份驗證器
雲端身份驗證器是目前應用最廣泛的將金鑰引入安全便捷世界的方案之一。然而，儘管底層 FIDO 和 WebAuthn 協定定義完善且經過廣泛評估，但雲端身份驗證器本身並未在標準中明確規定。為了更好地理解該模型的安全性和風險，即將發布的文章（第二部分：Google雲端身分驗證器）將透過分析 Chromium 的開源實作和可觀察的執行時間行為來探討其設計。在此基礎上，第三部分將重點分析安全假設如何在實踐中體現，以及攻擊者和防御者可能如何應對雲端金鑰。
Arie Olshtein 是 CyberArk Labs 的高級惡意軟體分析師。
文章來源/CyberArk Blog CyberArk Blog
返回