一文入门TEE与ARM TrustZone安全技术

date

Nov 15, 2024

slug

2024-11-15-ARM-Trustzone-Summary

status

Published

TEE的概念及其由来

TEE就是可信执行环境（Trusted Execution Environment）。TEE概念的提出，主要是为了应对在智能设备日益普及的今天，用户敏感数据和关键信息在智能设备中的存储和处理，存在严重的泄露和被滥用的风险，可能会导致用户隐私、财产乃至人身安全面临严重的威胁，因此如何通过系统性的机制确保智能设备及其上运行的智能设备操作系统中的数据安全，就成为信息安全领域刻不容缓的事情。

更本质上讲，TEE实际上就是针对当前系统执行环境越来越复杂的情况，把用户应用的执行环境分为可信环境和不可信环境。把对用户隐私和安全高度相关的部分放在可信环境中运行，在其中施加更高级别的限制和控制；而安全级别不高的应用仍然放在不可信环境中正常运行，以此来提升系统的安全强度。

那么问题来了，在TEE这个概念或者ARM的Trustzone技术之前，产业界是如何解决信息安全或者可信执行环境相关的问题的？或者说，敏感数据信息及其处理逻辑是如何保存的？

加密保存在本地。在传统的嵌入式硬件产品的开发过程中，势必也是有一些敏感的信息需要得到合理的存储和处理，才能确保相关业务的安全开展。最典型的就是涉及到通信的情况下，对于通信数据如何进行加密就成为安全产品实现的必备要素之一，毕竟通信数据一旦被监听，可能会给用户造成很大的损失和威胁。而加密过程中所需要使用的密钥、证书文件、私钥等信息应该如何保存在这个产品中，是产品在安全性设计中需要仔细思考的问题之一。几乎所有的安全性设计指南中都提到，禁止敏感数据以明文的形式保存在产品的固件代码以及文件系统之中，那么一个相对可以容易被接受的方案，就是把这些敏感信息（密钥、私钥文件、初始化向量、License等）再额外的做一次加密，以密文的形式保存起来，这就是所谓的白盒密码算法。但是问题是，对这些敏感信息进行加密也需要密钥，那么这些对敏感信息加密的密钥应该如何管理呢？因此，这种做法只是增加了破解的难度，无法从实际上去解决问题，只适合一些对于安全性要求不是很高的应用场合。事实上，限制业界尚未有任何公开的安全白盒密码算法。

独立加密芯片/TPM。既然敏感信息及其处理逻辑不能保存在产品的固件以及文件系统之中，那么在产品中放一个独立的、无法被破解的加密子系统就成为针对以上问题的有效解决方案，这就是独立加密芯片的思路。大致就是把所有的敏感信息在出厂时写入加密芯片，这些信息无法被读出来，甚至连加密的逻辑也都是在加密芯片内部完成，在应用处理器的处理中只需要按照加密芯片原厂提供的API来调用接口对信息加解密即可。其实智能卡、银行所使用的U盾、各种工控板上的TPM等都可以认为是独立加密芯片方案的具体应用。之前在另外一篇笔记中整理过的MicroChip的ATECC608就是一款业界非常通用的独立加密芯片解决方案，这款芯片以I2C接口与应用处理器接口，为产品提供可靠的加密信息存储以及加解密算法硬件加速的功能。

加密芯片与应用处理器的整合。独立加密芯片/TPM确实是可以很好的解决加密芯片存储以及加密逻辑在独立硬件上运行的问题，但是独立的加密芯片和TPM需要与应用处理器基于某种硬件接口（例如I2C，SPI等）进行通信，这个硬件通信信道往往会被人从硬件攻击的角度上利用，存在一定的安全性隐患。所以人们开始尝试直接把独立加密芯片和TPM的功能直接集成在主处理器里面，相当于在主处理器里面直接封装了应用处理器和加密芯片，两者之间直接通过芯片内部的CPU总线等方式来进行通信，不会暴露通信线路到外部。这方面的典型应用就是苹果的Secure Enclave，以及微软的Pluton。但是目前存在的问题是这类整合加密芯片到应用处理器内部的设计并没有遵循一定的标准和规范，所以用户应用程序就很难甚至无法使用它们所提供的功能。

实际上加密芯片与应用处理器直接整合在同一个芯片上的安全解决方案已经与TEE已经比较类似了。TEE在前者的基础上，进一步通过扩展CPU指令集的方式把用户代码区分为可信执行环境和不可信执行环境，应用程序和加密数据逻辑运行在同一个CPU的不同运行状态之下，两者之间的切换通过CPU指令及其状态来进行区分，既可以共享CPU体系架构中的大部分功能，有可能为安全性敏感的数据及其处理逻辑提供一个独立的安全执行环境，同时保证了高效和安全。

TEE在逻辑层面把CPU上运行的应用程序代码分为安全应用和非安全应用，分别运行在安全环境和非安全环境中。两个环境和系统都运行在同一个CPU上，通过特殊的切换指令来控制进行切换。安全环境和系统既可以访问受安全保护权限所保护的硬件外设，也可以保护非安全模式下的外设，专门用于存储和处理对用户隐私和安全敏感的信息和应用逻辑；而非安全系统和系统只能访问非安全模式下的外设，当要访问用户敏感信息时通过标准化的预定义接口访问安全环境系统下的应用，得到其执行的返回值，非安全系统应用无法直接接触敏感信息及其运算逻辑。

因为TEE是在扩展CPU指令及其体系架构的基础上实现，所以基本上也就是由不同的CPU体系供应商来负责独立开发和维护，并牵头实现其在应用层上的标准化。目前业界著名的TEE解决方案主要是英特尔的SGX（Softeware Guard Extension，软件保护扩展）以及ARM的TrustZone，分别对应于X86平台和ARM平台。

ARM TrustZone的软件工作流程与实现方式

ARM的TrustZone就是ARM公司针对TEE可信执行环境所提出的解决方案。

ARM从ARMv6架构中开始引入TrustZone技术，并且在ARMv7和ARMv8两代架构中不断增强，日臻完善成熟。基本上TrustZone技术按照TEE的理念能够从芯片级别上实现对硬件资源的保护和隔离，并且目前已经在手机、智能电视乃至采用ARM平台的物联网、嵌入式等领域得到了非常广泛的应用。

在ARM CPU具体的代码执行流程上，ARM TrustZone技术把CPU的工作状态分为正常世界状态（或者说非安全世界）和安全世界状态两种状态。同时在ARM SOC的设计中，也把SOC内部所包含的各种硬件外设分为非安全硬件外设和安全硬件外设，对SOC芯片的外围硬件资源提供硬件级别的保护和安全隔离。

在CPU执行代码的流程中，当CPU处于正常世界状态时，任何应用程序都无法访问归属于安全世界状态的安全硬件外设，所有的安全硬件外设只能由处于安全世界状态运行下的可信操作系统及其可信应用程序访问。

而在整个系统的软件设计与实现的层面上，实际上同时有两个操作系统分时运行在ARM处理器上。我们一般的应用操作系统（例如Linux，Android，Windows）及其应用程序均运行在正常世界状态，正常世界状态下所具有的开发资源和功能相对于安全世界状态更为丰富，所以通常把运行在正常世界状态下的软件环境称为与TEE相对的丰富执行环境REE（Rich Execution Environment），运行在REE OS（就是Linux、Android、Windows等）上的应用程序就是正常世界状态下的客户端应用程序CA（Client/Untrusted Application）；而安全世界状态下的安全操作系统TEE OS则运行在安全世界状态，在TEE OS上运行的应用程序则是可信应用程序TA（Trusted Application），TEE OS下针对安全系统硬件的驱动则是可信硬件驱动SD（Secure Driver）。

以上对CPU的状态以及不同状态下运行的操作系统属性进行区分以后，处于正常世界运行状态下的操作系统和应用程序即使被黑客攻破，也仍然无法访问到安全世界状态下的任何资源。

在具体的ARM CPU执行逻辑上，ARM SOC在芯片级别内置的安全扩展组件会去校验CPU发出的访问请求的安全状态标志位（Non-Secure Bit，即NS bit），以此来判断当前CPU向总线发出的请求是安全请求还是非安全请求。

处于非安全状态下，CPU向总线发出的访问指令的安全状态标志位NS Bit固定为1，表示该请求是一个非安全请求。

处于安全状态下，CPU向总线发出的访问指令的安全状态标志位NS Bit固定为0，表示该请求是一个安全请求。

那么当一个非安全请求尝试去访问安全资源（只应该被安全访问请求访问）时，SOC中的安全扩展组件就会认为这个请求是非法访问，因此就会禁止其访问这个安全资源，并且返回失败或者无效的结果。ARM CPU本身就是通过以上的执行流程来实现对系统资源硬件级别的安全隔离和保护。

Client APP与Trusted APP之间的通信

REE OS和TEE OS两个操作系统及其上层的应用程序之间如何通信，或者说在REE OS端的应用程序如何调用TEE OS所提供的安全服务/功能？

在REE OS下的应用程序需要调用安全功能（例如使用用户的敏感数据进行身份验证）时，一般先在REE和TEE两侧预先定义好针对该安全功能所对应的请求编号Command ID，然后再TEE侧具体该安全功能的具体实现。REE侧的APP调用该功能时，通过这个预定义的请求ID从TEE侧获取验证结果。完整的验证过程以及验证中所需要用到的用户敏感信息全部在TEE OS中的Trusted APP上运行，REE侧是始终无法看到任何TEE侧的数据。因此对于REE侧而言，TEE侧的APP执行过程就是一个黑盒子，只会接受有限并且提前在双方定义好的合法应用，至于这些合法应用的执行逻辑，以及执行中用到了那些敏感数据信息，REE侧是完全无法知晓的。

各种TEE解决方案针对CA与TA之间的通信也都提供了相应的支持库，以方便在两者之间快速展开开发，例如OPTEE方案的libteec库就是其给Linux侧用户空间应用程序访问REE功能所提供的支持库。

Trusted APP的开发

目前国内外各种TEE解决方案一般都是遵循GP（Global Platform）规范进行开发并实现该规范所定义的API。在GP规范中，定义好了TEE解决方案应该遵循的架构以及可以提供给Trusted应用程序开发所使用的API原型，不同的TEE解决方案都应该支持这些标准化的API，这样开发者就可以使用这些标准化的API开发实际的Trusted应用程序，并且能让这个Trusted应用程序运行在不同的TEE解决方案中。这就有点像是Linux的Posix API，不管哪个Linux Distribution做了什么样的个性化开发，都必须要支持相同的Posix API接口，这样的情况下，同一个应用层程序才能够在不同的Linux Distribution上运行起来。

ARM TrustZone技术的硬件实现

一个完整的ARM片上系统SOC由ARM核、系统总线、片上RAM、片上ROM以及通过总线连接到ARM核上的其他外设构成。为了能够在CPU的体系结构上支持TrustZone，ARM在CPU扩展指令以及以上系统设计的基础上额外增加了安全扩展组件，为系统提供硬件级别的保护和隔离。

下图是基于ARMv8架构的一个支持TrustZone的SOC设计框图，红色部分表示可由非安全环境访问的部分，绿色部分则是只能由安全环境中的操作系统和应用程序访问的部分。

基于TrustZone的TEE OS解决方案

如上所述，TrustZone实际上是ARM针对TEE所提出的一种安全解决方案，通过扩展指令以及在架构设计中把硬件资源区分为安全环境部分和非安全环境部分两部分，来实现安全应用与非安全应用在硬件系统设计上的隔离。

因此，TrustZone只是ARM在CPU和SOC硬件设计上为支持TEE所提供的硬件基础，要能够实现完整的TEE解决方案，还需要完备的软件解决方案的支持。

基于ARM TrustZone所提供的框架技术，目前已有多个针对性的TEE OS方案。例如高通的QSEE，MTK的Trustonic，华为海思也有自己的TEE OS解决方案的完整实现，此外还有专业的TEE OS独立解决方案瓶钵、豆荚科技，以及开源的OP-TEE OS解决方案等。这些TEE OS都按照Global Platform规范来进行标准化实现，所以尽管其内部操作系统的逻辑不一样，但是对于二级厂商以及Trust APP的开发人员而言，其API接口是统一的。

参考资料

《手机安全与可信应用开发指南：Trustzone与OP-TEE技术详解》

TEE/Trustzone学习_trustzone和tee的区别-CSDN博客