分布式系统中对数据的有意义控制。
Oak 是一个用于构建分布式系统的软件平台，以透明的方式提供关于系统行为的可外部验证（或可证伪）的声明。
Oak 提供用于构建 Enclave 应用（即与运行所在主机隔离、且可远程证明的应用）的构建模块。
在本文档中，我们聚焦于由异构“节点”组成的分布式系统；一个节点可以是运行在服务器上的 Enclave 应用（例如私有数据中心、公有云提供商等）、运行在客户端设备上的常规应用（例如手机、笔记本电脑）、常规的 HTTP 或 gRPC 服务、存储系统等。当两个节点相互通信时，其中一方或双方都可能是 Enclave 应用。对于两个节点之间的每次交互，我们将其分别称为“发起方”和“响应方”。我们避免用“客户端”和“服务器”来指代这些角色，因为在某些情况下，“发起方”节点实际上可能运行在“服务器”上——所有组合都是可能的。
Oak 分布式系统中的 Enclave 应用可以向其他节点远程证明自身：这包括提供其自身软件和硬件身份的证明，该证明绑定到本地加密密钥（存储在防篡改硬件中，保证密钥无法被窃取或复制），并最终由该节点主机上可用的一个或多个软件或硬件信任根签名。Enclave 应用的软件身份由对其有贡献的可执行二进制文件的度量值（即摘要/哈希）以及附加数据（例如配置）组成。
Oak 聚焦于基于 VM 的可信执行环境（TEE）（例如 AMD SEV-SNP、Intel TDX）作为 Enclave 应用的硬件信任根。这使得 Enclave 应用能够提供由 TEE 中硬件绑定的密钥签名的远程证明报告，而这些密钥无法被服务提供商访问。这些密钥最终根植于 TEE 制造商（例如 AMD、Intel）；通过将信任分散到多个不串通的参与者之间，这减少（理想情况下是消除）了为了验证该节点的证据而需要信任该节点服务提供商的需求。
在启动时，每个 Enclave 应用生成一个本地密钥对，并将公钥绑定到自身的证据上。当某个节点打算与一个 Enclave 应用通信时（无论作为发起方还是响应方），两个节点之间会建立一条端到端加密通道。作为通道建立的一部分，每个节点还会向另一个节点提供自身的证据（如果有的话），并可能使用另一个节点提供的证据来确立其可信度，然后再决定是否与其交换数据。
这条加密且经过证明的通道提供：
为了最小化 Enclave 应用的攻击面和可信计算基（TCB），Oak 鼓励采用拆分架构：
Enclave 应用：由开源代码（可复现地）构建的二进制文件，运行在 TEE 内部。Enclave 应用可以访问与证明证据绑定的解密密钥；它解密来自其他节点的传入请求，处理这些请求，加密响应并通过通信通道将其发回。该二进制文件与外部可验证的声明相关联。没有其他二进制文件能够以明文形式访问传入请求。
Host 应用：运行在主机（不受信任）服务器环境中的二进制文件，充当 Enclave 应用的前端；它暴露一个可被其他节点从外部访问的 gRPC 端点。该二进制文件只处理加密数据；其主要职责是在 TEE 中创建并维护 Enclave 应用的实例，并在 Enclave 应用与外部之间转发加密数据。它还可能包含与服务提供商基础设施上运行所需的控制平面或其他内部系统交互所需的专有逻辑。
这种架构意味着服务提供商无法在不被发现的情况下将 Enclave 应用二进制文件替换为另一个（可能恶意的）二进制文件。如果服务提供商在 Enclave 应用中引入后门，它就必须对该二进制文件进行签名，并通过 Transparent Release 流程将其发布到可验证日志中，这将使后门不可逆地对外部观察者可见。
Oak 的一个典型用途是构建保护隐私的密封计算应用。
在密封计算应用中，一个节点（通常是客户端设备）将数据发送给 enclave 应用（通常是服务器），该应用处理数据时，托管该 enclave 应用的服务提供商无法看到计算的输入、输出或副作用。
以下是一个简化的架构图。
Oak 支持 TEE 内两种操作系统，Enclave 应用可部署于其上：
Oak Restricted Kernel：一个非常精简的自定义微内核，仅支持单个 CPU 和单个应用。它通过仅向应用暴露非常有限的系统调用集合，对应用能做什么施加了非常严格的限制。Oak Restricted Kernel 应用适用于以下场景：审查 TEE 内整个可信代码库至关重要，而有限的功能和降低的性能是可接受的权衡。理想情况下，单个专家级人类审查者应能在几周内完整审查 Oak Restricted Kernel 的全部代码。
Oak Containers：Enclave 应用作为 OCI 运行时包的一部分提供。这包括一个完整的 Linux 内核和一个带有容器运行时引擎的 Linux 发行版，均位于 TEE 内。使用 OCI 运行时包作为兼容层可提供更熟悉的开发体验和更大的灵活性。Oak Containers 还支持 TEE 内的多个 CPU，因此适用于高性能要求的场景。这种方法的缺点是，TEE 中运行的整个可信代码库的规模显著更大，因为单个人类审查者审查整个 Linux 内核和 Linux 发行版的代码是不可行的。这种方法的信任模型依赖于更广泛的 Linux 生态系统的安全性。Linux 内核为应用提供的额外功能和灵活性也使得推理应用的行为更加困难，这反过来又使审查过程更加复杂。
远程证明是 TEE 向远程方提供关于其自身状态以及 TEE 内运行的工作负载（Enclave 应用）身份的证据的过程。
Oak 使用多阶段协议来度量启动过程中每一层的身份（不仅限于引导加载程序），并将其与 TEE 证据进行密码学绑定。Oak Stage 0 虚拟固件 被预加载到 VM 内存中，并包含在 TEE 证明报告中。为了覆盖后续的启动阶段，Oak 依赖设备标识组合引擎（DICE）方法，其中每个启动阶段负责度量下一个阶段。Oak 用这些额外证据扩充证明报告，从而使工作负载所有组件（例如内核和应用程序）的身份都被证据所覆盖。
当节点连接到 Enclave 应用程序时，它首先请求证明证据及相关的背书。背书包括来自 AMD 的证书链，用于证明该证明报告由合法的 AMD CPU 签名，以及（可选地）由运行在 enclave 内各组件开发者签署的声明。随后，另一节点使用这些背书验证证据，以确保其符合自身预期。客户端节点应确保 enclave 应用程序运行在最新且配置正确的 TEE 中（例如 CPU 运行最新版本的微码和 SNP 固件，且调试功能已禁用），并确保 enclave 内运行各组件的身份符合预期。
一旦节点确认 enclave 应用程序满足其所有预期，它便使用与证据绑定的公钥与 enclave 应用程序建立加密通道。
为确保 enclave 应用程序按照预期处理数据，外部审查者必须审查运行在 TEE 中的代码。Oak 通过发布大多数 Oak 组件的来源信息来实现这一点。这些信息充当反向索引，使审查者能够根据证明证据中的二进制度量摘要，查找用于构建每个组件的精确源代码提交。所有 Oak 组件均可复现构建（见下文“透明发布”），这意味着审查者可以获取特定的源代码提交并重新构建组件，以确认其产生完全相同的度量摘要。这使审查者确信他们正在审查的代码版本与启动期间加载到 enclave 中的代码版本完全一致。
透明发布是一组格式和工具，允许开发者以透明且不可否认的方式发布和消费关于二进制制品的声明。
作为远程证明过程的一部分，节点以一个或多个二进制摘要的形式获取 Enclave 应用程序的身份（例如，通常启动链的每一层至少有一个摘要）；然后它需要确定这些度量是否可信。
作为初步近似，我们可以假设客户端通过硬编码确切知道应预期哪些摘要，并可在本地将实际值与预期值进行比对。这可行，但对服务器应用程序的演进非常受限：一旦 Enclave 应用程序的任何二进制文件因新版本发布而发生变化，节点将不再信任该 Enclave 应用程序，两者将无法再交互。
我们可以通过在节点中硬编码用于签署二进制摘要的公钥（而非摘要本身）来解决此问题。这样，当 Enclave 应用程序的二进制文件发生变化时，开发者可以使用其持有的相应私钥对其进行签名，并将这些签名连同远程证明报告一起分发给节点，节点随后可验证这些签名的有效性。这可行，但存在一个问题：它允许 Enclave 应用程序向不同节点呈现不同的签名，而用户将很难察觉。
所实现的解决方案是：在创建新版本时不仅对摘要进行签名，还将该签名记录到外部的仅追加可验证日志中。Oak 依赖 Rekor（由 Sigstore 提供）作为此用途的外部可验证日志。作为透明发布流程的一部分，签名会被记录到 Rekor，并从中获取包含证明（或包含承诺），由 Rekor 的根密钥签名。随后，该证明与相关二进制制品一同存储，并提供给可能需要验证 Enclave 应用身份的节点。这使得开发者无法在 Enclave 应用中植入后门而不将其记录到可验证日志中。
我们承认完美的安全是不可能的。一般而言，拥有更小的可信计算基（TCB）更好，Oak 努力将 TCB 最小化到需要被信任的最少组件。
Oak 的设计目标是无需信任以下内容即可实现可验证的可信性：
服务提供商可能意图访问并窃取用户的私有数据。他们拥有数据中心的宿主机，因此拥有服务器 root 访问权限，能够修改宿主机操作系统、驱动程序、虚拟机监控程序等。他们还可以检查包含用户数据的网络流量。在 Oak 架构中，我们将服务提供商运营的宿主硬件和宿主操作系统视为不受信任。需要保护的数据在存储于宿主操作系统的内存系统时必须加密，解密密钥由 TEE 管理，托管硬件机器的服务提供商无法访问。Oak 架构允许应用程序通过减少对服务提供商的信任需求来做出更强的声明。
Oak 平台库和组件，以及在该平台上运行的 Enclave 应用，都运行在 TEE 内部。它们可以访问未加密的数据。Oak 通过开源这些组件来建立信任，并通过透明发布实现外部检查和验证。
硬件 TEE 负责内存加密和解密，以及生成远程认证报告等。
Oak 并不绝对信任任何特定的 TEE 制造商；相反，每个客户端在连接到运行于其他主机上的 Enclave 应用时，自行决定信任哪些 TEE 制造商。Oak 使运行在 TEE 上的 Enclave 应用能够提供以 TEE 制造商本身为根源的证据。Oak 未来可能会支持更多的 TEE 型号和制造商。
侧信道攻击对机密计算环境构成了重大挑战。我们承认大多数现有 TEE 存在妥协，可能容易受到某些侧信道攻击的影响。这是一个活跃的研究领域，需要硬件和软件两方面的创新才能完全防御此类攻击。托管基于 TEE 的服务器的服务提供商需要实施强大的主机安全。强大的安全需要纵深防御>)。
需要物理访问服务器硬件的攻击是另一类 Oak 和 TEE 硬件制造商无法单独防御的攻击。物理攻击成本高昂，因此不具备可扩展性。为了防御此类攻击，服务提供商需要在其数据中心实施强大的物理安全。
