Android 使用用戶身份驗證門控加密密鑰的概念，需要以下組件：
- 加密密鑰存儲和服務提供商。存儲加密密鑰並在這些密鑰之上提供標準加密例程。 Android 支持用於加密服務的硬件支持的 Keystore和 Keymaster，包括用於密鑰存儲的硬件支持的加密，可能包括受信任的執行環境 (TEE) 或安全元件 (SE)，例如 Strongbox。
- 用戶驗證器。證明用戶的存在和/或成功的身份驗證。 Android 支持用於 PIN/圖案/密碼認證的Gatekeeper和用於指紋認證的Fingerprint 。搭載 Android 9 及更高版本的設備可以使用
BiometricPrompt作為指紋和其他生物識別的單一集成點。這些組件通過經過身份驗證的通道將其身份驗證狀態與密鑰庫服務進行通信。 （框架級別的Android Keystore 系統也由 keystore 服務提供支持。）
Gatekeeper、Fingerprint 和 Biometric 組件與 Keystore 和其他組件一起使用，以支持使用硬件支持的身份驗證令牌(AuthTokens)。
註冊
在恢復出廠設置後首次啟動設備時，所有身份驗證器都準備好接收來自用戶的憑據註冊。用戶最初必須向 Gatekeeper 註冊一個 PIN/模式/密碼。此初始註冊會創建一個隨機生成的 64 位用戶安全標識符 (SID)，用作用戶的標識符和用戶加密材料的綁定令牌。此用戶 SID 以加密方式綁定到用戶的密碼；對 Gatekeeper 的成功驗證會產生包含該密碼的用戶 SID 的 AuthToken。
想要更改憑證的用戶必須出示現有憑證。如果現有憑證驗證成功，則與現有憑證關聯的用戶 SID 將轉移到新憑證，使用戶能夠在更改憑證後繼續訪問密鑰。如果用戶不提供現有憑據，則使用完全隨機的用戶 SID 註冊新憑據。用戶可以訪問設備，但在舊用戶 SID 下創建的密鑰將永久丟失。這稱為不受信任的註冊。
在正常情況下，Android 框架不允許不受信任的註冊，因此大多數用戶永遠不會看到此功能。但是，設備管理員或攻擊者強制重置密碼可能會導致這種情況發生。
驗證
用戶設置憑據並收到用戶 SID 後，他們可以開始身份驗證，這在用戶提供 PIN、圖案、密碼或指紋時開始。所有 TEE 組件共享一個密鑰，用於驗證彼此的消息。
- 用戶提供身份驗證方法，相關服務向相關守護程序發出請求。
- 對於 PIN、圖案或密碼，
LockSettingsService向gatekeeperd發出請求。 - 基於生物特徵的身份驗證流程取決於 Android 版本。在運行 Android 8.x 及更低版本的設備上，
FingerprintService向fingerprintd發出請求）。在運行 Android 9 及更高版本的設備上，BiometricPrompt使用相應的Biometric Manager類（例如FingerprintManager或faced）向相應的生物識別守護程序發出請求（例如，fingerprintd指紋識別或面部識別FaceManager。無論版本如何，生物特徵身份驗證都會在發送請求後異步進行。
- 對於 PIN、圖案或密碼，
- 守護程序將數據發送到其對應方，後者生成一個 AuthToken：
- 對於 PIN/模式/密碼身份驗證，
gatekeeperd將 PIN、模式或密碼哈希發送到 TEE 中的 Gatekeeper。如果 TEE 中的身份驗證成功，則 TEE 中的 Gatekeeper 將包含相應用戶 SID（使用 AuthToken HMAC 密鑰簽名）的 AuthToken 發送到其在 Android 操作系統中的對應方。 - 對於指紋認證，
fingerprintd監聽指紋事件並將數據發送到 TEE 中的 Fingerprint。如果 TEE 中的身份驗證成功，則 TEE 中的指紋會向其在 Android 操作系統中的對應方發送一個 AuthToken（使用 AuthToken HMAC 密鑰簽名）。 - 對於其他生物特徵認證，適當的生物特徵守護進程偵聽生物特徵事件並將其發送到相應的生物特徵 TEE 組件。
- 對於 PIN/模式/密碼身份驗證，
- 守護程序接收簽名的 AuthToken 並通過密鑰庫服務的 Binder 接口的擴展將其傳遞給密鑰庫服務。 （當設備重新鎖定和設備密碼更改時，
gatekeeperd還會通知密鑰庫服務。） - 密鑰庫服務將 AuthTokens 傳遞給 Keymaster，並使用與 Gatekeeper 共享的密鑰和支持的生物識別 TEE 組件對其進行驗證。 Keymaster 信任令牌中的時間戳作為最後的身份驗證時間，並根據時間戳做出密鑰釋放決定（以允許應用程序使用密鑰）。
AuthToken 格式
為確保跨語言和組件的令牌共享和兼容性，在 hw_auth_token.h 中描述了hw_auth_token.h格式。該格式是具有固定大小字段的簡單序列化協議。
| 場地 | 類型 | 必需的 | 描述 |
|---|---|---|---|
| 認證令牌版本 | 1 個字節 | 是的 | 以下所有字段的組標籤。 |
| 挑戰 | 64 位無符號整數 | 不 | 防止重放攻擊的隨機整數。通常是請求的加密操作的 ID。當前由事務指紋授權使用。如果存在，則 AuthToken 僅對包含相同質詢的加密操作有效。 |
| 用戶 SID | 64 位無符號整數 | 是的 | 非重複用戶標識符以加密方式綁定到與設備身份驗證關聯的所有密鑰。有關詳細信息，請參閱網守。 |
| 身份驗證器 ID (ASID) | 網絡順序的 64 位無符號整數 | 不 | 用於綁定到特定身份驗證器策略的標識符。所有身份驗證器都有自己的 ASID 值，可以根據自己的要求進行更改。 |
| 驗證器類型 | 網絡順序的 32 位無符號整數 | 是的 |
|
| 時間戳 | 網絡順序的 64 位無符號整數 | 是的 | 自最近一次系統啟動以來的時間（以毫秒為單位）。 |
| AuthToken HMAC (SHA-256) | 256 位 blob | 是的 | 除 HMAC 字段外的所有字段的鍵控 SHA-256 MAC。 |
設備啟動流程
每次啟動設備時，都必須生成 AuthToken HMAC 密鑰並與所有 TEE 組件（Gatekeeper、Keymaster 和受支持的生物識別 trustlets）共享。因此，為了增加對重放攻擊的保護，必須在每次設備重啟時隨機生成 HMAC 密鑰。
與所有組件共享此 HMAC 密鑰的協議是依賴於平台的實現特性。不得在 TEE 之外提供密鑰。如果 TEE OS 缺少內部進程間通信 (IPC) 機制，需要通過不受信任的 OS 傳輸數據，則必須通過安全密鑰交換協議進行傳輸。
與 Android 相鄰運行的Trusty操作系統是 TEE 的一個示例，但也可以使用其他 TEE。 Trusty 使用內部 IPC 系統在 Keymaster 和 Gatekeeper 或適當的生物識別 trustlet 之間直接通信。 HMAC 密鑰僅保存在 Keymaster 中； Fingerprint 和 Gatekeeper 每次使用都向 Keymaster 請求密鑰，並且不會保留或緩存該值。
由於某些 TEE 缺乏 IPC 基礎設施，因此 TEE 中的小程序之間不會發生通信。這也允許密鑰庫服務快速拒絕那些必然會失敗的請求，因為它知道系統中的身份驗證表，從而將成本高昂的 IPC 保存到 TEE 中。