用户认证是系统安全的重要特征，这是隔离机制之后的第一重要安全基本特征，并且另一重要安全基本特征“访问控制”需要基于此来实施。
Android系统不仅采用用户身份认证，并且采用通过身份认证验证把关的加密密钥机制。为此，该机制需要如下组件：
（1）用户身份验证程序
证明用户通过身份认证。
Android支持GateKeeper（用于PIN码/解锁图案/密码身份验证）和生物识别身份认证BiometricPrompt（如：指纹识别和人脸识别）。
（2）加密密钥存储和服务提供程序
存储加密密钥并给予这些密钥提供标准加密服务。
Android支持由硬件支持的密码库和Keymaster这两种加密服务，该服务包括可信执行环境（TEE）或安全元件（SE），例如：Strongbox。
Gatekeeper、BiometricPrompt组件与密码库进行协同运作，以支持使用由硬件支持的身份认证令牌（AuthToken）。
典型应用场景：对于指纹支付应用，首先通过指纹来验证用户身份，并且用该验证结果来获取该用户对应的密钥来进行支付数据的加解密操作。
一、用户认证的主要内容
1、注册
首次启动时，用户必须先通过Gatekeeper注册一个PIN码/解锁图案/密码身份验证，这会随机生成一个64位的用户安全标识符（SID）。SID作为用户的标识符与用户加密信息的绑定令牌，该SID会以加密形式绑定到用户的密码。当用户通过Gatekeeper的身份验证后，会生成相应的AuthToken，其中包含SID。
AuthToken的格式：
（1）AuthToken版本 ： 1个字节：下方所有字段的组代码。
（2）质询：64位（Option）：防范重放攻击的随机整数，通常是所请求的加密操作的ID。
（3）SID：64位：用户标识符，以加密形式绑定到设备身份验证关联的所有密钥。
（4）身份验证程序ID：64位：绑定到特定身份验证程序时使用的标识符（所有身份验证程序都有自己的ASID值）。
（5）身份验证程序类型：32位：表示Gatekeeper或者Fingerprint等。
（6）时间戳：64位：自最近一次系统启动以来已经过的时间。
（7）AuthToken HMAC: 256位：上述字段的已加密SHA-256 MAC。
2、身份验证
身份验证从用户提供PIN码/解锁图案/密码身份验证开始。所有TEE组件都共用一个密钥来验证对方的消息。
（1）用户提供身份验证方法，然后关联的服务向关联的守护程序发出请求：
-
对于PIN码/解锁图案/密码身份验证，LockSettingsService会向gatekeeperd发出请求。
-
对于生物识别技术的身份验证，BiometricPrompt会使用合适的BiometricManager（如：FingerprintManager或FaceManager）向相应的生物识别守护程序发出请求。
（2）守护程序将数据发给副本，后者生成AuthToken：
-
对于PIN码/解锁图案/密码身份验证，gatekeeperd将PIN码/解锁图案/密码哈希发送给TEE中的Gatekeeper。如果TEE中的身份验证成功，TEE中的Gatekeeper会将包含相应用户SID的AuthToken发送到它在Android系统中的副本。
-
对于指纹识别身份验证（生物识别技术之一），fingerprintd会监听指纹事件并将数据发送到TEE中的Fingerprint。如果TEE中的身份验证成功，TEE中的Fingerprint会将AuthToken发送到它在Android系统中的副本。
（3）守护程序收到签名的AuthToken，将它传递给密钥库服务。
（4）密码库服务将AuthToken传递给Keymaster，并使用与Gatekeeper和生物识别TEE组件共用的密钥来验证该AuthToken。
注：设备重新启动后，AuthToken即作废。
3、设备启动流程
每次设备启动时，都必须生成AuthToken HMAC密钥并由所有TEE组件共用该密钥。
并且在任何情况下都不能将该密钥设为在TEE之外可用。
二、用户认证的主要子系统
1、Gatekeeper
Gatekeeper子系统在TEE中执行设备解锁图案/密码身份验证。
Gatekeeper会限制连续失败的验证尝试次数，并且必须根据指定的超 时和指定的连续失败尝试次数拒绝服务请求。
当用户验证身份密码时，Gatekeeper认证可让Keystore知道可以发布与身份验证绑定的密钥（例如，应用创建的密钥）供应用使用了。
（1）架构
GateKeeper包括如下3个主要组件
-
gatekeeperd（Gatekeeper守护程序）：与GateKeeperService Java接口相对应。
-
Gatekeeper硬件抽象层：HAL接口的实现模块
-
Gatekeeper（TEE）：gatekeeperd的TEE副本。基于TEE的Gatekeeper实现。
（2）HAL实现
gatekeeperd守护程序利用HAL同TEE副本进行交互，以进行密码身份验证。
HAL实现必须能够签署和验证Blob：
-
enroll函数会获取一个密码Blob，为其签名，并以句柄形式返回签名。
-
verify函数将收到的签名与注册的句柄进行比较，并确定两者是否一致。
所有实现都需要遵循每次密码验证成功时生成AuthToken的标准格式。
用于注册和验证的密钥不得更改，并且应该可以在每次设备启动时重新派生。
2、生物识别
生物识别属于第二层级的身份验证方法，是一种更方便的身份确定方法，虽然其安全性可能较低。（在Andorid分层身份验证模式下，安全级别最高的第一层级是：PIN码、图案和密码。）
强身份认证的三个因素是：
A：你知道什么 Somthing You Know 知识因素；
B：你有什么 Something You Have 占有因素；
C：你是谁或你有什么特征 Something You Are 生物因素。
有效的多因子认证（MFA）应该是多因子包含三个因子中的2个或3个（密码+银行卡），不应该是同一因子下的多个（密码+身份证号码 或者 指纹+人脸）。
结合这三种因素可以实现多层次的身份验证，显著提高安全性。例如，银行在进行高风险交易时可能会要求客户提供密码（知识因素）、银行卡（占有因素）以及通过指纹识别（生物因素）来确认身份。
Android CDD定义了三类生物识别强度：第3类（强类）；第2类（弱类）；第1类（便利类）。虽然这三类都可以与锁屏集成，但只有第3类和第2类才能与android.hardware.biometrics API集成。
（1）架构实现
（2）HAL
应遵循以下生物识别HAL准则，确保生物识别数据不会泄露，并在从设备中移除用户时一并移除。
-
确保在任何情况下都无法从TEE以外访问原始生物识别数据或衍生内容。
-
生物识别信息的采集、注册和识别必须在安全隔离环境内部进行，以防范数据泄露和其他攻击。
-
为了防范重放攻击，请使用设备专用私钥对生物识别模版进行签名。
-
CDD要求生物识别数据和衍生文件以加密形式存储，尤其是不在TEE中时。在移除用户后，必须清理这些文件。
3、Protected Confirmation
Android受保护的确认利用受硬件保护的界面（称为“可信界面”）来促进关键事务的高可信度。搭载Android9（API级别28）或更高版本的受支持设备可以使用Android Protected Confirmation功能。
当应用调用受保护的确认时，可信界面会提示用户确定。即使Android或其内核Linux收到攻击，可信界面也可断言用户对提示信息的批准具有高可信度，此断言将与Keymaster一同传递给远程第三方。
可信界面的实现可以分为两部分，这两部分都位于TEE中。
I、Keymaster的扩展程序：生成带有使用要求（Tag::TRUSTED_CONFIRMATION_REQUIRED)的密钥。
II、Confirmation UI的应用：用于显示画面和生成确认令牌。
在金融支付的场景，最后一步确定进行支付的时候，通常会要求“交易回显确认”，即：显示出交易信息（转账方账户 | 接收方账户 | 转账金额 ），让用户最终手工确定一下。
这其中会包含两个可能的风险：
I：显示出来的交易信息是否会被伪造或者实际交易信息是否会被篡改？（非“所见即所想”）
II：确定动作是人工操作的还是被程序控制的？
以上两个风险，在TEE世界得以安全保障。
【参考资料】
1、https://www.android.com/android-14/
2、https://source.android.com/docs/security/
3、身份认证相关知识