机密计算技术分析

 

注：本文是对机密计算联盟发布的白皮书A Technical Analysis of Confidential Computing v1.2的原文翻译。

介绍

在计算的过程中，数据存在三种状态：传输中、静止时和使用中。通过网络传输的数据处于“传输中”的状态；存储的数据处于“静止”状态；而正在处理的数据处于“使用中”的状态。在这个世界上，我们正不断地存储、使用和共享各种敏感数据：从信用卡数据到病历，从防火墙配置到地理位置数据。为所有状态下的敏感数据提供保护比以往任何时候都更为重要。现在通行的做法是使用密码学技术为数据机密性（防止未经授权的读取操作）和数据完整性（防止或检测出未经授权的篡改操作）提供保护，但这些技术主要被用于保护传输中和静止状态的数据，目前对“使用中”的数据提供安全防护的技术仍旧属于新的前沿领域。

机密计算联盟白皮书为机密计算如何解决这个问题提供了概述以及使用场景和动机。本白皮书则为技术受众提供了更多细节。

机密计算

定义

机密计算指的是通过在基于硬件的可信执行环境（Trusted Execution Environment）中执行计算过程的方式，为使用中的数据提供保护的计算模式（见《 可信执行环境（TEE）》一节中有关可信执行环境的定义）。

最为重要的是，该定义不仅限于云场景，还可应用于任何其他地方，包括公共云服务器、内部部署的服务器、网关、IoT设备、边缘部署、用户设备等场景。机密计算也不限于特定处理器所能提供的可信执行能力，比如GPU或网卡也同样能够具备这种可信计算能力。机密计算甚至也不局限于数据加密技术，尽管这是机密计算最常用的技术。

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

为什么机密计算需要硬件的支持

整个计算栈中每一层的安全强度都必须至少与它下面一层的安全强度相同，因为计算栈中的任何一层的安全性都可能被底层的漏洞所规避。这就需要在尽可能低的层次上提供更为彻底的安全解决方案，甚至直至硬件层。利用最底层硬件所能提供的安全性，在保持最小信任依赖的情况下，可以将操作系统和设备驱动程序厂商、平台和设备厂商、服务提供商及管理员从需要信任的实体列表中删除，从而减少潜在的风险。

为了减少机密计算环境对专有软件的依赖，机密计算联盟将只实现了基于软件信任根的TEE排除在关注范围之外，并只将机密计算环境的关注重点放在了基于硬件的安全保障上。机密计算联盟发布的另一个白皮书对机密计算的使用和机密计算联盟关注的范围进行了更多的讨论。

可信执行环境（TEE）

性质

按照一般的行业惯例，机密计算联盟将可信执行环境定义为一个能够为以下三个属性提供一定程度保证的环境：

数据机密性：未经授权的实体不能窥探到在TEE内使用的数据。数据完整性：未经授权的实体不能添加、删除或篡改在TEE内使用的数据。代码完整性：未经授权的实体不能添加、删除或篡改在TEE中执行的代码。

在机密计算的上下文中，未经授权的实体可以包括主机上的应用程序、主机操作系统和Hypervisor、系统管理员、服务提供商、基础设施所有者或任何能够物理接触硬件的人。

总之，这些性质不仅保证了数据的机密性，而且还保证了所执行的计算过程是符合预期的，从而使人们能够相信计算的结果。

结合特定的TEE的具体情况，它还能提供：

代码机密性：除了保护数据外，一些TEE还可以保证代码在使用过程中不会被未经授权的实体窥探。这种能力能够保护被视为敏感知识产权的算法。

经过认证的启动（Authenticated Launch）：一些TEE可能强制要求在启动之前必须执行必要的授权或认证检查，以便拒绝未经授权或认证的启动流程。比如SEV(-ES)的pre-attestation和SGX的launch control机制。

可编程性：一些TEE可以使用任意代码对其进行编程，但有些TEE可能仅支持一组有限的操作，还有的TEE甚至可能包含或完全由生产时固化的代码组成。

可证明性：通常TEE可以提供其起源和当前状态的证据或度量值，以便由另一方进行验证，并且可以通过编程或手动方式决定是否信任运行在TEE中的代码。其中最重要的是，此类证据是经过了由芯片制造商能够证明的硬件签名过的，因此检查证据的一方能够非常坚定地确定证据不是由恶意软件或其他未经授权的实体生成的。（《Attestation》一节会专门讨论这个话题）

可恢复性：一些TEE具备从不合规或危及安全性的状态下恢复的机制。例如，如果确定固件或软件组件不再满足合规要求，并因此导致启动时的验证机制失败，则可以更新该组件并重试或恢复启动。可恢复性通常要求TEE的某些组件必须永远保持可信，只有这样才能保证当更新其他组件时，永久可信的组件可以充当“信任根”。（《TCB Recovery》一节将对这个话题进行进一步的讨论）

基于硬件的TEE使用硬件提供的技术为运行在该环境中的代码和数据的安全性提供了更高的安全保证。而不使用基于硬件的TEE是无法提供这种保证的。

有关行业中关于TEE定义的更多讨论，详见这里的讨论。

相关技术

TAC对行业中与为使用中的数据提供保护的相关技术进行了调查，并绘制了以下Venn图：

不幸的是，与术语“机密计算”不同，图中使用的一些术语有多个相互矛盾的定义。例如，“隐私保护计算”被不同程度地视为与多方计算同义，或同时涵盖多方计算和同态加密，甚至在《UN Handbook on Privacy-Preserving Computation Techniques》中，“隐私保护计算”涵盖了所有与为使用中的数据提供保护的相关技术。

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

安全性比较

下面的表格将基于硬件的TEE、可信平台模块（TPM）以及同态加密这三个方案进行了比较：

基于硬件的TEE同态加密TPM数据完整性YY（需要代码完整性作为前提）只有密钥受到保护数据机密性YY只有密钥受到保护代码完整性YNY代码机密性Y（视具体TEE的实现而定）NY经过认证的启动视具体TEE的实现而定NN可编程性Y部分可编程N可证明性YNY可恢复性YNY

在实践中，上述安全属性是否全部可用取决于供应商、模型和算法，但前三点能够特别突出地反映出各个方案在安全性上的关键区别。例如，典型的TPM能够保护密钥，但其本身不能保证由这些密钥签名或加密的数据的有效性，并且TPM的逻辑是不可编程的；而TEE是可编程的，并且还能够保护其中的代码及数据。典型的同态加密算法可以保护任意数据，但其本身不能保证操作的正确性，也不能确保其代码本身没有被篡改；而TEE可以同时保护数据和代码。这些技术通常是互补的，甚至可以组合起来形成一个更为强大的安全解决方案。

可扩展性比较

下表显示了普通计算、使用典型的基于硬件的TEE计算和同态加密之间，在各维度上的可扩展性的比较。与安全性比较类似的是，实际答案可能因供应商、模型或算法而异。

普通计算基于硬件的TEE同态加密对数据大小的限制低中高计算速度快偏快慢跨平台能力具备视具体TEE的实现而定具备跨集合合并数据的能力（MPC）具备具备非常有限

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

威胁模型

目标

机密计算的目标是最大限度地降低平台所有者、管理员和攻击者访问TEE内的数据和代码的能力，从而使该路径在执行层面变得不再经济或逻辑上可行。 当然，使用“经济或逻辑上可行”这种描述会对所考虑的攻击者类型做出了一定假设：有些攻击者在这方面可能与其他攻击者有着不同的考量，包括国家行为和一些学术机构。相关的共识是，不存在所谓的“绝对安全”，但与其他用于保护使用中数据的技术相比，除了能够提供机密性和完整性保护外，TEE还能够通过多种方式显著提高安全水位。这种安全性的改进使管理敏感数据和算法系统的设计者、实现者和管理员能够更专注于系统的其他方面。

机密计算涉及到使用中的数据，因此它关注的重点是对执行过程中的数据提供保护。正在使用TEE的系统可能会遭受与存储和传输（分别针对静态数据和传输中的数据）相关的攻击，但它们与TEE提供的保护不直接相关。但其中一些攻击属于机密计算威胁模型的范畴，包括：

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

在一些场景中，那些将工作负载部署到TEE环境中的人（比如租户）可能对实际运行工作负载的系统的所有者（比如CSP）抱有不同程度的信任感，并且这种信任感会随着时间的推移而发生变化。这种变化可能与主机上的软件和硬件、与主机所有者或管理员的关系、以及被物理、软件或社会工程攻击的可能性等多种因素有关。发生这种变化是合理的，并且机密计算框架和相关的项目可以根据上述因素采用不同的信任模型。

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

威胁向量

有很多种可以利用系统中的漏洞发起攻击的威胁向量。如前所述，机密计算不会试图解决所有这些问题。有的威胁向量在机密计算的范畴之内，而有的则在机密计算的范畴之外。

应注意的是，虽然通常可以通过机密计算技术缓解某些属于机密计算范畴内的威胁向量，但有些威胁向量，其缓解程度将根据具体的硬件实现有着显著不同，而且可能还存在一些“灰色区域”。某些厂商可能会将其视为再机密计算的范畴之内，但其他厂商可能会将其视为在机密计算的范畴之外，尤其是在完整性、回滚和重放攻击等领域。

属于机密计算范畴之内的威胁向量

以下威胁向量属于在机密计算范畴之内：

软件攻击：这些攻击包括对主机上安装的软件和固件的攻击，包括操作系统、hypervisor、BIOS、其他软件栈、以及与任何一方有关的工作负载。

协议攻击：这些攻击包括对与证明以及工作负载和数据传输相关的协议的攻击。任何可能危及证明TEE实例的攻击都可能会连带危及到工作负载或数据的安全。同样，即使证明协议没有被破坏，在工作负载和/或数据的配置或部署过程中发生的漏洞也会危及到它们的安全性。

密码攻击：密码学是一门不断发展的学科。随着时间的推移，密码和算法中的漏洞会因许多因素而被发现，包括数学上的突破、计算能力的提升和新的计算方法，如量子计算。在可能的情况下，应支持加密灵活性原则，即允许用新版本或更适合特定环境的方法替换过时的加密原语。虽然这对TEE中的软件和固件是可能的，但对TEE硬件来说是不可行的。在某些情况下，可以采用纵深防御的方式，比如虽然TEE本身不是抗量子的，但可以在TEE实例中使用抗量子密码技术。在假设这种方式能够对特定使用场景提供保护之前，需要由适合的人才对此进行仔细的考虑和评估。

基本的物理攻击：虽然针对CPU的长期的侵入式攻击被视为超出了机密计算的范畴（见下文），但其他攻击则被视为机密计算的范畴之内的攻击，包括冷DRAM提取（cold DRAM extraction）、总线和缓存监听以及将攻击设备插入端口的攻击，比如PCIe、Firewire、USB-C。

基本的上游供应链攻击：虽然在供应链中对TEE组件发起的攻击不在机密计算安全威胁模型的范畴内（见下文），但比如通过添加调试端口这种全局性的危害TEE组件的攻击属于机密计算的范畴。

机密计算联盟还认为，应尽可能为设计、实现和操作工作负载的人员提供指导，关注那些可能比其他类型的应用程序更容易受到攻击的应用程序以及生命周期管理，以减轻攻击所造成的危害。

属于机密计算范畴之外的威胁向量

通常被认为不属于机密计算范畴的威胁向量包括：

复杂的物理攻击：这些物理攻击通常需要长期和/或侵入性地访问硬件，包括芯片scraping技术和电子显微镜probes。上游硬件供应链攻击：这类攻击包括对CPU的攻击，比如发生在芯片制造阶段和密钥注入/生成阶段的攻击，但不包括针对主机系统中不直接提供TEE功能的组件的攻击。可用性攻击（比如DoS或DDoS）：在当前基于硬件的TEE的安全威胁模型中，是不解决可用性的。软件和服务提供商可以为这类攻击提供相应的缓解方案。

侧信道

背景

根据《目标》一节中所描述的威胁模型的目标，TEE能够为数据机密性提供一定程度的保证。然而，这种保证基于一些假设，其中一个关键假设是，所有者（或任何其他有权访问系统的实体）无法利用任何可利用的侧信道来推断出有关数据或执行过程的信息。在过去几年中，学术研究人员发现并证明了某些TEE设计中的漏洞，而这些漏洞允许攻击者发起迄今为止仅被认为是理论上的侧信道攻击。这些问题在其他技术（如TPM和HSM）以及其他隔离或数据保护机制中也有类似的发现。这些攻击引起了技术和安全界的广泛关注。

举例

这里给出一个椭圆曲线密码（ECC）的简化示例。ECC使用椭圆曲线的点乘运算来生成单向函数。在ECC中，将曲线上的点P乘以n会在曲线上产生一个新的点Q。ECC依赖于这样一个数学难题：即在给定P和Q的情况下，很难求出n。TEE可以使用倍点和点加（double-and-add）的方法来实现点乘运算来计算Q。用简单的术语来说，该方法每次迭代n的一个二进制位，对每个0位执行倍点运算，对每个1位执行倍点和点加运算。

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

如果攻击者对机器具有物理访问权限，则攻击者可能利用的一个侧信道是在执行上述方法的过程中准确测量TEE CPU的功耗。例如，如果TEE CPU执行倍点运算的功耗与执行点加运算的功耗不同，则攻击者可以根据power profile推测出n。此外，并非所有的侧信道攻击都需要物理访问，有些攻击可以通过度量执行攻击者用软件精心构造的操作所花的时间来实现（比如著名的Meltdown）。

如上图所示，一个倍点和点加运算的组合表示该位为1；一个后面不跟点加运算的倍点运算则表示0。利用这些信息，攻击者可以完全恢复出n的值。

还要注意的是，值为1的每个位都要比值为0的位花更长的处理时间，因此可以执行其他类型的侧信道攻击，比如攻击者可以通过精确测量运算的执行时间来确定n中0与1的比率，从而显著降低在后续使用把暴力破解来恢复n的复杂性。

侧信道允许攻击者利用TEE本身的体系结构知识来推断出关于TEE内部数据或运算的信息。上面的示例相对简单，但可以使用针对现有TEE的组合技术对TEE发起更为复杂的攻击。

缓解方式

一个自然的假设是TEE本身应该提供针对侧信道攻击的基本防御手段。但是，防止侧信道攻击是TEE制造商、第三方厂商和应用程序开发人员的共同责任。

回到上面的例子，由于在处理0与1时采用了不同的运算方法，因此攻击者可以利用功率和定时侧信道发动攻击。如果运算方法的作者在处理0时插入一个假的点加运算操作，这会导致在处理0和1时将使用相同的功耗，并且执行时间也是相同的。攻击者将没有可利用的侧信道来发动攻击。

当然，并非所有的侧信道攻击和缓解方法都像上面的示例那样简单。有些侧信道的产生源于应用程序开发人员的代码或第三方库中的算法，而有些侧信道的产生则源于运行TEE的CPU中的高速缓存实现。

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

证明（Attestation）

证明是一个过程。通过该过程，作为验证者的一方将评估潜在不可信的另一方即证明者的可信度（这些术语的使用与IETF定义的Remote Attestation Procedures Architecture保持一致）。证明的目标是通过获得真实、准确和及时的关于证明者的软件和数据状态的报告，使验证者能够相信证明者。

基于硬件的证明

基于硬件的证明方案依靠在安全环境中可信的硬件组件和相关固件所执行的证明步骤。以下是一个证明协议的工作步骤：

在验证者和证明者之间建立一条安全的通信信道；在建立了安全连接之后，验证者生成挑战值并将其发送给证明者；在收到来自验证者的挑战值后，证明者通过将挑战值发送到其信任的硬件组件并请求返回包含了其软件和数据状态的证据；可信的硬件组件在证明平台上收集证据并对证明数据和挑战值进行签名；证明者将经过签名的证据返回给验证者；验证者验证签名，并根据鉴定策略来鉴定证据，比如将已证明的平台状态与一组可信参考值进行比较，并验证已签名的证据中是否包含了之前提供的挑战值，以便说服验证者相信证据是新生成的。

上述证明过程建立起了验证者对证明者的信任，并确认了证明者在生成证据时正处于可信状态。有关其他证明协议的详细讨论，参见Remote Attestation Procedures Architecture。

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

不可伪造性：攻击者无法伪造可信的硬件组件生成的签名。吊销：如果已经危及到了可信的硬件组件的安全性，则不能再接受由该组件生成的密钥所产生的签名。

有些证明方案还提供了匿名性，即攻击者无法从签名中揭示出可信的硬件组件的身份信息。

匿名性

在基于硬件的证明方案中，能够通过可信的硬件组件相关联的密钥来唯一标识该硬件组件。攻击者可能会利用这一点来监控特定可信的硬件组件的活动。

解决匿名问题的一种做法是采用直接匿名认证（DAA）方案（在ISO/IEC 11889:2015中规定的算法）。该方案利用先进的加密原语，如零知识证明和组签名，来应对这一隐私挑战。实际上，DAA方案可以使用多种密码技术实现，包括RSA、椭圆曲线密码（ECC）、基于配对的密码（PBC）或基于晶格的密码（LBC）。

TCB恢复

Trusted Computing Base（TCB）恢复指的是在发现了TEE的TCB中存在可以修复的缺陷后进行修复，并最终能够重新建立对TEE的信任的过程。例如，如果经过签名的证据与最新的参考值不匹配，则证明过程会让验证者得出证明者是不完全可信的结论，这时就需要进行TCB修复。

TEE的TCB（通常包括不可变部分和可变部分）提供了能够创建用在证明过程中的证据的功能。如果在TCB中发现了缺陷，则证明过程本身可能被欺骗或破坏。TEE实现可以利用特殊技术，让不可变部分来保障对可变部分的更新过程。验证者可以通过识别更新后新创建的任何证据，证实确实已经进行过TCB更新，而且不会被以前有缺陷的实现所欺骗。

结论

机密计算通过使用基于硬件的可信执行环境来保护敏感数据和代码免受执行期间发生的日益普遍的威胁。这些威胁在以前虽非不可能，但相对来说是很难抵御的。例如，在经典的安全威胁模型中，系统的所有者或管理员通常被认为是可信的，而机密计算不仅将他们视为潜在的威胁，还需要保护数据免受他们的潜在危害。

结合基于硬件的证明技术，机密计算可以为数据完整性、数据机密性和代码完整性提供强大的保证。同时与TPM或同态加密等其他技术一起使用，机密计算和基于硬件的证明技术可以额外为数据和代码完整性提供一定级别的保护，以此来提高系统整体的安全水位。随着对使用中的数据加以保护的需求不断增加，开始出现越来越多新的使用场景，比如金融和/或监管行业中的多方计算场景，或边缘计算中的机器学习场景。在这些场景中，需要对参与计算的数据进行保护，以免受到来自计算环境的所有者所产生的影响。