可信执行环境（TEE）技术介绍

转自：https://blog.csdn.net/trustbo/article/details/78234373

1. 当前移动安全背景

 

当前移动终端面临这严重的安全威胁，威胁点如下图所示：

 

因此移动厂商、用户、服务提供商等各方都对移动安全提出了强烈的需求。

 

2. REE介绍（Rich Execution Environment）

 

REE简介

所有移动设备都支持REE

运行通用OS：Android、iOS、Linux

为上层App提供设备的所有功能

开放的、可扩展的且通用的

在互联互通的网络世界中运转

 

REE存在安全隐患

基于OS实现的App隔离极易被绕过；

OS代码庞大，漏洞频发；

OS很难被检验和认证；

OS可以看到App内部的所有数据；

大量的恶意代码和高级的攻击技术；

缺乏隔离意味着App无法安全存储密钥；

需要一个隔离环境操作密钥和敏感数据.

 

虚拟化技术实现的隔离

多个OS执行在虚拟的处理器上

基于软件的隔离，缺乏硬件安全性

Hypervisor可以访问所有OS的数据：进而可以访问所有App的数据

Hypervisor存在bugs

Malware通过控制hypervisor 窃取各种密钥

运行性能损耗大

 

SE实现的安全平台

SE具备极强的安全等级

SE向外提供的接口和功能极其有限：缓慢的串口连接、性能极低的CPU、无法处理大量数据、无UI能力

SE主要关注于保护内部密钥

TEE+SE的方案更加有强大：强于单独使用某一技术

 

3.TEE（Trusted Execution Environment）的提出

 

GlobalPlatform TEE 架构

 

TEE具备的特性

受硬件机制保护：TEE隔离于REE、只能通过特定的入口与TEE通信、并不规定某一种硬件实现方法

高性能：TEE运行时使用CPU的全部性能（独占）

快速通信机制：TEE可以访问REE的内存、REE无法访问受硬件保护的TEE内存

TEE中可以同时运行多个Trusted Application（TA）

由GlobalPlatform（GP）标准化：可在多种平台上移植

TEE中的所有组件模块先定义安全，再考虑性能

TEE中的可执行代码在执行前先要被验证（validate）

对于密钥使用安全存储机制：认证性、完整性和机密性

GP定义了TEE的保护轮廓（Protection Profile）：定义了所需的硬件保护强度

TA间相互隔离

 

TEE的安全设计

基本目标：
1.保护敏感数据免受REE和其他环境的恶意行为
2.必须使用硬件机制进行保护，且该机制仅能受控于TEE

保护强度：
1.对于密码学算法，当前采用128bit的安全强度

可抵御某些基于硬件的攻击：
1.抵御能力不如SE
2.SoC内部无安全防护措施

TEE必须被安全启动：
1.使用片上（on-chip）资源实现完全的安全启动流程
2.在控制权转移过程中完成完整性的传递

TEE提供可信存储：
1.保护数据的认证性、机密性和完整性
2.安全防护能力等同于TEE
3.可以被存储于非安全区域
4.必须提供某种回滚保护机制

 

 

TEE软件架构

 

TEE Internal APIs

 TEE Internal Core API：向上提供TrustedOS的功能、与CA通信、TA与TA通信、安全存储、密码学功能、时间

其他APIs：构建于Internal Core API之上，共享错误处理和API定义规则

私有APIs：GP未定义，无法通用，允许产品的特定差异化

 

启动流程

GP标准：启动流程只在系统启动时执行一次、要求启动流程至少建立一个信任根（RoT）、需要一些机制和方法去实现

一般情况下启动基于ROM代码：允许其他实现、依次验证加载的代码

一般情况下TEE首先启动：阻止REE接口生效

系统可以实现一个启动时的TEE（完全TEE的子集）

启动流程1：Trusted OS首先启动，如下图：

 

启动流程2：Trusted OS按需启动，如下图：

 

4.TEE实现：ARM TrustZone

 

 

TrustZone

为TA提供系统硬件隔离

嵌入式安全解决方案

ARM Cortex-A系列处理器及Cortex-M微处理器

创建了一个隔离的Secure World

REE与TEE通过SMC实现切换

应用场景包括：认证，支付，内容保护

目前实现和应用TEE的主要方式