摘要

報告深入探討無密碼身分驗證背後複雜的技術機制，特別聚焦於 Google Cloud Authenticator 生態系。透過分析裝置上線流程、金鑰產生、密碼學運算及安全通訊協定，我們的目的在全面理解這些系統如何建立信任並管理敏感的金鑰資料。報告同時檢視了在此不斷演進的安全環境中潛在的攻擊途徑與緩解策略，著重於技術層面的剖析。

Noise Protocol 與 TPM 如何守護 Google Cloud Authenticator 的無密碼世界？ | 資訊安全新聞

1. 簡介

無密碼身分驗證代表數位安全領域的重大典範轉移，從傳統的密碼驗證系統轉向更強健且用戶友善的方法。儘管如 Fast IDentity Online (FIDO) 等協定在理論上的安全性已確立，但理解其實務實作細節對於評估實際威脅樣貌至關重要 [1] 。此報告聚焦於 Google 廣泛採用的密碼金鑰 (passkey) 驗證生態系，特別是在桌面環境中扮演管理同步密碼金鑰關鍵角色的 Google Cloud Authenticator [1] 。

此研究目的在剖析此雲端驗證器背後隱藏的機制，探討裝置如何上線、密碼學金鑰如何產生與管理，以及採用的安全通訊協定。透過分析客戶端程式碼、執行時期行為、網路封包及公開資訊，我們期望釐清支撐 Google 無密碼驗證的架構基礎，進而識別潛在的新攻擊向量，並為未來的防禦策略提供參考 [1] 。

2. Google Cloud Authenticator 架構概觀

Google Cloud Authenticator 作為一個雲端元件，執行敏感的密碼學運算，其功能範疇超越了 FIDO 規格中的明確定義 [1] 。它促使用戶所有連線裝置之間的密碼金鑰同步，使無密碼驗證流程更加順暢。其運作核心在於透過專屬的上線流程，在使用者裝置與雲端驗證器之間建立信任。

2.1 裝置上線流程

裝置上線流程對於建立信任、驗證裝置身分及使用者持有權至關重要 [1] 。此流程包含數個關鍵步驟：

graph TD A[Chrome User Initiates Onboarding] --> B{Generate TPM-backed Key Pairs} B --> C["Identity Key (Something You Have)"] B --> D["User Verification Key (Something You Know/Are)"] C --> E[Client Sends Registration Request] D --> E E --> F{Cloud Authenticator Processes Request} F --> G[Store Identity & UV Public Keys] F --> H[Generate & Store Device-Specific Wrapping Key] F --> I[Generate Member Key Pair] I --> J[Encrypt Private Member Key with Wrapping Key] J --> K[Return Wrapped Private Member Key & Public Member Key] K --> L[Device Onboarded & Joined Security Domain] subgraph Key Generation Details C --> C1[Represents device identity] D --> D1["Requires user authentication (biometric/PIN)"] end subgraph Registration Request Details E --> E1[Commands: "device/register", "keys/genpai"] E --> E2[Identity_public_key] E --> E3[UV_public_key] E --> E4["Device_id (SHA256 hash of Identity_public_key)"] end subgraph Cloud Authenticator Actions G --> G1["devices[device_id] = {hw: identity_public_key, uv: uv_public_key}"] H --> H1["wrapping_keys[device_id] = random(32)"] J --> J1["wrapped_member_private_key = encrypt(member_private_key, key:wrapping_key)"] end

在上線流程期間，Chrome 會為裝置指派兩個由 TPM 後台支援的金鑰對：

  • 身分金鑰： 代表「你擁有的東西」，作為未來身分驗證時的一個驗證因子 [1] 。
  • 使用者驗證金鑰 (UV 金鑰)： 代表「你知道的或你本身的特徵」。此金鑰僅能在使用者以其裝置解鎖方式（例如生物辨識或 PIN）完成身分驗證後才能使用 [1] 。

產生這些金鑰後，客戶端會向雲端驗證器發送註冊請求，其中包含「device/register」和「keys/genpair」等指令，以及公開金鑰和一個衍生自身分公開金鑰的裝置 ID [1] 。接著，雲端驗證器會儲存這些公開金鑰，產生一個用於加密祕密的裝置專屬 wrapping key，並建立一組成員金鑰對。成員私鑰會使用 wrapping key 加密後回傳給裝置，使該裝置能夠加入帳戶的安全網域 [1] 。

2.2 首台裝置上線與帳戶秘密

針對第一台上線的裝置，系統會產生額外的帳戶祕密：

  • 安全網域秘密 (SDS)： 一個對稱式主金鑰，由雲端驗證器用於加密及解密帳戶中所有同步的密碼金鑰 [1] 。
  • GPM PIN 碼： 使用者自選的祕密，允許新加入的裝置存取該帳戶的同步密碼金鑰 [1] 。

此流程亦包含建立一個由 Google Trusted Vault 服務支援的安全網域，用以連結已授權的裝置並管理 Chrome Sync 的加密金鑰，以安全地同步密碼金鑰 [1] 。

3. 安全通訊協定

Chrome 與雲端驗證器之間的通訊，透過基於 Noise Protocol Framework 的客製化協定進行保護，特別是 Noise_NN 交握模式 [1] 。此架構為雙方的相互驗證及金鑰交換提供了強大的密碼學保證。此協定包含數個步驟：

graph TD A[Chrome Client] -->|1.Ephemeral Key Share| B[Cloud Authenticator] B -->|2.Ephemeral Key Share + Static Key Share| A A -->|3.Static Key Share + Authenticated Data| B B -->|4.Authenticated Data| A A -->|5.Derive Shared Secret & Encrypt Traffic| B B -->|6.Derive Shared Secret & Encrypt Traffic| A subgraph Noise_NN Handshake A --> X1[Client sends ephemeral public key] B --> X2[Server sends ephemeral public key + static public key] A --> X3[Client sends static public key + authenticated data] B --> X4[Server sends authenticated data] end

Noise_NN 交握確保雙方能夠相互驗證，並建立用於加密後續通訊的共享秘密金鑰。這對於在傳輸過程中保護敏感的密碼金鑰資料至關重要。雲端驗證器的靜態公開金鑰被硬編碼 (hardcoded) 在 Chrome 中，使客戶端能驗證伺服器的身分 [1] 。

4. 密碼金鑰操作與密碼學機制

一旦裝置完成上線並建立安全通道，Google Cloud Authenticator 便會協助各種密碼金鑰操作，包含建立、擷取及斷言 (assertion)。這些操作仰賴精密的密碼學機制。

4.1 密碼金鑰建立

當使用者建立一個新的密碼金鑰時，客戶端會向雲端驗證器發送請求。驗證器會產生一個新的 FIDO 憑證，並使用 SDS 加密其私鑰。這個加密後的憑證接著會被儲存在雲端，僅有使用 SDS 的雲端驗證器才能存取 [1] 。

4.2 密碼金鑰斷言 (身分驗證)

在身分驗證過程中，客戶端會要求雲端驗證器為一個斷言簽章。驗證器會擷取相關的密碼金鑰，使用 SDS 解密其私鑰，接著使用此私鑰對信賴方提供的挑戰 (challenge) 進行簽章。簽署完成的斷言會回傳給客戶端 [1] 。

4.3 程式碼分析：金鑰管理與密碼學操作

原始文章提到了與 Google Cloud Authenticator 中密碼學操作相關的數個關鍵函式與概念。雖然文章中未提供直接的原始碼，但我們可以推斷此類系統中常見的典型操作。舉例來說，文章提及了像是 NCryptOpenStorageProvider 、 NCryptImportKey 與 NCryptSignHash 等函式，這些都是 Windows Cryptography API: Next Generation (CNG) 的一部分 [1] 。這些函式對於與 TPM 互動及執行密碼學操作至關重要。

金鑰匯入與簽章之範例 Pseudocode： 

  1. // 使用 Windows CNG 匯入金鑰並為雜湊值簽章之 Pseudocode
  3. // 1. 開啟儲存提供者 (例如給 TPM 使用)
  4. NCRYPT_PROV_HANDLE hProv;
  5. NCryptOpenStorageProvider(&hProv, MS_PLATFORM_CRYPTO_PROVIDER, 0);
  7. // 2. 匯入私鑰 (例如從一個被包裹的 BLOB)
  8. NCRYPT_KEY_HANDLE hKey;
  9. NCryptImportKey(
  10.     hProv,              // 金鑰儲存提供者的控制代碼
  11.     NULL,               // 父金鑰的控制代碼 (此處未使用)
  12.     BCRYPT_PRIVATE_KEY_BLOB, // BLOB 類型
  13.     NULL,               // 參數清單
  14.     &hKey,              // 匯入金鑰的控制代碼
  15.     pbKeyBlob,          // 指向金鑰 BLOB 的指標
  16.     cbKeyBlob,          // 金鑰 BLOB 的大小
  17.     0                   // 旗標
  18. );
  20. // 3. 對要簽章的資料進行雜湊處理 (假設 pbHash 與 cbHash 已計算完成)
  21. // 此步驟通常會涉及像 SHA256 這樣的雜湊演算法
  23. // 4. 為雜湊值簽章
  24. DWORD cbSignature;
  25. NCryptSignHash(
  26.     hKey,               // 金鑰的控制代碼
  27.     NULL,               // 填補資訊 (例如 RSA-PSS 使用 PSS_PADDING_INFO)
  28.     pbHash,             // 要簽章的雜湊值
  29.     cbHash,             // 雜湊值的大小
  30.     NULL,               // 簽章緩衝區 (先取得所需大小)
  31.     0,                  // 簽章緩衝區大小
  32.     &cbSignature,       // 簽章大小
  33.     NCRYPT_SILENT_FLAG  // 旗標
  34. );
  36. // 配置緩衝區並再次簽章以取得實際簽章
  37. PBYTE pbSignature = (PBYTE)HeapAlloc(GetProcessHeap(), 0, cbSignature);
  38. NCryptSignHash(
  39.     hKey,               // 金鑰的控制代碼
  40.     NULL,               // 填補資訊
  41.     pbHash,             // 要簽章的雜湊值
  42.     cbHash,             // 雜湊值的大小
  43.     pbSignature,        // 簽章緩衝區
  44.     cbSignature,        // 簽章緩衝區大小
  45.     &cbSignature,       // 簽章大小
  46.     NCRYPT_SILENT_FLAG  // 旗標
  47. );
  49. // 清除控制代碼
  50. NCryptFreeObject(hKey);
  51. NCryptFreeObject(hProv);

此 pseudocode 說明了私鑰在被解開(Unwrap)或匯入(Import)後，如何用來為雜湊值簽章，這是為身分驗證斷言建立數位簽章時的基本操作。使用 TPM 後台金鑰能確保私鑰受到硬體保護，使其更能抵抗利用軟體的攻擊 [1] 。

5. 安全影響與攻擊途徑

雖然無密碼身分驗證透過消除常見的密碼相關漏洞顯著提升了安全性，但雲端驗證器的複雜架構也引入了新的考量。Google Cloud Authenticator 這種集中式管理 SDS 及 wrapping keys 的特性，使其成為攻擊者的高價值目標 [1] 。

5.1 潛在攻擊情境

  • 雲端驗證器遭入侵： 對雲端驗證器發動成功的攻擊，可能導致 SDS 外洩，進而解密所有同步的密碼金鑰 [1] 。
  • 裝置偽冒： 若攻擊者能入侵裝置的身分金鑰或 UV 金鑰，他們或許能偽裝成正當裝置，進而取得密碼金鑰 [1] 。
  • 旁路攻擊(Side-Channel Attack)： 進階攻擊者可能嘗試對 TPM 或密碼學操作發動旁路攻擊，以擷取敏感的金鑰資料 [1] 。

5.2 緩解策略

針對這些新興攻擊向量的緩解策略包括：

  • 強健的雲端安全： 對雲端驗證器基礎設施實施嚴格的安全措施，包括強效存取控制、入侵偵測及定期安全稽核 [1] 。
  • 硬體後台安全： 利用如 TPM 等硬體安全模組來保護私鑰，即使作業系統遭入侵，也難以將其提取 [1] 。
  • 復原機制使用多因子驗證 (MFA)： 確保密碼金鑰的復原機制（例如 GPM PIN）受到強效 MFA 的保護，以防止未授權存取 [1] 。
  • 持續監控與威脅情資： 主動監控與無密碼身分驗證及雲端驗證器相關的新攻擊技術與漏洞 [1] 。

6. 結論

Google Cloud Authenticator 體現了實現安全且可擴展的無密碼身分驗證所需的複雜工程。透過將金鑰管理與密碼學操作集中於雲端，它提供了流暢的使用者體驗，同時仰賴如 Noise Protocol Framework 與硬體後台金鑰等強健的安全協定。然而，此架構也轉移了攻擊面，因此需要持續專注於保護雲端基礎設施及裝置端密碼學操作的完整性。理解這些隱藏的機制，對於開發者與安全專業人員在無密碼的未來中建構系統並防禦新興威脅至關重要。

參考資料

  1. Google Cloud Authenticator: The Hidden Mechanisms of Passwordless Authentication
  2. SCF 檔案如何偷走你的 NTLM Hash？關鍵漏洞與應對策略