中国建设网官方网站企业,dedecms 网站还原,手机咋做网站,简单网站html模板下载地址SoK: Hardware-supported Trusted Execution Environments [ArXiv22] 摘要引言贡献 范围系统和威胁模型系统模型威胁模型共存飞地对手无特权软件对手系统软件对手启动对手外围对手结构对手侵入性对手 关于侧信道攻击的一点注记 VERIFIABLE LAUNCH信任根#xff08;RTM#xf… SoK: Hardware-supported Trusted Execution Environments [ArXiv22] 摘要引言贡献 范围系统和威胁模型系统模型威胁模型共存飞地对手无特权软件对手系统软件对手启动对手外围对手结构对手侵入性对手 关于侧信道攻击的一点注记 VERIFIABLE LAUNCH信任根RTM测量认证的体系结构支持在飞地中提供机密 运行时隔离隔离策略的分类CPU隔离内存隔离 可信的IO建立受信任的路径受信任的设备体系结构 安全存储器密封解决方案和权衡用于密封的结构支撑 TCB讨论相关工作总结 SoK: Hardware-supported Trusted Execution Environments [ArXiv22] 摘要
现代计算平台日益复杂软件组件之间需要强大的隔离保护这导致了可信执行环境TEE的采用率不断提高。尽管近年来出现了几种商业和学术TEE架构但它们仍然很难进行比较和对比。更普遍地说现有的TEE还没有经过全面的系统化以了解TEE设计各个方面的可用设计方案及其相应的优缺点。
因此在这项工作中我们分析了现有TEE的设计并系统化了TEE实现其安全目标的机制即可验证启动、运行时隔离、可信IO和安全存储。更具体地说我们分析了TEE解决方案背后的典型架构构建块、这些组件的设计备选方案以及它们所带来的权衡。我们专注于硬件辅助TEE涵盖了学术界和行业的广泛TEE提案。我们的分析表明尽管TEE在目标、使用模型和指令集架构方面各不相同但在设计方面它们都有许多共同的构建块。
引言
今天的计算平台在其架构、软件供应模型及其支持的应用程序类型方面是多样化的。它们包括用于云计算的大型服务器、用于移动网络的智能手机和智能家居设备。随着时间的推移这些设备已经发展到存储和处理安全敏感数据从而在医疗保健和金融行业等各个领域实现新的应用。因此现代计算平台必须实现保护此类安全敏感数据免受未经授权的访问和修改的机制。
当今计算系统中的数据保密性和完整性解决方案不仅必须考虑网络上的攻击还必须考虑源自同一平台上的软件和硬件组件其子集或具有物理访问权限的对手的攻击。这是因为这些系统通常承载多个相互不信任的软件组件。此类软件部署模型的示例包括来自共享同一云平台的不同租户的代码/数据以及属于共享同一智能手机的用户和网络提供商的代码/资料。因此如今的平台必须将敏感数据与潜在的共同存在的软件和硬件对手隔离开来。事实上这一要求同样适用于涉及此类敏感数据的任何计算更广泛地说适用于任何安全关键计算。
针对保护敏感计算和数据免受共存攻击者攻击的问题一种越来越流行的解决方案是可信执行环境TEE。虽然现有的TEE在其确切的安全目标方面往往各不相同但它们中的大多数旨在提供四个高级别安全保护的子集即i可验证地启动敏感代码和数据的执行环境以便远程实体能够确保其设置正确ii运行时隔离以保护敏感代码和数据的机密性和完整性iii可信IO以实现对外围设备和加速器的安全访问最后ivTEE数据的安全存储这些数据必须持久存储并在以后的时间点仅对授权实体可用。
如今存在各种学术和商业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 ExtensionsSGX将TEE实例称为飞地[7]Trust Domain ExtensionsTDX使用Trust Domains[8]AMD Secure Encrypted VMs Secure Nested PagingSEV-SNP[3]使用Secure Encrypted VMARM Confidential Compute ArchitectureCCA将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和内存映射IOMMIO。在本讨论中我们将重点讨论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的研究从它们提供的安全保护类型的角度对它们进行了比较我们总结如下。我们将以下讨论限制在TEE的调查文件中并排除各种由于后一组作品是本文的主题因此对单个TEE本身的论文。
Sabt等人是最早认识到2015年前后存在相互竞争的TEE定义的人之一因此他们试图得出正式的TEE的定义。随后使用该定义对来自工业界和学术界的基于ARM TrustZone的TEE进行了简要调查[76]。关于基于ARM TrustZone的TEE、它们在不同ARM处理器版本中的各种风格以及利用ARM TrustZone的软件解决方案的更详细讨论请参见[77]。进一步研究的重点是基于ARM TrustZone的安全限制[78]。所有这些工作的主要焦点是涉及ARM Trustzone的TEE架构、系统和攻击。我们注意到[77]简要介绍了其他一些非ARM TEE但只关注它们启用的安全属性而不是它们的体系结构细节。
也有类似的工作调查RISC-V生态系统中的安全机制和TEE。在[79]中作者调查了RISC-V处理器的硬件和体系结构安全性并将其与ARM处理器进行了对比。虽然本文在ARM和RISC-V架构之间进行了许多很好的比较例如异常级别以及在安全相关功能方面例如对密码学的支持、ISA扩展但它只提到Keystone架构[35]与ARM TrustZone相似但将任何进一步的讨论推迟到未来的工作中。最近[80]中总结了现有的RISC-V TEE体系结构但没有对不同处理器体系结构上的TEE进行比较。类似的限制适用于以前对英特尔SGX及其应用程序[81]以及安全限制[82]、[83]的研究。与这些关注ARM或RISC-V的调查相比本文涵盖了各种不同指令集架构的TEE并比较了支撑它们的不同微架构元素。
在所有主要处理器体系结构中TEE体系结构系统化的唯一努力是[84]。在这里作者从四个维度总结了TEE架构确保TEE初始内容完整性的机制、内存保护、范围例如每个系统、处理器包、核心或线程最后是开发人员访问。它讨论了不完整硬件抽象的安全含义这些抽象没有捕获TEE的实现方面例如操作的定时、缓存、并发最后还涵盖了TEE的不同应用。[84]中对TEE中运行时隔离机制的微体系结构支持的讨论仅限于内存保护例如不包括CPU状态保护或可信IO支持。此外关于内存保护的讨论也不是详尽无遗的也不像本文所涵盖的那样详细。
现有文献还包括对TEE体系结构例如[85]、[86]以及安全特性例如[87]、[88]的调查。尽管这些工作涵盖了多处理器体系结构中的TEE但没有一项工作像我们在本文中所做的那样系统地编目和分析这些TEE设计背后的各种体系结构设计决策并分析它们的优缺点。
总结
在本文中我们分析了商业和学术TEE的基本设计选择以实现四个高级安全目标i可验证的启动、ii运行时隔离、iii安全IO和iv安全存储。尽管这些提案一开始看起来很不一样但其中许多都有许多共同的设计决策但使用了不同的名称和描述。我们相信我们的发现可以帮助即将提出的TEE提案权衡不同的设计决策并有望减少该领域的重新发明。
