02-15 19:55 华为_系统工程师

关注

可信启动、安全启动：SGX、TrustZone、Secure

最近在公众号上看到了一篇文章，算是又丰富了自己的安全方面的眼界。最近看公众号取代了小视频、知乎这些东西。以前是真的不喜欢碎片化的东西，看什么学什么总是要找到书籍。但是这样的做法太过的极端，因为有时候有些事是两面性的。比如像安全这方面，本来有的东西和内容就很少，所以即使碎片化，也是前辈们花时间分享出来的东西，学起来还是很有价值的。

1、安全启动与可信启动

对于这两个概念你知道他们的区别吗？

1、安全启动

安全启动：启动过程中，前一个部件验证后一个部件的数字签名，验证通过后，运行后一个部件，否则就中止或复位系统。因此它是一个防恶意篡改的手段。

目前安全启动基本上是对安全要求比较高的场景下，芯片必备功能。

这里的关键词是前一个校验后一个，这里就有了一个信任链-CoT

2、可信启动

可信启动：启动过程中，前一个部件度量（计算HASH值）后一个部件（通常在后一个部件被签名校验过之后），然后把度量安全的保存下来，比如扩展到TPM的PCR中。后续接入平台后，部件的度量会上报到认证平台，认证平台会有配置一个可信白名单，如果某个部件的版本信息不在白名单里，则认为此设备是不受信任的，因为它可能使用了一个虽然有签名，但可能BUG的版本。因此它是一个可信版本的管理手段。

可信启动(Trusted Boot):也称为Measure boot,就是在启动过程中，前一个部件度量（计算HASH)后一个部件，然后把度量值安全保存下来，比如放到一个集中的部件(或云端)，设备启动后的一致性(完整性)的校验由集中的部件负责完成。

要实现可信启动，首先需要 cpu 的支持，其次还需要 TPM（Trusted Platform Module）芯片的支持，TPM 有两个作用，作用一：提供加解密算法的支持，作用二：存储对称密钥及私钥。可能部分嵌入式产品还需要 OTP（One Time Programmable）芯片。

3、小结

安全启动/可信启动是确保系统级别的安全手段，适用于有可信诉求的整机系统，终端设备如手机、STB、路由器等，当然也适用于通用服务器设备。

可信计算组织（TCG）提出了“可信链”和“可信度量”的概念，并认为：如果信息系统由一个初始的“可信根”开始，在平台控制权每一次转换时，通过完整性度量将这种信任传递给下一个组件，则平台计算环境就始终是可信的。

TCG规范提倡采用一个单独的安全模块作为信任根,这是一个软/硬件相结合的子系统。该子系统被设计成能够度量、存储和报告系统可信赖属性的模块,是建立信任链的起始点。TCG规范旨在提供开放的、平台无关的标准,从而被应用到不同的平台设备中。TCG中的信任模型是以TPM硬件模块为基础的。TPM是一个可独立进行密钥生成、加/解密的装置,内部拥有独立的处理器和存储单元,可存储密钥和敏感数据，为各种计算平台提供完整性度量、数据安全保护和身份认证服务。但TCG只为系统引导阶段建立初始信任过程中参数的度量和报告制定了标准,但对于如何实施未作探讨。

两者的区别就在于安全启动的校验是在信任链，而可信启动是一个TPM统一校验，不过在我们实际的开发中，这两者都是交互的，可能某些过程的镜像是一个信任链，但是有的镜像或者说是模块，又负责校验了多个镜像。

以上安全启动和可信启动的概念，网上有许多专家在讨论，可以自行进一步理解。然而，如果仅从字面要求试图实施时，我们又会发现许多新的问题，举个例子：安全启动时，确实每一级都被签名校验了，但确定安全吗？某一级如操作系统1分钟前刚刚被校验过，1分钟后还是可信的吗？不见得，这个过程中，操作系统完全有可能已经被非法修改过了。

要做到相对更安全，要么能够做到Runtime的实时校验，即每次使用那一刻都要校验。如果做不到Runtime校验，那就想办法将校验过的数据安全保存起来…相关实现方案和技术其实在有前提的情况下已具备，这是另一个课题。

这个前提是指系统需要是不开放的嵌入式系统，因为不开放，可定制，提供特定的功能/服务，因此整机系统的保护是可行的，并且方案都是很成熟的。 (但是像安卓这些其实都是很开放的系统。)

回归产品

2、现状-回归产品（我觉得这点很重要-为什么有了trustzone?）

下一次想想为什么需要安全？

对于通用计算设备比如服务器产品是个什么样的情况呢？基本上就是这么个事实：

1、系统“全局保护”越来越难以实现，且不切实际

原因是当前开源共享，并且是自由的大环境。操作系统开源，应用开源，用户自由地选择不同版本的操作系统和应用，一切都不在设备厂商的控制中。

2、“全局保护”不可行，那就将保护范围缩小到应用的部分片段

这就是Intel SGX或ARM TrustZone的由来

因此，Intel SGX或ARM TrustZone是传统的系统保护手段不可行，通用系统设备的保护方案无法借鉴嵌入式系统的方案后，安全技术工作者转变思路后的产物。

3、技术

1、Intel SGX

网上有相当多的材料，并且都有一个特点：短小精悍。于是我们就看到了非常经典的一个图，足以说明SGX应用的工作原理：

应用在设计时，需要考虑所谓的trusted和untrusted两部分，trusted即为处理敏感数据的实现部分
实现应用，对于trusted部分，需要使用Enclave定义语言（EDL）来实现需要的逻辑。通过EDL实现的内容，将被执行在安全区域（Enclave）
Enclave中的实现可被untrusted的代码调用，当被调用时，命令会通过底层驱动传递Enclave中；
Enclave中的数据对外部不可见，也禁止外界的访问（包括系统高权限的代码也不可访问）
处理完之后，返回结果，但过程数据仍然在Enclave中；
获得返回后，应用的untrusted部分按即定的过程继续执行。

安全执行环境（Secure Execution Environment)是宿主进程的一部分，这意味着：

该应用程序包含其自己的代码，数据和安全区域；
Enclave也包含自己的代码和数据。
SGX保护飞地代码和数据的机密性和完整性；
Enclave进入点是在编译时预定义的；
支持多线程（但实现起来并不容易）；
一个安全区可以访问其应用程序的内存，但不能相反

我们可以再看一下EDL的使用示例，这样可以了解应用开发的难易程度：

可以看到，EDL并不是要求用户掌握学习一门新的语言，它的代码仍然是类POSIX API，C/C++库构成的，它也可以快速的将已有的实现迁移到Enclave中。

小结SGX Enclave完全使用了CPU的隔离能力，不可操作外设、中断等。EDL定义片段属于普通App的一部分，因此多核、多线程都可以支持。EDL随时随地定义，部署非常灵活方便。但是EDL是定义在代码中的，通过版本的逆向工程，对于数据的处理逻辑，是有可能被窥探的。 (最安全的还是在硬件中保护)

2、ARM TrustZone

TrustZone是标准TEE实现的一种方案，GP的TEE架构和规范标准都是由ARM TrustZone 贡献。当我们讲TrustZone时，可以理解为是在讲GP TEE。则于标准规范，就导致了与SGX不一样的情况，TEE实现有大量的资料可以参考。以下是TEE应用实现的原理：

基础设施：与SGX不同的，TEE的功能，依赖于安全OS，首先要确保设备上已经部署了安全OS，并且要确保其是可信的；
设计应用，对于需要可信保护的处理过程，需要实现在单独的可应用中（TA）；APP以及TA需要分别开发，物理上他们是两个程序；APP执行到安全处理部分时，它通过TEE标准接口向TA发消息；调用需要进入内核态，通过驱动将消息送到TEE侧；TA收到消息后，来执行即定的数据处理逻辑。最后将结果返回到APP，但过程数据仍然在TEE侧。

TrustZone 利用的是CPU时间片切换来模拟了安全世界，这两个世界可以将它理解成一个CPU上处理的两个进程，它们通过上下文切换来将CPU的时间片占满以利用CPU。从安全角度，仅仅分时复用或拟化，是不足以确保安全的，因此ARM另外定义了安全框架，从硬件级别两个世界，包括Timer、TRNG、TZPC、MMU、Cache等相关设备，不同的芯片厂商会有自己的考虑，这个设备可能是双份的，或者是动态切换以达到隔离目的。同时，安全侧也需要有一个可信操作系统执行应用。从原理上，REE侧和TEE侧是对等的，因此并不会性能的差异。应用程序的开发，除了使用TEE定义的标准接口，依赖的都POSIX API，使用标准的开发语言。

在部署应用时，SGX只需要在代码中定义即可，在TrustZone中侧需要单独开发部署TA。一般设置厂商都会提供给应用开发者自行部署TA的方法，与SGX相比稍有一点不同，但并不是不可接受（个人观点），这也确实是SGX很明显的一个优势，于是乎，ARM后面有了Newmore这样一个概念。

但也正因为TA与APP是分离的，并且TEE侧是不可查看的，因此数据的处理过程很难以被窥探。（我倒是认为这样的解耦其实是有点，同时TA需要签名，安全的特性会进一步的得到保证。）

最后，还有一点，网上还有一种声音，认为SGX和TrustZone“没有什么用”，观点的理由是：

“且不说传统的攻击，如SQL注入、溢出攻击,使得攻击者可以直接控制非安全应用，进而通过定义的接口取得数据，即使没有这些漏洞，恶意软件通过其他途径入侵到了OS里面，它是不是可以远程注入一段代码到APP，然后调用接口获取数据？”

这里必须要反驳一下，之所有这个观点，是他没有理解SGX或TrustZone的真正的使用场景。正确的处理方式其实上面的过程描述中我们已经提到了：

“处理完之后，返回结果，但过程数据仍然在Enclave中”
“最后将结果返回到APP，但过程数据仍然在TEE侧”

一个有价值的安全应用，并不会支持将敏感数据通过接口调用返回到非安全侧。

应用的安全与否，无论是SGX还是TrustZone应用，确实很大程度上是依赖开发者的意识。SGX或者TrustZone，**它们的价值在于是隐匿敏感数据本身，以及尽可能的隐藏处理敏感数据的处理过程。**只有以这个导向，在应用开发时才能有意识地向这个方向去努力。

我们拿媒体数据举例，一看就会明白应该如何正确使用SGX或TrustZone---

高价值的媒体内容在网络传输时，它通常是被DRM加密保护的，只有凭证的订户才可以解密播放。盗版者本身可能就是个订户，在没有SGX、TrustZone等保护时，通过拷贝内存等手段就很容易实现盗版。但有这些技术后，加密的媒体流并不会在非安全侧解密，而是送往安全侧。注意，在SGX、TrustZone解完密之后的媒体，也并不会返回到安全侧，而是使用底层安全驱动，直接送往解码播放了，媒体数据直接在安全侧消费了。（这部分的解码是硬件实现的，将数据和秘钥直接放到硬件的槽位，硬件解密之后直接送到player显示。）

以上是从应用开发者角度来比较SGX与TrustZone的差异。但事实上，两者完全不是一个层面的东西，SGX更适合拿AMD的SEV来比较，因为这两种技术类似，都是基于所谓的realm技术（局部保护）来实现。ARM有最新的newmore方案，但目前还在验证的概念阶段，预计在2023年以后才可能产品化，这个世界变化太快，两年的时间实太是太久，暂不便讨论。