Google Cloud 金鑰保管箱服務

我們介紹的雲端服務是使用安全硬體儲存加密編譯金鑰,因此存取金鑰受到低熵知識因素 (例如螢幕鎖定 PIN 碼) 的保護。安全硬體可防止暴力攻擊,在錯誤嘗試提供正確知識因素的次數過多後,讓已儲存的加密編譯金鑰永久無法擷取。

作者:Shabsi Walfish
版本日期:2018-03-06

注意:這份文件仍在開發中,相關細節也尚未定案。隨著系統穩定性和說明文件的數量增加,我們也會更新這份白皮書,提供更詳細的資訊 (特別是搭配相關的開放原始碼版本)。

總覽

傳統上,加密 (用於保護資料隱私) 必須使用從攻擊者的角度來看,具有高度熵的密鑰。您需要使用高熵,因為加密配置必須抵禦暴力攻擊,這類攻擊會探索所有可能的密鑰空間,直到找到正確的密鑰為止。鑒於今日的運算能力可用性,加密編譯密鑰的最小熵量可能位於 70 至 80 位元的附近。可惜的是,人類很難記住並有效記住包含這個數量過多的密碼1,尤其是使用次數不多的密碼 (但使用高熵密碼時,使用難度高且沒有麻煩)。這也讓我們面臨了一個棘手的問題:如果我們想使用加密技術保護私人資料,是使用者很可能就會記住的「知識因素」,該怎麼避免?基於多種原因,這個問題難以解決,因為 Cloud Storage 服務通常只會使用由 Cloud Storage 供應商自行代管的密鑰來加密資料,不會仰賴使用者記住自己的密鑰。

如要彌補加密編譯密鑰要求與人類可記住的密鑰要求之間的差異,可以使用 Cloud Key Vault (CKV) 服務儲存高熵「復原金鑰」,該金鑰受到低熵人容易記住的密鑰保護。CKV 服務只會向一方釋出復原金鑰,該方可證明您瞭解正確的人可記住的正確密鑰。CKV 服務可能會遏止對人類好記的密鑰施加暴力攻擊,這種行為會強制限制失敗次數,有效證明密鑰知識。復原金鑰本身是標準的加密編譯對稱金鑰,適合與 (經驗證) 的加密配置搭配使用,可輕鬆加密可安全地儲存在任何位置的大量資料 (例如磁碟備份)。如果無法取得備援金鑰的使用者,就能使用這類加密資料。

這份白皮書說明我們如何使用受信任的硬體模組 (THM) 建構 Cloud Key Vault 服務。我們首次實作 CKV 服務,是藉由使用者的鎖定螢幕知識特徵 (LSKF) 保護復原金鑰,也就是用來解鎖智慧型手機的秘密 PIN 碼、密碼或滑動圖案。人類可以放心記住自己的 LSKF。同時,這類 LSKF 密鑰通常有足夠的熵,可以抵禦發動次數有限的攻擊者,因此相當適合 CKV 服務。

Cloud Key Vault 服務的第一個應用程式會啟用用戶端加密 Android 備份。先前,在 Android 裝置本機上加密的檔案會使用受使用者 LSKF 保護的金鑰,但這些檔案在雲端儲存 (和加密) 的備份則不受 LSKF 保護。首次使用 Cloud Key Vault,還能針對儲存在雲端的 Android 備份啟用螢幕鎖定防護功能。這表示 Google 的伺服器無法存取或還原已加密備份的內容,只有具備使用者 LSKF 的裝置才能解密備份。

核心概念

一開始,Cloud Key Vault 服務唯一支援的用戶端平台是 Android 9 Pie 作業系統。本白皮書中提到的用戶端是指搭載 Google Play 服務且搭載 Android 9 Pie 作業系統的裝置。我們的伺服器端實作作業是在特別指定的 Google 伺服器上運作,且伺服器會安裝額外的 Titan 晶片2。Google 設計的 Titan 晶片是可信任硬體模組中的硬體元件,我們特別以自訂系統啟動載入程式和韌體佈建了這個晶片,藉此實作通訊協定和安全性強制執行機制 (如下文所述)。我們使用硬體認證技術確保通訊協定確實在 Titan 硬體上運作。

CKV 服務必須調度資源以處理來自數十億3 Android 裝置的流量,而不會因為硬體故障 (例如停止運作的晶片) 或因資料中心維護而長期服務中斷。因此,搭載 Titan 晶片的伺服器會整理成同類群組,其中每個同類群組都包含數個獨立的 THM,每個群組都包含相同金鑰內容的副本。系統會將指定的同類群組分配到在不同維護區域的不同資料中心,確保系統能達成可用性和可靠性目標。對於擴充性,系統會將用戶端分割為幾個不同的同類群組,以便增加可用同類群組的數量來調整服務的容量。

我們現在已準備好列舉 Cloud Key Vault 服務架構的主要元件。

架構組件 / 詞彙表

螢幕鎖定知識因素 (LSKF):使用者容易記住的密鑰,例如短 PIN 碼、在 3 點 3 點格線上方滑動的圖案,或是密碼。這個密鑰是用來保護在本機解鎖裝置的能力,也是使用者本機裝置螢幕鎖定的主要 (或稱「高強度」) 驗證因素。

用戶端:執行 Android 9 Pie 作業系統、Google Play 服務,或同等支援的軟體的使用者裝置。

Android 架構:我們使用這個通用術語 (或簡稱「架構」) 指稱 Android 9 Pie 以上版本中的 API,而不是任何早期版本。

Google Play 服務:一組在使用者裝置上執行的服務和應用程式,可搭配 Google 的帳戶系統和自訂伺服器 API 使用。

復原代理程式:在 Android 9 Pie 裝置 (或類似裝置) 的使用者空間中執行 Google Play 服務期間的系統應用程式。復原代理程式負責執行各種通訊協定的用戶端,並在必要時與 Android 作業系統介面互動,以編寫任何涉及 LSKF 的通訊協定訊息。

復原請求:當使用者想要擷取復原金鑰時,必須建立復原請求,該回應具有使用者宣稱知道的 LSKF 加密副本。一般而言,系統會要求使用者在新裝置上輸入舊裝置的 LSKF,以便存取舊裝置的備援金鑰。

復原金鑰:受 Cloud Key Vault 服務保護的加密編譯金鑰,用於在用戶端裝置上加密 (及驗證) 資料。將備援金鑰放入保管箱 (請見下方說明) 後,只要用戶端使用金鑰加密資料,就能立即刪除本機副本。

Cloud Key Vault (CKV) 服務:這項網際網路服務可讓用戶端裝置儲存由人工記錄 LSKF 保護的加密編譯金鑰。

同類群組:一組可當做彼此備援備用資源的保管箱伺服器/THM。

同類群組公開金鑰:由特定 THM 產生的金鑰組產生的公開金鑰。對應的私密金鑰僅適用於金鑰產生期間在同類群組中的 THM 中。

受信任的硬體模組 (THM):專門的安全性模組 (微控制器),旨在提供最小可靠的運算環境。安全元素至少必須能夠產生和/或儲存密鑰,並維持一些不變性持續變動的狀態,以防發生涉及重設為先前狀態的攻擊。

保管箱:CKV 服務資料庫中的特定項目,包含單一裝置的 LSKF 保護復原金鑰。一位使用者可能會有多個保管箱檔案,每個保管箱都對應至不同的裝置或 LSKF。只有保管箱伺服器的 THM 可以檢查或擷取保管箱的內容。

保管箱伺服器:在 Google 資料中心運作的一般用途機器,經過特別改造,經過特別設計,可新增受信任的硬體模組 (THM)。

通訊協定設計

CKV 通訊協定由幾個階段組成,如下所示:

初始化

為了初始化系統,Google 會提供「信任根」的公開金鑰,讓架構用來驗證 Google 的硬體認證。這個信任根的簽署金鑰會離線儲存,並妥善保護,因此必須使用多位員工才能簽署金鑰。此信任根的公開金鑰已內建於 Android 作業系統中,並且只能透過 OS 更新變更。

此外,Google 也會定期發布每個 THM 同類群組的公開金鑰清單,以及清單上的認證。清單上的認證使用了鏈結回信任根的簽章。已發布清單的每項更新也包含序號,因此可以避免復原作業。復原代理程式會擷取最新發布的同類群組公開金鑰清單,並將該金鑰提供給架構。接著架構會驗證認證,並從清單中隨機選取要用於保管箱建立階段的同類群組公開金鑰。

建立保管箱

擷取同類群組公開金鑰清單,協助架構完成初始化後,復原代理程式會要求該架構建立新的保管箱。每當使用者下一次輸入 LSKF 時,架構將產生全新的復原金鑰,並先使用從 LSKF 雜湊衍生的金鑰加密,然後以架構在初始化期間選取的「同類群組公開金鑰」對金鑰進行加密。產生的加密 blob 是保管箱,由架構傳回給復原代理程式,然後據此上傳至 Google 的 CKV 服務。

保管箱開啟

如果新裝置的復原代理程式需要存取儲存在特定保管箱中的復原金鑰,系統會先提示使用者輸入最初建立保管箱裝置的 LSKF。復原代理程式隨後會要求架構使用該 LSKF 建立復原要求。架構會產生新的要求者金鑰,並使用與保管箱原先加密的同類群組公開金鑰相同的「請求者金鑰」以及已聲明擁有權的 LSKF 雜湊。產生的加密 blob 稱為復原要求,架構會將此內容傳遞至復原代理程式,再將其提供給 CKV 服務。

CKV 會將「復原要求」 (以及對應的「保管箱」) 轉送至正確同類群組的保管箱伺服器。保管箱伺服器中的 THM 會解密復原要求,並嘗試使用已聲明的 LSKF 雜湊 (衍生內部加密金鑰) 從原始保管箱擷取復原金鑰。如果原始 LSKF 雜湊與已聲明的 LSKF 雜湊相符,THM 會從保管箱擷取復原金鑰,並使用復原要求中的要求者金鑰重新加密。否則,THM 將會略過失敗的嘗試計數器。一旦失敗的嘗試計數器達到上限,THM 就會拒絕為這個保管箱處理任何後續的復原請求

最後,如果一切都沒問題,重新加密的復原金鑰 (現在在請求者金鑰中已加密) 會從保管箱伺服器從保管箱伺服器傳回到架構。這個架構會使用其要求者金鑰的副本來解密「復原金鑰」,而通訊協定現已完成。

安全措施

Cloud Key Vault 系統針對我們的堆疊提供多層安全防護機制,目的是提供「縱深防禦」。我們會先描述用戶端,並逐步瞭解這些防護機制的運作方式。

用戶端安全性

視特定原始設備製造商 (OEM) 和裝置而定,鎖定螢幕知識係數 (LSKF) 通常會使用不同原始設備製造商 (OEM) 提供的方法儲存並保護。舉例來說,Google 的 Pixel 2 裝置會使用防竄改硬體安全性模組來存放靜態資料,並針對 LSKF 驗證強制執行硬體頻率限制。為支援 Cloud Key Vault 而推出的全新 Framework API,也就是盡可能保留現有的安全性保證,即使裝置是透過這類硬體安全性模組來保護 LSKF 的儲存空間也一樣。

本節將著重說明會影響全新 Cloud Key Vault 功能的相關安全性問題和保護措施,而不是提供完整資訊,說明 LSKF 的所有安全性機制。

保護 Framework API

為支援 CKV 服務新增的 Framework API 會標示為 @SystemApi,並需要特殊權限,以確保只有原始設備製造商 (OEM) 核准的系統應用程式 (例如 Google Play 服務) 才能使用這些 API。這樣大致上會移除使用者安裝在裝置上的應用程式時,可能會暴露的直接攻擊途徑。

Framework API 也能確保系統只會為經過信任根認證的同類群組公開金鑰建立保管箱。信任根會在原始設備製造商 (OEM) 發布時納入架構中,且無法在沒有 OS 更新的情況下變更。如此一來,LSKF 只會用來建立可妥善強制執行硬體式暴力保護功能的保管箱。透過 Cloud Key Vault 服務中的 THM,我們能對 LSKF 採用嚴密的強制保護措施,讓我們能在使用安全硬體時,達到相當於使用安全硬體的裝置安全 (與 Google Pixel 2 裝置相同)。

由於系統不會假設 LSKF 會儲存在裝置上任何位置,且不會儲存在安全硬體之外,因此只能在裝置解鎖後立即建立新的保管箱。使用者進入 LSKF 解鎖裝置時,RSKF 會短暫提供給 RAM 中的架構使用。屆時,保管箱的新 API 就會使用該 API。由於 LSKF 無法使用,因此您無法在裝置鎖定時建立新的受 LSKF 保護的保管箱。

保護復原代理程式的安全性

我們在復原代理程式中提供的主要安全保護措施,就是該通訊協定的設計目的是防止復原代理程式查看目前裝置的 LSKF 或任何備援金鑰。只有架構可以查看用戶端上的這些內容,因而更難以濫用復原代理程式中的任何潛在錯誤或安全漏洞。復原代理程式主要用於管理生命週期事件,以及在雲端和架構之間來回傳遞資料。唯一的例外情況是,在保管箱開啟通訊協定之前的復原期間,使用者必須輸入舊裝置的 LSKF,也就是為舊裝置收集已聲明 LSKF 的 UI 會在復原代理程式4中實作。不過,一旦架構取代復原請求的建構,復原代理程式實作就會「清除」已聲明的 LSKF。

通訊協定的安全功能

雖然此通訊協定的完整分析不在本文件的範圍內,但我們要特別介紹通訊協定中內建的幾個保護措施。請特別注意,通訊協定在整個過程中只會使用 LSKF 的雜湊。換句話說,如果 LSKF 的熵不足 (例如,如果 LSKF 使用很高的熵),儲存保管箱的方式比儲存密碼雜湊來得好,而在這種情況下,密碼雜湊可提供與 THM 安全性無關的安全性評估。因此,在通訊協定中,我們支援在 LSKF 中使用加鹽的「記憶體硬」雜湊。此外,我們也以加密方式將保管箱繫結到建立該套件的裝置 ID,並繫結復原憑證附加在保管箱開放通訊協定期間做為驗證用的 Nonce,確保復原憑證所需的資訊符合現況。

由於每次建立保管箱時,系統都會重新產生復原金鑰,因此我們採用金鑰輪替的方式,使用新建立的保管箱覆寫現有保管箱項目。系統會在保管箱建立期間,選取保管箱使用的失敗計數器位址位址。這個架構可確保用於後續保管箱使用的計數器位址不會改變,除非 LSKF 發生變更,或是有新的認證的同類群組公開金鑰清單。因此,復原金鑰的輪替作業不會影響 LSKF 的暴力強制防護措施。

Cloud Key Vault 服務的伺服器安全性

實作伺服器時,系統採用在一般伺服器硬體上執行的軟體,以及在專屬硬體 (Titan 晶片) 上執行的韌體組合。我們會說明各層提供的保護措施。

硬體保護

CKV 服務伺服器端採用的主要安全防護機制,是使用 Google 自有設計的 Titan 晶片建構的受信任硬體模組 (THM)。晶片正在執行的韌體,會公開必要的 API 以實作 CKV 通訊協定。具體來說,他們能產生一組以安全的方式與其他同類群組成員共用金鑰組,藉此保護私密金鑰組,避免私密金鑰在同類群組的 Titan 晶片外外洩。他們也可以執行保管箱開啟作業,並針對每個保管箱的失敗嘗試,維持嚴格遞增的計數器 (計數器會以儲存在 Titan 晶片中的狀態備份)。我們將在日後推出的版本中,針對 CKV Titan 晶片韌體執行通訊協定的詳細說明。

由於伺服器安全性取自 Titan 晶片中的韌體邏輯,我們必須確保這項邏輯不會改變,讓方塊外洩密鑰或忽略計數器限制。為達成這個目標,我們也調整了 Titan 系統啟動載入程式,確保在套用任何更新前,已完全清除晶片儲存的資料 (例如同類群組的私密金鑰)。這項保護措施的缺點是,我們無法在不會遺失部分資料的情況下修補韌體中的錯誤。更新韌體的功能等同於刪除現有硬體並替換為新的晶片。如果需要重大韌體修補程式,Google 需要產生並發布一份全新的認證同類群組公開金鑰清單,然後將所有使用者逐步遷移至新的清單。為降低這個風險,我們會盡可能減少韌體程式碼集,並仔細稽核是否有任何潛在的安全性問題。

軟體防護

除了 THM 設下的個別保管箱固定故障限制外,CKV 服務也會實施軟體式頻率限制。頻率限制旨在防止駭客進入使用者帳戶,並快速用盡失敗的救援嘗試次數限制,有效鎖定實際使用者無法存取備援金鑰的情形。CKV 服務在嘗試解鎖螢幕失敗的次數過多後,對此裝置造成的時間延遲的情況類似,在後續每次發生保管箱開啟要求失敗時,CKV 服務都會強制執行較長的延遲時間。

我們也針對託管使用者資料的 Cloud 服務實施標準安全措施,包括嚴格的存取權控管、監控與稽核措施。

詳細的通訊協定規格

詳細的通訊協定規格仍在開發中,今年稍晚會更新本文件,納入這些詳細資料,連同用戶端程式碼在 Android 開放原始碼計畫中發布。

附註

  1. 「對人類記憶中的 56 位元密鑰的可靠儲存空間 | USENIX」表示。1 8 月 1 日,https://www.usenix.org/node/184458
  2. 「Google Cloud Platform 網誌:Titan 深入解析:明文中的安全性。」2017 年 8 月 24 日,https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html
  3. 「Google 公布每月使用中的 Android 裝置數量超過 20 億部...」,2017 年 5 月 17 日,https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users
  4. 這讓我們能提供彈性 UI 進入其他裝置的 LSKF,因為目前裝置的架構可能沒有適合進入舊裝置的 LSKF 的使用者介面。