https://blog.csdn.net/trustbo/article/details/78234373 本文对当前流行的移动终端TEE技术做简要概述,并对一些细节展开讨论。
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的主要方式
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/biggoodbobo/article/details/78234373
|