一、TEE GP规范文档合集

参考书籍：《手机安全和可信应用开发指南》

Trusted User Interface API v1.0
TEE System Architecture v1.3
TEE Secure Element API v1.1.2
TEE Client API Specification v1.0
TEE Internal Core API Specification v1.1

二、TEE 开发入门知识

1. 概述

REE（Rich Execution Environment）富执行环境 是指移动端系统的运行环境，运行的系统称为Rich OS（Rich Operating System），如常见的Android、iOS操作系统。

REE 是一个开放的环境，容易受到恶意软件的攻击，比如 敏感数据被窃取、数字版权被滥用、移动支付被盗用 等。因此，2010年7月 GP（Global Platform，全球平台组织）提出了 TEE (Trusted Execution Environment) 可信执行环境 的设计。

例如：Trusty，就是 Google 基于 ARM 架构的 Trustzone 技术实现的一套运行环境，通过硬件和系统软件层面的隔离，实现 normal world和secure world，也就是 REE和TEE 。Trustzone 从 ARM-v6 即开始支持，且在 ARM-v8 上增强了secure mode，TrustZone 技术能提供芯片级别对硬件资源的保护和隔离，当前在手机芯片领域已被广泛应用。而Google也规定从 Android M 版本以后所有的 人脸、指纹、虹膜识别 的隐私数据都需要使用TEE环境进行安全保护，否则无法通过Google的 CTS认证授权。

TEE 是一个与 REE 并存运行的独立执行环境，它具有自身完全可信的执行空间，即使设备被 root 也依旧安全，它可以访问设备主处理器和内存的全部功能，但完全隔离。Trusted OS 比 Rich OS 的安全级别更高，因此为Rich OS提供安全服务，如 指纹的录入比对、支付校验认证 等操作。

ARM-v8 上的 Trustzone 技术

2. OP-TEE

OP-TEE 由非营利的开源软件工程公司 Linaro 按照 GP规范 开发，所有源代码均可在 Github 上下载到。支持 QEMU、Hikey（Linaro推广的96Board系列平台之一，使用Hisilicon处理器）以及其他通用的 ARMv7/ARMv8 平台，开发环境搭建方便，便于开发者开发自有的 上层可信应用 ，且OP-TEE提供了完整的 SDK ，方便编译 TA和CA 。

OP-TEE 遵循 GP规范 ，支持各种 加解密和电子签名验签算法 以便实现 DRM、在线支付、指纹和虹膜识别 功能。OP-TEE 也支持在芯片中集成第三方的硬件加解密算法。除此之外，在 IoT和车载芯片 领域也大都使用 OP-TEE 作为TEE解决方案。

3. TEE Internal Core API Specification

常用术语概念

术语    |   			 全称        	    | 		解释		 
-----   | ----------------------------  | --------------- 
 REE    | Rich Execution Environment    |  	富执行环境	 
 TEE    | Trusted Execution Environment |  可信任执行环境   
 GP	    | 	Global Platform             |  全球平台组织
 SE     |   Secure Element              |  
Client  |        指REE端		        	|
Trusty  |        指TEE端                 |
 CA	    |	Client Application 	   	    |  运行在REE上的应用程序
 TA     |	Trusted Application         |  运行在TEE上的应用程序
 UUID   | Universally Unique Identifier |  TA的通用唯一身份标识符


CA 与 TA 交互规范中的名词概念:
Contexts			| 上下文			  | CA与TA连接使用的上下文，用于打开会话，TEEC_InitializeContext
Session 			| 会话			  | 发送命令的通道，TEEC_OpenSession
Commands			| 命令			  | 通过指定命令ID，CA向TA发送实际指令
Share Memroy		| 共享内存		  | CA和TEE之间数据交互的区域
Memory References	| 共享内存区		  | 固定范围的共享内存块
UUID				| 通用唯一身份标识   | TA的身份标识ID，用于CA调用某TA时，TEE通过UUID启动某TA镜像

Panic   				| 
Task    				| 
Command Identifier 		| 命令标识符，一个32位的整型数
Single Instance Trusted Application  | 单实例运行环境
Multi  Instance Trusted Application  | 多实例运行环境

加解密或摘要算法:
CMAC | Cipher-based Message Authentication Code
HMAC | Hash-based Message Authentication Code
AE   | Authenticated Encryption
AES  | Advanced Encryption Standard
DES  | Data Encryption Standard
RSA  | Rivest，Shamir，Adleman asymmetric algorithm
MD5  | Message Digest 5
SHA  | Secure Hash Algorithm

CA与TA之间的关系

CA 即执行在 REE 中的 普通应用程序，TA 则是执行在 TEE 中的 完全被信任安全程序。涉及到安全方面的操作时（如：人脸比对、指纹校验），CA就需要与TA交互，从TA中获取到结果。

REE中的系统结构：

CA（Client Application）对应 REE 层应用，比如指纹采集、支付能力等，通过调用 TEE Client API 实现与 TA 进行交互。CA通过接口让TA完成工作，完成对应功能然后返回计算结果，CA不需关心计算过程。

REE Communication Agent 为TA和CA之间的消息传递提供了REE支持

TEE Client API 是REE中的TEE驱动程序提供给外部的接口，用于 CA 与 TA 交互。

TEE中的系统结构：

TA（Trusted Application）是TEE中完成特定功能的应用。由于TEE中完成计算因此具有较高的安全性。每一个TA在REE中有一个或者多个对应的CA。TEE Internal Core API 则是TA侧的接口。

TEE Communication Agent 是可信操作系统的特殊组成部分，它与REE Communication Agent 一起工作，保证TA与CA之间传输消息的安全。

TEE Internal Core API 是TEE系统提供给TA调用的内部接口，包括密码学算法，内存管理等功能。

Trusted Device Drivers 可信设备驱动程序，为专用于TEE的可信外设提供通信接口。

Shared Memory 是一块只有CA和TA可以访问的一块安全内存，CA和TA通过共享内存来快速有效传输指令和数据

三、TEE软件交互接口定义

下面是TEE的软件交互流程，使用GlobalPlatform组织定义的 GP API 接口。

CA与TA通信需要使用下列接口完成整个会话流程：

CA侧接口如下：

TEEC_InitializeContext / TEEC_FinalizeContext：

对变量Context进行初始化和释放，用来建立和结束CA和TEE的联系，向TEE申请共享内存地址用于存放数据。
TEEC_OpenSession / TEEC_CloseSession：

建立和关闭一个CA和TA间的session，用于CA和UUID指定的TA进行通信，是CA连接TA的起始点和终点。
TEEC_InvokeCommand：

依靠打开的session，将传送命令请求给TA，并将必要的指令执行参数一并发送给TA。
TEEC_RegisterSharedMemory / TEEC_ReleaseSharedMemory：
TEEC_AllocateSharedMemory / TEEC_ReleaseSharedMemory：

同样是申请共享内存缓冲区，为更接近实现 零拷贝数据传输，TEEC_AllocateSharedMemory 是首选，其次才是 TEEC_RegisterSharedMemory。共享内存是由 REE 拥有并映射到 TEE 内存空间的内存。

TA侧接口：

TA_CreateEntryPoint：为CA建立接入点，使得TA可以被CA调用。

TA_DestroyEntryPoint：移除CA的接入点，结束TA的功能。

TA_OpenSessionEntryPoint：建立CA与TA之间的通讯通道，作为CA连接TA的起点。

TA_CloseSessionEntryPoint：关闭CA与TA的通讯通道

TA_InvokeCommandEntryPoint：接收CA传送的指令和参数，并在这TEE侧执行。

交互流程实现：

在 GP 标准中，CA 要与 TA 进行通信，需要建立如下所示的软件逻辑流程：

1）首先CA 需要与 Trusted OS 之间建立一个 Context，以后此 CA 与 TEE 环境的所有通信均基于此 Context。

2）然后 CA 会向 Trusted OS 申请与请求的 TA 建立一个 Session。

3）CA 与 TA 之间的 Session 建立完成后，CA 就可以向 TA 发送 Commands。

4）Commands 及其参数会通过共享内存的方式传递，TA 从共享内存中获取到 CA 的请求以及请求参数。

5）TA 在 TEE 环境下执行处理，得到的处理结果重新填充到共享内存中，CA 通过共享内存就可以获取到处理结果。

6）获得处理结果后，如不需要进一步请求，则由 CA 发起关闭 Session 的请求，Trusted OS 回收 TA 相关资源，最后 CA 发起销毁 Context 的请求，完成一次完整交互。

交互原理：

CA 通过调用 TEE Client API 触发系统调用，进入 REE 的操作系统内核态，系统根据 CA 的入参来找到需要执行的 REE 驱动程序，REE驱动程序通过 SMC （secure monitor call，安全监控模式调用) 汇编指令进入 Monitor模式，并修改 安全状态读写信号位（Non-secure bit，NS bit）将CPU切换到安全内核状态（改变寄存器最后1bit为0，1为非安全），进入 secure world。

切换到 TEE 后，CA 的服务请求通过 Binder 传到TEE侧，然后 TEE OS 通过 TEE Internal API 拉起对应的 TA，TA 运行结束后将结果和数据返回给 CA 。执行完后回到 TEE内核态，再通过 SMC 汇编指令进入 Monitor 切换到 REE 环境。

TEE 开发入门知识