Authentication

Android 採用使用者驗證器概念，用於解鎖裝置及控管加密編譯金鑰的存取權。這項作業涉及下列元件：

  • 加密編譯金鑰儲存空間和服務供應商。Android KeyStore 為應用程式提供採用專屬硬體的加密編譯服務。架構層級的 Android KeyStore 系統由 keystore2 系統服務支援。這項機制是以基礎供應商專屬的 KeyMint (先前稱為 Keymaster) 實作為基礎，確保金鑰內容只能在採用專屬硬體的安全環境中存取，例如受信任的執行環境 (TEE) 或安全元件 (SE)，例如 StrongBox。
  • 使用者驗證器：證明使用者已成功驗證。Android 支援下列驗證元件：
    • Gatekeeper：在 TEE 中進行 PIN 碼、解鎖圖案或密碼驗證。
    • (選用) Weaver，用於安全元件中的 PIN 碼、圖案或密碼驗證。
    • 指紋：用於指紋驗證。
    • 其他生物辨識驗證方式。搭載 Android 9 以上版本的裝置可以使用 BiometricPrompt 做為指紋和其他生物辨識的單一整合點。
    這些元件會使用採用專屬硬體支援的驗證權杖 (AuthToken)，與 keystore2 服務通訊驗證狀態。

這些元件都因供應商而異，但供應商實作必須符合硬體抽象層 (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)，向適當的生物辨識 Daemon 提出要求 (例如指紋的 fingerprintd 或臉部的 faced)。無論版本為何，生物辨識驗證都會在要求傳送後以非同步方式進行。
  2. HAL 服務會將資料傳送至對應的 TA，由 TA 產生 AuthToken：
    • 如果是 PIN 碼/解鎖圖案/密碼驗證，gatekeeperd 會透過 Gatekeeper HAL 服務，將 PIN 碼、解鎖圖案或密碼雜湊傳送至 TEE 中的 Gatekeeper TA。如果 TEE 中的驗證成功，Gatekeeper TA 會發出包含對應使用者 SID 的 AuthToken (以共用 HMAC 金鑰簽署)。
    • 如果是指紋驗證，fingerprintd 會監聽指紋事件，並透過指紋 HAL 將資料傳送至 TEE 中的指紋 TA。如果 TEE 驗證成功，指紋 TA 會發出 AuthToken (以 AuthToken HMAC 金鑰簽署)。
    • 如果是其他生物辨識驗證，適當的生物辨識 Daemon 會監聽生物辨識事件，並將事件傳送至適當的生物辨識 HAL 服務和 TA。
  3. 產生的已簽署 AuthToken 會透過繫結器介面傳遞至 keystore2 系統服務。
  4. keystore2 服務會將 AuthToken 附加至要求，以便 KeyMint (先前稱為 Keymaster) 執行加密編譯作業。KeyMint HAL 服務會將這些資料傳遞給 KeyMint TA，後者會使用與 Gatekeeper 和支援的生物辨識 TEE 元件共用的 HMAC 金鑰驗證這些資料。KeyMint 會將權杖中的時間戳記視為上次驗證時間，並根據時間戳記決定是否允許使用金鑰。

驗證流程不需要安全環境中的 TA 之間直接通訊：AuthToken 會從驗證器 TA 流向 Android 中的 keystore2 服務，然後再傳遞至 KeyMint TA。這也允許 keystore2 服務快速拒絕必定失敗的要求，因為它知道系統中可用的 AuthToken，從而節省了可能昂貴的 IPC 進入 TEE。

AuthToken 格式

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

裝置啟動流程

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

TA 通常會透過以下兩種方式取得這組共用 HMAC 金鑰：

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

無論是哪種情況，HMAC 金鑰都絕不能在 TEE 外部提供。

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

由於部分 TEE 缺少 IPC 基礎架構，因此 TEE 中的小工具之間不會進行通訊。這也允許 Keystore 服務快速拒絕必定失敗的要求，因為它知道系統中的驗證表，從而節省了可能昂貴的 IPC 進入 TEE。