一、简介

1.1 机密计算联盟与成员

2019年8月22日，Linux基金会宣布多家巨头企业组建“机密计算联盟”（Confidential Computing Consortium），该基金将负责对联盟活动进行监督。机密计算联盟专门针对云服务及硬件生态，致力于保护计算数据安全。联盟创始成员包括阿里巴巴、Arm、百度、谷歌云、IBM、英特尔、微软、红帽、瑞士通和腾讯，不包括全球最大的云服务器运营商亚马逊。

截至到 2023年 7 月，机密计算联盟成员状况如下：

高级会员单位：

普通会员单位：

准会员/联系会员/非正式会员：

机密计算还是比较年轻的技术领域，机密计算联盟 CCC 也刚成立 4 年

1.2 目标

机密计算联盟致力于解决人们对于数据隐私的担忧问题，寻求基于硬件和软件的技术解决方案，用以在处理计算机内存时隔离用户数据。通过机密计算方案，敏感数据能免于被暴露给其他应用程序、操作系统或者服务器租用者。

1.3 官方自定义

对于机密计算联盟，其官方网站描述如下：

机密计算联盟是一个社区，专注于一些保护使用中数据的项目，通过开放合作，加速机密计算技术的落地应用。

机密计算联盟（CCC）将硬件供应商、云提供商和软件开发人员聚集在一起，以加速可信执行环境（TEE）相关技术和标准的落地使用。

CCC 是 Linux 基金会的一个项目社区，致力于定义和加速机密计算的使用。从中我们能看到开放的管理和合作，这更有助于让我们的付出得到回报。这项付出包括来自众多成员组织的投入以及来自几个开源项目的贡献。

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

如今，数据通常在存储和通过网络传输时进行静态加密，但在内存中使用时则不加密。此外，在使用数据和代码时，保护数据和代码的能力在传统计算基础设施中受到限制。处理敏感数据（如个人身份信息（PII）、财务数据或运行状况信息）的组织需要缓解针对应用程序或系统内存中数据的机密性和完整性的威胁。

二、与 TCG 的关系

The TCG publishes standard specifications for the TPM hardware, the various profiles for TPM use-cases (e.g., PC client, mobile, IoT), their attestation evidences, and specifications covering other forms of hardware-based roots of trust (e.g., DICE hardware latches). These specifications complement the effort in the CCC that make use of TEEs that may be reliant on other hardware-based roots of trust for booting the system into a safe state where the TEE can function correctly.

TCG 发布 TPM 硬件的标准规范、TPM 用例（例如 PC 客户端、移动、IoT）的各种配置文件、其证明证据以及涵盖其他形式的基于硬件的信任根（例如 DICE 硬件）的规范。这些规范和 CCC 工作互补，CCC 使用的 TEE 会依赖其他信任根来将系统引导到TEE 可以正常运行的安全状态。

TCG 发布通用标准规范，但不生成规范的实现。CCC 是开源项目的大本营，这里相关的开源项目能够对使用 TPM 进行机密计算的组织形成优势互补。

三、与 TPM 的关系

Trusted Platform Modules (TPMs) provide basic functionality such as encryption, signing, and measuring, but are not general purpose computing environments.

TPMs can provide data integrity only for data which is recorded inside them, but not for the data that is passed to a TPM for purposes of encryption, signing, or measuring. Ensuring such integrity requires the component passing such data to the TPM to also have integrity protection, such as being implemented in ROM or a TEE.

受信任的平台模块（TPM）提供加密、签名和度量等基本功能，但不是通用计算环境。

TPM 只能为其中记录的数据提供数据完整性，但不能为传递给 TPM 加密、签名或度量的数据提供数据完整性。

确保此类完整性要求，就要求传递此类数据给 TPM 的组件具有完整性保护，例如在 ROM 或 TEE 中实现。

四、与 TEE 的关系

A TEE is a Trusted Execution Environment and is key to confidential computing

TEE 是可信执行环境，是机密计算的关键。

五、CC 当前开源项目

一个专注于开源许可项目的社区，保护使用中的数据，并通过开放式协作加速机密计算的采用，欢迎每个成员、欢迎每个符合我们标准的项目，我们是一个透明、协作的社区。

5.1 Enarx

Enarx 为可信执行环境（TEE）提供了一个平台抽象，支持创建和运行“私有，可替代，无服务器”的应用程序。

5.2 Gramine

Gramine 的一个主要用例就是为英特尔软件防护扩展（SGX）应用程序开发提供开箱即用。Gramine解决了这个问题，并增加了安全优势，Gramine可以作为其他平台上的兼容层。

5.3 Keystone

Keystone 是一个开源项目，用于基于 RISC-V 架构构建具有安全硬件飞地 Enclave 的可信执行环境（TEE），目标是建立一个安全可靠的开源安全硬件飞地，工业界和学术界的每个人都可以访问。

5.4 Occlum

Occlum 使在飞地 Enclave 内运行应用程序变得容易。它允许人们只需几个简单的命令即可在飞地内运行未经修改的程序。Occlum是开源的，可以免费使用。

5.5 Open Enclave SDK

Open Enclave SDK 是一个开源框架，允许开发人员使用单个安全区抽象构建可信执行环境（TEE）应用程序。

5.6 Veracruz

Veracruz 是一个探索隐私保护分布式系统设计的研究项目。Veracruz 使用强大的隔离技术和远程证明协议来建立一个“中立基础”，在该基础中，一组不信任的委托人之间进行协作的多方计算。

5.6 Veraison

Veraison 项目构建可用于构建证明验证服务的软件组件。

六、机密计算联盟白皮书

6.1 《机密计算通用术语》

Common-Terminology-for-Confidential-Computing.pdf (confidentialcomputing.io)

6.2 《机密计算：数据安全前沿》

Everest Group - Confidential Computing – The Next Frontier in Data Security

6.3 《机密计算技术分析 v1.3》

https://confidentialcomputing.io/wp-content/uploads/sites/10/2023/03/CCC-A-Technical-Analysis-of-Confidential-Computing-v1.3_unlocked.pdf

6.4 《机密计算：基于硬件可信执行的应用和数据》

CCC_outreach_whitepaper_updated_November_2022.pdf (confidentialcomputing.io)

七、机密计算联盟博客

7.1 机密计算：日志记录和调试（2023.6.14）

调试应用程序是开发过程的重要组成部分，我们使用的机制之一是日志记录：提供有关应用程序内部（和周围）发生的事情的额外详细信息，以帮助我们了解问题，管理错误并（当我们幸运时！）监视正常运行。因此，日志记录不仅对异常有用，而且对正常（“名义”）操作也很有用。日志条目和其他错误消息可能非常有用，但它们也可以向其他方提供信息 - 有时是您希望他们没有的信息。当您考虑机密计算时尤其如此：在您真正希望保护应用程序及其数据的机密性和完整性的环境中运行应用程序或工作负载。本文探讨了我们在设计机密计算框架、在其中运行的应用程序及其操作时需要考虑的一些问题。它部分是从Enarx项目的角度编写的，但这主要是为了提供一些具体的例子：这些例子在可能的情况下被概括了。请注意，这是一篇相当长的文章，因为它详细讨论了一些复杂的问题，并试图检查尽可能多的替代方案。

首先，让我们提醒自己关于机密计算的一个基本假设，即您不信任主机。在此上下文中，主机是在 TEE 实例中运行工作负载的计算机 - 机密计算工作负载（或简称工作负载）。当我们说我们不信任它时，我们的意思是：我们不想向主机泄露任何可能允许它（主机）推断有关正在运行的工作负载的信息的信息，无论是程序本身（和任何关联的算法）还是数据。

现在，这是一个相当高的要求，特别是考虑到目前最先进的技术不允许对工作负载的资源利用率进行强有力的保护。工作负载无法阻止主机系统使其缺乏 CPU 资源，减慢速度，甚至完全停止运行。这为主机提供了许多人为施加的定时攻击的机会，而这些攻击很难保护。事实上，围绕 I/O 还有其他类型的资源匮乏和监控，这也与我们的对话密切相关。

除此之外，主机系统还可以尝试通过监视其资源利用率来推断有关工作负载的信息，而无需任何主动干预。举个例子，假设主机注意到工作负载创建了一个到外部地址的网络套接字。它（主机）开始监视通过此套接字发送的数据，并注意到这些数据全部使用 TLS 加密。主机可能无法读取数据，但它可能能够推断出套接字打开后的特定短时间活动突发对应于加密密钥的生成。这些信息本身可能足以让主机进行被动或主动攻击，以削弱此密钥的强度。

这些都不是好消息，但让我们将我们的思维扩展到工作负载的正常操作之外，并考虑一般的调试和更具体的错误处理。为清楚起见，我们将假定一个租户在单独的计算机上具有客户端进程（被视为受信任，与主机不同），并且主机上的 TEE 实例有四个层，包括关联的工作负载。这可能不适用于所有应用或设计，但是一种有用的概括，涵盖了可能出现的大多数问题。此体系结构为云工作负载部署建模。

这些层可以这样定义：

应用程序层 – 应用程序本身，它可能会也可能不知道它在 TEE 实例中运行。对于许多用例，从主机的租户/客户端的角度来看，这就是上面定义的工作负载。
运行时层 – 运行应用程序的上下文。TEE 类型和实现之间的考虑方式可能会有很大差异，在某些情况下（例如，工作负载是完整的 VM 映像，包括应用程序和操作系统），此层和应用程序层之间可能几乎没有区别（工作负载包括两者）。然而，在许多情况下，运行时层将负责加载应用程序层 - 工作负载。
TEE 加载层 – 负责至少将运行时层以及可能的其他一些组件加载到 TEE 实例中的层。其中的某些部分可能存在于 TEE 实例之外，但其他部分（例如 VM 的 UEFI 加载程序）可能存在于其中。出于这个原因，我们可以选择在此层中将“TEE 内部”与“TEE 外部”组件分开。对于许多实现，一旦运行时启动，此层可能会消失（停止运行并从内存中删除）。
TEE 执行层 – 负责在其上实际执行运行时并与主机通信的层。与 TEE 加载层一样，这可能存在于两个部分 – 一个在 TEE 实例内，另一个在 TEE 实例外部（再次，“TEE 内部”和“TEE 外部”。

此处显示了相对生命周期的示例。

应用程序层通常通过数据平面与 TEE 外部的其他应用程序组件进行通信，包括租户控制下的组件，其中一些组件可能位于客户端计算机上。从应用程序的角度来看，其中一些将被视为受信任的，并且这些至少通常需要加密的通信通道，以便主机无法窥探数据（其他可能也需要加密）。这些通道的确切设置方式因实现而异，但应用程序级错误和日志记录应使用这些通信通道，因为它们与应用程序的操作相关。这是最简单的情况，只要外部组件的通道可用即可。无论出于何种原因，如果它们不再可用，应用程序都可以选择存储日志记录信息以供以后传输（如果可能）或将可能的错误状态传达给运行时层。应用程序还可以选择将其他运行时错误或它认为与运行时相关或可能相关的应用程序错误传达给运行时层。

运行时层可能可以访问应用程序层没有的外部各方的通信通道 - 事实上，如果它正在管理运行时层的加载和执行，这可以被视为控制平面。由于运行时层负责应用程序的执行，因此需要保护它免受主机的影响，并且它完全驻留在 TEE 实例中。它还可以访问与应用程序层相关的信息（可能包括应用程序直接传递给它的日志记录和错误信息），这些信息也应受到主机的保护（在机密性和完整性方面），因此它与外部各方的任何通信都必须加密。可能会有一种诱惑，认为运行时层应该向主机报告错误，但这很危险。很难控制将传递哪些信息：不仅是主要信息，还有推断信息。当然，运行时层和主机之间确实需要通信才能允许执行 - 无论是系统调用还是其他机制 - 但在此处描述的模型中，这是由TEE执行层处理的。

更多参考机密计算：日志记录和调试 – 机密计算联盟 (confidentialcomputing.io)

八、机密计算趋势

2022 年 IEEE 技术预测中，机密计算是数据安全领域唯一入选的技术：