可信执行环境（Tee）入门综述

最新推荐文章于 2024-04-02 19:38:01 发布

粥粥粥少女的拧发条鸟

最新推荐文章于 2024-04-02 19:38:01 发布

阅读量704

点赞数

分类专栏： TEE 文章标签：安全网络 TEE

本文链接：https://blog.csdn.net/qq_41691212/article/details/133362005

版权

TEE 专栏收录该内容

25 篇文章 3 订阅

订阅专栏

SoK: Hardware-supported Trusted Execution Environments [ArXiv`22]

摘要

现代计算平台日益复杂，软件组件之间需要强大的隔离保护，这导致了可信执行环境（TEE）的采用率不断提高。尽管近年来出现了几种商业和学术TEE架构，但它们仍然很难进行比较和对比。更普遍地说，现有的TEE还没有经过全面的系统化，以了解TEE设计各个方面的可用设计方案及其相应的优缺点。

因此，在这项工作中，我们分析了现有TEE的设计，并系统化了TEE实现其安全目标的机制，即可验证启动、运行时隔离、可信IO和安全存储。更具体地说，我们分析了TEE解决方案背后的典型架构构建块、这些组件的设计备选方案以及它们所带来的权衡。我们专注于硬件辅助TEE，涵盖了学术界和行业的广泛TEE提案。我们的分析表明，尽管TEE在目标、使用模型和指令集架构方面各不相同，但在设计方面，它们都有许多共同的构建块。

引言

今天的计算平台在其架构、软件供应模型及其支持的应用程序类型方面是多样化的。它们包括用于云计算的大型服务器、用于移动网络的智能手机和智能家居设备。随着时间的推移，这些设备已经发展到存储和处理安全敏感数据，从而在医疗保健和金融行业等各个领域实现新的应用。因此，现代计算平台必须实现保护此类安全敏感数据免受未经授权的访问和修改的机制。

当今计算系统中的数据保密性和完整性解决方案不仅必须考虑网络上的攻击，还必须考虑源自同一平台上的软件和硬件组件（其子集）或具有物理访问权限的对手的攻击。这是因为这些系统通常承载多个相互不信任的软件组件。此类软件部署模型的示例包括来自共享同一云平台的不同租户的代码/数据，以及属于共享同一智能手机的用户和网络提供商的代码/资料。因此，如今的平台必须将敏感数据与潜在的共同存在的软件和硬件对手隔离开来。事实上，这一要求同样适用于涉及此类敏感数据的任何计算，更广泛地说，适用于任何安全关键计算。

针对保护敏感计算和数据免受共存攻击者攻击的问题，一种越来越流行的解决方案是可信执行环境（TEE）。虽然现有的TEE在其确切的安全目标方面往往各不相同，但它们中的大多数旨在提供（四个高级别安全保护的子集），即（i）可验证地启动敏感代码和数据的执行环境，以便远程实体能够确保其设置正确，（ii）运行时隔离，以保护敏感代码和数据的机密性和完整性，（iii）可信IO，以实现对外围设备和加速器的安全访问，最后，（iv）TEE数据的安全存储，这些数据必须持久存储，并在以后的时间点仅对授权实体可用。

如今，存在各种学术和商业TEE设计和解决方案。它们在底层安全假设、目标指令集架构和支持的使用模型方面各不相同（图1）。在这项工作中，我们分析了现有TEE的设计，并系统化了TEE的常见和独特设计决策。尽管许多TEE设计使用不同的名称和对其潜在机制的描述，但产生的机制往往非常相似。为了解释这些设计之间的相似性，我们将底层机制分组为机制类别，并强调特殊情况。

我们通过识别和分类大多数TEE考虑的常见对手，并根据他们在软件和硬件中控制的平台组件，来开始对TEE解决方案的研究。我们专注于硬件辅助的TEE，并介绍它们如何实现可验证的启动、运行时CPU和内存隔离、可信IO和安全存储。通过分析不同的TEE支持哪些功能，它们是如何实现的，以及它们考虑的攻击者，我们可以比较包括移动和云计算在内的各种不同用途的TEE。它还使我们将具有包容性，并涵盖绝大多数现有的学术和商业TEE。

我们研究的第一个TEE安全目标是可验证发射，即提供关于TEE初始状态正确性的证据。这通常是通过首先建立测量信任根（RTM）来实现的，然后利用它来测量TEE中代码/数据的状态，最后通过一个称为证明的过程使其可用于验证。长期以来，可信计算集团使用可信平台模块（TPM）建立了标准的测量和证明过程[1]。在很大程度上，今天的证明解决方案涉及类似的机制和协议，但随着时间的推移，已经发展到依赖于不同的体系结构组件。例如，在一些TEE中，证明密钥和测量值保存在芯片上组件[2]-[4]中，但其他TEE依赖于芯片外TPM[5]、[6]。现代证明协议中涉及的密钥层次结构也不同于基于TPM的标准协议，并且在某些情况下，出于性能原因，涉及用于平台内证明的对称密钥。

然后，我们将重点讨论TEE如何实现运行时隔离，以保护敏感计算和数据的机密性和完整性。我们介绍了隔离策略的分类法，该分类法根据两个维度对它们进行分类：资源分区和隔离强制。然后，我们使用这些尺寸来解释各个TEE设计所使用的技术。由于每种策略对每种资源都有独特的优势，我们讨论了它们在隔离CPU和内存以对抗不同对手方面的适用性。然后，我们通过描述不同的TEE解决方案用于CPU和内存隔离的各种体系结构组件，总结了它们是否以及如何采用这些策略。我们发现，尽管存在多样性，但大多数现代TEE设计都使用单一的通用策略来保护CPU。相比之下，记忆保护的策略是多样的，一些TEE针对不同的对手采用不同的策略。

随着时间的推移，用于TEE的可信IO解决方案已经从支持用户IO发展到更多样化的加速器。大多数可信IO解决方案涉及两个主要组件：设备的可信路径和与CPU一样保护安全敏感数据的可信设备架构。我们确定了TEE可以实现的两种常见类型的可信路径，即逻辑路径和加密路径。然后，我们描述了实现这些可信路径的不同方法，它们在不同场景中的适用性，以及它们在每种情况下所需的体系结构支持。最后，我们应用与在CPU和内存隔离上下文中使用的隔离策略相同的分类法来理解不同的可信设备架构。

TEE环境中的安全存储涉及确保任何持久的敏感数据仅对授权实体可用。这个概念通常被称为密封。与测量和证明解决方案类似，TEE的早期密封机制通常依赖于TPM开创的概念[1]。我们观察到，随着时间的推移，密封工艺已经适应了新的要求（例如，迁移、防回滚），并且只依赖于片上元件。我们的研究揭示了只有大约三分之一的现有TEE解决方案讨论了使用类似实现方法的密封支持。

贡献

本文描述了一个包括软件和物理攻击者的对手模型及其能力。我们相信，在TEE的设计过程中，在不同的安全机制之间进行选择以及分析其安全性方面，这种对手分类法都是有用的。这源于这样一个事实，即TEE解决方案中安全机制的选择往往不仅因受保护的资源而异，还因被挫败的对手类型而异。

据我们所知，这是第一次对TEE做出的设计决策进行识别和分类，以实现四个基本的安全目标，即可验证的启动、运行时隔离、可信的IO和安全存储。我们相信，这种系统化可以作为基于不同设计约束和安全模型设计新TEE架构的基础。

基于调查的TEE架构，我们得出结论，四个基本安全目标的设计空间相对较小。新的方案通常会重复使用许多设计选择，并且只对单个组件进行微小的修改。

范围

近年来，已经提出了许多新的TEE架构。奇怪的是，尽管对TEE进行了大量研究，商业上可获得的TEE解决方案也越来越多，但TEE并没有一个单一的、被广泛接受的定义。在本文中，我们并不试图找到TEE的一般定义。相反，我们调查了各种各样的现有方法，并根据它们对四种常见安全属性的体系结构支持将其系统化：（i）可验证的启动，（ii）运行时隔离，（iii）可信IO，以及（iv）安全存储。鉴于现有TEE设计的所有差异，我们旨在找到将所有这些看似不同的方法联系起来的潜在设计决策。由于TEE的性能主要由处理器设计决定，而不是由TEE的具体情况决定，因此我们不调查所调查的TEE之间的性能差异。

调查设计的选择对本文至关重要，它基于以下标准：

我们专注于硬件辅助的TEE，而不研究可以说更复杂的软件方法，例如，依赖可信管理程序。

我们考虑来自许多不同处理器体系结构的TEE。我们选择了涵盖四种主要处理器架构的设计：x86、ARM、POWER和RISC-V。同时，我们还分析了基于更小众的指令集架构（如SPARC和OpenRISC）的建议。

虽然有些提案有时不被视为TEE（例如ARM TrustZone），但我们仍试图将其包括在内即使建议书本身没有使用“TEE”一词，也可以将尽可能多的设计放入TEE的信封中。

我们故意排除基于协同处理器的提案，如Google Titan和Apple的Secure Enclaves，或基于硬件安全模块（HSM）的提案。我们希望关注在通用处理器上运行的方法，这些方法与运行在同一处理器上的其他不受信任的应用程序紧密交织在一起。

术语：在学术文献和行业中，TEE的各个组成部分都使用了许多名称。例如，Intel Software Guard Extensions（SGX）将TEE实例称为飞地[7]，Trust Domain Extensions（TDX）使用Trust Domains[8]，AMD Secure Encrypted VMs Secure Nested Paging（SEV-SNP）[3]使用Secure Encrypted VM，ARM Confidential Compute Architecture（CCA）将Realms用于其VM隔离解决方案，将trustlets用于其应用程序隔离功能[9]。在本文中，我们使用飞地来指代这样的TEE实例，并使用可信计算库（TCB）来描述所有底层的可信组件。我们使用TEE来指代能够创建飞地的整个体系结构。

系统和威胁模型

本节讨论了大多数TEE设计的通用平台及其考虑的对手类型。

系统模型

大多数TEE解决方案针对的是现代通用计算平台，该平台由带片外存储器的片上系统（SoC）和可选的片外外围设备组成，如图2所示。

SoC本身包含一个或多个内核，这些内核可能共享高速缓存（或其一部分）和将它们连接到存储器控制器的结构。SoC还包括一个IO复合体，用于将片上和片外外围设备连接到SoC结构和缓存。系统的典型软件堆栈包括操作系统（OS）和多个用户空间应用程序。如果虚拟化，系统管理程序将在一个或多个虚拟机（VM）下运行，每个虚拟机都有自己的（来宾）操作系统和用户空间应用程序。这些软件组件在大多数现代CPU上以不同的权限级别运行（见图3）。用于实现TEE安全保护的硬件和软件组件称为可信计算库（TCB）。

威胁模型

TEE旨在提供各种安全保护，以对抗共同驻留在同一平台上的各种对手。这些包括不可信的共同驻留软件（例如，其他飞地中的代码、诸如OS的系统管理软件）、不可信的平台硬件（例如，IO外围设备）、能够物理访问平台的硬件攻击者（例如，总线插入器）或其组合。我们讨论了这些对手以及他们可以针对受害者飞地发动的攻击类型（见图2）。

共存飞地对手

当平台同时或随着时间的推移支持多个飞地时，该对手是相关的。这个对手能够用自己选择的代码/数据发射一个或多个飞地。例如，这种情况通常出现在多租户云平台中，多个用户可以在共享硬件上启动飞地。它也发生在移动生态系统中，其中多个服务提供商提供代码（和数据）以在飞地内运行。为了简洁起见，我们使用Atee来指代这样的攻击者以及它控制的任何代码/资源。

无特权软件对手

该对手可以在与受害者飞地相同的共享硬件上启动任何无特权软件。这样的攻击者通常可以以与受害者的飞地相同的权限级别运行代码，但不能更高。此类对手的例子包括在与受害者飞地一起运行的云环境中控制访客虚拟机的云用户，以及可以启动与手机飞地同时运行的应用程序的手机用户。我们用Aapp来指代这样的攻击者。

系统软件对手

这是指控制系统管理软件的对手，例如管理平台资源的操作系统。这个对手拥有Atee和Aapp的所有能力。此外，它还控制系统资源，如内存和调度。因此，它比上述对手更强大。这种对手的例子包括云设置中的不受信任的管理程序和在手机上运行的操作系统。这个对手被称为Assw。

启动对手

指的是控制TEE所在平台系统启动的对手。这种攻击者控制系统配置，如内存和IO结构参数，如果配置错误，可能会破坏整个TEE设计。此类攻击者的示例包括不受信任的BIOS。这个对手被称为Aboot。

外围对手

现代平台可能包括多个不在受害者飞地TCB中的外围设备。这些外围设备可以在SoC内，也可以通过外部总线连接到SoC。它们通常被认为是不可信的，尤其是如果它们包含可能被远程利用的固件。控制这种外围设备的对手可以发起邪恶的IO事务，试图访问或修改属于受害者飞地的内存和其他资源。我们用Aper来表示这样的攻击者。

结构对手

TEE架构考虑的另一个对手有能力引入特殊硬件，如结构插入器，以发起中间人攻击[10]。结构对手还可以直接访问静止的数据，如磁盘或外部存储器。然而，这个对手不能破坏SoC包：包中的所有内容都不在范围内。在论文的其余部分，我们使用Abus来代表这个对手。

侵入性对手

该对手可以发起侵入性攻击，如对物理芯片进行分层、操纵时钟信号和电压轨导致故障等，以提取机密或强制使用与预期不同的执行路径。为了完整起见，我们将这个对手包括在内（Ainv），但请注意，目前没有TEE设计可以抵御此类攻击者。因此，我们在本文中不再进一步讨论这个攻击者。

关于侧信道攻击的一点注记

已经探索了许多物理[11]、[12]和微体系结构[13]-[15]侧信道攻击，并证明在TEE[14]和更广泛[13]的背景下，这些攻击在现代系统上是可行的。上述任何一个对手都可以发动这种攻击，并取得不同的成功。考虑到侧信道通常是共享计算资源的结果，而不是飞地特有的，TEE通常依靠通用对策来减轻其影响。例如，通用软件防御方法，如消除秘密相关内存访问[16]或秘密相关分支[17]，同样适用于飞地。如今，大多数（商业）TEE提案都明确将侧信道攻击排除在攻击者模型之外，并建议使用现有的对策来抵御它们。尽管侧通道攻击不是本文的重点，但我们仍将在适当的情况下简要提及特定设计决策对侧通道的影响。

VERIFIABLE LAUNCH

在实际执行飞地之前的关键第一步是一个安全的设置过程，确保飞地的执行环境配置正确，并且其初始状态符合预期。TEE中流行的可验证引导过程是飞地测量和证明。直观地说，飞地的测量，以及更普遍的任何软件，是其初始状态的指纹，通常由飞地的初始存储器上的一系列一个或多个密码散列构建。测量过程本身必须值得信赖；它从测量信任根（RTM）开始，通过飞地的TCB实现为信任链，TCB最终测量飞地本身。这些测量值稍后作为数字签名报告的一部分使用，该报告通过称为证明的过程发送给验证者。证明可以提供关于飞地的安全属性的附加信息（例如，托管飞地的平台的真实性，关于其TCB本身的详细信息）。本节讨论了对不同类型RTM的体系结构支持、典型的测量过程以及TEE的认证方案。

信任根（RTM）

可验证启动过程的核心是RTM，它是测量过程的信任锚。目前，TEE使用三种类型的RTM之一，即静态（SRTM）、动态（DRTM）和基于硬件（HW），如表I所示。
在这里插入图片描述
SRTM是由一个完整的信任链创建的，从在系统重置时首先执行的代码模块到在飞地中运行的代码。该信任链通常只包括飞地TCB的所有软件组件，如图4所示。

链通常不包括操作系统。这样的解决方案可以在任何不受信任的组件（Atee、Aapp、Assw和Aper）处于活动状态之前引导系统TCB的运行时组件。对于考虑Abus的解决方案，这种自举必须确保在此过程中不需要芯片外组件（例如，平台TPM）。典型的SRTM可以完全用硬件或BootROM中的不可变软件来实现。

相反，使用DRTM的解决方案可以建立一个新的RTM，而无需信任自系统重置以来在其之前执行的代码（见图4b）。因此，这些解决方案必须实现架构扩展，以保护引导过程免受在飞地发射[5]、[6]、[18]时可能活跃的对手（Atee、Aapp、Assw和Aper）的攻击。这可以通过专门的硬件指令来完成，这些指令首先挂起所有其他活动进程（因此，Atee、Aapp、Assw），并禁用所有IO设备和中断（因此，Aper）。然后，硬件加载、测量和验证作为实际飞地的TCB的签名代码模块。一旦硬件验证了签名代码模块并可能记录了其测量值，它就会执行模块，该模块反过来加载并测量包围区本身。

大多数接受调查的TEE使用SRTM（表一）。只有两家商业处理器制造商（英特尔和AMD）的少数系统使用DRTM。我们推测DRTM的主要动机——将引导代码从TCB中排除——仅适用于具有大量遗留引导代码的平台（例如，x86 BIOS[19]）。

测量

在SRTM和DRTM解决方案中，从RTM开始，直到飞地的信任链中的每个实体都会在将执行控制权转移到下一个组件之前对其进行测量。实际上，在执行之前，不仅会对此类信任链中所有组件进行测量，还会对其完整性进行检查（例如，通过验证签名、对照参考值检查测量值）。我们注意到，所有接受调查的TEE都使用非常相似的测量技术，我们没有发现重大差异。我们请读者参考附录A1，以进一步讨论典型测量机制的实施细节。

认证的体系结构支持

验证是可验证启动的第三步，也是最后一步，验证器检查飞地是否已正确启动，以及其初始状态是否如预期。更具体地说，验证器确保飞地的测量值及其底层TCB与它们的预期参考值相匹配。认证有两种类型：本地认证和远程认证。当验证器与飞地位于同一平台上时，本地证明适用。相反，远程证明是由与被证明的飞地不在同一平台上的远程验证器使用的。远程证明方案通常依赖于非对称加密，并且经常产生检查一个或多个证书链的成本。这可能很昂贵，尤其是在硬件中实现时。相比之下，本地证明通常使用对称密码学来实现，并且往往更高效。大多数现有的TEE解决方案都支持远程认证（表I），但只有少数解决方案同时指定了本地和远程认证，如表I所示。请注意，一些TEE的远程认证可以很容易地重复用于本地认证。

在飞地中提供机密

在飞地中提供机密通常是其启动过程中的最后一个可选步骤。一些TEE，如IBM PEF[22]、AMD SEV-SNP[3]、PodArch[24]和Wen-cf13[29]，允许在认证之前为飞地提供秘密数据。在这种情况下，飞地的初始状态将包含一些秘密值，这些值也反映在测量中。这是通过飞地供应机制实现的，在该机制中，开发人员在将飞地二进制文件交付给平台之前对秘密数据进行加密。

在提供任何秘密数据之前，其他TEE设计需要证明。为了建立绑定到证明报告的通信信道，这些TEE中的包围区可以将一些自定义数据（例如，公钥证书）附加到证明报告[2]、[3]、[46]。由于这些额外的数据在证明过程中也经过了身份验证，因此其完整性得到了保护，可以用来构建整个安全通道基于所选择的密钥交换协议。我们注意到，AMD SEV[3]支持初始秘密供应和建立绑定到证明的安全通道。

运行时隔离

在设置飞地之后，它开始执行。为了防止攻击者干扰飞地的执行，必须保护属于飞地的所有资源，包括其CPU和内存，防止未经授权的访问和篡改。这种保护机制通常被称为运行时隔离。下面，我们首先描述隔离策略的广泛分类。然后，我们讨论是否以及如何将它们应用于CPU和内存隔离。最后，我们调查了现有TEE设计用于保护CPU和内存的一组策略。

隔离策略的分类

通常，隔离机制旨在实现受保护资源的机密性和完整性，并且可以根据资源的划分方式和隔离的实施方式进行广泛分类。我们在下面描述了这两个维度，并在图5和图6中进行了描述。

划分资源：资源可以在空间、时间或它们的混合中被隔离（图5）。请注意，这不是一个分类，而是一个从完全时间到完全空间的平滑范围。正如我们稍后将讨论的那样，这些完全时间或空间的极端情况很少出现。相反，大多数隔离机制都有一些时间和空间方面，即它们是时空的。

时间分区在时域中分割资源，即，随着时间的推移，它在多个执行上下文中安全地多路复用同一资源。在任何时间点，单个执行上下文都可以独占访问资源。临时分区需要安全地切换上下文的机制，同时将资源重新分配给新的执行上下文。这样的安全上下文切换应该是快速的，不会影响一般的系统性能。时间隔离通常用于空间分区成本高昂的资源，以及不需要从多个执行上下文并行访问同一资源的情况。

在空间分区中，资源是分开的，这样受信任和不受信任的上下文使用单独的专用分区。当同一资源（例如，逻辑处理器）有多个相同的副本时，或者当资源可以拆分为更小的相同副本时，可以使用它。请注意，如果需要，可以为给定的执行上下文分配资源的多个实例（例如，多个逻辑处理器）。因此，空间隔离技术通常用于复制或拆分相对便宜的资源。它还需要实施机制，以确保不同实体可以同时使用资源的不同副本，而不会对它们产生任何干扰。

时空分区利用时间和空间两个方面来对资源进行分区，例如，资源可以在空间上进行分区，但这些分区可能会随着时间的推移而改变。这个概念只能用于同时支持时间和空间划分的资源中。然而，它可能提供更多的灵活性和一些性能优势，因此是一个非常受欢迎的选择。

强制：与资源分区不同，隔离策略的强制可以分为两类：逻辑隔离和加密隔离。这两种策略的概述如图6所示。

逻辑隔离利用逻辑访问控制机制来强制隔离。这些机制禁止对手访问受保护的数据。例如，可信上下文切换例程使用逻辑隔离来确保下一个执行线程无法通过保存和清除处理器寄存器来访问任何受保护的数据。另一方面，许多逻辑隔离机制拦截数据访问，并根据一些访问控制信息检查请求。此访问控制信息必须由系统中的受信任实体生成和管理，并且可以在运行时对其进行修改，以实现灵活的资源重新分配。维护访问控制信息所需的资源（例如，存储器）根据访问控制信息的粒度和所管理的资源的类型而变化。此外，必须保护访问控制信息本身免受攻击。

顾名思义，加密隔离使用密码学来实现隔离。保密性通常通过加密实现；只有访问正确的密码密钥材料的授权上下文才能正确地解密数据。与根本无法访问受保护数据的逻辑隔离相反，未经授权的上下文可能会读取密文，但他们无法检索明文。完整性在一定程度上是通过与数据一起存储的加密消息验证码（MAC）来实现的。这可以防止未经授权的上下文篡改不属于它的数据，因为如果不访问正确的密钥，它就无法为给定的数据生成正确的MAC。通过加密隔离实现完全完整性需要使用防重放方案，以防止在以后的时间点重新注入旧数据（使用正确的、相应的MAC）。

下面，我们将讨论上述隔离策略在CPU和内存中的应用以及由此产生的权衡。

CPU隔离

虽然典型的CPU有许多组件，但下面的讨论集中在CPU内的体系结构状态，如寄存器状态。这主要是因为许多关于微体系结构CPU状态的细节（例如，中间CPU缓冲区、调度器）对于商业TEE解决方案是不公开的。即使是学术TEE解决方案也经常忽略这些细节。然而，TEE实现对CPU中与内存相关的微体系结构（例如，缓存、TLB）的影响是可用的，并在第V-C节中进行了分析。

CPU隔离策略的选择：虽然所有隔离策略都适用于CPU内的体系结构状态，但大多数隔离策略都有相当大的缺点，例如，在空间上为飞地专门保留一个（虚拟）核心会导致次优的资源利用率，并限制并发飞地的数量。类似地，时空方法在处理器的性能关键部分需要额外的硬件来保护空间分离的数据。因此，这些技术不太适合于CPU隔离。相比之下，时间分区非常适合CPU隔离，因为它不在受信任的上下文切换旁边添加额外的运行时检查。

在实施方面，由于处理器的快速路径上有额外的加密硬件，加密实施面临着巨大的性能开销。另一方面，除了需要在时间上分离同一CPU线程上的多个执行上下文的快速且安全的上下文切换例程之外，与逻辑强制相结合的时间分区没有表现出这样的开销。

根据我们的分析，我们研究的所有现有TEE解决方案都使用了时间分区和CPU状态的逻辑强制。我们的结果列于表二。
在这里插入图片描述
对CPU隔离的体系结构支持：如前所述，具有逻辑强制的临时分区通常通过保存、清除和恢复执行上下文的安全上下文切换例程来实现。上下文切换例程必须确保飞地中的数据不会泄漏到任何不受信任的上下文或执行计划中跟随它的另一个飞地。此外，当飞地被启动或恢复时，不受信任的上下文不能篡改或更一般地控制飞地的CPU执行状态。虽然有多种选项可以保存和恢复执行上下文，例如在飞地出口加密寄存器，但大多数TEE都会将上下文保存到飞地的专用内存中，然后清除寄存器值。为了实现这一点，TEE依靠其TCB在启动飞地之前正确设置CPU状态，并在退出飞地时清理CPU状态。

为了确保TCB能够完全调解每个上下文切换，TEE利用多种CPU模式、权限级别，在某些情况下，还利用它们的组合。这确保了所有进入和离开包围区的转换都是从TCB控制模式/特权级别进行的。TEE设计所使用的实际解决方案通常取决于底层处理器的指令集架构。英特尔、AMD、ARM和IBM的商用处理器经常添加新的执行模式来支持TEE（见图7）。

相比之下，大多数学术TEE没有引入任何新的处理器模式或特权级别。相反，它们依赖于在现有的高特权级别（PL0）中运行的固件来进行安全上下文切换。有一些建议认为，硬件本身有助于上下文切换过程中的时间隔离[27]–[29]，[38]，[39]，[44]，[45]。

除了上下文切换之外，CPU模式和权限级别通常是安全运行飞地及其软件TCB组件（如果有的话）所必需的，如表II所示。虽然包围区代码通常包括应用程序或虚拟机并以较低的特权运行（PL2、PL3），但在大多数TEE设计（PL0、PL1）中，TCB倾向于以较高的特权运行。这允许TCB实现许多其他类型的安全机制，如第四节中讨论的测量和证明，以及本文其余部分中讨论的内存隔离、可信IO和安全存储。

内存隔离

确保飞地使用的内存在运行时受到保护，防止未经授权的访问和修改，是TEE设计的一个特别具有挑战性的方面。这种保护不仅必须覆盖实际的片外存储器，还必须覆盖片上微体系结构（如指令和数据缓存）中的任何代码/数据。此外，由于大多数TEE支持虚拟存储器，所以诸如将虚拟地址转换为物理地址的页表之类的转换结构的可信度（或缺乏可信度）是所有存储器隔离解决方案的关键设计方面。与处理器缓存类似，保存最近页面翻译的翻译后备缓冲区（TLB）也必须受到保护，防止误用和错误配置。

内存隔离策略的选择：之前讨论的所有隔离策略都可以应用于内存，我们将在下面讨论这些策略的含义。虽然所有TEE设计都使用时间分区进行CPU隔离，但它们的内存隔离策略是多样的。事实上，许多TEE设计根据所考虑的攻击者类型使用不同的策略，如图8所示。
内存的全空间分区意味着保留一个或多个内存区域供飞地或TCB独占使用，并且这些区域一直分配给它，直到下一次系统重新启动。当系统必须支持的包围区的数量小时，空间划分工作良好，并且它们的存储器资源需求是相当静态的并且是预先已知的。它还适用于保护用于逻辑隔离的访问控制信息的粗粒度内存保护（如下所述）。

完全临时内存分区包括只允许从当前活动的执行上下文访问内存，并在上下文切换。它用于内存隔离的用途仅限于在任何时间点只有单个执行上下文处于活动状态的情况。因此，对于支持并发飞地的TEE来说，这是无效的。此外，将内存内容保存到磁盘可能需要相当长的时间。因此，很少使用时间内存分区。

由于其灵活性，时空内存分区是首选风格：随着时间的推移，内存区域可以重新分配给不同的执行上下文。因此，它在无法提前预测包围区的内存需求的系统中很有用。

逻辑强制依赖于访问控制机制，只允许对飞地资源的授权访问。逻辑隔离要求每个访问都要对照访问控制信息进行检查，例如由存储器管理单元（MMU）进行检查。此外，实现针对软件对手的完整性保护是相当有效的，每个飞地只有少量的访问控制信息。

加密强制通过加密实现机密性。它通过为每个可配置大小的内存块维护加密MAC来确保完整性。防止重放攻击是通过保持新鲜度信息（例如计数器）来实现的，通常以Merkle树的形式[45]，[47]。与上述所有隔离策略相反，加密内存隔离可以防止Abus。然而，加密隔离很难扩展，特别是如果不同的执行上下文需要单独的密钥，因为它需要在SoC内的芯片上维护大量的加密密钥材料。此外，使用密码隔离实现完整性和反重放特性会导致存储开销（例如，MAC和反重放元数据）以及延迟和吞吐量开销[47]。

在调查的TEE中，我们发现了各种各样的此类策略。虽然通常有一个首选的设计选择（如图8中的Rest或all所示），但也存在其他选择，而且似乎是实用的。我们强调，许多TEE同时使用多种策略，例如，Intel SGX[7]使用时空分区和逻辑强制来保护飞地内存，但它使用纯空间分区来保护其TCB，并使用加密隔离来应对Abus。

内存隔离的体系结构支持：访问控制检查促进了空间或时空内存隔离的逻辑实施。所有接受调查的TEE都使用两个选项之一进行访问控制检查：内存保护单元（MPU）或内存管理单元（MMU）。

我们请读者参阅附录B，了解这两个选项的实施细节。MPU和基于MMU的强制之间的主要区别之一是，前者在物理地址上操作，后者在虚拟地址上操作。此外，MPU通常只支持有限数量的规则，而MMU更灵活。我们注意到，利用MMU的TEE通常更复杂，并且通常带有深入的安全分析。另一方面，MPU相当简单，因此可以简化安全性分析。许多现代学术TEE依赖MPU来提供隔离[4]、[31]、[34]、[35]、[37]。另一方面，许多商业TEE似乎欣赏MMU[3]、[7]、[9]、[22]增加的灵活性。

我们注意到，用于强制内存隔离的访问控制信息，即MMU的受信任页表、MPU的访问控制规则或其他辅助元数据，本身必须受到保护，以防止未经授权的访问。这通常是通过空间分区来完成的，即，在启动时分配用于此类结构的内存，并通过简化的MPU（例如，范围寄存器）进行保护。

缓存：缓存包含最近使用的内存部分，以提高软件性能。通常，CPU包含多个缓存层，其中一些是核心专有的，另一些是共享的。在一些TEE体系结构中，CPU中的MPU/MMU及其IO对应物防止不受信任的实体访问缓存中的飞地数据（例如，Intel SGX）。在现有机制无法阻止此类访问的其他TEE中，额外的缓存保护机制隔离缓存中的包围区数据（例如，Arm TrustZone）。缓存隔离策略概述如图9所示。

空间缓存分区，即保留缓存的一部分供飞地独占使用，不能很好地扩展，降低了资源利用率，并可能导致潜在的性能下降。然而，它可以用于减轻侧信道攻击[4]，[35]-[37]，[48]。世俗的缓存分区不是很有效，因为它需要在执行上下文之间的每次转换时刷新整个缓存。因此，它仅被少数TEE设计用于防止侧信道泄漏，并且仅限于单个核心专用的小型缓存[4]、[31]、[35]。加密强制不适用于像缓存这样的微体系结构，因为额外的加密硬件及其有限的延迟和吞吐量会带来成本。因此，如今TEE解决方案中的大多数缓存都实现了时空和逻辑缓存隔离。

可信的IO

虽然早期的TEE设计只关注CPU，但最近对与外部设备的安全交互的兴趣激发了可信IO的多种方法[37]，[49]-[51]。可信IO有两个组成部分：（i）飞地访问设备的机密性和完整性，即建立可信路径，以及（ii）通过可信设备架构保护设备上的飞地数据。我们将在下面讨论这些组件的现有解决方案。

建立受信任的路径

最初，术语“可信路径”用于为用户启用可信IO交互[52]。然而，如今，随着IO设备的多样性不断增加，以及使其能够与TEE一起使用的趋势，可信路径也被用来指代飞地和设备之间的（安全）通信信道。

逻辑和加密隔离技术都可以用于建立可信路径。如果受信任路径有多个跃点，则每个跃点可以实现不同类型的隔离。虽然逻辑和加密可信路径都可以抵御Atee、Aapp、Assw、Aboota和Aper，但只有加密可信路径可以抵御Abus。下面，我们将讨论实现逻辑和加密可信路径的不同方法。

对逻辑可信路径的体系结构支持：逻辑可信路径需要体系结构支持才能实现两种类型的IO交互：直接内存访问（DMA）和内存映射IO（MMIO）。在本讨论中，我们将重点讨论MMIO，并请读者参阅第V-C节，以了解DMA隔离机制的详细分析。

为MMIO构建逻辑可信路径的一种方法是通过访问控制过滤器，该过滤器基于MMIO请求的来源或目的地允许/拒绝访问。这样的过滤器可以是静态的，也可以在运行时由可信实体进行编程。许多系统依赖ARM的TrustZone Protection Controller来过滤对外围设备的访问[49]、[50]、[53]、[54]。CURE[37]、TrustOTP[55]和HectorV[51]依赖于在每个外围设备前面的类似但更复杂的过滤器来允许/禁止访问。构建逻辑可信路径的另一种选择是通过安全MPU配置（例如，TrustLite[42]）或相关元数据结构（例如，HIX[56]）的可信内存映射，每当飞地试图访问设备时都会对其进行检查。

加密可信路径的体系结构支持：端到端加密可信路径依赖于在两个端点（飞地和设备）之间建立的安全通道。这种方法产生了与加密操作和硬件相关的开销。要建立安全通道，必须为设备和飞地提供凭据和加密密钥，以用于身份验证和认证（可选）。使用加密可信路径的解决方案示例包括Fidelius[57]和HIX[56]。有时，加密信道可以是多跳的，即，包括飞地和设备之间的可信中间硬件组件（例如，Bastion SGX[58]、ProtectIOn[59]和HETEE[60]）。链路级别（与高软件级别相反）的加密可信路径正在出现，专门针对Abus进行保护[61]。

某些可信路径解决方案结合了加密和逻辑可信路径。例如SGXIO[62]使用CPU包和设备之间的加密路径，但是使用具有对设备的独占访问的CPU包上的可信中介来隔离来自不同包围区的访问。还可以分别为DMA和MMIO使用不同类型的可信路径；HIX[56]为MMIO使用逻辑可信路径，为DMA使用加密可信路径。

受信任的设备体系结构

对于某些类型的可信IO使用，建立从飞地到设备的可信路径就足够了。示例包括不处理明文用户数据的外围设备（例如，加密存储设备、网卡）。然而，诸如加速器之类的新兴设备被用于对用户数据进行计算。这种加速器必须像CPU一样确保每个飞地数据的机密性和完整性。

如今，存在各种加速器：例如，用于人工智能处理的定制芯片、现场可编程逻辑阵列（FPGA）和通用图形处理单元（GPU）。这些系统在其底层架构方面差异很大，因此，它们必须实现的隔离飞地数据的确切机制也各不相同。单个加速器的这些机制的细节超出了本文的范围。然而，仍有一套基于第V-a节中讨论的策略的高级隔离技术适用于以下讨论的许多加速器。

空间分区：在平台的整个生命周期内，为每个飞地分配单独/专用的加速器实例通常既不节省资源，也不节省成本。因此，虽然在理论上是可行的，但空间隔离并不是很实用。然而，如果这样的专用实例是可用的，那么建立到设备的可信路径就足够了，并且不会产生额外的设备要求。

临时分区：直到最近，加速器都是在任何给定时间由单个执行上下文独占使用的情况下构建的。因此，时间划分，即随着时间的推移在多个上下文之间共享，是一种常见的方法。这种时间划分需要一种安全的上下文切换机制，该机制可以在软件中实现，也可以通过增强加速器硬件本身来实现。依赖于这种时间分区的示例解决方案包括用于通用一次性加速器的HETEE[60]、用于GPU的ZeroKernel[63]和HIX[56]，以及用于FPGA的MeetGo[64]和ShEF[65]。

时空分区和逻辑强制：由于其灵活性，通常在多个飞地需要同时访问加速器时使用。这种时空隔离需要设备架构的硬件支持，以实现真正的多租户。同样，确切的增强集是特定于设备的，但它们通常涉及维护访问控制信息以跟踪资源的所有权，即将资源映射到飞地。此类解决方案的例子包括Graviton[66]、Telekine[67]和SEGIVE[68]用于GPU，以及Trustore[69]用于FPGA。

加密强制：这不太适合保护片上加速器资源（例如，缓存、TLB），原因与保护片上CPU资源不理想的原因相同，即，由于所有加密硬件的性能开销和额外的区域成本。然而，加密强制可以专门应用于设备侧存储器资源，就像它们应用于CPU上的DRAM一样，如第五节所述。

安全存储器

在许多应用程序中，需要包围区来在不同的调用之间保持特定（持久）状态。通过加密以这种方式保护数据的过程称为密封，而解释飞地状态的反向（解密）过程称为解封。

虽然这种安全存储是一种非常常见的要求，但大多数现有的TEE设计都没有明确描述。一些TEE支持可用于安全存储的原语（例如，AMD SEV-SNP[3]），但没有描述完整的解决方案；因此，我们在此不再进一步讨论它们。因此，在本节的其余部分中，我们将重点介绍TEE，它们提供了对密封支持的完整描述：Flicker[5]、SEA[6]、IBM-PEF[22]、Intel SGX[20]、TIMBERV[34]、Keystone[35]和Sanctuary[31]。

密封解决方案和权衡

调查TEE中的所有密封方案与基于TPM的原始方案非常相似[1]。Flicker[5]、SEA[6]和IBM-PEF[22]直接依赖于TPM的原始密封机制。这通常包括生成一个非对称密钥对，并使用它来加密秘密，以便只有当系统配置与加密（密封）时的配置匹配时，才能成功解密（解封）。TPM密封和解封过程中使用的系统配置信息使用TPM平台配置寄存器（PCR）中记录的测量值。由于TPM的存储有限，保护大量数据的典型方法是生成用于批量数据加密的对称密钥，然后将该密钥密封到TPM。

存在许多不同形式的确定哪个飞地可以解封以前密封的数据：一些TEE只允许具有相同测量值的飞地在具有特定TCB版本的同一平台上解封数据[3]，[31]，[34]。其他提案允许同一开发商签署的所有飞地解封对方的数据[20]，[70]。一些云TEE还允许飞地附带迁移策略，将密封数据迁移到不同的主机[3]。

用于密封的结构支撑

OP-TEE[71]、Keystone[35]、TIMBERV[34]和Sanctuary[31]等解决方案通过其软件TCB提供密封支持。在这里，TCB公开了一个接口，为每个包围区创建密封密钥。在这些情况下，不需要额外的硬件或体系结构支持。因此，该技术可能适用于具有在软件中实现的运行时TCB组件的TEE设计。基于TPM的解决方案需要支持上述密封能力的平台TPM芯片。由于TPM通常是片外组件，并且通过未受保护的总线连接，因此此类解决方案对Abus不安全。像Intel SGX[7]、[20]这样的解决方案在硬件中公开了特殊的CPU指令，以实现密封。更具体地说，它们包括基于不同类型的绑定（例如，开发者身份、包围区测量）生成和访问密封密钥的指令。

最后，在所有情况下，体系结构必须确保只有TCB和所有者飞地可以访问密封密钥。这些保护可以通过第五节中描述的隔离机制来实施。

TCB讨论

本节总结了现有TEE设计的TCB组成。然而，很难将单独的设计选择归因于TCB的大小或复杂性。此外，尽管TCB大小的常见度量是代码行，但并非所有TCB组件都能获得准确的数字。因此，我们讨论TEE是否以完全不可变的方式实现其不同的体系结构组件，或者它们是否包含可变的元素。当一个组件是可变的时，它可以在制造后进行更改，从而在计算平台的使用寿命内进行更新，这对于避免昂贵的产品召回非常重要。TCB的这种更新（也称为TCB恢复[73]）通常反映在平台的证明报告中。可变组件通常在软件中实现，不可变组件在硬件中实现。我们注意到，在某些情况下，软件可以以不可变的方式实现（例如，Boot ROM），硬件组件可以是可变的（例如，某些CPU中的μ代码）。

表III总结了现有TEE设计中包含可变元素（标记为M）的组件。如果表中的条目标记为不可变（标记为I），则表示该元素在制造后无法更改或更新。我们使用U来表示实现的可变性不明确的情况。
在这里插入图片描述
可验证启动的TCB：所有支持RTM的TEE中的RTM都是不可变的。在大多数情况下，该RTM仅用于测量信任链中的第一个（或DRTM中的下一个）软件TCB组件，该组件直接或间接（通过链中稍后的组件）测量实际飞地。很少有设计，即HyperWall[39]、Iso-X[38]和Sancus[41]在硬件中执行整个飞地测量。所有其他TEE允许更新测量过程，例如，包括系统参数，例如启用超线程[3]、[74]。验证通常也由软件TCB的可变部分执行，与上述测量相同的例外情况除外。

运行时隔离的TCB：许多TEE使用软件TCB的可变部分来实现用于CPU隔离和管理内存隔离的安全上下文切换。在硬件中完全实现CPU和内存隔离的例外是PodArch[24]、Hypercave[25]、H-SVM[26]、Hyperwall[39]、Iso-X[38]、XOM[44]、Aegis[45]以及Xu等人[28]和Wen等人[29]的作品。在某些情况下，这种功能在可变组件和不可变组件之间的划分仍然不清楚[2]，[75]。

安全IO的TCB：大多数研究的TEE不支持可信IO。例外情况包括TrustICE[32]、CURE[37]和Trustlite[42]，它们都依赖可变软件TCB来实现可信IO。我们注意到，有几项建议侧重于启用可信IO，其中一些TEE不本机支持可信IO，如第六节所述。

安全存储的TCB：在我们研究的31个TEE提案中，有10个提案明确讨论了密封支持。其中一些，如Flicker[5]、SEA[6]和IBM PEF[22]，依赖TPM，而另一些，如Sanctuary[31]、Timber-V[34]、Keystone[35]和TrustLite[42]，则将此功能作为其软件TCB的一部分来实现。虽然Intel SGX提供了类似的功能[20]，但尚不清楚它是否或其中的哪一部分是可变的。

总体TCB大小：通常，大多数TEE设计和实现都试图最大限度地减少TEE架构的TCB，以降低其存在漏洞或易受攻击的风险，并在理论上使其更适合正式验证。然而，在实践中，很难忽视在必要时能够更新TCB组件的优势，而不是依赖于TCB没有bug。此外，如本文所示，许多TEE总体上使用类似的机制，无论它们是在可变组件还是不可变组件中实现的。考虑到这一点，以及现有实现在其支持的功能方面差异很大的事实，我们警告不要使用可变的TCB大小来比较TEE。为了完整性，我们在这里只包括了根据我们的调查获得的代码行来衡量的可变TCB复杂性。

总结

在本文中，我们分析了商业和学术TEE的基本设计选择，以实现四个高级安全目标：（i）可验证的启动、（ii）运行时隔离、（iii）安全IO和（iv）安全存储。尽管这些提案一开始看起来很不一样，但其中许多都有许多共同的设计决策，但使用了不同的名称和描述。我们相信，我们的发现可以帮助即将提出的TEE提案权衡不同的设计决策，并有望减少该领域的重新发明。

粥粥粥少女的拧发条鸟

关注

0
点赞
踩
7

收藏

觉得还不错? 一键收藏
打赏
0
评论
可信执行环境（Tee）入门综述

现代计算平台日益复杂，软件组件之间需要强大的隔离保护，这导致了可信执行环境（TEE）的采用率不断提高。尽管近年来出现了几种商业和学术TEE架构，但它们仍然很难进行比较和对比。更普遍地说，现有的TEE还没有经过全面的系统化，以了解TEE设计各个方面的可用设计方案及其相应的优缺点。因此，在这项工作中，我们分析了现有TEE的设计，并系统化了TEE实现其安全目标的机制，即可验证启动、运行时隔离、可信IO和安全存储。
复制链接

扫一扫