机密计算联盟 CCC

Confidential Computing Consortium (CCC).

机密计算的常用术语

PDF: Common Terminology for Confidential Computing

简介

随着越来越多的公司和开源项目开始使用类似的术语来描述基于硬件的、经过验证的可信执行环境 (TEE) 的类似范例，供应商使用一致的术语来描述这些新功能在不同功能域中的应用方式将变得越来越重要。

机密计算联盟已将机密计算定义为“通过在基于硬件的、经过验证的可信执行环境中执行计算来保护正在使用的数据”，并确定了可信执行环境的三个主要属性：数据完整性、数据机密性和代码完整性。如“机密计算：基于硬件的应用程序和数据可信执行”中所述，可能存在四个附加属性（代码机密性、可编程性、可恢复性和可验证性），但只有可验证性才是将计算环境归类为机密计算的严格必要条件。

本文将术语“机密”的其他应用定义为描述性前缀，例如“机密容器”、“机密虚拟机”等。此类术语已开始出现在营销材料和商业产品以及相关开源项目中。本文重点介绍机密计算和相关的“机密 xxx”术语，以提供描述将机密计算添加到计算机架构的影响时的通用词汇表。目标是充分描述隔离计算工作负载所引入的不同潜在架构变化，以便正确评估保护完整应用程序及其数据的影响。内存隔离是机密计算引入的新元素之一。能够保护正在运行的应用程序会显著改变计算机安全的方法。网络攻击通常始于对内存内容的破坏（提取数据或修改内存状态以启用执行）。因此，有效的内存隔离能力早已被认为是最佳的潜在缓解措施。但保护正在使用的数据只是应用程序安全性的一部分。需要一种综合解决方案，利用机密计算和静态和动态保护来全面保护敏感工作负载及其数据，无论它们流向何处。

例如，在云计算中，保护使用中的数据成为一项基本要求，以使客户能够在云供应商提供的基础设施上运行时控制保护应用程序及其数据。所有云都支持建立在一定信任程度上的共享责任模型。机密计算允许以更强的方式分离责任和隔离资源。

包装模型术语

本文档定义了以下术语：

  • 机密库：在基于硬件的、经过认证的 TEE 内执行的库（例如“enclave”），这样它就不会受到其他此类库和 TEE 中任何托管环境的影响，并且可以由 TEE 外部的应用程序使用。
  • 机密进程：在基于硬件的、经过认证的 TEE 内执行的进程（例如“受信任的应用程序”），这样它就不会受到其他机密进程和 TEE 中任何托管环境的影响。
  • 机密容器：由 OCI 容器运行时启动的符合开放容器计划 (OCI) 的容器映像的入口点进程，这样该进程在基于硬件的 TEE 内执行，并且不会受到其他机密容器和 TEE 中任何托管环境的影响。
  • 机密 VM：在基于硬件的、经过认证的 TEE 内执行的虚拟机，通过这种方式，整个 VM 映像内的代码和数据受到保护，不受虚拟机管理程序和主机操作系统以及其他机密 VM 和 TEE 中的任何托管环境的影响。

在上述定义中，托管环境可能包括在 TEE 内运行但在多个机密库、进程、容器或 VM 之间共享的部分。在这种情况下，使用术语“机密”意味着额外的隔离层，通过该隔离层，机密代码和数据即使在托管机密代码和数据的整体 TEE 实例内的共享环境中也受到保护。例如，可能使用嵌套隔离边界。

当代码的机密部分是较大包的一部分时，例如包含在整体 VM 映像内的机密库，我们使用介词“with”，如“带有机密库的 VM”，而不是“机密 VM”，后者要求整个 VM 映像在 TEE 内执行。

当代码的机密部分包含多个可以单独安装但它们之间没有安全隔离的包时，我们使用介词“in”，如“机密虚拟机中的进程”。

隔离方法

上述封装术语将由与 TEE 的硬件和固件协同运行的软件提供。这种组合将提供数据机密性、数据完整性和/或代码完整性保护的混合。数据机密性是在运行时通过隔离处理器（无论是 CPU 还是其他处理单元，如 GPU）内的特定 TEE 上下文（可能在 RAM 内）提供的。有多种方法可以提供使用中数据保护。限制 CPU 对 TEE 数据的可寻址性/可访问性的三种技术示例包括：

  • 访问控制验证：对内存区域的访问仅限于某些进程/上下文。
  • 地址转换：内存的分段区域根本无法从 TEE 边界之外直接寻址。
  • 分页控制：非 TEE 进程不会与 TEE 数据同时在 CPU 内活动。

当然，CPU 并不是唯一可以看到 TEE 数据的地方。此类数据通常也存储在 RAM 中。当在 RAM 中时，可能会尝试对 TEE 数据进行旁道攻击。可以通过加密 RAM 中的 TEE 数据等方式保护 RAM 免受此类攻击。

处理器供应商通常会捆绑多种隔离方法来保护其实现。提供机密计算功能的软件就是在这些捆绑包的基础上进行分层的。

但是，根据这些隔离方法，实际上集成和交付了哪些软件层？软件层的打包取决于代码是为软件开发人员、系统集成商还是系统管理员准备的。在系统管理员实际安装代码之前，很可能会出现许多嵌套的打包应用层。考虑到这一点，下面的栏目列出了九个示例，说明软件层如何实际打包以供软件供应链下游参与者使用。在这些示例中，仅突出显示了 NIST 800-12 Rev.1 定义的可信计算基 (TCB) 的软件元素。未显示 TCB 的其他元素（例如固件和硬件）。

如图所示，这九种实施方案中的每一个都可以映射到上述四个打包术语之一。红色框显示了在 TEE 内运行的组件集。黄色框显示了可能一起打包的示例。在另一个示例（未显示）中，红色框中的某些组件可能被单独打包。

此外，九列中的每一列都可由某些使用中数据隔离方法子集支持。这种打包分类对于机密计算的最终用户非常有用，因为它可以：

  • 表达应该作为打包产品一部分的软件元素。
  • 了解在特定封装产品中哪些信息是隔离的（或不是）。注意：这由红色虚线表示，该虚线描绘了在内存隔离部分运行的机密计算。
  • 了解隔离方法中的常见角色，例如“TEE shim”，它有助于加载 TEE，并将信息传递到受保护的内存和从受保护的内存传递信息。
  • 了解各种 CCC 项目如何通过常见的北向抽象来抽象内存隔离方法的差异。
  • 了解从 TEE 公开的封装 API 如何与其他软件交互。这包括 TEE 在建立机密性后通过安全通道加载其他代码/数据的能力。
  • 允许比较封装软件替代方案，每个替代方案可能基于不同的隔离方法。
  • 启用可扩展性，以便新兴处理器技术可以声明它们支持的封装模型（例如基于 RISC-V）。

各种 CCC 项目将提供针对此处描述的一种或多种包装模型的代码。示例可能包括：

  • Occlum 和/或 Gramine 可以帮助开发人员将现有应用程序打包为基于 Intel SGX 构建的“机密库”包。
  • Enarx 可以帮助开发人员编译单个应用程序包，该包可以透明地部署到多个部署类别中。相同的应用程序包可以在 SGX 等“机密库”或 SEVSNP 等“机密 VM”中运行，Enarx 提供抽象层以确保相同的运行时环境。
  • Open Enclave 可以让开发人员设计一个能够在 SGX（打包为“机密库”）和 TrustZone（打包为“机密进程”）上运行的库。

认证

无论工作负载如何打包，最终的部署都应支持交互，以证明其正在 TEE 实例中运行。

虽然在传统计算中，通常需要对服务器进行身份验证，但在机密计算中，目标是对 TEE 实例进行身份验证，而证明是实现这一目标的手段。最终的部署应提供一种机制，以允许验证其正在 TEE 实例中运行的断言。在机密计算中，证明是对 TCB 测量的硬件签名报告（“证明报告”）的验证。证明中提供的测量与上图所示的 TCB 边界有关。然后，进程隔离证明对应用程序进行身份验证，而 VM 隔离证明在概念上对 VM 和/或用于启动 VM 的虚拟固件进行身份验证。

证明结果可用于支持无状态通信，例如，此数据报或计算结果是由特定的 TEE 实例生成的；或有状态通信，例如，此 TLS 通道在特定 TEE 实例内终止。打包提供程序可能包括经过认证的协议（例如 RA-TLS），或提供对 TEE 堆栈中细粒度认证 API 的 API 访问。协议或 API 方法必须支持认证的最佳实践，包括新鲜度、证书卫生和 TCB 测量。

认证最佳实践的完整描述超出了本文档的范围。鼓励感兴趣的读者阅读 IETF RATS 工作组的工作内容，尤其是 RATS 架构。机密计算联盟还运行一个认证特别兴趣小组，该小组向公众开放，并提供丰富的记录和书面内容。

总结

机密计算是一种模式，它通过对现代处理器添加基本架构来实现，它有可能像将虚拟化添加到商用芯片中一样，对计算机的运行方式产生变革性的影响。通过创建保护使用中数据的能力，它为如何在现代系统中管理信任、隐私和安全提供了重要组成部分。为了增加这项技术的采用，必须有一个通用的词汇表来描述该技术的使用方式以及它可以带来哪些好处。

机密计算的技术分析

PDF: A Technical Analysis of Confidential Computing

简介

在传统计算中，数据有三种状态：传输中、静止和使用中。通过网络传输的数据是“传输中”，存储中的数据是“静止”，正在处理的数据是“使用中”。在我们不断存储、使用和共享敏感数据（从信用卡数据到医疗记录，从防火墙配置到我们的地理位置数据）的世界中，保护所有状态下的敏感数据比以往任何时候都更加重要。现在通常使用加密技术来提供数据机密性（阻止未经授权的查看）和数据完整性（防止或检测未经授权的更改）。虽然现在通常使用保护传输中和静止数据的技术，但第三种状态 - 保护使用中的数据 - 是新的前沿。

PDF: 机密计算联盟白皮书概述了机密计算如何解决此问题，以及用例和动机。本文为技术受众提供了更多详细信息。

机密计算

定义

机密计算是通过在基于硬件的、经过认证的可信执行环境中执行计算来保护正在使用的数据。 （有关可信执行环境的定义，请参阅可信执行环境 (TEE)。）重要的是，该定义不仅限于“云”用途，还可以应用于任何地方，包括公共云服务器、本地服务器、网关、物联网设备、边缘部署、用户设备等。 它也不限于由任何特定处理器完成的此类可信执行，因为可信处理也可能位于其他各种地方，例如 GPU 或网络接口卡。 它也不限于使用加密的解决方案，尽管这是最常用的技术。

相反，机密计算并不是保护正在使用的数据的唯一技术。相关技术介绍了与其他方法的比较。

为什么硬件对于机密计算必不可少

安全性的强弱取决于其下方的各层，因为计算堆栈中任何一层的安全性都可能被底层的漏洞所规避。这就需要尽可能在最低层（直至硬件的硅片组件）提供安全解决方案。通过在最低层的硬件上提供安全性，并尽量减少依赖，可以从所需信任方列表中删除操作系统和设备驱动程序供应商、平台和外围设备供应商以及服务提供商及其管理员，从而​​减少系统生命周期中任何阶段的潜在危害。

为了减少机密计算环境对专有软件的依赖，机密计算联盟已将仅具有软件信任根的 TEE 排除在其范围之外，并专注于为机密计算环境提供基于硬件的安全保障。

另一份 机密计算联盟 (CCC) 白皮书 进一步讨论了机密计算的用途和 CCC 的范围。

可信执行环境 (TEE)

属性

CCC 遵循行业惯例将可信执行环境 (TEE) 定义为提供以下三个属性一定程度保证的环境：

  • 数据机密性：未经授权的实体无法在 TEE 中使用数据时查看数据。
  • 数据完整性：未经授权的实体无法在 TEE 中使用数据时添加、删除或更改数据。
  • 代码完整性：未经授权的实体无法添加、删除或更改在 TEE 中执行的代码。

在机密计算的上下文中，未经授权的实体可能包括主机上的其他应用程序、主机操作系统和虚拟机管理程序、系统管理员、服务提供商和基础设施所有者，或任何其他可以物理访问硬件的人。 这些属性共同确保了数据的机密性，而且确保执行的计算确实是正确的计算，从而让人们可以信任计算的结果。 根据特定 TEE 的具体情况，它还可以提供：

  • 代码机密性：除了保护数据之外，某些 TEE 还可以保护正在使用的代码，防止未经授权的实体查看。例如，这可以保护被视为敏感知识产权的算法。
  • 经过身份验证的启动：某些 TEE 可能会在启动请求的进程之前强制执行授权或身份验证检查，并可能拒绝启动未经授权或身份验证的进程。
  • 可编程性：某些 TEE 可以使用任意代码进行编程，而某些 TEE 可能仅支持一组有限的操作。TEE 甚至可能包括或完全由制造时固定的代码组成。
  • 可证明性：通常，TEE 可以提供其来源和当前状态的证据或测量结果，以便另一方可以验证证据，并且可以以编程方式或手动方式决定是否信任在 TEE 中运行的代码。通常，重要的是，此类证据应由制造商担保的硬件签名，以便检查证据的一方能够确信该证据不是由恶意软件或其他未经授权的一方生成的。（认证将进一步讨论证明问题。）
  • 可恢复性：一些 TEE 可能提供一种机制，用于从不兼容或可能受损的状态中恢复。例如，如果确定固件或软件组件不再满足遵从性需求，并且启动身份验证机制失败，则可能更新该组件并重试(恢复)启动。可恢复性通常要求TEE的某些组件保持受信任，当其他组件更新时，这些组件可以充当“根”。(关于这种恢复的进一步讨论将在后面的认证中提供。)

基于硬件的 TEE 使用硬件支持的技术来为该环境中的代码执行和数据保护提供更高的安全保障。不使用基于硬件的 TEE 的方法通常缺乏这种保证。

有关行业中使用的 TEE 定义的更多讨论，请参阅机密计算联盟 (CCC) 白皮书中的讨论。

相关技术

TAC 对行业中与保护使用中数据相关的各种术语进行了调查，并绘制了以下技术维恩图：

不幸的是，与“机密计算”一词不同，图表中使用的几个术语有多个相互竞争的定义。例如，“隐私保护计算”被定义为与多方计算同义，或涵盖多方计算和同态加密，甚至（例如在 UN Handbook on Privacy-Preserving Computation Techniques 中）涵盖保护使用中数据的整个空间。

此图说明了为什么我们将机密计算称为使用基于硬件的 TEE 保护使用中数据，以将其与其他技术区分开来。

安全性比较

下表将典型的 TEE 实现与保护正在使用的数据的另外两种新兴解决方案的典型实现进行了比较，即 同态加密 (Homomorphic Encryption, HE) 和 可信平台模块 (Trusted Platform Modules, TPM)。

Hardware TEE 同态加密（HE） 可信平台模块（TPM）
Data integrity Yes Yes (subject to code integrity) Keys only
Data confidentiality Yes Yes Keys only
Code integrity Yes No Yes
Code confidentiality Yes (may require work) No Yes
Authenticated Launch Varies No No
Programmability Yes Partial (“circuits”) No
Attestability Yes No Yes
Recoverability Yes No Yes

实际上，这些属性的存在程度可能因供应商、型号和算法而异，因此上述单元格的值是典型示例，但前三个属性突出了安全属性的主要区别。例如，典型的 TPM 保护密钥，并使用这些密钥对数据进行签名或加密，但其本身无法保证提供给它的数据是正确的。TPM 不能使用任意代码进行编程，而 TEE 是可编程的，并保护该代码及其数据。典型的同态加密算法可以保护任意数据，但其本身无法确保已执行正确的操作并且代码未被篡改，而 TEE 再次保护数据和代码。这些技术通常是互补的，甚至可以在解决方案中一起使用以增强安全性。

可扩展性比较

下表显示了传统计算、使用典型基于硬件的 TEE 的计算和同态加密在各种指标上的可扩展性比较。与安全性比较一样，实际答案可能因供应商、模型或算法而异。

Native Hardware TEE Homomorphic Encryption(HE)
Data size limits High Medium Low
Computation Speed High High-Medium Low
Scale out across machines Yes More work Yes
Ability to combine data across sets (MPC) Yes Yes Very limited

虽然组合技术可以提高安全性，但这种组合通常会降低性能和可扩展性。

威胁模型

目标

机密计算旨在降低平台所有者/运营商/拥有者访问 TEE 内部数据和代码的能力，以使该路径在执行期间不是一种经济上或逻辑上可行的攻击。当然，使用“经济上或逻辑上可行”这一短语会对所考虑的攻击者类型做出假设：有些攻击者的考虑因素可能与其他攻击者不同，包括民族国家行为者和一些学术机构。人们认识到没有“绝对的安全”，但 TEE 可以通过除机密性和完整性保护之外的各种措施（包括可用性和成本）显著提高保护使用中数据的其他技术的标准。这一改进使管理敏感数据和算法的系统的设计人员、实施者和操作员能够专注于系统的其他方面。

关注执行期间的数据保护非常重要，因为机密计算关注的是使用中数据。可能存在与存储和传输（分别为静态数据和传输中的数据）相关的攻击，这些攻击虽然与使用 TEE 的任何系统相关，但与 TEE 提供的保护没有直接关系。其中一些可能属于机密计算的范围，包括：

  • 对 TEE 和 TEE 环境进行认证，以确保有效且正确的部署；
  • 将工作负载和数据传输到 TEE 环境；
  • 将与 TEE 环境相关的数据存储在 TEE 实例之外；
  • 在 TEE 环境之间迁移工作负载

在某些情况下，将工作负载部署到 TEE 环境中的人员可能对托管工作负载的系统的所有者具有不同程度的信任，并且这种信任可能会随着时间的推移而发生变化。此类变化可能基于多种因素，例如与主机所有者或运营商的关系、主机所包含的软件和硬件，以及物理、软件或社会工程危害的可能性。这是适当的，机密计算框架和项目可能采用与主机、主机所有者、主机运营商和任何其他参与者相关的不同信任模型。

生态系统中依赖 TEE 安全保障的参与者可以通过多种方式建立对 TEE 的信任。一种方法是通过第三方评估实验室的评估来获得产品安全声明的保证。其他方法包括基于特定供应商的安全声明提供保证；社区或其他机构对硬件、固件和/或软件中的开源组件进行审计；以及行业或标准机构的评估或认证。

威胁载体

攻击可能利用系统中的漏洞，其载体有多种：如上所述，机密计算并不试图解决所有问题。即使不能提供正式定义，也值得提供各种威胁载体的描述，这些威胁载体被认为在机密计算范围内和范围外。

应该注意的是，虽然某些类型的范围内威胁载体通常可以通过机密计算技术缓解，但有一组威胁载体的缓解程度将根据硅片实现而有很大差异，并且可能存在一些“灰色区域”，一些供应商可能认为这些区域在范围内，而其他供应商则认为这些区域在范围外。在完整性、回滚和重放攻击等领域尤其如此。

范围内

以下威胁载体被视为机密计算的范围：

  • 软件攻击：这些攻击包括对主机上安装的软件和固件的攻击，包括操作系统、虚拟机管理程序、BIOS、其他软件和堆栈以及与任何一方相关的工作负载。
  • 协议攻击：这些攻击包括对与证明以及工作负载和数据传输相关的协议的攻击。任何可能危及 TEE 实例证明的攻击都可能导致工作负载或数据受到损害。同样，即使证明协议没有受到损害，工作负载和/或数据的配置或放置中的漏洞也可能导致损害。
  • 加密攻击：加密是一门不断发展的学科，随着时间的推移，由于多种因素，包括数学突破、计算能力的可用性以及量子计算等新计算方法，密码和算法中会发现漏洞。在可能的情况下，应提倡加密敏捷性原则，允许用较新的版本或更适合特定环境的方法替换已弃用的加密原语。虽然这在 TEE 的软件和固件组件中是可能的，但在硬件中通常不切实际。在某些情况下，纵深防御可能是合适的，例如在 TEE 实例中使用抗量子加密技术，其实现本身并不抗量子，但合格人员需要仔细考虑，然后才能假设这将为任何特定用例提供适当的保护。
  • 基本物理攻击：虽然对 CPU 的长期侵入性攻击被认为超出了范围（见下文），但其他攻击被认为在范围内，包括冷 DRAM 提取、总线和缓存监控以及将攻击设备插入现有端口，例如 PCIe、Firewire、USB-C。
  • 基本的上游供应链攻击：尽管在供应链中对 TEE 组件进行的攻击超出了范围（见下文），但通过添加调试端口等“严重”更改来破坏这些组件的攻击被认为在范围内。

机密计算联盟还认为，有机会为设计、实施和运营工作负载的人提供指导，让他们了解哪些类型的应用程序比其他应用程序更容易受到攻击，以及生命周期管理方面的问题，以帮助缓解攻击。

范围外

范围外的威胁载体通常被认为超出机密计算的范围，包括：

  • 复杂的物理攻击：这些物理攻击通常需要长期和/或侵入性访问硬件，包括芯片抓取技术和电子显微镜探针。
  • 上游硬件供应链攻击：这些攻击不包括对不直​​接提供 TEE 功能的主机系统组件的攻击，但包括对 CPU 等的攻击。示例包括在芯片制造时的攻击和在密钥注入/生成时的攻击。
  • 可用性攻击（如 DoS 或 DDoS）攻击：当前基于硬件的 TEE 未将其作为威胁模型的一部分来解决。软件项目和服务提供商可能会针对此类攻击提供缓解措施。

侧信道

背景

TEE 按照目标中描述的威胁模型目标，为数据机密性提供了一定程度的保证。然而，这种保证依赖于一些假设，其中最关键的一个假设是，不存在可供所有者（或任何其他有权访问系统的实体）用来推断数据或执行信息的可利用侧信道。在过去几年中，学术研究人员已经发现并证明了某些 TEE 设计中的漏洞，这些漏洞允许此前仅被认为只是理论上的侧信道攻击。这些漏洞与 TPM 和 HSM 等其他技术以及其他隔离或数据保护机制中的类似发现如出一辙。这些攻击引起了整个技术和安全社区的极大关注。

示例

这里我们给出一个椭圆曲线密码学 (ECC) 中的简化示例。ECC 使用椭圆曲线点乘法来生成单向函数。在 ECC 中，将曲线上的点 P 乘以 n 会得到曲线上的一个新点 Q。ECC 依赖于这样一个事实：给定 P 和 Q 就很难确定 n。TEE 可以使用“加倍并加法”方法实现此乘法来计算 Q。简而言之，该方法一次一位地遍历 n 的二进制表示，并对每个 0 位执行加倍运算，对每个 1 位执行加倍和加法运算。

由于该方法是在 TEE 内部执行的，因此可以确保数据的机密性，这意味着攻击者无法在数据导出时直接观察数据。但是，攻击者可能能够使用侧信道来确定 n 的值。

如果攻击者可以物理访问机器，他们可以利用的一个旁道攻击是准确测量方法执行期间 TEE CPU 的功耗。例如，如果 TEE CPU 执行加法和加倍的功耗不同，攻击者可能能够从功耗分布中得出 n。并非所有旁道攻击都需要物理访问，有些可以通过软件测量执行人为操作所需的时间来实现。

先加倍再加法，表示该位为 1。如果加倍后不加法，则表示该位为 0。攻击者可以利用此信息完全恢复 n。

还要注意，处理每个值为 1 的位所需的时间都比处理值为 0 的位所需的时间长。攻击者可以通过精确测量方法执行所需的时间来确定 n 中 0 与 1 的比例，从而执行另一种旁道攻击，大大降低使用后续暴力攻击恢复 n 的复杂性。

旁道攻击允许攻击者利用对 TEE 本身架构的了解推断有关 TEE 内部数据或操作的信息。上述示例相对简单，但可以使用针对现有 TEE 识别出的多种技术组合对 TEE 发起复杂的攻击。

缓解

一个自然的假设是，TEE 本身应该提供针对旁道攻击的主要防御。但是，防止旁道攻击是 TEE 供应商、第三方供应商和应用程序开发人员的共同责任。

回顾上面的例子，由于该方法处理 0 位和 1 位的方式不同，因此可以利用功率和时间旁道攻击。如果该方法的作者为遇到的每个 0 位插入一个虚拟加法运算会怎样？这将导致 0 和 1 具有完全相同的功率分布并花费相同的时间来执行。攻击者将没有有用的旁道信息可利用。

并非所有的旁道攻击和缓解措施都像上面的例子一样简单。一些旁道是由于应用程序开发人员的代码或第三方库中的算法而暴露的。其他旁道可能是由于在托管 TEE 的 CPU 中实现缓存等而暴露的。

编写将在 TEE 中运行的代码需要一定的专业知识和对侧信道缓解技术的了解，无论是应用程序、编译器、SDK 还是运行时环境提供的技术。TEE 制造商和第三方供应商提供专门针对安全 TEE 代码生成的工具和 SDK。这些可以大大降低代码作者引入可被利用的侧信道的风险，并为 TEE 中的已知漏洞提供良好的防御。

认证

认证是指一方（称为“验证者”）评估可能不受信任的对等方（即“证明者”）的可信度的过程。（这些术语的使用与互联网工程任务组的远程认证程序架构一致。）认证的目标是通过获得有关证明者软件和数据状态的真实、准确和及时的报告，让验证者对证明者的可信度充满信心。

基于硬件的认证

基于硬件的证明方案依赖于可信硬件组件和相关固件在安全环境中执行证明例程。例如，证明协议可能按如下方式工作：

  • 在验证者和证明者之间建立安全通信通道；
  • 建立安全连接后，验证者生成挑战并将其发送给证明者；
  • 收到验证者的挑战后，证明者通过将挑战发送到其可信硬件组件并请求其软件和数据状态的证据来启动证明过程；
  • 可信硬件组件在证明平台上收集证据并签署证明数据和挑战；
  • 证明者将签名的证据返回给验证者；
  • 验证者通过应用一些评估策略来验证签名并评估证据，例如将经过证明的平台状态与一组被认为值得信赖的参考值进行比较，并验证签名的证据是否包含提供的挑战，以便验证者知道证据是新生成的。

上述证明过程确立了证明者的可信度，并确保在生成证据时它处于可信状态。有关包括其他变体的更详细讨论，请参阅 远程认证程序架构。

证明协议设计和实现还必须围绕特定安全属性提供保证，包括：

  • 不可伪造性：如果可信硬件组件从未签署过此消息，那么攻击者就无法在与可信硬件组件的签名相关的消息上生成签名。
  • 撤销：如果可信硬件组件受到损害，则不再接受来自受损密钥的签名。

一些证明方案还提供：

  • 匿名性：攻击者无法从签名中揭示可信硬件组件的身份。

匿名

在基于硬件的证明方案中，可信硬件组件可以通过其加密密钥唯一地标识，这可能允许对手监视特定可信硬件组件的活动。

满足此要求的一种方法是由直接匿名证明 (Direct Anonymous Attestation，DAA) 方案（例如 ISO/IEC 11889:2015 中指定的算法）采用的，该方案试图通过利用零知识证明和群签名等高级加密原语来解决这一隐私挑战。在实践中，DAA 方案可以使用各种加密技术来实现，包括 RSA、椭圆曲线密码术 (Elliptic Curve Cryptography，ECC)、基于配对的密码术 (Elliptic Curve Cryptography，PBC) 或基于格的密码术 ( Lattice-based Cryptography，LBC)。

TCB 恢复

可信计算基 (Trusted Computing Base，TCB) 恢复是指在某个时间点发现 TEE 的 TCB 中存在可修复的缺陷时，能够重新建立 TEE 可信度的过程。例如，如果签名的证据与安全系统的最新预期值不匹配，则在认证过程中，验证者将得出认证者不完全可信的结论，从而需要进行此类修复。

TEE 的 TCB 通常包括不可变和可变部分，提供创建认证过程中使用的证据的功能。如果在 TCB 中发现缺陷，则此过程本身可能会被欺骗或破坏。TEE 实现可能包括特殊技术，以允许更新 TCB 的可变部分，并由不可变部分保护。更新后创建的任何新认证证据都会识别并证明更新已发生，而之前有缺陷的实现无法欺骗这种更新。

结论

机密计算通过使用基于硬件的、经过认证的可信执行环境，保护敏感数据和代码免受数据执行过程中日益常见的威胁，而这些威胁以前很难甚至不可能防范。例如，在经典的安全威胁模型中，系统的所有者或操作员通常被视为可信的，而机密计算还可以保护数据免受敌对所有者的侵害。

结合基于硬件的认证技术，机密计算可以提供强大的数据完整性、数据机密性和代码完整性保证。即使使用 TPM 或同态加密等其他技术，添加机密计算和基于硬件的认证也可以通过提供一定程度的数据和代码完整性保证来提高安全性。随着对使用中数据的这些增强保护，新的用例变得更加现实，例如金融和/或受监管行业中的多方计算或边缘机器学习，其中操作的数据需要保护免受处理环境所有者本身的侵害。

关于CCC

机密计算联盟 (CCC) 是一个专注于使用基于硬件的 TEE 保护使用中数据的项目并通过开放式协作加速机密计算的采用的社区。CCC 将硬件供应商、云提供商和软件开发人员聚集在一起，以加速可信执行环境 (TEE) 技术和标准的采用。

本白皮书或 CCC 的目的不是评估或比较特定的供应商技术。本白皮书旨在设置背景并定义供应商可以用来描述其产品的一致术语，以便其他人可以对该领域的各种产品进行同类比较。

本内容代表机密计算联盟 (CCC) 的协作工作（“工作”）。

CCC 对工作负全部责任，个别 CCC 成员可能没有贡献或参与，也可能不认可它。

机密计算：基于硬件的应用程序和数据可信执行

机密计算：基于硬件的应用程序和数据可信执行

简介

如今，数据在存储和网络传输过程中通常会被加密，但在内存中使用时则不会加密。此外，在传统计算基础设施中，保护使用中的数据和代码的能力有限。处理个人身份信息 (Personally Identifiable Information，PII)、财务数据或健康信息等敏感数据的组织需要缓解针对应用程序或系统内存中数据的机密性和完整性的威胁。

机密计算通过在基于硬件的、经过认证的可信执行环境中执行计算来保护正在使用的数据。这些安全且隔离的环境可防止未经授权访问或修改正在使用的应用程序和数据，从而提高管理敏感和受监管数据的组织的安全级别。

为什么需要机密计算

数据状态

在计算中，数据有三种状态：传输中、静止和使用中。通过网络传输的数据为“传输中”，存储中的数据为“静止”，正在处理的数据为“使用中”。在我们不断存储、使用和共享敏感数据（从信用卡数据到医疗记录、从防火墙配置到我们的地理位置数据）的世界中，保护所有状态下的敏感数据比以往任何时候都更加重要。现在通常使用加密技术来提供数据机密性（阻止未经授权的查看）和数据完整性（防止或检测未经授权的更改）。虽然现在通常使用保护传输中和静止数据的技术，但第三种状态 - 保护使用中的数据 - 是新的前沿。

未受保护的“正在使用”数据的安全风险

随着针对网络和存储设备的威胁载体越来越多地受到适用于传输中和静止数据的保护的阻止，攻击者已将目标转向正在使用的数据。业界见证了几起备受瞩目的内存抓取事件，例如 Target 漏洞和 CPU 侧信道攻击，这些事件大大增加了人们对第三种状态的关注，以及几起涉及恶意软件注入的备受瞩目的攻击，例如 Triton 攻击和乌克兰电网攻击。

此外，随着越来越多的数据被转移到云端，网络和物理边界安全在防御攻击方面的能力越来越有限。针对基于云的应用程序的广泛研究的攻击模式包括虚拟机管理程序和容器突破、固件入侵和内部威胁，每种攻击模式都依赖于不同的技术来攻击正在使用的代码或数据。虽然以前的保护措施（保护传输中和静止的数据）仍然是良好纵深防御策略的重要组成部分，但它们已不再适用于处理敏感数据的用例。

数据处理监管日益严格，例如《通用数据保护条例》（GDPR）和《加州消费者隐私法案》（CCPA），当用户、客户或客户的数据因违规而泄露时，数据保管人可能会直接承担责任。由于 GDPR 规定的数据泄露成本可能高达年总收入的 4%，因此数据保管人有强烈的动机保护潜在的表面区域免受攻击，包括正在使用的数据。

随着越来越多的数据存储和处理在移动、边缘和物联网设备上（这些设备在远程且通常难以保护的位置进行），在执行过程中保护数据和应用程序变得越来越重要。此外，由于存储在移动设备上的信息具有个人性质，制造商和移动操作系统提供商需要证明对个人数据的访问受到保护，在共享和处理过程中不会被设备供应商或第三方观察到，并且这些保护措施符合监管要求。

即使您控制了所有基础设施，在使用过程中保护最敏感的数据也是良好的纵深防御策略的一部分。

机密计算有何帮助

机密计算是使用基于硬件的、经过认证的可信执行环境来保护正在使用的数据。通过使用机密计算，我们现在能够提供针对上一节中描述的许多威胁的保护。

什么是可信执行环境

可信执行环境 (TEE) 通常被定义为提供一定程度的数据完整性、数据机密性和代码完整性保证的环境。基于硬件的 TEE 使用硬件支持的技术为该环境中的代码执行和数据保护提供更高的安全保障。

在机密计算的背景下，未经授权的实体可能包括主机上的其他应用程序、主机操作系统和虚拟机管理程序、系统管理员、服务提供商和基础设施所有者，或任何其他可以物理访问硬件的人。数据机密性意味着这些未经授权的实体在 TEE 内使用数据时无法查看数据。数据完整性是指在数据被 TEE 之外的任何实体处理时，防止未经授权的实体更改数据。代码完整性意味着 TEE 中的代码不能被未经授权的实体替换或修改。

这些属性共同确保了数据的机密性，并且确保了执行的计算实际上是正确的计算，从而让人们可以信任计算的结果。不使用基于硬件的 TEE 的方法通常缺乏这种保证。

实际上，这些属性的存在程度可能因供应商、型号和算法而异，但前三个属性突出了安全属性的主要差异。例如，典型的 TPM 保护密钥，但本身无法保证由这些密钥签名或加密的数据的有效性，并且不能用任意代码进行编程，而 TEE 是可编程的，并保护该代码及其数据。典型的同态加密算法可以保护任意数据，但本身无法确保已执行正确的操作并且代码未被篡改，而 TEE 再次保护数据和代码。这些技术通常是互补的，甚至可以在解决方案中一起使用以增强安全性。

根据 TEE 的具体情况，它还可以提供：

  • 代码机密性：除了保护数据之外，某些 TEE 还可以保护使用中的代码，以防止未经授权的实体查看。例如，这可以保护被视为敏感知识产权的算法。
  • 经过身份验证的启动：某些 TEE 可能在启动请求的进程之前强制执行授权或身份验证检查，并可能拒绝启动未经授权或身份验证的进程。
  • 可编程性：某些 TEE 可能使用任意代码进行编程，而某些 TEE 可能仅支持有限的一组操作。TEE 甚至可能包含或完全由制造时固定的代码组成 • 可恢复性：某些 TEE 可能提供从不合规或可能受损状态恢复的机制。例如，如果确定固件或软件组件不再满足合规性要求且启动身份验证机制失败，则可能可以更新该组件并重试（恢复）启动。
  • 可恢复性通常要求 TEE 的某些组件保持受信任，当其他组件更新时，这些组件可以充当“根”。
  • 可证明性：TEE 通常可以提供其来源和当前状态的证据或测量结果，以便另一方可以验证该证据，并以编程或手动方式决定是否信任在 TEE 中运行的代码。通常重要的是，此类证据应由制造商可以担保的硬件签名，以便检查证据的一方可以确信该证据不是由恶意软件或其他未经授权的方生成的。

当前基于硬件的 TEE 的威胁模型并未解决可用性攻击（例如 DoS 或 DDoS）。软件项目和服务提供商可能会针对此类攻击提供缓解措施。

为什么机密计算需要硬件

安全性的强弱取决于其下层的安全性，因为计算堆栈中任何一层的安全性都可能因底层的漏洞而被规避。这就需要尽可能在最低层（直至硬件的硅片组件）提供安全解决方案。通过在最低层的硬件上提供安全性，并尽量减少依赖性，可以将操作系统和设备驱动程序供应商、平台和外围设备供应商以及服务提供商及其管理员从所需信任方列表中删除，从而减少潜在危害。

为了减少机密计算环境对专有软件的依赖，机密计算联盟已将仅具有软件信任根的 TEE 排除在其范围之外，并专注于为机密计算环境提供基于硬件的安全保障。

机密计算中的利用范例

如今，基于硬件的 TEE 有多种使用方式，可提供机密计算所寻求的高效纵深防御机制和安全边界。这些方法的可信计算基 (TCB) 大小各不相同，TCB 是用户需要信任的代码行数的粗略衡量标准，以及应用程序如何使用相应的 TEE。

用户应该了解这两种常见方法之间的差异以及它们如何满足机密计算的质量要求，以便做出支持其用例的相应选择。

方法 1：应用程序 SDK

在这里，开发人员负责识别其应用程序代码并将其划分为可信和不可信组件。他们如何执行此类活动可能会受到应用程序是为一个硬件 TEE 编写的，还是由软件开发工具包将 TEE 特定内容抽象为通用编程模型的影响，从而实现跨硬件 TEE 的一定程度的可移植性。这种方法可以更仔细地审查在 TEE 中运行的代码及其提供的接口，因为与范例 #2 相比，需要审查的代码可能更少，但可能需要设计（或更改）应用程序以使用 TEE 感知 SDK。

方法 2：运行时部署系统

这种方法涉及尽量减少将典型应用程序工作负载转换为可以在 TEE 中运行的应用程序所需的工作量。同时，人们也在努力开发跨 TEE 可移植应用程序，同时还在进行其他努力以将未修改的应用程序部署到 TEE 中。部署完整的应用程序有其优点和缺点：一方面，它降低了部署获得额外隔离的应用程序的成本，但原始应用程序很可能没有设计为利用 TEE 的其他功能，例如证明和秘密保护。这些优势可能为了易于使用而放弃，或者可能由运行时部署系统或通过其他机制处理。

机密计算的用例

密钥、机密、凭证和令牌的存储和处理

加密密钥、机密、凭证和令牌是负责保护敏感数据的组织的“王国钥匙”。从历史上看，存储和处理这些关键信息资产需要符合当地国家安全标准（例如美国联邦信息处理标准 (FIPS 140-2、140-3) 对加密模块的安全要求）的内部部署硬件安全模块 (HSM)。传统 HSM 硬件的专有性质增加了其成本，限制了其可扩展性，并为在云和边缘计算环境中的部署带来了成本和兼容性挑战。

机密计算已被独立软件供应商 (ISV) 和大型组织使用，使用内部部署、公共/混合云中，甚至在 IoT 用例的网络边缘可用的标准化计算基础设施来存储和处理加密和机密信息。密钥管理应用程序在安全的基于硬件的 TEE 中存储和处理加密密钥、机密和令牌，提供数据机密性、数据完整性和代码完整性，以实现与传统 HSM 相当的安全性。

公有云用例

在传统的公有云场景中，必须信任云提供商的许多层：硬件；核心和外围设备的固件；主机操作系统、虚拟机管理程序和云提供商的编排系统本身。虽然公有云提供商显然不遗余力地保护此堆栈的所有层，但机密计算提供了额外的保护保证，并大大减少了最终用户必须信任的层数。

使用基于硬件的TEE来保护正在使用的应用程序和数据，对于未经授权的参与者(即使是对硬件具有物理访问权限、对主机操作系统或管理程序具有根访问权限或对编排系统具有特权访问权限的参与者)来说，访问受保护的应用程序代码和数据变得更加困难。Confidential Computing的目标是允许将云提供商从可信计算基础中移除，这样只有硬件和受保护的应用程序本身在攻击范围内。

这使得许多工作负载能够迁移到公共云，而以前由于安全问题或遵从性需求而无法迁移到公共云。

多方计算

新的计算范式正在出现，使数据集和处理能力可以在多方之间共享。但是，数据和计算模型可能很敏感或受到监管，例如在金融服务、医疗保健、政府和非营利领域。

那么，即使在其他交易方可能不信任的平台之间共享数据，如何才能保持数据的机密性和完整性呢？组织希望摆脱数据孤岛的限制，但仍必须确保共享数据源时不会受到损害，并且只有获准共享的各方才能访问结果。

例如，私人多方分析可以应用于任何多方拥有需要合并和分析的私人数据的情况，而无需将底层数据或机器学习模型暴露给任何其他方。该技术可以应用于防止金融服务中的欺诈行为、检测或开发医疗保健行业疾病的治疗方法，或获得业务洞察力。例如，多家医院可以合并数据来训练机器学习模型，以使用放射学信息更准确地检测脑肿瘤。但即使发生泄露，个人患者数据仍将保密。

利用机密计算，组织现在可以确保远程系统上的数据免受篡改和泄露，包括合作组织内部的内部威胁，还可以验证处理该数据的代码的完整性。数据可以在 TEE 内组合和分析，结果可以以加密格式发送回各方。数据在整个过程中都受到保护：在传输、计算和存储过程中。

这些功能将有助于推动全球数据共享环境的发展，例如上述技术，使组织能够解锁以前未利用的数据集，以便与其他组织进行协作分析和交换，同时降低安全、隐私和监管影响的风险。

区块链

区块链是一种共享的、不可变的分类账，它记录了参与者网络之间的数据、数字资产或货币交换。

区块链提供了记录和验证交易的基础设施，而不需要集中的第三方。区块链可以为供应链活动提供透明度，促进数字资产的交换，或支持合规流程，如了解您的客户(KYC)。区块链的一个关键特征是，它确保应该拥有共同数据的参与者确信他们看到的是相同的东西，并且一旦进入区块链数据是不可变的。这取决于应用程序开发人员，以确保敏感数据(如PII)不存储在不可变的区块链上。

机密计算可用于增强基于区块链的系统的实施。通过结合机密计算和区块链技术的力量，用户可以利用基于硬件的 TEE 提供认证和验证服务，以优化可扩展性、隐私性和安全性。区块链用户之间数据一致性的保证通常取决于各方是否独立验证了当前数据有效性所依赖的所有历史数据。

这需要这些历史数据集的可见性，这是​​一个潜在的可扩展性或隐私问题。用户可以在基于硬件的 TEE 中执行智能合约，而不是自己独立访问和验证历史数据和相关智能合约。交易完成后，TEE 提供认证服务来证明交易的可靠性，这意味着后续参与者无需再次自己执行验证。基于 TEE 的认证服务还可以帮助解决由共识协议引起的一些计算和通信效率低下的问题。

移动和个人计算设备

客户端设备上的用例主要涉及应用程序开发人员或移动设备制造商，他们保证在共享或处理过程中个人数据不会被观察到。从合规性和最佳实践的角度来看，这使设备制造商免于承担责任，因为他们可以声称他们无法观察到客户的个人数据。如果 TEE 能够确保前面提到的可证明性和代码完整性属性，则可以正式证明计算的功能正确性（以及计算结果的可信度）。这提供了一个环境，应用程序开发人员可以向用户证明他们的数据没有离开设备。

例如，在持续身份验证（始终登录）的实现中，设备上的用户帐户登录应用程序使用可以从用户交互中收集的信号来识别用户。这些可能包括敏感数据，例如用户与设备交互的生物特征或物理模式，这些数据可以从 TEE 内操作中受益。用户行为引擎只需识别用户，而无需将原始用户行为数据暴露给其他设备或 TEE 之外的代码。

另一个例子是去中心化的设备上模型训练的情况，其目的是改进模型，并允许将这些改进与其他设备共享，而不会泄露用于训练模型的数据。使用基于硬件的机密计算的协议设计比差分隐私[3]等统计模型更容易使用。此外，统计方法仍然依赖于消费者信任应用程序开发人员注入适量的噪声以充分隐藏敏感数据。相比之下，设备上的硬件 TEE 可以让用户通过相互证明的属性在自己的设备上设置数据的使用和处理策略和约束。

边缘和物联网用例

例如，在家庭路由器中进行 DDoS 检测的背景下的本地搜索和过滤等案例就是机密计算环境非常适合的例子。在大多数情况下，TCP/IP 数据包元数据需要保密，因为可以推断出敏感的用户行为。其他示例包括边缘机密机器学习处理，如视频元数据生成，以减少后端网络的延迟和/或带宽； CCTV 摄像机监控，提供商需要加载可能泄露的可疑人员模板；或者类似于上述移动环境中的设备训练模型。

某些设备的设计使其可以被不受信任的各方物理访问。机密计算技术可用于帮助缓解依赖于对设备的物理访问的攻击。

销售点设备/支付处理

如今，使用基于硬件的、经过认证的可信执行环境在支付处理行业已经很常见。接受芯片和 PIN 式信用卡或借记卡的销售点设备用于保护机密信息，例如信用卡号、PIN、有效期、CVV 和用于保护消息的密钥材料。通常，其他设备（例如收银机或平板电脑）是通用计算设备，芯片读取硬件用于保护支付处理代码免受此类通用计算设备上任何潜在恶意软件的攻击。

为了保护用户输入的信息（例如 PIN），保护数据输入方式也很重要，这样用户输入的数据就不会被读取或篡改。在安全设备中，数字键盘是隔离的，因此输入只能由基于硬件的 TEE 内的代码读取。通过这种方式，可以安全地操作数据并将其用于生成加密消息以发送给支付处理服务，所有这些都不会受到任何恶意软件或第三方未经授权的访问。

结论

机密计算领域正在迅速发展，为企业和最终用户提供新工具，保护敏感数据和代码免受数据执行期间发生的一类威胁，而这些威胁以前很难甚至不可能防范。

解决方案提供商通过权衡利弊，开发了不同的机密计算方法，例如围绕 TCB 大小，从将应用程序代码划分为可信和不可信组件，到支持在几乎不做任何更改的情况下迁移现有应用程序。

这些不同的方法支持各种用例，但最终目标都是帮助确保敏感、业务关键信息和工作负载的机密性。随着机密计算的不断发展，可能会出现更多方法，或者这些方法可能会演变。机密计算联盟对该领域面临的创新持乐观态度。