Google Cloud Key Vault 服務

我們要介紹使用安全硬體儲存加密編譯金鑰的雲端服務,讓存取金鑰的存取受到低熵知識因素 (例如螢幕鎖定 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 作業系統。這份白皮書提到的用戶端是指執行 Android 9 Pie 作業系統的裝置和 Google Play 服務。我們的伺服器端實作程序會在特別指定的 Google 伺服器上執行,且已安裝額外的 Titan 晶片2。Google 設計的 Titan 晶片是「受信任硬體模組」中的硬體元件,我們特別為其佈建自訂的系統啟動載入程式和韌體,以便導入相關通訊協定和安全性強制執行機制 (如本文所述)。我們採用硬體認證技術,來確保我們的通訊協定確實可以在 Titan 硬體上執行。

CKV 服務必須調度資源,以處理從數十億3 Android 裝置傳出的流量,同時避免因硬體故障 (例如晶片故障) 或因資料中心維護作業而延長服務中斷的情況,而遺失大量使用者資料。因此,上面有 Titan 晶片的伺服器會組織成多個同類群組,每個同類群組都包含多個獨立的 THM,每個 THM 都包含相同金鑰內容的副本。系統會將特定同類群組分配到不同維護區域的不同資料中心,確保系統能達到可用性和可靠性目標。為了提高擴充性,系統會將客戶分割為幾個不同的同類群組,只要新增伺服器來增加可用同類群組的數量,即可調整服務容量。

現在可以來列舉 Cloud Key Vault 服務架構的主要元件。

架構元件 / 詞彙表

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

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

Android 架構:我們將使用這個通用術語 (或簡稱「架構」) 來指 Android 9 Pie 以上版本中的 API,而不是指任何舊版 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 內使用。

Trusted Hardware Module (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 系統的目標是在堆疊的多個層級加入安全性防護,來提供「縱深防禦」。為讓您瞭解防護功能的運作方式,我們首先會說明用戶端,並將堆疊與 Cloud Key Vault 服務進一步結合。

客戶安全性

視特定的原始設備製造商 (OEM) 和裝置而定,螢幕鎖定知識特徵 (LSKF) 通常會使用各種方式 (視原始設備製造商 (OEM) 而有所不同) 來儲存及保護裝置。舉例來說,Google 的 Pixel 2 裝置使用防竄改硬體安全性模組來儲存靜態 LSKF,並針對 LSKF 驗證強制執行硬體頻率限制。而新推出的 Framework API 可啟用 Cloud Key Vault 功能,更能盡可能維持現有安全性保證,即使裝置使用此類硬體安全性模組來保護 LSKF 儲存空間亦然。

本節將著重在影響全新 Cloud Key Vault 功能的相關安全性問題和保護措施,而非嘗試提供所有與 LSKF 相關安全性機制的全貌。

保護架構 API

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

Framework API 也能確保保管箱只會針對獲得信任根憑證的同類群組公開金鑰建立保管箱。信任根會在原始設備製造商 (OEM) 出貨時加到架構中,而且除非作業系統更新,否則無法變更。如此一來,LSKF 即可確保其只用於建立可正確強制執行硬體式暴力保護措施的保管箱。只要運用 Cloud Key Vault 服務的 THM,我們都能為 LSKF 提供暴力防護,確保安全,媲美 Google Pixel 2 裝置使用的安全硬體,效果媲美 Google Pixel 2 裝置。

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

保護復原代理程式

「復原代理程式」提供的主要安全防護機制,就是用來防止復原代理程式看到目前裝置的 LSKF 或任何備援金鑰。只有架構可以在用戶端看到這些內容,使復原代理程式中的潛在錯誤或安全漏洞更容易利用。復原代理程式主要用於管理生命週期事件,以及資料在雲端與架構之間來回傳遞的資料。在保管箱 Opening 通訊協定之前的復原期間,這種情況的例外狀況是,當使用者必須輸入舊裝置的 LSKF 時,也就是收集舊裝置的 LSKF 的 UI 是在復原代理程式4中執行。然而,一旦架構完成復原要求的建構程序,復原代理程式的實作就會「清除」已聲明的 LSKF。

通訊協定的安全防護功能

雖然完整的通訊協定分析不在本文件的討論範圍內,但我們還是想重點說明該通訊協定內建的幾項防護功能。具體來說,通訊協定只會在過程中使用 LSKF 的雜湊。也就是說,如果 LSKF 的熵高 (例如,建議使用高熵密碼),儲存保管箱的做法會比儲存密碼雜湊來得好,在這種情況下,密碼雜湊可以提供獨立於 THM 安全性的測量結果。因此,我們在通訊協定中支援 LSKF 的鹽化「記憶體硬」雜湊。我們也會透過加密方式將保管箱繫結至建立該保管箱的裝置 ID,並將復原憑證繫結至在保管箱開啟通訊協定期間用於驗證的 Nonce,確保復原聲明是最新的。

由於每次建立保管箱時,系統都會重新產生備援金鑰,因此我們會以新建立的保管箱覆寫現有的保管箱項目,藉此執行金鑰輪替作業。建立保管箱時,系統會選取保管箱使用的失敗計數器位址。如果 LSKF 曾變更或有新的同類群組公開金鑰清單,此架構可確保後續用於任何保管箱的計數器位址不會改變。因此,您可以在不損害 LSKF 的暴力式防護的情況下進行備援金鑰輪替。

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

這套伺服器的實作方式是結合在一般伺服器硬體上執行的軟體,以及在特殊硬體 (Titan 晶片) 上執行的韌體。我們將說明每個圖層提供的保護措施。

硬體保護

CKV 服務伺服器端實施的主要安全防護措施是利用 Google 獨家設計的 Titan 晶片建構的可信任硬體模組 (THM)。晶片正在執行韌體,公開實作 CKV 通訊協定所需的 API。特別是,他們可以產生金鑰組並安全地與同類群組的其他成員共用金鑰組,這樣一來,韌體邏輯就能防止私密金鑰在 Titan 晶片外外洩。他們也可以執行保管箱開啟作業,並嚴格地為每個保管箱遞增失敗的計數器 (此計數器受 Titan 晶片中儲存的狀態支援)。本文件的後續版本會進一步提供 CKV Titan 晶片韌體執行通訊協定的詳細說明。

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

軟體保護

除了 THM 對個別保管箱故障的限制外,CKV 服務還採用軟體式頻率限制。頻率限制是為了避免駭客入侵使用者的帳戶,並迅速用盡復原嘗試失敗的次數限制,有效鎖住實際使用者的備援金鑰存取權。使用者裝置解鎖螢幕失敗次數過多後,CKV 服務會強制因後續的保管箱開啟要求失敗,而強制增加延遲時間,類似情況。

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

詳細的通訊協定規格

詳細的通訊協定規格仍在開發階段,本文件將於今年稍晚更新,納入這些詳細資料與在 Android 開放原始碼專案中發布的用戶端程式碼。

附註

  1. 「改用可靠的 56 位元密鑰儲存空間 | USENIX。」2014 年 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 宣布,每月使用中的裝置數量超過 20 億部。」2017 年 5 月 17 日,https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users
  4. 這樣一來,我們就能提供靈活的 UI,方便使用者進入其他裝置的 LSKF。目前裝置的架構可能沒有適合進入舊裝置的 LSKF 的 UI。