PDF为什么我应该信任你的代码？
可信计算使用户能够验证在 TEE 中运行的代码，但用户还需要证据证明这些代码是值得信任的。
Antoine Delignat-Lavaud、Cédric Fournet、Kapil Vaswani、Sylvan Clebsch、Maik Riechert、Manuel Costa、Mark Russinovich
既然通信和存储默认情况下都已加密，可信计算 (CC) 是使云更安全的下一个重要步骤：通过在硬件隔离的可信执行环境 (TEE) 内终止与可信服务的网络连接，并使用只有处理器才能访问的密钥加密其内存，就有可能保护使用中的数据，并将云托管基础设施视为对手的一部分，就像今天对待网络和存储基础设施一样。
例如，考虑一个 AI 云服务，它使用大型语言模型与用户就一系列敏感主题（如健康、财务和政治）进行聊天。许多用户担心这些服务可能会存储他们的对话并将其用于恶意目的。能否利用 CC 提供强大的技术保证，确保对话的私密性？
解决这个难题的关键在于远程证明：硬件可以验证初始 TEE 配置，包括通过其加密摘要识别 TEE 中的代码，并向远程方证明他们的连接在硬件隔离的 TEE 内部终止（而不是，比如说，软件模拟）。这至关重要，因为用户获得的实际保证取决于硬件隔离和 TEE 内部处理他们数据的代码。但这仍然给用户留下了一个艰难的决定：他们应该信任这段代码吗？
一个不信任任何人的用户原则上可以从软件提供商处下载所有源代码和依赖项（包括所有构建脚本和工具18）；仔细审查它们以确保没有后门或漏洞；然后为服务重新编译代码，重新哈希其二进制文件，并将其与 TEE 证明的摘要进行匹配。这需要时间和专业知识，并且如果构建不可重现或依赖于并非所有用户都可用的特定版本的库和工具，则可能会失败。这也与现代软件工程相悖，现代软件工程依赖于云平台服务（如容器平台、键值存储、密钥管理系统等）来实现可扩展性和竞争力，而不是从头开始构建一切。
仔细检查后，实际上这对于两个原因来说是不可能的。首先，也是最重要的一点，它对安全审查期望过高：代码、协议甚至标准中的严重漏洞在最初部署多年后仍然被发现；理解代码的作用，或者仅仅确保它不会造成危害，从根本上来说是困难的。更复杂的是，云服务更新频繁（每周更新很常见），有时为了快速部署安全补丁而匆忙进行。因此，我们必须为未来漏洞披露做好准备，确保由此产生的补丁能够快速传播和部署；在所有用户完成代码审查后再部署这些补丁是不现实的。
因此，为了使 CC 像 HTTPS 成为网络默认协议一样在云中普及，需要一种不同的、更灵活的方法。尽管不能保证所有恶意代码行为都会被预先发现，但可以保证精确的可审计性：任何怀疑可信服务破坏了信任的人都应该能够审计其证明代码库的任何部分，包括所有更新、依赖项、策略和工具。
为了实现这一目标，我们提出了一种架构来跟踪代码出处并追究代码提供商的责任。其核心是一个新的代码透明服务 (CTS)，它维护一个公共的、仅追加的账本，记录为可信服务部署的所有代码。在注册新代码之前，CTS 会自动应用策略来强制执行代码完整性属性。例如，它可以强制使用授权发布的库依赖项，并验证代码是否已使用特定的运行时检查进行编译并由特定的工具进行分析。这些预先检查可以防止常见的供应链攻击。
进一步的策略可以确保记录足够的证据以供审计：例如，要求将构建工件托管在软件提供商控制之外，并要求可重现或经过证明的构建。通过强制执行出处和完整性，CTS 为 CC 软件供应链提供了独立的信任根。
当用户连接到可信服务时，他们现在可以验证其证明代码是否已成功由 CTS 注册，因此符合策略并可审计。至关重要的是，用户不必在代码部署之前对其进行审计，尽管这是支持的，并且可能是一些用户的要求。审计需要大量资源；因此，预计只有少数组织会执行审计。然而，审计使所有用户受益，因为他们都共享 CTS 账本。
我们认为，代码透明性通过使恶意行为留下不可磨灭的痕迹，从而有力地威慑恶意行为，同时提供处理云规模部署所需的敏捷性。这种方法让人联想到证书透明性9，它帮助用户判断 Web 证书是否值得信任。通过吸取 HTTPS 推广的经验教训，我们希望 CC 将在不到十年的时间内被大多数服务采用。
可信计算基础知识
有关 CC 的介绍，请参阅 Russinovich 等人 2021 年的文章“迈向可信云计算”15。以下是对共同实现 CC 的基础知识的解释。
隔离和证明
CC 利用新型 CPU 功能来创建 TEE，将给定任务的代码和数据与系统的其余部分隔离，包括特权组件，如主机操作系统和虚拟机监控程序。
TEE 代码可以请求硬件证明给定的消息（例如公钥），以及其二进制镜像和配置的摘要，这些摘要是在创建 TEE 时测量的。证明使用 CPU 特有的密钥（存储在硬件熔丝中）签名，并由平台公钥证书（由硬件供应商认可）支持。通过验证此签名，用户可以在信任 TEE 处理私有数据之前验证 TEE 的代码和硬件平台。
硬件支持
CPU 以多种外形尺寸支持 CC：Intel SGX 通过扩展进程隔离提供子进程 TEE（也称为飞地）；AMD SEV-SNP、Intel TDX 和 ARM CCA 通过加强 VM 隔离提供基于 VM 的 TEE。CC 也被高性能加速器（包括 Nvidia GPU）支持。
软件支持
TEE 涉及可用性和安全性之间的实际权衡，这取决于其证明的可信计算基 (TCB) 的大小和复杂性。虽然飞地促进了最小的软件 TCB，但它们通常需要以相当大的工程成本进行代码重构。基于 VM 的隔离既适用于最小的类飞地 VM，也适用于成熟的传统 VM；后者提供更好的可用性，但安全性较低，因为传统 VM 通常包括一个大型的、动态的软件 TCB，它依赖于外部代理和服务。
可信容器
现代云原生服务通常依赖于容器和编排服务（如 Kubernetes）进行部署、维护和扩展。它们对于 CC 很方便，但它们使证明变得复杂，因为一些可信组件（如访客操作系统内核、容器运行时和辅助容器）由云服务提供商 (CSP) 管理，而应用程序容器由租户拥有。以下示例服务假定在基于 VM 的 TEE 中的可信容器内运行，例如 Microsoft11 和 Google6 在云中提供的那些。
示例可信 AI 云服务
让我们详细说明示例服务并介绍所涉及的主要参与方（见图 1）
• 模型提供商 研究、开发和训练机器学习模型。他们希望将其模型货币化，但担心如果他们将其交给其他人本地运行，则可能会被盗版或泄露私有训练数据。相反，他们选择在云中提供对模型的查询访问。
• 应用提供商 在其服务中利用此模型。他们希望严格控制服务，以便向用户保证他们的对话是私密的（例如，不会被重用于训练或广告，甚至不会暴露给第三方）。
• 隐私监管机构 希望确保用户的对话仅用于服务的既定目的进行处理，而不会被服务提供商保留或重用。
• 审计员 提供对服务的独立安全和隐私审查。
为了解决他们共同的担忧，这些参与方同意在公有云中运行的 TEE 内的可信容器中部署服务。
• 提供商就服务的代码达成一致，使用信誉良好的开源项目并记录其依赖项。这可能包括来自模型提供商、服务提供商、CSP 和第三方开发人员的代码。他们审查并授权生成的容器配置。正如稍后解释的那样，这涉及到签署和注册关于服务的声明。
• CSP 提供 VM TEE，加载并证明此配置。
• 模型提供商在向这些 TEE 发布模型解密密钥之前验证其证明。
代码透明服务
假设用户想用关于个人健康的对话来信任这个示例 AI 服务。当用户的客户端打开与 TEE 的连接时，在发送任何个人数据之前，应向客户端提供证据，证明用于处理对话的代码是为服务提供的、符合策略且可审计的。为了实现这一目标，该架构要求所有参与方发布关于受信任运行可信服务的代码的最新记录。
用户之所以信任这些服务，是因为证据提供了追究任何不良行为者责任的方法：如果怀疑有任何不当行为，永久性痕迹使审计员能够调查谁应负责。此证据可能包括信息，例如最新的已知良好代码和配置；代码出处，包括源项目、二进制包和软件工具链的版本；以及独立方的审查和认可。
架构的核心新组件（在图 2 中）是一个经过证明的 CTS，它维护一个公共的、仅追加的、可验证的账本，其中包含其他各方签署的声明，并生成声明注册证明，称为收据。
发布和注册声明
声明是关于可信服务的陈述；一方通过签署声明并在 CTS 处注册来发布声明。模型提供商可以发布声明，记录其模型和随附软件的新版本（例如，记录其二进制哈希和元数据，如源代码标签、时间戳和版本）；应用程序服务提供商可以类似地为其服务器的每个版本发布声明；CSP 可以为其容器运行时的每个新版本发布声明。更一般地，这些也可以发布声明：CPU 制造商为其固件；持续集成服务为其构建报告；以及安全专家发布其审查报告。
声明也可能包含策略。例如，代码提供商可以发布可重现构建的配置；模型提供商可以发布关于其支持的服务器配置的要求；服务提供商可以记录其策略以认可未来的代码更新。一旦注册，这些策略可能会被一些客户端应用（例如，模型提供商在发布模型密钥之前，或用户在发送请求之前），或者由 CTS 在注册其他声明之前预先强制执行。
图 2 说明了部署示例服务的更新二进制镜像的工作流程，该工作流程由来自应用程序服务提供商的声明支持。
1. 服务提供商审查更新，然后签署声明，认可更新后的二进制镜像的哈希值。（审查可能涉及支持更新的其他声明，这些声明由供应链上游的其他参与者较早注册，并由服务提供商在签署之前验证。）
2. 它调用 CTS 以注册此新声明；CTS 应用其注册策略，然后将声明附加到其透明度账本，并返回收据作为注册证明。
3. 服务提供商将二进制镜像及其声明和收据上传到 CSP。
4. CSP 创建一个 TEE，加载并证明新的二进制镜像及其传输层安全性 (TLS) 密钥。
5. 客户端使用 TLS 连接到此 TEE。
6. 客户端接收并验证平台证书、将新的二进制哈希绑定到服务器 TLS 密钥的证明报告、服务提供商签署的具有相同哈希的声明以及 CTS 签署的收据。
在注册声明之前，CTS 应用由其账本内容确定的注册策略。一些注册策略是通用的，例如，确保声明格式良好、其发布者被正确识别以及其签名有效。更高级的策略可以强制执行一系列声明的一致性，甚至可以自动执行否则将由人工审计员执行的检查，通过验证来自受信任执行这些检查的 TEE 的辅助声明和证明报告。
收据：注册和新鲜度的加密证明
注册确保声明在全球范围内可见且符合策略，并且不能被撤回或篡改。在注册结束时，CTS 生成、签署并返回收据，使任何人都能验证声明在给定的时间和账本中的位置被注册。与发布者签名非常相似，收据可以附加到声明并随其分发，并且其验证是本地操作，不涉及与 CTS 的通信。
收据是使用整个 CTS 账本上的 Merkle 树实现的。对于给定的声明，收据由 CTS 签署的树根组成，其中包含中间哈希，用于从记录树中此声明的叶子重新计算树根。CTS 可以通过增量计算 Merkle 树并仅对其注册的每批声明的根签名一次来高效地生成收据。
验证也很高效：它需要本地重新计算根并验证其签名。为了支持只能验证纯签名的系统，例如在启动时验证其固件的硬件设备，可以依赖旧版签名服务，该服务在生成签名之前验证收据。
收据还提供了追究 CTS 本身责任的证据，因为每个人都可以重放账本来确认给定的收据是否被正确发布，或者责怪透明服务。例如，在 CTS 分叉或损坏账本的情况下，可以将签署的收据作为不当行为的证据提交。
收据可以选择用于验证声明是否是最新的。这对于防止回滚攻击非常重要，在回滚攻击中，恶意 CSP 会部署过时的易受攻击的服务版本。检查声明新鲜度的设计空间很大；本文简要描述了两种方法。
一种方法是发布具有到期时间的声明，要求定期更新声明。另一种方法是提供收据，其中包含证明在生成收据时（可能在声明注册后很久），相应的声明尚未被账本中更近期的声明取代。这对于确保声明是一系列声明中的最新声明很有用。例如，我们服务容器的收据可以证明该声明是在三个月前由服务提供商注册的，并且在一天前 CTS 生成此收据时仍然是该服务的最新声明。通过每天获取最新的收据并将其附加到声明中，CSP 因此使用户能够验证他们正在使用该服务的最新代码，延迟最多为一天。
真实性和透明性
我们的方法提供了两个完整性属性：真实性，意味着每个声明都必须由发布它的方的身份密钥签名；以及透明性，意味着每个声明都必须在 CTS 仅追加账本中注册，并且必须在该时间通过其注册策略。
仅凭声明的真实性并不能保证发布者是诚实的。同样，透明性不能阻止不诚实或被入侵的发布者，但它会追究他们的责任。例如，审计员可以访问账本并独立审查服务提供商认可的所有二进制镜像的完整声明列表。因此，信誉良好的发布者有动机在签名和注册声明之前仔细审查其声明。同样，信誉良好的 CTS 有动机安全地管理其账本，因为审计员可以查明任何不一致之处。
通过维护注册声明的完整记录，CTS 还可以防御高级定向攻击，这些攻击可能涉及不良行为者发布专门制作的声明来欺骗某些用户。例如，假设服务提供商或 CSP（可能受到地方当局的胁迫）试图通过将用户的请求定向到运行恶意服务变体的 TEE 来窃听用户，该服务变体会静默地将用户输入转发给第三方。此恶意代码甚至可能被呈现为合法的安全更新，既由 TEE 证明，又由提供商签署的声明支持。这种特权攻击用户很难检测到，因为服务请求和响应未更改。
但是，如果用户要求注册收据并验证它，则恶意声明必须已公开注册，因此审计员在审查服务更新历史记录时可以随时发现它。然后，审计员有签署的证据来指责服务提供商。这在服务性和安全性之间取得了良好的平衡：不良行为者因最终会根据注册证据被抓住的风险而被威慑，同时，这支持云的敏捷性和规模，因为用户和审计员无需在部署之前审计代码更新。
这种代码透明性的概念受到证书透明性9 以及许多相关努力的启发，这些努力旨在维护由半信任机构生成并由可能不以其他方式相互交互的多个方使用的已签名声明的独立、一致的记录。证书透明性已被证明在迫使 CA（证书颁发机构）遵守 CA/浏览器论坛准则或面临从根程序中删除的风险（这确实发生了）方面是有效的，并且已扩展到超过 100 亿个记录证书。透明度日志也已成功应用于，例如，公钥记录10、签名委托12、供应链策略8、软件包19、固件更新1、分布式构建13 和多方计算7。
威胁分析
正如阿加莎·克里斯蒂小说中一样，参与此示例可信服务的任何一方都可能是恶意的。让我们分析服务妥协的由此产生的风险。
CC 允许将重点放在运行服务的 TEE 上，而将托管基础设施的其余部分视为不受信任的。特别是，CSP 仅因其贡献给 TEE 的代码（例如服务容器的实用程序 VM）而受信任，这些代码记录在 CSP 发布的声明中，并受代码证明和透明性的约束。CSP 在其他方面不受信任；它控制 TEE 的创建及其不受信任的网络和存储；因此，它可能很容易降低可用性和服务质量。例如，它也可能延迟或阻止关键服务更新的部署。但它不能破坏 TEE 代码和数据的完整性或机密性，因此（由于所有客户端通信都受到 TLS 保护）也不能破坏其请求和响应的完整性和机密性。
因此，我们关注 TEE 妥协的潜在原因和后果。虽然 TEE 显着提高了平台安全性，但它们仍然容易受到超出其威胁模型的攻击（例如高级物理攻击）以及其设计和实现中的缺陷的影响。虽然特定于平台的讨论超出了范围，但我们区分了两种情况
• 损坏的 TEE 硬件平台（例如，特定的 CPU 甚至整个 CPU 系列）可能会发布具有任意内容的证明报告。这可能是由物理攻击、严重固件漏洞或恶意平台证书引起的。最严重的攻击可能会启用具有任意代码身份的恶意证明报告。可以通过强制执行限制性证明验证策略（例如，通过将位于每个云数据中心的 CPU 列入白名单并将有缺陷的固件版本列入黑名单）来缓解这些攻击。透明度日志也可能通过追究恶意平台提供商对其固件和平台证书的责任，并激励他们快速修补缺陷，从而帮助检测和威慑恶意平台提供商。
• 损坏的 TEE 实例可能会滥用证明报告——例如，通过使用其证明密钥签署任意语句，而无法修改其证明的代码身份和初始配置。由于 TEE 内部运行的软件的多样性和复杂性，预计这种情况是最常见的。常见原因包括在 TEE 内运行的特洛伊木马代码、导致密钥泄露的微架构侧信道攻击，或者仅仅是导致缓冲区溢出和权限提升的错误代码。
我们进一步关注第二种情况，在这种情况下，至关重要的是，TEE 妥协可以追溯到其证明的代码。还假定任何依赖方都会在信任 TEE 之前验证此代码的透明度收据。这确保了 CTS 必须已注册（错误地）认可此代码的声明，因此，妥协可以追溯到声明发布者。
这里的主要目标是在所有妥协场景中提供可审计性：应该可以根据 CTS 账本中记录的声明或——在账本不可用或已被篡改的情况下——根据其他各方保留的声明和收据来确定哪个签名方有过错。
让我们从不良声明发布者（假设 CTS 是受信任的）开始，然后讨论涉及 CTS 的潜在攻击。
不良声明发布者
不良发布者可能会签署具有任意负载的声明。这可能是由诚实的错误（如编程错误）、恶意意图（如插入后门）或针对发布者的攻击（如泄露的签名密钥）引起的。在所有情况下，一旦声明被注册，审计就可以根据不良负载来指责发布者。在许多情况下，其他声明可能会提供更精细的图像（例如，识别提交危险代码的开发人员和将其包含在发布中的软件经理）。
CTS 攻击
作为可信服务，CTS 受上述所有潜在 TEE 攻击（和缓解措施）的影响。虽然我们希望 CTS 代码库和治理能够得到仔细审查和审计，但仍需要考虑其妥协的影响。
运行 CTS 的损坏的 TEE 可能会注册不符合其注册策略的声明（例如，发布者身份和签名未验证的声明），并且可能会发布与其账本不匹配的收据（例如，未注册或过时的声明）。为了缓解这些攻击，CTS 代码库及其治理记录在其账本中的一系列声明中。如果可以访问账本，审计员可以详细审查它们；它还可以重放账本中记录的注册以检测任何错误或不一致之处；同样，它可以检查一系列声明和收据是否与账本一致，否则会指责 CTS。
CSP 也可能降低 CTS 的可用性。特别是，它可能会阻止访问账本，从而限制审计范围。CSP 将因这种中断而受到指责，这可以通过在不同的信任域中复制和存档账本来缓解。一般来说，审计取决于声明中记录的质量。
代码透明性策略可以帮助确保记录足够详细。精确的审计也可能取决于其他服务持有的附加信息。在该示例中，我们使用 CTS 通过记录其标签和加密摘要来跟踪源代码发布，但仍然依赖于 git 存储库的可用性来跟踪软件漏洞到各个提交。
透明性策略
回想一下，CTS 在生成收据之前强制执行预定义的注册策略；这可以预先防止一些错误和攻击。CTS 还使任何审计策略都可以在以后应用，以检测和威慑（但不能阻止）更复杂或更不可预测的攻击。以下是对几种代码透明性策略以及 CTS、审计员和辅助 TEE 如何强制执行这些策略的讨论。
作为基本注册策略，CTS 始终确保声明格式良好，并包括发布者的长期标识符、密钥信息和签名；它验证密钥在该时间对发布者有效，并且签名对声明正确。这对于保护仅验证收据的用户非常重要。
CTS 可以应用其他注册策略，如两个用例所示
• 为了注册记录给定开源项目的源代码发布的声明——例如，记录项目 URL、git 提交哈希和发布标签——策略可以验证发布是否在项目的主要稳定分支上，标签是否与先前声明中的标签一致（例如，强制执行语义版本控制或增加安全版本号），代码存储库配置正确（例如，要求双因素身份验证），每个中间提交都格式良好且已签名，并且发布本身由授权的项目经理签名。该策略还可以验证辅助声明（例如，项目子模块或依赖项的源代码声明）以及代码扫描或代码验证服务生成的声明。
• 为了注册记录成功构建步骤的声明——例如，记录其源代码依赖项、构建环境和生成的二进制包或二进制镜像——策略可以验证声明是否由受信任的构建服务发布，并且还可以验证每个这些输入的声明。虽然不是绝对必要，但要求声明中指定的构建工具是确定性的，这大大减少了对构建服务的信任需求（因为审计员可以重建并在构建服务产生不同二进制文件时指责构建服务）。该策略可能要求构建在 TEE 中的指定构建容器中运行，该 TEE 发布构建声明和支持性证明报告，从而显着提高构建服务的信任度和可审计性。
这些示例策略涉及记录存储在账本外部的材料（如源树、容器和二进制文件）的位置和摘要的声明。由于精确的审计取决于这些材料，因此注册策略还可以检查这些材料是否存储在信誉良好的存储（如公共源代码存储库或容器注册表）中，并为审计员提供足够的复制和读取访问权限（例如，使用不同的云或信任域）。这对于即使某些代码不是公开可用的，也能确保透明度尤为重要。
许多策略过于复杂，无法由 CTS 直接强制执行，而不会使其自身的可信代码库膨胀：CTS 应该能够验证声明性策略及其加密材料（包括签名、声明、收据和证明报告），但不能运行大型可编程构建任务。对于此类高级用例，CTS 可以改为使用注册策略，该策略利用 CC 将复杂任务的执行委托给辅助 TEE。我们实施了这种方法来自动构建和注册示例 AI 服务和引导 CTS 本身的证明代码。
主要思想是让发布者委托他们通常在发布其声明之前自行执行的任务（例如，发布其软件的新源代码版本）或使用新发布的源代码构建二进制镜像的任务。
为此，这些方改为发布和签署委托策略声明，该声明指定委托的任务、他们信任运行任务的 TEE 配置（例如，要使用的容器化构建环境）、要使用的证明验证策略以及 TEE 在任务完成后要发布的生成声明的模板。
当 CSP 需要运行任务时——例如，在发布安全补丁后更新服务——它会根据为此任务注册的委托策略中指定的配置创建 TEE。此 TEE 创建一个临时签名密钥；生成一个证明报告，将相应的公钥绑定到其代码身份；运行任务；并且（假设任务成功完成）为其刚刚编译的更新后的二进制镜像发布一个声明，以及其自身的证明报告和构建日志；使用其临时证明密钥签署声明；最后在 CTS 处注册声明。
当 TEE 发出声明时，CTS 会根据任务最新的注册委托策略验证其证明报告和经过证明的配置，如果所有验证都成功，则注册委托声明。
一旦委托策略声明由“人工”方编写和注册后，整个过程就可以由不受信任的方（如 CSP）自动化完成；然而，只有当结果二进制镜像通过先前注册的策略时，才会注册该镜像的声明。因此，验证结果委托声明的用户在使用其服务之前可以得到保证，即其代码符合透明服务处注册的所有策略。
CTS 的实现
最后，让我们概述一下正在进行的标准化工作以及我们基于声明格式和协议的 RFC 草案以及保密联盟框架 (CCF4) 的 CTS 实现，CCF 提供了一个仅附加、可验证、防篡改的声明账本，由 SGX enclave 执行。这使我们能够通过证明、透明性和审计来引导对 CTS 自身代码库的信任。
标准化的声明格式
为了被软件提供商采用，代码透明性需要就通用格式和协议达成广泛共识，以便发布、注册和验证声明。指定这些格式和协议并确保其互操作性是 IETF SCITT（供应链完整性、透明性和信任）工作组2的任务。
SCITT 为沿着供应链交换透明声明提供通用支持；它指定了一个透明服务，该服务记录声明，但不解释其有效载荷（这些有效载荷很重要，但通常特定于每个供应链）。独立的标准化工作旨在为常见的声明有效载荷提供标准格式，例如 SBOM（软件物料清单）。5,17
SCITT 将声明表示为 CBOR（简洁二进制对象表示）编码的签名信封，其中包含必须被所有各方理解的特定标头。因此，标准化的标头记录了声明发布者的长期身份，以 W3C DID（去中心化标识符）3（例如，服务提供商）和声明的目的（例如，授权给定服务的二进制镜像）表示。虽然 SCITT 透明服务主要关注这些标头，但签署声明的发布者和基于声明做出信任决定的验证者也应解析并理解其有效载荷。例如，我们将 SCITT 应用于 CC 涉及不同类型的声明，用于源代码发布、构建策略、容器镜像、容器配置和 SGX 二进制镜像。
经过证明的 CTS 实现
我们的实现结合了 TEE（具有透明、经过证明且相对较小的 TCB）和来自 CCF 的去中心化账本技术。4 一份技术报告描述了其设计和评估。20
CCF 在多个 TEE 之间运行共识协议，以确保账本持久存在，并且服务可以承受单个 TEE 故障；它还通过允许成员联盟对重要的治理决策（例如，对其执行的安全策略的更改）进行投票来限制对 CSP 的信任。
我们的 CTS 原型16是一个部署在 Azure DCsv3 系列 VM 中的 SGX enclave 内的 CCF 应用程序。应用程序代码由约 3,500 行 C++ 代码和约 3,000 行用于客户端工具的 Python 代码组成，特别是用于格式化、签名和注册声明的命令行工具。该服务公开了用于注册和收据的 REST（具象状态传输）端点。它支持以 Typescript 编程并在特定声明中注册的灵活注册策略。它可以每秒注册 1,550 个声明，并且每个线程每秒可以生成 5,100 个收据。
CTS 依靠透明声明和 CCF 治理相结合来保护其自身的代码更新。一旦获得 CTS 运营商发布的声明的授权，由 CTS 注册，并通过其治理代码更新策略（以 Typescript 编写并记录在账本中）验证，则共同实施该服务的 TEE 节点可以逐步替换为运行其更新代码的新 TEE 节点，准备好向 CTS 客户端提供最新的证明报告和透明性声明。正如先前关于策略的讨论中概述的那样，对于不涉及策略更改的构建和部署更新，该过程可以完全自动化。
我们通过使用我们的 CTS 原型自动记录一系列现有开源项目（包括 OpenSSL、Triton、21 Open Enclave、14 CCF4 和 CTS 自身16）的透明更新和经过证明的构建历史来评估我们的方法。它们的构建过程复杂，并且涉及大型 TEE（具有 64GB RAM 的 32 核 SEV-SNP VM），需要下载数百个软件包，然后才能最终签名和注册结果二进制镜像的声明。另一方面，它们只需要修改几行 Dockerfile 即可在经过证明的容器中运行它们。
总结
CC 使用户可以验证在 TEE 中运行的代码，但无法确定其是否值得信赖。这是一个难题，因为保密服务的 TCB 可能很大、很复杂、经常更新，并且容易受到其软件供应链上的攻击。
我们已经展示了如何跟踪任何有助于保密服务 TCB 的代码和策略，并在其软件提供商中具有精确定义、有限且透明的信任假设。这并没有完全解决问题，但确实使其变得易于处理，使 CC 供应链上的所有各方都对其依赖的代码获得更多信任，并且在发生攻击时，可以根据透明的签名证据追究不良行为者的责任。
我们的代码透明服务可以使用强大的 CC 安全措施来自动化该过程，但其在实践中的成功将取决于软件开发人员、服务提供商、云运营商和安全专家技术社区的广泛采用。这是 IETF 和其他地方正在进行的更大规模标准化工作的一部分。
从长远来看，回顾 SSL（安全套接字层）的蹒跚起步的日子很有趣，当时参与者表达了许多与今天讨论的类似担忧：HTTPS/TEE 会使我的网站运行速度变慢或更难操作吗？如果我的签名密钥泄露了怎么办？谁制定认证/证明策略并对其进行审计？谁负责？如何识别不良行为者？
最终，新的开放标准和协议与用户隐私倡导团体的压力相结合，逐渐推动了通信安全的进步。CC 可能会遵循相同的道路。
参考文献
1. Al-Bassam, M., Meiklejohn, S. 2018. Contour: a practical system for binary transparency. In Data Privacy Management, Cryptocurrencies and Blockchain Technology, 94–110. Springer; https://link.springer.com/chapter/10.1007/978-3-030-00305-0_8.
2. Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., Lasker, S. 2022. An architecture for trustworthy and transparent digital supply chains. IETF SCITT Working Group; https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/.
3. Brunner, C., Gallersdörfer, U., Knirsch, F., Engel, D., Matthes, F. 2020. DID and VC: untangling decentralized identifiers and verifiable credentials for the web of trust. In Proceedings of the Third International Conference on Blockchain Technology and Applications, 61–66; https://dl.acm.org/doi/abs/10.1145/3446983.3446992.
4. Confidential Consortium Framework. Microsoft. GitHub; https://github.com/microsoft/CCF.
5. CycloneDX SBOM standard. 2023. CycloneDX; https://cyclonedx.org.
6. Damlaj, I., Saboori, A. 2020. A deeper dive into confidential GKE nodes. Google; https://cloud.google.com/blog/products/identity-security/confidential-gke-nodes-now-available.
7. Dauterman, E., Fang, V., Crooks, N., Popa, R. A. 2022. Reflections on trusting distributed trust. In Proceedings of the 21st Workshop on Hot Topics in Networks (HotNets), 38–45; https://dl.acm.org/doi/10.1145/3563766.3564089.
8. Ferraiuolo, A., Behjati, R., Santoro, T. Laurie, B. 2022. Policy transparency: authorization logic meets general transparency to prove software supply chain integrity. In Proceedings of the Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses, 3–13; https://dl.acm.org/doi/10.1145/3560835.3564549.
9. Laurie, B. 2014. Certificate transparency. Communications of the 57(10), 40–46; https://dl.acm.org/doi/abs/10.1145/2659897.
10 Melara, M. S., Blankstein, A., Bonneau, J., Felten, E. W., Freedman, M. J. 2015. CONIKS: bringing key transparency to end users. In Proceedings of the 24th Usenix Security Symposium; https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-melara.pdf.
11. Microsoft. 2023. Confidential containers on Azure container instances (ACI); https://learn.microsoft.com/en-us/azure/container-instances/container-instances-confidential-overview.
12. Newman, Z., Meyers, J. S., Torres-Arias, S. 2022. Sigstore: software signing for everybody. In Proceedings of the SIGSAC Conference on Computer and Communications Security, 2353–2367; https://dl.acm.org/doi/10.1145/3548606.3560596.
13. Nikitin, K., Kokoris-Kogias, E., Jovanovic, P. Gailly, N., Gasser, L., Khoffi, I., Cappos, J., Ford, B. 2017. CHAINIAC: proactive software-update transparency via collectively signed skipchains and verified build. 26th Usenix Security Symposium; https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/nikitin.
14. Open Enclave SDK. GitHub; https://github.com/openenclave/openenclave.
15. Russinovich, M., Costa, M. Fournet, C. Chisnall, D., Delignat-Lavaud, A., Clebsch, S., Vaswani, K., Bhatia, V. 2021. Toward confidential cloud computing. Communications of the 64(8), 54–61; https://cacm.acm.org/magazines/2021/6/252824-toward-confidential-cloud-computing/abstract.
16. SCITT service prototype based on CCF. 2023. Microsoft. GitHub; https://github.com/microsoft/scitt-ccf-ledger.
17. Stewart, K., Odence, P. Rockett, E. 2010. Software package data exchange (SPDX) specification. International Free and Open Source Software Law Review 2(2), 191–196; https://www.jolts.world/index.php/jolts/article/view/45.
18. Thompson, K. 1984. Reflections on trusting trust. Communications of the 27(8), 761–763; https://dl.acm.org/doi/10.1145/358198.358210.
19. Torres-Arias, S., Afzali, H., Kuppusamy, T. K., Curtmola, R., Cappos, J. 2019. in-toto: providing farm-to-table guarantees for bits and bytes. In Proceedings of the 28th Usenix Security Symposium; https://www.usenix.org/conference/usenixsecurity19/presentation/torres-arias.
20. Transparent code updates for confidential computing. Draft technical report. https://www.microsoft.com/research/group/azure-research/.
21. Triton inference server. GitHub; https://github.com/triton-inference-server.
Antoine Delignat-Lavaud 是微软 Azure 研究院的首席研究员，致力于研究基于硬件安全保证的保密云服务的协议和系统。
Cédric Fournet 是微软 Azure 研究院的高级首席研究经理。他对安全性、隐私、密码学、分布式编程和形式化验证系统感兴趣。
Kapil Vaswani 是微软 Azure 研究院的高级首席研究员。他的研究重点是构建安全、稳健和透明的系统。他在使用可信硬件和新型可信硬件的安全数据库方面取得了开创性成果。
Sylvan Clebsch 是微软 Azure 研究院的高级首席研究工程师。他的工作包括保密联盟框架、Verona 和 Pony 编程语言。
Maik Riechert 是微软研究院的高级研究工程师。他对供应链安全、隐私和机器学习感兴趣。
Manuel Costa 是微软的合伙研究经理，领导 Azure 研究院。他对推进安全性、隐私、操作系统和编程语言的最新技术水平感兴趣。
Mark Russinovich 是微软 Azure 的首席技术官，负责领导微软云计算平台的技术战略和架构。
版权 © 2023 归所有者/作者所有。出版权已授权给 。
最初发表于 Queue vol. 21, no. 4—
在 数字图书馆 中评论本文
更多相关文章
Jinnan Guo, Peter Pietzuch, Andrew Paverd, Kapil Vaswani - 使用保密联邦学习的可信赖人工智能
安全性、隐私性、问责制、透明性和公平性原则是现代人工智能法规的基石。经典的 FL 设计非常强调安全性与隐私性，但却牺牲了透明性和问责制。CFL 通过将 FL 与 TEE 和承诺相结合，谨慎地弥补了这一差距。此外，CFL 还带来了其他理想的安全属性，例如基于代码的访问控制、模型机密性以及推理过程中模型的保护。保密计算的最新进展（如保密容器和保密 GPU）意味着现有的 FL 框架可以无缝扩展以支持 CFL，且开销很低。
Raluca Ada Popa - 保密计算还是密码学计算？
通过 MPC/同态加密与硬件 enclave 进行安全计算，在部署、安全性和性能方面存在权衡。关于性能，您想到的工作负载非常重要。对于简单的求和、低阶多项式或简单的机器学习任务等简单工作负载，这两种方法都可以在实践中使用，但对于复杂的计算（如复杂的 SQL 分析或训练大型机器学习模型），目前只有硬件 enclave 方法在许多实际部署场景中足够实用。
Matthew A. Johnson, Stavros Volos, Ken Gordon, Sean T. Allen, Christoph M. Wintersteiger, Sylvan Clebsch, John Starks, Manuel Costa - 保密容器组
此处展示的实验表明，Parma（在 Azure 容器实例上驱动保密容器的架构）增加的额外性能开销不到底层 TEE 增加开销的百分之一。重要的是，Parma 确保了容器组所有可达状态的安全不变性，并以证明报告为根基。这使得外部第三方可以与容器安全地通信，从而实现需要保密访问安全数据的各种容器化工作流程。公司可以在云中运行最机密的工作流程，而无需在其安全要求上妥协，从而获得优势。
Charles Garcia-Tobin, Mark Knight - 利用 Arm CCA 提升安全性
保密计算通过将监控系统从 TCB 中移除，从而减小 TCB 的大小、攻击面和安全架构师必须考虑的攻击向量，从而极大地提高了通用计算平台的安全性。保密计算需要平台硬件和软件方面的创新，但这些创新有可能增强对计算的信任，尤其是在由第三方拥有或控制的设备上。保密计算的早期消费者将需要自行决定他们选择信任的平台。
© 保留所有权利。