走近隐私计算 | 浅谈可信执行环境TEE的诞生与技术变革_tee可信执行环境

前言

隐私计算作为保障数据价值挖掘过程中隐私安全的技术集合，能够在释放数据价值的同时，实现数据处于加密状态或非透明状态下的流通与计算，以达到各参与方隐私保护的目的。

本系列“走近隐私计算”将陆续带来隐私计算的几种技术路径（多方安全计算、同态加密、零知识证明、可信执行环境、联邦学习等）的整体介绍，以及部分经典论文的学术研读。

本期将浅谈可信执行环境(TEE)的定义及发展历程，以及当下常见的可信执行环境技术的现状及应用场景。

可信执行环境（TEE）的定义

可信执行环境 ( trusted execution environment ,TEE )是指在设备上一个独立于不可信操作系统而存在的可信的、隔离的、独立的执行环境, 为不可信环境中的隐私数据和敏感计算提供了一个安全而机密的空间, 其安全性通常通过硬件相关的机制来保障[1]。

对于TEE不同的使用和理解:

❖ Ben Pfaff [2] 认为 TEE 是“专用的封闭虚拟机, 与平台的其余部分隔离。通过硬件内存保护和存储的密码保护, 可以保护其内容免受未经授权的人员的观察和篡改。”

❖ OMTP [3] 认为“TEE 能抵御一组已定义的威胁。它实现与平台的不安全部分的隔离, 对生命周期管理, 安全存储, 加密密钥和应用程序代码提供保护。”

❖ GlobalPlatform[4] 认为“TEE 是一个与设备主操作系统同时运行但与其隔离的执行环境。它可以保护其资源免受一般的软件攻击。它可以使用多种技术来实现, 并且其安全级别也会有相应变化。”

❖ Jonathan M [5] 认为 TEE“旨在实现可信执行的功能集如下: 隔离执行、安全存储、远程证明、安全设置和可信路径。”

从以上定义来看, TEE 可以简单描述为一种安全的、受完整性保护的执行环境, 并具有内存和存储功能 [6] ，在帮助系统实现安全计算、隐私保护和数据保护的同时, 还为第三方提供隔离的执行环境[7]。

                                         图1 基于可信执行环境的数据计算平台技术架构

目前，可信执行环境的代表性硬件产品主要有Intel的SGX、ARM的 TrustZone等，由此也诞生了很多基于以上产品的商业化实现方案，如百度MesaTEE、华为iTrustee等。

可信执行环境（TEE）发展历程

1 TEE技术的发展历程

01 ARM TrustZone

⏰2006年 / 双系统解决方案

Open Mobile Terminal Platform(OMTP),也即开放移动终端平台组织，致力于为移动设备制造商、相关的软件与硬件供应商建立开放性架构，以帮助其开发出开放性的移动终端平台。

OMTP于2006年提出一种双系统解决方案：即在同一个智能终端下，除了多媒体操作系统外再提供一个隔离的安全操作系统，这一运行在隔离的硬件之上的安全操作系统用来专门处理敏感信息以保证信息的安全。该方案即TEE的前身。

基于OMTP的方案，ARM公司于2006年提出了TrustZone及其相关硬件实现方案，以期在ARM架构处理器中实现TEE技术。自此TrustZone 技术成为所有Cortex-A 类处理器的基本功能。

⏰2011年11月 / ARMv8

2011年11月，ARM公司发布了新一代处理器架构ARMv8。这是ARM公司的首款支持64位指令集的处理器架构。同时，随着ARMv8-M架构的公布，为了满足市场对嵌入式安全解决方案的需求，Cotext-M微处理器系列也引入了TrustZone技术。

⏰2021年上半年 / AMRv9

2021年上半年，在ARMv8发布十年后，AMRv9面世，带来了CCA等新的安全扩展。

02 Intel SGX

英特尔软件防护扩展（Intel Software Guard Extensions，SGX）是一组安全相关的指令，它被内置于一些现代Intel 中央处理器（CPU）中。

⏰2015年 / SGX 第一代

SGX 第一代于2015 年首次在第六代Intel Core（Skylake微架构）微处理器中实现。

⏰2021年 / SGX 第二代

SGX 第二代已在2021年正式开始大规模商用，其中最引人注目的升级为扩大了enclave的大小，以及加入了允许动态申请enclave实例的指令。

03 AMD PSP

AMD 平台安全处理器（AMD Platform Security Processor，PSP），是于2013年纳入AMD微处理器的可信执行环境子系统（PSP是一个协处理器）。

根据AMD的开发者指南，该子系统 "负责创建、监控和维护安全环境"，"其功能包括管理启动过程，初始化各种安全相关机制，监控系统的任何可疑活动或事件并实施适当的响应。

04 IBM SSC

IBM安全服务容器（IBM Secure Service Container，SSC）是可用于 IBM Z 和 IBM LinuxONE 服务器的可信执行环境。

⏰2016年 / zACI

2016年，IBM为IBM z13、z13s、LinuxONE Rockhopper和LinuxONE Emperor服务器推出了z Appliance Container Infrastructure（"zACI"）功能，通过驱动（固件）更新交付。IBM最初设想其可信执行环境最适合于软件 "设备"，如其自己的z/VSE网络设备、zAware和GDPS虚拟设备产品。

⏰2017年 / SSC

随着IBM改进zACI并扩大其适用性，他们在2017年推出IBM z14和LinuxONE Emperor II型号时迅速将其名称改为IBM安全服务容器（SSC）。

05其他

在可信执行环境技术发展的过程中，还出现过例如AMD Secure Encrypted Virtualization和IBM Secure Execution等各式各样的技术。但因种种原因，它们并未过多地吸引学者和消费者的目光。

2 TEE技术标准的发展历程

⏰2009年 / OMTP TR1

OMTP在其“高级可信环境：OMTP TR1”标准中首次对TEE做出了定义。

该标准定义了两个安全级别，其一针对软件攻击，其二针对软件、硬件攻击，并定义满足二者之一的“提供支持应用所需设施的一组硬件和软件组件”为TEE。

⏰2010年中旬 / WAC

OMTP的标准工作在2010年中旬结束，工作组转移至大规模应用社区WAC（Wholesale Applications Community）。

OMTP的标准，包含其定义的TEE，由全球移动通信系统联盟GSMA（Global System for Mobile Communications Alliance）主持。

⏰2010年7月 / GlobalPlatform

GlobalPlatform首次宣布了它们自己的TEE标准，首先关注TEE client API（与TEE交互的接口），后来扩展到TEE internal API，以及一整套TEE系统体系。

GlobalPlatform的TEE规范构成现在TEE环境的基础，任何商业或者开源产品一般都会参考该规范，并按照其定义的各种功能接口进行规范实现。

随着数字化信息的发展，开放式操作系统所引发用户信息泄露、密码被盗取等安全问题激增，因此，在常规操作系统之外，一个专门为高安全应用运行的操作系统TEE技术诞生。

以上，我们主要介绍了可信执行环境的定义及发展历程；

接下来，让我们关注一下现阶段常见可信执行环境技术的现状以及安全分析。

常见的可信执行环境技术

01 Intel SGX

SGX允许用户态及内核态代码定义将特定内存区域，设置为私有区域，此区域也被称作飞地（Enclave）。其内容受到保护，不能被本身以外的任何进程存取，包括高权限级别运行的进程（例如操作系统内核进程）。

//飞地中的代码和数据遵循的威胁模型为：

飞地是可信的，但它之外的任何进程都不可信（包括操作系统本身和任何管理程序），因此所有这些都被视为潜在的攻击者。在SGX不启用时，飞地的内容以加密的形式存放。

如果开发者想要使用SGX所提供的安全性，就需要将程序在源码层面重构。开发者需要将程序代码分成可信与不可信两部分，分别单独设计，并申明SGX专用的接口文件连接它们，最后重新编译、运行。这个过程一度被视为使用SGX技术的拦路虎。

同时，因为SGX内的进程运行在用户态，如果该进程需要大量调用系统调用，将会造成频繁的进程环境切换，带来极大开销。又因为在SGX第二代出现之前，enclave大小仅为可怜的128MB，所以开发者无法在enclave内放置内存占用量过大的进程。

图片来源：pixabay

Enclave还因其本身设计限制，无法天然地支持进程创建。因为这种种限制，想要享受Intel公司所宣称的安全性，所付出的代价并不算小。

❂ 学术界从2016年便开始着手解决这些问题。发表在顶级系统会议OSDI上的文章[1]允许开发者们将未经修改的二进制文件直接放入SGX中运行。

❂ 2017年发表在usenix ATC上的文章[2]解决了enclave内进程创建的问题。

❂ 2021年，阿里巴巴公司的成果[3]发表在ASPLOS上，解决了Graphene-SGX创建进程开销巨大的问题。同时，这个成果也被部署到阿里云中。SGX技术发展至今，已是一个可以称得上“方便好用”的可信执行环境技术了。

但因SGX设计中存在的限制，自其发布以来，便出现了许多针对SGX的侧信道攻击。

❂ 2017年3月27日，奥地利格拉茨理工大学的研究人员发现，通过使用某些CPU指令代替细粒度定时器，利用缓存DRAM侧通道，可以在5分钟内从运行在同一系统上的SGX飞地抓取RSA密钥[10]。

❂ 伦敦帝国学院的LSDS小组展示了一个概念证明，Spectre投机执行安全漏洞可用于攻击飞地[11]。

❂ 2021年发表在顶级安全会议CCS上的文章[4]公布了一种借用SGX的异步异常处理实现在enclave内任意位置任意写的攻击，影响极大，打击面极广。

02 ARM TrustZone

ARM TrustZone 是物联网网关的典型硬件[12]，Trustzone通过提供由基于硬件的访问控制支持的两个虚拟处理器，为在SoC中添加另一个专用安全内核提供了低成本的替代方案。这使得应用核心可以在两种状态（称为“世界”，分别为安全世界和不安全世界）之间切换，以防止信息从安全世界泄漏到不安全世界。

这种世界切换通常与处理器的所有其他能力正交，因此每个世界都可以在使用同一个内核时独立运行（这一点与SGX技术截然不同）。然后，内存和外设被告知内核的操作世界，并可利用这一点对设备上的数据和代码提供访问控制。

通常情况下，富操作系统（rich OS，也就是我们平时接触到的操作系统）在不可信的世界中运行，而较小的安全专用代码在可信世界中运行，以减少攻击面。典型的应用包括DRM功能，用于控制基于ARM的设备上的媒体使用，并防止对设备的任何未经批准的使用。

Trustzone的出现距今已有十余年了，用于其安全世界的操作系统也已相对完善，例如OP-TEE、Trusty、QSEE、SierraTEE等等。但和SGX一样，没有硬件是绝对安全的，针对trustzone的攻击也层出不穷。但和SGX一样，没有硬件是绝对安全的，针对trustzone的攻击也层出不穷。

例如近几年发表在IEEE上的文章[5-7]都是针对trustzone的侧信道攻击。其中Tang A等人提出了一种能源攻击[8]：

✦ CLKSCREW 攻击可用于通过提取秘密加密密钥并在商用手机上加载签名应用程序来破坏启用 TrustZone 的设备；

✦ CLKSCREW 攻击利用动态电压和频率缩放 (DVFS) 来推动处理器的操作限制，直到引发故障。

而针对安全世界操作系统的攻击也不少。例如在2014年Black Hat黑客大会上，Rosenberg 的演讲[9]描述了一个存在于 QSEE中的漏洞。

此漏洞影响了大量支持 TrustZone 的移动设备，包括三星 Galaxy Note 3、三星 Galaxy S4、LG Nexus 4 和 5、Moto X、LG G2 和 HTC One 系列。

可信执行环境技术的应用场景

如今，可信执行环境技术在以下场景中得到了广泛应用：

指纹识别

为了保护指纹识别全过程的安全性 ，防止指纹信息被窃取 。可以借助TrustZone空间隔离技术为指纹识别程序提供可信的执行环境，确保其执行安全，防止恶意代码攻击。同时，TrustZone技术可以对指纹数据和指纹特征模板进行加密，将密钥放入TrustZone保护的安全区域，以防止其被盗用。

数据资产所有权保护

通过TEE技术与区块链技术的有机结合，可以在企业间进行数据共享和交易时有效确保数据所有权和数据使用权的分离和保护。所有数据的使用过程都在TEE内部发生，计算过程完成后，原始数据也会在TEE内部被销毁，保障数据所有权不会因使用者对原始数据的沉淀而丢失。

无人机飞行控制系统

早期无人机的飞行控制系统的禁飞区数据保护方面相对较弱， 导致飞行控制系统很容易被人为破解， 禁飞指令形同虚设。近几年，TEE系统应用在无人机上，TEE端有完备的GPS坐标监控系统，只要飞机进入禁飞区域就会自动触发相应的程序切换到SWS模式，将飞行控制权限移交给相关人，执行预设的返航或者降落指令，真正地保证了禁飞区的领空安全。

总结

可以说，可信执行环境技术从本世纪初出现，发展到现在，在可用性方面，已有了长足的进步。在移动设备、嵌入式设备领域占主导的ARM架构，和在个人电脑、服务器领域普及率高的Intel，都有自主研发的可信执行环境技术。正在显示本篇报告的设备有极大可能就搭载了其一。

而针对这一类硬件设计的攻击，本就是网络安全攻防绕不开的一环。没有一种安全技术敢宣称自己是绝对安全的，可信执行环境也不例外，但它仍为我们的数据和代码提供了一个相对安全的环境。

参考文献

[1]宁振宇,张锋巍,施巍松.基于边缘计算的可信执行环境研究[J].计算机研究与发展,2019,56(07):1441-1453.

[2] Garfinkel T, Pfaff B, Chow J, et al. Terra: A Virtual Machine-Based Platform for Trusted Computing[C]. The nineteenth ACM symposium on Operating systems principles - SOSP '03, 2003: 193-206.

[3] Open Mobile Terminal Platform Consortium. OMTP advancedtrusted environment: OMTP TR1 (v1.1). //www.omtp.org/

Pub-lications.aspx. 2009.

[4] Global Platform. TEE system architecture. http://www.globalplatf-orm.org/specificationsdevice.asp. 2011.

[5] Vasudevan A, Owusu E, Zhou Z, et al. Trustworthy execution on mobile devices: What security properties can my mobile platform give me[C]. The 5th International Conference on Trust and Trustworthy Computing, 2012: 159-178.

[6] Asokan N, Ekberg J E, Kostiainen K, et al. Mobile Trusted Computing[J]. The IEEE, 2014, 102(8): 1189-1206.

[7] 姜超,李玉峰,曹晨红,李江涛.基于可信执行环境的物联网边缘流处理安全技术综述[J].信息安全学报,2021,6(03):169-186.DOI:10.19363/J.cnki.cn10-1380/tn.2021.05.11.

[8] Arnautov S , Trach B , Gregor F , et al. SCONE: secure Linux containers with Intel SGX. 2016.

[9] Tsai C , Porter D , Vij M . Graphene-SGX: a practical library OS for unmodified applications on SGX. 2017.

[10] Shen Y , Tian H , Chen Y , et al. Occlum: Secure and Efficient Multitasking Inside a Single Enclave of Intel SGX[J]. 2020.

[11] Cui J , Yu J Z , Shinde S , et al. SmashEx: Smashing SGX Enclaves Using Exceptions[J]. 2021.

[12]Guanciale R , Nemati H , Baumann C , et al. Cache Storage Channels: Alias-Driven Attacks and Verified Countermeasures[C]// 2016 IEEE Symposium on Security and Privacy (SP). IEEE, 2016.

[13] Lipp M , Gruss D , Spreitzer R , et al. ARMageddon: Cache Attacks on Mobile Devices[J]. Mundo Electrónico, 2015, 6(1):págs. 60-65.

[14] Ning Z , He S , Sun K , et al. CacheKit: Evading Memory Introspection Using Cache Incoherence[C]// IEEE European Symposium on Security & Privacy. IEEE, 2016.

[15]Tang A, Sethumadhavan S, Stolfo S. {CLKSCREW}: exposing the perils of security-oblivious energy management[C]//26th {USENIX} Security Symposium ({USENIX} Security 17). 2017: 1057-1074.

[16]Rosenberg D. Qsee trustzone kernel integer over flow vulnerability[C]//Black Hat conference. 2014: 26.

[17] Chirgwin R. Boffins show Intel's SGX can leak crypto keys. Theregister.com.https://www.theregister.com/2017/03/07/eggheads_slip_a_note_under_intels_door_sgx_can_leak_crypto_keys/. Published 2017. Accessed January 20, 2022.

[18] GitHub - lsds/spectre-attack-sgx: Spectre attack against SGX enclave. GitHub. https://github.com/lsds/spectre-attack-sgx. Published 2018. Accessed January 20, 2022.

[19]Eclipse Foundation. Key Trends from the IoT Developer Sur-

vey.https://iot.eclipse.org/resources/iot-developer-survey/iot-devel

oper-su-rvey-2018.pdf. 2018.