Android 採用使用者驗證控管加密金鑰的概念，這需要下列元件：
- 加密編譯金鑰儲存和服務供應商。儲存加密編譯金鑰，並在這些金鑰之上提供標準加密編譯例程式。Android 支援硬體支援的 KeyStore 和 Keymaster，用於加密編譯服務，包括硬體支援的金鑰儲存加密編譯，可能包含受信任的執行環境 (TEE) 或安全元件 (SE)，例如 Strongbox。
- 使用者驗證器。驗證使用者是否在場和/或驗證成功。Android 支援Gatekeeper (用於 PIN 碼/解鎖圖案/密碼驗證) 和 Fingerprint (用於指紋驗證)。搭載 Android 9 以上版本的裝置可使用
BiometricPrompt做為指紋和其他生物特徵辨識功能的單一整合點。這些元件會透過已驗證的管道，將驗證狀態傳送至 KeyStore 服務。(架構層級的 Android KeyStore 系統也由 KeyStore 服務支援)。
Gatekeeper、Fingerprint 和 Biometric 元件可與 Keystore 和其他元件搭配使用，支援使用硬體支援的驗證權杖 (AuthTokens)。
註冊
在恢復原廠設定後首次啟動裝置時，所有驗證工具都會準備好接收使用者註冊的憑證。使用者必須先向 Gatekeeper 註冊 PIN 碼/解鎖圖案/密碼。這項初始註冊作業會建立隨機產生的 64 位元使用者安全 ID (SID)，做為使用者的 ID，以及使用者密碼編譯資料的繫結權杖。這個使用者 SID 會以加密方式繫結至使用者的密碼；如果成功向 Gatekeeper 驗證，AuthToken 就會包含該密碼的使用者 SID。
如要變更憑證，使用者必須出示現有憑證。如果現有憑證通過驗證，與現有憑證相關聯的使用者 SID 會轉移至新憑證，讓使用者在變更憑證後仍能存取金鑰。如果使用者未提供現有憑證，系統會使用完全隨機的使用者 SID 註冊新憑證。使用者可以存取裝置，但舊使用者 SID 下建立的金鑰會永久遺失。這就是所謂的不受信任的註冊程序。
在一般情況下，Android 架構不會允許不受信任的註冊，因此大部分使用者都不會看到這項功能。不過，如果裝置管理員或攻擊者強制重設密碼，就可能會發生這種情況。
驗證
使用者設定憑證並收到使用者 SID 後，即可開始驗證程序，這項程序會在使用者提供 PIN 碼、解鎖圖案、密碼或指紋時開始。所有 TEE 元件都會共用密鑰，用於驗證彼此的訊息。
- 使用者提供驗證方法，而相關服務會向相關的 Daemon 提出要求。
- 針對 PIN 碼、解鎖圖案或密碼，
LockSettingsService會向gatekeeperd提出要求。 - 生物特徵辨識驗證流程取決於 Android 版本。在搭載 Android 8.x 以下版本的裝置上，
FingerprintService會向fingerprintd提出要求。在搭載 Android 9 以上版本的裝置上，BiometricPrompt會使用適當的BiometricManager類別 (例如FingerprintManager或FaceManager)，向適當的生物辨識守護程序 (例如fingerprintd用於指紋或faced用於臉部) 提出要求。無論版本為何，生物特徵辨識驗證都會在要求傳送後以非同步方式進行。
- 針對 PIN 碼、解鎖圖案或密碼，
- 這個 Daemon 會將資料傳送至對應的 Daemon，後者會產生 AuthToken：
- 針對 PIN 碼/解鎖圖案/密碼驗證，
gatekeeperd會將 PIN 碼、解鎖圖案或密碼雜湊值傳送至 TEE 中的 Gatekeeper。如果 TEE 中的驗證成功，TEE 中的 Gatekeeper 就會將 AuthToken 傳送至 Android OS 中的對應項目，其中包含相應的使用者 SID (使用 AuthToken HMAC 金鑰簽署)。 - 針對指紋驗證，
fingerprintd會監聽指紋事件，並將資料傳送至 TEE 中的指紋驗證。如果 TEE 中的驗證成功，TEE 中的指紋會將 AuthToken (使用 AuthToken HMAC 金鑰簽署) 傳送至 Android OS 中的對應項目。 - 對於其他生物辨識驗證，適當的生物辨識 daemon 會監聽生物辨識事件，並將事件傳送至適當的生物辨識 TEE 元件。
- 針對 PIN 碼/解鎖圖案/密碼驗證，
- 這個 Daemon 會接收已簽署的 AuthToken，並透過 Keystore 服務的 Binder 介面擴充功能，將其傳遞至 Keystore 服務。(
gatekeeperd也會在裝置重新上鎖及密碼變更時通知 KeyStore 服務)。 - 金鑰庫服務會將 AuthToken 傳遞給 Keymaster，並使用與 Gatekeeper 共用的金鑰和支援的生物辨識 TEE 元件進行驗證。Keymaster 會將權杖中的時間戳記視為上次驗證時間，並根據時間戳記做出金鑰釋出決定 (允許應用程式使用金鑰)。
AuthToken 格式
為確保憑證可在各語言和元件間共用及相容，請參閱 hw_auth_token.h 瞭解 AuthToken 格式。這個格式是具有固定大小欄位的簡單序列化通訊協定。
| 欄位 | 類型 | 必填 | 說明 |
|---|---|---|---|
| AuthToken 版本 | 1 個位元組 | 是 | 下方所有欄位的群組標記。 |
| 挑戰 | 64 位元不帶正負號整數 | 否 | 隨機整數，可防範重播攻擊。通常是要求的加密編譯作業 ID。目前由交易指紋授權使用。如果有 AuthToken，則該值僅適用於包含相同驗證問題的加密作業。 |
| 使用者 SID | 64 位元不帶正負號整數 | 是 | 不重複的使用者 ID，以加密方式繫結至與裝置驗證相關聯的所有金鑰。詳情請參閱 Gatekeeper。 |
| 驗證器 ID (ASID) | 以網路順序表示的 64 位元無號整數 | 否 | 用於繫結至特定驗證器政策的 ID。所有驗證工具都有自己的 ASID 值，可根據自身需求進行變更。 |
| Authenticator 類型 | 以網路順序表示的 32 位元不帶正負號整數 | 是 |
|
| 時間戳記 | 以網路順序表示的 64 位元無號整數 | 是 | 自上次系統啟動以來的時間 (以毫秒為單位)。 |
| AuthToken HMAC (SHA-256) | 256 位元 Blob | 是 | 除了 HMAC 欄位以外，所有欄位的 SHA-256 MAC 金鑰。 |
裝置啟動流程
每次啟動裝置時，都必須產生 AuthToken HMAC 金鑰，並與所有 TEE 元件 (Gatekeeper、Keymaster 和支援的生物特徵信任元件) 共用。因此，為了加強防範重送攻擊，每次裝置重新啟動時，都必須隨機產生 HMAC 金鑰。
與所有元件共用此 HMAC 金鑰的通訊協定是一種平台特定的實作功能。金鑰絕對不提供給 TEE 以外的實體。如果 TEE OS 缺少內部進程間通訊 (IPC) 機制，且需要透過不受信任的 OS 傳輸資料，則必須透過安全的金鑰交換通訊協定進行傳輸。
Trusty 作業系統是 TEE 的範例，會與 Android 一同執行，但您也可以使用其他 TEE。Trusty 會使用內部 IPC 系統，直接在 Keymaster 和 Gatekeeper 或適當的生物辨識信任小工具之間進行通訊。HMAC 金鑰只會保留在 Keymaster 中；Fingerprint 和 Gatekeeper 每次使用時都會向 Keymaster 要求金鑰，且不會持續或快取該值。
由於某些 TEE 缺少 IPC 基礎架構，因此 TEE 中的小應用程式之間不會發生通訊。這也允許金鑰庫服務快速拒絕必定失敗的要求，因為它知道系統中的驗證表，可將可能成本高昂的 IPC 儲存至 TEE。