Authentication

Android 具有使用者驗證器的概念，可用於解鎖裝置，以及控管加密金鑰的存取權。這項程序涉及下列元件：

  • 加密編譯金鑰儲存空間和服務供應商。儲存加密金鑰，並在這些金鑰上提供標準加密常式。Android 支援採用專屬硬體的 Keystore 和 KeyMint (先前稱為 Keymaster)，提供加密服務，包括採用專屬硬體的金鑰儲存加密功能，可能包含受信任的執行環境 (TEE) 或安全元件 (SE)，例如 StrongBox。
  • 使用者驗證器。證明使用者在場和/或已成功通過驗證。Android 支援 Gatekeeper，用於 PIN 碼/解鎖圖案/密碼驗證，以及 Fingerprint，用於指紋驗證。搭載 Android 9 以上版本的裝置可使用 BiometricPrompt 做為指紋和額外生物特徵辨識的單一整合點。這些元件會透過經過驗證的管道，將驗證狀態傳達給金鑰儲存服務。架構層級的 Android KeyStore 系統也由 KeyStore 服務提供支援。

這些元件各有不同的供應商，但供應商實作項目必須符合硬體抽象層 (HAL) 介面規格，並通過相應的供應商測試套件 (VTS) 測試。

供應商實作通常也分成兩部分，並透過供應商專屬的通訊機制連結：

  • HAL 服務會以 Android 系統程序的形式執行，並接收來自 Android 系統的 Binder 要求。
  • 受信任的應用程式 (TA) 會在安全環境中執行，執行實際的安全作業。

註冊

裝置恢復原廠設定後首次啟動時，所有驗證器都會準備好接收使用者的憑證註冊資訊。使用者必須先透過 Gatekeeper (或 Weaver，如果有的話) 註冊 PIN 碼、解鎖圖案或密碼。這項初始註冊程序會隨機產生 64 位元的使用者安全 ID (SID)，做為使用者的 ID 和使用者加密編譯資料的繫結權杖。這個使用者 SID 會以密碼編譯方式繫結至使用者的密碼；成功向 Gatekeeper 驗證後，系統會產生包含該密碼使用者 SID 的 AuthToken。

如要變更現有憑證，使用者必須出示該憑證。如果現有憑證通過驗證，與現有憑證相關聯的使用者 SID 會轉移至新憑證，讓使用者在變更憑證後仍可存取金鑰。

在某些情況下，裝置管理員可以執行「不信任的註冊」，註冊新憑證，不必出示現有憑證。這樣一來，使用者就能存取裝置，但以舊使用者 SID 建立的金鑰會永久遺失。

驗證

本節說明一般的驗證流程，其中涉及 Android 和安全環境中多個元件之間的互動。請注意，所有安全元件都會共用 (每個啟動程序) 密鑰 HMAC 金鑰，用來驗證彼此的訊息。

使用者設定憑證並獲派使用者 SID 後，即可開始驗證。驗證程序會在使用者提供 PIN 碼、解鎖圖案、密碼、指紋或其他高強度生物特徵辨識資訊時啟動。驗證流程

圖 1. 驗證流程

  1. 使用者提供驗證方法，相關聯的服務會向 HAL 服務提出要求。
    • 如果是 PIN 碼、解鎖圖案或密碼，LockSettingsService 會向 gatekeeperd 發出要求。
    • 以生物特徵辨識為基礎的驗證流程取決於 Android 版本。 在搭載 Android 8.x 以下版本的裝置上，FingerprintService 會向 fingerprintd 發出要求。在搭載 Android 9 以上版本的裝置上，BiometricPrompt 會使用適當的 BiometricManager 類別 (例如 FingerprintManager 或 FaceManager)，向適當的生物辨識精靈 (例如指紋的 fingerprintd 或臉部的 faced) 發出要求。無論是哪個版本，生物辨識驗證都會在傳送要求後非同步進行。
  2. HAL 服務會將資料傳送至對應的 TA，後者會產生 AuthToken：
    • 如果是透過 PIN 碼/解鎖圖案/密碼進行驗證，gatekeeperd 會透過 Gatekeeper HAL 服務，將 PIN 碼、解鎖圖案或密碼雜湊值傳送至 TEE 中的 Gatekeeper TA。如果 TEE 中的驗證成功，Gatekeeper TA 會發出 AuthToken，其中包含相應的使用者 SID (以共用的 HMAC 金鑰簽署)。
    • 如要進行指紋驗證，fingerprintd 會監聽指紋事件，並透過指紋 HAL 將資料傳送至 TEE 中的指紋 TA。如果 TEE 中的驗證成功，指紋 TA 會發出 AuthToken (以 AuthToken HMAC 金鑰簽署)。
    • 如果是其他生物辨識驗證，適當的生物辨識精靈會監聽生物辨識事件，並將事件傳送至適當的生物辨識 HAL 服務和 TA。
  3. 精靈會收到已簽署的 AuthToken，並透過擴充功能傳送至金鑰儲存區服務的 Binder 介面，(gatekeeperd 也會在裝置重新鎖定和裝置密碼變更時通知金鑰儲存服務)。
  4. Keystore 服務會將 AuthToken 傳遞至 KeyMint，並使用與 Gatekeeper 和支援的生物特徵辨識 TEE 元件共用的金鑰驗證這些權杖。KeyMint 會將權杖中的時間戳記視為上次驗證時間，並根據該時間戳記決定是否發布金鑰 (允許應用程式使用金鑰)。

驗證流程不需要安全環境中的 TA 直接通訊：AuthToken 會從驗證器 TA 傳送至 Android 中的 keystore2 服務，然後再傳送至 KeyMint TA。這也允許 keystore2 服務快速拒絕註定會失敗的要求，因為該服務瞭解系統中可用的 AuthToken，可節省可能耗費大量資源的 IPC 到 TEE。

AuthToken 格式

AuthToken 的格式由 HardwareAuthToken.aidl 中的 AIDL 規格提供。

裝置啟動流程

每次啟動裝置時，都必須產生 AuthToken HMAC 金鑰，並與所有 TEE 元件 (Gatekeeper、KeyMint 和支援的生物特徵辨識 Trustlet) 共用。因此，為加強防範重送攻擊，每次裝置重新啟動時，都必須隨機產生 HMAC 金鑰。

技術助理通常會透過以下兩種方式取得共用 HMAC 金鑰的存取權：

  • 共用密鑰協議：keystore2 服務會在裝置啟動時執行多方金鑰協議通訊協定，以便在參與的 TA 之間安全地衍生 HMAC 金鑰。不過，參與的 TA 必須有權存取共用的預先分享密碼。
  • 直接存取：位於相同安全環境中的 TA 可以使用內部處理序間通訊機制 (視平台而定) 分享 HMAC 金鑰。

無論如何，HMAC 金鑰絕不得在 TEE 外部提供。

與 Android 並行執行的 Trusty 作業系統就是 TEE 的例子，但您也可以使用其他 TEE。Trusty 會使用內部 IPC 系統，在 KeyMint 和 Gatekeeper 或適當的生物特徵辨識 Trustlet 之間直接通訊。HMAC 金鑰只會保留在 KeyMint 中；Fingerprint 和 Gatekeeper 會在每次使用時向 KeyMint 要求金鑰，且不會保留或快取該值。

由於部分 TEE 缺少 IPC 基礎架構，TEE 中的小程式之間不會進行通訊。此外，由於金鑰儲存區服務瞭解系統中的驗證資料表，因此可以快速拒絕註定會失敗的要求，節省可能耗費大量資源的處理序間通訊 (IPC) 到 TEE。