TEE normal world侧实现分析

1 TEE 验证操作流程

1.用户提供PIN/pattern/password/fingerprint，在Android侧，LockSettingsService 和FingerprintService 产生通过binder给Gatekeeperd ，fingerprintd 发送一个请求。
2.这一步涉及到PIN/pattern/password和fingerprint，这取决于PIN/pattern/password和fingerprint是否提供。

• GateKeeperd发送PIN/pattern/password的哈希值到TEE侧的GateKeeper，如果TEE侧验证成功，GateKeeper会发送一个包含AuthToken HMAC密钥签名的相应的User SID到android下的GateKeeperd。
• 或者监听指纹事件的Fingerprintd发送数据到TEE侧的Fingerprint，如果TEE侧验证成功，Fingerprint会发送一个包含AuthToken HMAC密钥签名的相应的AuthToken到android下的Fingerprintd。

3.GateKeeperd和Fingerprintd接收到签名的AuthToken，并且通过拓展的Keystore服务binder接口将其发送给Keystore服务。另外，当设备密码改变或设备再次锁住时，GateKeeperd会通知Keystore服务。
4.Keystore服务将从GateKeeperd和Fingerprintd获取的AuthTokens发送给Keymaster，使用GateKeeper和Fingerprint共享的密钥验证AuthTokens。 Keymaster 将token中的时间戳信任为最后一次认证时间， 并基于时间戳的密钥发布决策。

2 GateKeeper

2.1 GateKeeper简介

Gatekeeper子系统在可信执行环境（TEE）中执行设备pattern/PIN/password认证。 GateKeeper通过具有硬件支持的密钥的HMAC注册和验证密码。 此外，Gatekeeper抑制连续失败的验证尝试，并且必须拒绝那些基于给定的超时和给定数量的连续失败尝试的服务请求。
当用户验证密码时，GateKeeper使用TEE派生的共享密钥签名认证证书发送个硬件支持的Keystore。也就是说，GateKeeper通知Keystore，认证绑定密钥（例如app创建的密钥）可以发布供app使用。

2.2 GateKeeper 结构

GateKeeper主要包含三个部分：

• GateKeeperd(GateKeeper daemon)： 一个c++的binder service，包括平台无关的逻辑和对 GateKeeperService Java接口的响应
• Gatekeeper HAL：hardware/libhardware/include/hardware/gatekeeper.h中的HAL接口，以及相应的HAL实现模块
• Gatekeeper (TEE)：TEE环境下对应的GateKeeperd，一个基于TEE环境实现的GateKeeper

GateKepper 认证流程：

摘自https://source.android.com/security/authentication/gatekeeper.html#architecture

2.3 GateKeeper 实现

GateKeeper的实现分为两种：
1.基于软件的实现（无硬件TEE环境，安全性较低）；
2.基于硬件的实现（存在硬件TEE环境，安全性较高）；
GateKeeper HAL实现：
GateKeeperd使用HAL与TEE下的GateKeeper进行密码验证。HAL的实现必须能够注册和验证blobs，所有实现都应遵循在每次成功密码验证生成的AuthTokens的标准格式。AuthToken的内容和语法都有相应的专门描述。
尤其是，gatekeeper.h的实现需要实现enroll和verify这两个函数。
enroll函数接收password blob，并对其签名，返回一个签名的句柄，返回的blob必须遵循system/gatekeeper/include/gatekeeper/password_handle.h中规范的结构。
verify函数需要比较给定password的签名，并确保与enroll的密码句柄匹配。
enroll和verify使用的key不能改变，并且应该在每次设备启动时重新生成。

3 Fingerprint HAL

3.1 简介

如果设备有用指纹传感器，那么用户能够注册一个或多个指纹来解锁设备或执行其他任务，android使用Fingerprint HAL链接供应商特定库和指纹硬件，要实现Fingerprint HAL，你必须在供应商特定库中实现fingerprint.h (/hardware/libhardware/include/hardware/fingerprint.h) 中的函数。
指纹对比流程：
假设设备上已经注册过一个指纹，指纹设备通常是空闲的，但是因为要响应注册和认证函数的调用，指纹会监听触碰事件（并且有可能指纹触碰时，屏幕会被唤醒）。
1.用户将手指放到指纹传感器上，供应商特定库基于当前注册模板集合决定是否匹配；
2.上一步的结果将被发送到Fingerprint HAL，Fingerprint HAL通知Fingerprintd指纹认证。

3.2 Fingerprint 结构

Fingerprint认证流程：

摘自https://source.android.com/security/authentication/fingerprint-hal.html

• FingerprintManager API: 直接和APP进程交互
  
  • 每个app都有FingerprintManager的实例；
  • FingerprintManager 是与FingerprintService通信的封装；
• FingerprintService.:操作系统进程的单一服务,主要处理和fingerprintd的通信
• fingerprintd (Fingerprint daemon): FingerprintService中binder接口的c++实现， fingerprintd 在其自己的进程中操作，并且封装Fingerprint HAL的供应商特定库
• Fingerprint HAL供应商特定库：Fingerprint HAL硬件供应商的实现，其主要和特定的硬件设备通信
• Keystore API and Keymaster：这些组件提供在TEE环境下安全密钥存储的硬件支持加密

具体供应商HAL的实现需要遵循TEE通信协议的要求。

指纹传感器采集的原始图像和处理的指纹特征数据不能发送到不可信的内存空间中，所有生物识别数据都需要被放到可信内存和传感器硬件中保护(在TEE中的内存被认为是可信的，反之，不可信)。
fingerprintd通过供应商特定库调用去注册指纹或执行其它操作。

3.3 Fingerprint HAL 实现

本节的指南旨在确保一下内容:

• 指纹数据不泄露
• 当用户在设备中被删除时，指纹数据被移除

以下是指南：
1.原始指纹数据或者派生产物（例如指纹模板），必须不能用传感器驱动和TEE环境外访问。如果硬件支持访问，则访问必须被TEE限制，并且应该被SElinux策略保护。也就是说SPI通道只能由TEE访问，并且所有设备文件必须有明确的SELinux策略。
2.指纹的获取，注册，识别都必须在TEE内部。
3.只有加密形式的指纹数据可以存储在文件系统上，即使文件系统是加密的。
4.指纹模板必须使用专用的设备特定的密钥签名（例如使用AES），其中至少包含文件路径，group和指纹ID，以使指纹模板文件不能被其他设备操作以及除用户以外的其他人在同一台设备上注册。比如在同一台设备上把指纹数据复制到其他用户，或者复制到另一台设备，都不能工作。
5.实现既不能使用文件系统提供的set_active_group()函数，也不能提供当删除用户时删除所有用户模板的方法。强烈建议将指纹模板文件加密存储在提供的路径中，如果因为TEE要求导致这不可行，则实现必须添加钩子函数以使删除用户时删除指纹数据。

3.4 Fingerprint HAL主要函数

主要的函数都已经在/hardware/libhardware/include/hardware/fingerprint.h中列出，一下是对一些函数的简要说明：

• enroll：切换HAL状态机开始收集和存储指纹模板，一旦注册完成或超时，状态机将会返回到空闲状态。
• pre_enroll：产生一个唯一的token，一开始指纹注册。为enroll函数提供token以确保已经有一个先前的认证，例如密码。token会被封装，并且例如，一旦设备认证确认，HMAC就会防止篡改。注册期间，必须检查token已验证token是否可用。
• get_authenticator_id：返回一个与token相连的当前指纹集。
• cancel：取消任何挂起的注册和认证操作，HAL状态机返回到空闲状态。
• enumerate：枚举所有指纹模板的同步调用。
• remove：删除指纹模板。
• set_active_group：将指纹操作限定为属于特定组（由GID标志或组标识符标志）的一组指纹中。
• authenticate：认证指纹相关操作。
• set_notify：注册一个从HAL获取通知的用户函数，如果HAL状态机处在忙状态，该函数将会被阻塞直到状态机解除忙状态。

4 Keystore

4.1 硬件支持的Keystore

SOC TEE环境的能力为android设备的系统，平台服务甚至第三方应用程序提供了硬件支持的强安全服务的机会。
Keystore在Android 6.0中得到显着增强，增加了对称加密原语，AES和HMAC，以及为硬件支持的密钥添加了访问控制系统。在密钥生成期间指定访问控制，并在密钥生命期内强制执行。密钥可被限制为仅在用户被认证之后才可使用，并且仅用于指定目的和指定加密参数。
android 6.0之前，android已经有一个简单的，硬件支持的加密服务API，提供了0.2,0.3版本的Keymaster HAL。keystore提供了数字签名和认证操作，加上生成和导入非对称签名密钥对。这已经在很多设备上实现了，但是还有很多安全目标是不能仅靠一个签名API能简单达到的。android 6.0的Keystore拓展了Keystore API 已提供更广泛的功能。

4.2 目标

Android 6.0 Keystore API和底层Keymaster 1.0 HAL的目标是提供一组基本但足够的加密原语，以允许使用访问控制的硬件支持密钥实现协议。
除了拓展加密原语的范围外，android6.0的Keystore还添加了一下内容：
- 允许限制密钥使用的使用控制方案，以减轻由于密钥的滥用而导致的安全损害的风险
- 允许将密钥限制到指定的用户，客户端和定义的时间范围的访问控制方案

4.3 架构

Keymaster HAL是一个OEM提供的，可动态加载的库，由Keystore服务使用，以提供硬件支持的加密服务。HAL的实现不能在用户空间甚至内核空间执行任何敏感操作。敏感操作被委派给通过某些内核接口到达的安全处理器。
在android设备中，keymaster HAL 认为”客户端”是多层的（例如app，framework，Keystore daemon），但由于本文档的目的，可以忽略。这就意味着所描述的Keymaster HAL API是底层的，用于平台内部组件，并不暴露给应用开发者。
Keymaster HAL的目的不是实现安全敏感算法，而是实现对安全世界的编排和解排请求。