Google Cloud Key Vault Service

我們將介紹一種雲端服務,該服務會使用安全硬體來儲存加密編譯金鑰,以便透過低熵知識因子 (例如鎖定畫面 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) 保護復原金鑰,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 服務必須擴充,才能處理來自數十億部 Android 裝置3的流量,且不會因硬體故障 (例如燒毀的晶片) 而導致大量使用者資料遺失,或因資料中心維護作業而導致服務中斷時間過長。因此,裝有 Titan 晶片的伺服器會分組,每個群組都包含多個獨立的 THM,每個 THM 都包含相同金鑰素材的副本。特定同類群會分散至不同維護區內的實體分散資料中心,以確保系統可達到可用性和可靠性目標。為了提升可擴充性,用戶端會分割成多個不同的同類群,讓我們只需新增更多伺服器來增加可用同類群數量,即可調整服務容量。

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

架構元件 / 詞彙

螢幕鎖定知識因素 (LSKF):人類可記住的密碼,例如短 PIN 碼、3 x 3 點格式滑動圖案或密碼。這個機密金鑰可用於保護在本機解鎖裝置的能力,並視為使用者本機裝置螢幕鎖定功能的主要 (或「強大」) 驗證因素。

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

Android 架構:我們使用這個通用術語 (或稱「架構」) 來指稱 Android 9 Pie 以上版本中的 API,但不代表任何舊版。

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

Recovery Agent:在 Android 9 Pie 裝置 (或類似裝置) 的使用者空間中,作為 Google Play 服務一部分執行的系統應用程式。復原代理程式負責執行各種通訊協定的用戶端,並視需要與 Android 作業系統連結,以便製作任何涉及 LSKF 的通訊協定訊息。

復原權利聲明:當使用者想要擷取復原金鑰時,必須建立復原權利聲明,其中包含使用者聲稱知道的 LSKF 加密副本。一般來說,系統會要求使用者在嘗試存取舊裝置的復原金鑰時,在新裝置上輸入舊裝置的 LSKF。

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

Cloud Key Vault (CKV) 服務:這項網路服務可讓用戶端裝置儲存由 LSKF 保護的加密編譯金鑰,方便使用者記憶。

同類群:一組可做為彼此備援副本的 Vault 伺服器/THM。

同類群公開金鑰:由特定 THM 同類群產生的金鑰組所產生的公開金鑰。對應的私密金鑰僅可在金鑰產生時位於同組的 THM 中使用。

信任硬體模組 (THM):專屬安全性模組 (微控制器),旨在提供最小且可信賴的運算環境。安全元素至少必須能夠產生和/或儲存密鑰,並維持某些非易失變的狀態 (以防範涉及重設至先前狀態的攻擊)。

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

Vault 伺服器:在 Google 資料中心中運作的通用機器,已特別改裝以新增信任硬體模組 (THM)。

協定設計

CKV 通訊協定包含以下幾個階段:

初始化

為初始化系統,Google 會為「信任根」提供公開金鑰,讓架構用於驗證 Google 的硬體認證。這個信任根的簽署金鑰會儲存在離線狀態,並受到嚴密保護,因此需要多名員工共同簽署。這個信任根的公開金鑰已內建於 Android 作業系統中,且只能透過作業系統更新進行變更。

Google 也會定期發布每個 THM 同類群組的公開金鑰清單,以及清單上的認證。清單上的認證會使用簽章,將鏈結回信任根。發布清單的每個更新都包含序號,因此可以防止回溯。復原代理程式會擷取最近發布的同類群公開金鑰清單,並提供給架構。架構會隨機從清單中選取要用於金庫建立階段的群組公開金鑰,然後驗證認證。

建立保管箱

擷取同類群組公開金鑰清單後,復原代理程式會要求架構建立新的保險庫。每當使用者下次輸入 LSKF 時,架構都會產生新的復原金鑰,並先使用從 LSKF 雜湊衍生的金鑰加密,然後再使用架構在初始化期間選取的同類群組公開金鑰加密。產生的加密 blob 是 Framework 傳回給復原代理人的保管箱,而復原代理人會將該 blob 上傳至 Google 的 CKV 服務。

開啟保管箱

當新裝置上的復原代理程式需要存取儲存在特定保險庫中的復原金鑰時,系統會先提示使用者輸入建立保險庫的原始裝置的 LSKF。接著,Recovery Agent 會要求架構使用該 LSKF 建立Recovery Claim。架構會產生新的聲明者金鑰,並使用同一個群組公開金鑰 (Vault 最初用於加密) 加密該聲明者金鑰,以及聲明的 LSKF 雜湊。產生的加密 blob 稱為「Recovery Claim」,而架構會將其傳遞給 Recovery Agent,後者再將其呈現給 CKV 服務。

CKV 會將復原權利聲明 (及其對應的保管箱) 轉送至正確同類群的保管箱伺服器。之後,Vault 伺服器中的 THM 會解密復原權利聲明,並嘗試使用已聲明的 LSKF 雜湊 (用於衍生內部加密金鑰),從原始Vault 中擷取復原金鑰。如果原始 LSKF 雜湊和聲明的 LSKF 雜湊相符,THM 會從儲藏庫中擷取復原金鑰,並使用復原聲明中的聲明者金鑰重新加密。如果不是,則 THM 會增加失敗嘗試計數器。失敗嘗試計數器達到上限後,THM 就會拒絕處理此 Vault 的後續復原請求

最後,如果一切順利,則會從金庫伺服器將重新加密的復原金鑰 (現在已在聲明者金鑰下加密) 傳回至架構。架構會使用其聲明者金鑰副本解密復原金鑰,而通訊協定現已完成。

安全措施

Cloud Key Vault 系統旨在提供「縱深防禦機制」,在堆疊的多個層級中納入安全防護機制。為了讓您瞭解這些防護機制的運作方式,我們將從說明用戶端開始,然後逐步向上至 Cloud Key Vault Service。

用戶端安全性

視特定原始設備製造商 (OEM) 和裝置而定,螢幕鎖定知識因子 (LSKF) 通常會使用各種方法 (視原始設備製造商而異) 在裝置上儲存及受到保護。舉例來說,Google Pixel 2 裝置會使用防竄改硬體安全模組來儲存靜態 LSKF,並在 LSKF 驗證時強制執行硬體頻率限制。為了讓您能夠使用 Cloud Key Vault,我們推出了新的 Framework API,旨在盡可能保留現有安全保證,即使裝置使用這類硬體安全性模組來保護 LSKF 的儲存空間也一樣。

本節將著重於相關安全性問題和影響新雲端密鑰金庫功能的保護措施,而非提供與 LSKF 相關的所有安全性機制完整資訊。

保護 Framework API

新增的 Framework API 是為了支援 CKV 服務而新增,因此會標示為 @SystemApi,並需要特殊權限,確保這些 API 僅供 OEM 核准的系統應用程式 (例如 Google Play 服務) 使用。這麼做可大幅移除任何可能向使用者在裝置上安裝的應用程式公開的直接攻擊面。

框架 API 也會確保只有針對已由信任根證明的叢集公開金鑰建立金庫。信任根會在 OEM 出貨時內建於架構中,且必須更新作業系統才能變更。這可讓您確信 LSKF 只會用於建立可正確強制執行硬體暴力破解防護機制的金庫。我們會使用 Cloud Key Vault 服務中的 THM 為 LSKF 提供暴力破解保護,這可提供與在裝置上使用安全硬體相同的安全性 (如 Google Pixel 2 裝置)。

由於我們不假設 LSKF 會儲存在安全硬體以外的裝置任何位置,因此只能在裝置解鎖後立即建立新的保險庫。當使用者輸入 LSKF 解鎖裝置時,LSKF 會暫時提供給 RAM 中的架構。這就是建立 Vault 的新 API 使用該值的時間點。裝置處於鎖定狀態時,無法建立新的 LSKF 保護的保管箱,因為 LSKF 無法使用。

保護復原代理程式

我們在復原代理程式中提供的主要安全防護措施,是讓復原代理程式無法查看目前裝置的 LSKF 或任何復原金鑰。只有架構應在用戶端端看到這些內容,這樣就更難利用復原操作員中的任何潛在錯誤或安全漏洞。Recovery Agent 主要用於管理生命週期事件,以及在 Cloud 和 Framework 之間來回傳遞資料。唯一的例外狀況是,在復原程序中,如果發生在 Vault 開啟通訊協定之前,使用者必須輸入舊裝置的 LSKF,也就是收集舊裝置已聲明 LSKF 的 UI,則會在復原代理程式 4 中實作。不過,一旦架構接手 Recovery Claim 的建構作業,Recovery Agent 實作就會「忘記」已聲明的 LSKF。

協定中的安全性功能

雖然完整分析該通訊協定超出本文的範圍,但我們想強調通訊協定內建的幾項防護機制。具體來說,這個通訊協定只會在整個過程中使用 LSKF 的雜湊。也就是說,如果 LSKF 具有高熵 (例如,如果是高熵密碼),儲存保管箱會比儲存密碼雜湊更安全,而且在這種情況下,密碼雜湊可提供獨立於 THM 安全性的安全性評估。因此,我們確實支援以 LSKF 為例,對鹽值進行「記憶體硬式」雜湊運算。我們也會以加密編譯方式將密鑰庫繫結至建立密鑰庫的裝置 ID,並將復原權利聲明繫結至在密鑰庫開啟通訊協定期間用於挑戰的 Nonce,以確保復原權利聲明為最新版本。

由於復原金鑰會在每次建立金庫時重新產生,因此我們會使用新建立的金庫覆寫現有金庫項目,實作金鑰輪替。金鑰庫在建立時會選取用於失敗嘗試計數器的地址,而架構會確保後續金鑰庫使用的計數器地址不會變更,除非 LSKF 已變更,或有新的同類群組公鑰認證清單。因此,您可以輪替復原金鑰,而不會影響 LSKF 的暴力破解保護機制。

Cloud Key Vault Service 的伺服器安全性

伺服器是透過在一般伺服器硬體上執行的軟體,以及在專用硬體 (Titan 晶片) 上執行的韌體,實作而成。我們將說明各層提供的防護措施。

硬體保護措施

CKV 服務伺服器端實作的首要安全防護機制,是使用 Google 自家設計的 Titan 晶片建構的「信任硬體模組」(THM)。晶片會執行韌體,公開實作 CKV 通訊協定的必要 API。具體來說,他們可以產生金鑰組合,並安全地與同群組的其他成員分享,讓韌體邏輯保護私密金鑰,避免洩漏至同群組的 Titan 晶片之外。他們也可以執行保管箱開啟作業,並維持嚴格遞增的失敗嘗試次數計數器 (計數器由 Titan 晶片內儲存的狀態提供支援)。我們會在本文件的後續版本中,提供 CKV Titan 晶片韌體執行的通訊協定更詳細的說明。

由於 Titan 晶片中的韌體邏輯會影響伺服器安全性,因此我們必須確保邏輯不會以允許晶片洩漏機密或忽略計數器限制的方式變更。為達成這項目標,我們也會變更 Titan 啟動載入程式,確保在套用任何更新之前,晶片儲存的資料 (例如同類群組的私密金鑰) 會完全清除。這項保護機制的缺點是,我們無法修補韌體中的錯誤,而不會造成資料遺失。更新韌體的功能等同於破壞現有硬體,並以新晶片取代。如果需要重大的韌體修補程式,Google 就必須製作並發布全新的認證同類群組公開金鑰清單,並逐步將所有使用者遷移至新清單。為降低此風險,我們會盡量減少韌體程式碼庫,並仔細稽核是否有任何潛在的安全性問題。

軟體防護

除了 THM 強制執行的每個 Vault 失敗限制之外,CKV 服務也實作了以軟體為基礎的頻率限制。這項限制頻率的功能旨在防止駭客入侵使用者的帳戶,並快速耗盡其 Recovery Key 的失敗次數上限,有效阻止使用者存取 Recovery Key。就像使用者在嘗試解鎖螢幕失敗太多次後,裝置會強制延遲一段時間一樣,CKV 服務也會在每次開啟保險箱的請求失敗後,強制延遲一段時間。

我們也會為託管使用者資料的 Cloud 服務導入標準安全措施,包括嚴格的存取權控管、監控和稽核機制。

詳細的通訊協定規格

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

附註

  1. 「Towards Reliable Storage of 56-bit Secrets in Human Memory | 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 宣布 Android 每月活躍裝置數超過 20 億部...」2017 年 5 月 17 日,https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users。  
  4. 這樣一來,我們就能提供靈活的 UI,讓使用者輸入其他裝置的 LSKF。目前裝置的架構可能沒有適當的 UI,無法輸入舊裝置的 LSKF。