问题：“通用翻译器”困境
想象你是一名高安全建筑的安全警卫（即验证者）。人们来自不同国家（不同的硬件平台，如 Intel、AMD 或 ARM），声称自己是安全且可信的。
为了检查他们，你需要会说他们的语言。
- 如果有人说“Intel"语言，你需要一本 Intel 词典。
- 如果有人说"AMD"语言，你需要一本 AMD 词典。
- 如果有人说"ARM"语言，你需要一本 ARM 词典。
目前，安全警卫必须背着一个装满所有可能词典的巨大背包。如果明天有一个新国家开放，警卫必须停下，返回办公室，学习新语言，更新背包，然后再次尝试。这既缓慢又昂贵且充满风险，因为如果其中任何一本词典存在拼写错误（即漏洞），犯罪分子就可能欺骗警卫。
解决方案：TrustMee（“自解释”护照）
本文介绍了TrustMee，一种处理此问题的新方法。不再由安全警卫携带所有词典，而是访客随身携带自己的词典。
以下是使用简单类比的工作方式：
- 访客抵达：一个虚拟机（访客）带着其“证据”（证明其身份的凭证）抵达。
- 自解释护照：附在这份证据上的是一本微小的、密封的说明书，称为WebAssembly 组件。该说明书是专门为该访客的语言编写的（例如，“如何读取 Intel 身份标识”）。
- 安全沙箱：安全警卫不直接阅读说明书。相反，他们将说明书放入一个安全沙箱（一个玻璃箱，说明书可以在其中运行，但无法接触其他任何内容）。
- 翻译：在箱内，说明书读取证据，并将其翻译成一种通用语言（称为EAT）的简单“是/否”报告。
- 核查：警卫只需检查两件事：
- 玻璃箱（沙箱）是否安全？
- 说明书是否由受信任的权威机构（如该国政府）签名？
如果答案为是，警卫就接受该报告。警卫无需亲自学习外语；他们只需信任玻璃箱和说明书上的签名。
为何这至关重要
- 不再需要沉重背包：安全警卫（验证者）不再需要在每次出现新硬件平台时进行更新。他们只需要沙箱。
- 安全至上：如果"Intel 词典”存在漏洞，它将被困在玻璃箱内。它无法感染警卫或建筑的其他部分。
- 即时更新：如果 Intel 更改了其身份标识的格式，他们只需发送一本新说明书（一个新的 WebAssembly 组件）。警卫无需重新培训或重新部署；他们只需将新说明书加载到箱中即可。
研究结果（论文发现）
研究人员构建了该系统的原型，称为TrustMee，并使用三种主要硬件类型进行了测试：AMD、Intel TDX和Intel SGX。
- 行之有效：他们成功验证了所有三种类型的证据，而无需更改核心警卫软件。
- 速度：它比旧方法（将词典全部记在脑中，即原生代码）稍慢，但差异很小（通常仅为几毫秒）。
- 面向未来：研究人员表明，随着技术进步（例如为沙箱提供更好的工具），速度差距将进一步缩小。
核心结论
TrustMee改变了游戏规则。不再是验证者试图了解每种可能硬件的所有信息，而是硬件通过在一个安全箱中自带其“翻译器”来证明其自身的可信度。这使得系统更安全、更易于更新，并为任何即将到来的新技术做好了准备。
以下是论文《TrustMee：自验证远程证明证据》的详细技术总结。
1. 问题陈述
远程证明对于在机密虚拟机（cVM）和可信执行环境（TEE）中建立信任至关重要。然而，当前的验证机制存在显著局限性：
- 平台特定复杂性：验证器必须为每个支持的 TEE（例如 Intel SGX、Intel TDX、AMD SEV-SNP）实现硬件特定的加密逻辑和解析库。
- 可信计算基（TCB）扩大：验证器依赖用内存不安全语言（如使用 OpenSSL 的 C/C++）编写的原生插件或驱动程序来解析证书和证据。这会在验证器本身引入错误和漏洞（例如远程代码执行）。
- 维护与可扩展性：添加对新 TEE 的支持需要更新验证器的代码库、重新编译并重新部署。这造成了一个“鸡生蛋、蛋生鸡”的问题：验证器有动力支持更少的平台，以最小化安全风险和维护成本。
- 脆弱性：针对某个 TEE 的验证器插件中的一个错误可能破坏整个验证服务，甚至可能允许攻击者冒充其他平台。
2. 方法论：TrustMee 架构
作者提出了 TrustMee，这是一种平台无关的证明验证器，它将平台特定的验证逻辑负担从验证器转移到了证明者身上。
核心概念：自验证证据
与其硬编码验证逻辑，证明 TEE 将其特定的验证逻辑作为 WebAssembly (Wasm) 组件 与证明证据捆绑在一起。
- 证明者：生成标准的证明证据，并捆绑一个相应的 Wasm 组件，该组件实现了用于解析和验证该特定证据格式的逻辑。
- 验证器 (TrustMee)：
- 接收证据和 Wasm 组件。
- 测量 Wasm 组件（将其哈希/签名与信任存储进行比对检查）。
- 在沙箱化的 WebAssembly 运行时（Wasmtime）中执行该组件。
- 该组件解析证据，检查背书，并输出一组标准化的声明。
- TrustMee 主机（平台无关代码）将这些声明应用于评估策略，并以标准的 实体证明令牌 (EAT) 格式对结果进行签名。
关键技术组件
- WebAssembly 组件模型：使用 Wasm 接口类型 (WIT) 定义主机与组件之间严格、语言无关的接口。这确保了无论 TEE 如何，验证器都通过统一的 API（
evaluate 函数）与组件交互。
- 沙箱化：Wasm 组件在具有受限访问权限的沙箱中运行（例如，通过“燃料计量”限制 CPU 周期、受控的网络访问以及隔离的文件系统）。这防止了恶意或有缺陷的组件导致验证器崩溃或访问敏感的主机数据。
- 信任模型：
- 验证器信任 Wasm 运行时 和 策略引擎。
- 平台特定逻辑被视为不可信但已隔离。
- 验证器检查 Wasm 组件的 签名者（通常是 TEE 供应商）以及组件的哈希值与参考值是否匹配。
- 如果组件未签名或来自未知的签名者，它将在严格的默认策略下运行（无网络、受限 CPU）。
3. 主要贡献
- TrustMee 架构：一种新颖的自验证远程证明设计，由证明者提供验证代码。这消除了验证器维护平台特定驱动程序的需求。
- 实现：一个集成到 Trustee 框架（Confidential Containers 项目的一部分）中的工作原型。它包含了针对 AMD SEV-SNP、Intel TDX 和 Intel SGX 的 Wasm 验证组件。
- 标准化：该系统以标准的 EAT 证明结果 (EAR) 格式生成结果，确保与现有依赖方的兼容性。
- 安全分析：证明了将平台特定的解析逻辑隔离在 Wasm 中可以显著减少验证器的 TCB，并缓解与内存不安全库相关的风险。
- 性能评估：量化了 Wasm 方法相对于原生驱动程序的开销。
4. 结果与评估
作者将 TrustMee 与 AMD SNP、Intel TDX 和 Intel SGX 的原生 Trustee 驱动程序进行了评估。
- 兼容性：成功使用单个未修改的验证器主机验证了来自三种不同 TEE 架构的证据。现在添加新 TEE 只需要分发新的 Wasm 组件，而无需更新验证器。
- 安全性：
- Wasm 沙箱成功隔离了解析和加密操作。
- 恶意组件无法破坏验证器或冒充其他平台，除非被策略引擎（通过签名者/哈希检查）检测到。
- 拒绝服务 (DoS) 攻击通过燃料计量和网络限制得到缓解。
- 性能（延迟）：
- 冷启动：初始验证（包括组件下载和编译）由于网络和编译开销而具有更高的延迟。
- 热启动：一旦组件被缓存，开销是可管理的。
- AMD SNP：原生 Wasm 验证比原生 C/Rust 驱动程序慢约 3.67 倍，主要是由于当前 Wasm 运行时缺乏硬件加速加密。然而，使用 基于主机的加密（从 Wasm 调用原生加密函数）将此开销降低至约 1.47 倍。
- Intel TDX/SGX：使用纯 Rust 库 (
dcap-qvl) 的基于 Wasm 的验证器实际上比使用 Intel 专有 DCAP 库的原生 Trustee 驱动程序 更快。当与同样使用 dcap-qvl 的原生驱动程序相比时，Wasm 开销约为 3.17 倍，但绝对延迟仍然很低（在大多数情况下低于 50 毫秒）。
- 请求大小：TrustMee 请求通常比原生请求 更小（最多减少 37%），因为它们使用 CBOR 编码而不是 Base64 编码的 JSON，抵消了组件标识符的大小。
5. 意义与未来影响
- 解耦验证与硬件：TrustMee 打破了验证器与 TEE 供应商之间的紧密耦合。这使得云提供商和验证器能够即时支持新的 TEE，而无需进行代码更改。
- 减少攻击面：通过将易出错的解析和加密逻辑移至沙箱中，验证器的 TCB 被缩减为核心逻辑和 Wasm 运行时，显著降低了远程代码执行漏洞的风险。
- 可扩展性：该模型将维护负担转移给 TEE 供应商（他们已经维护验证库），而不是验证器运营商。
- 可扩展性：该架构支持 复合证明（验证硬件层之上的应用层），并可适应其他框架，如 Veraison。
结论：TrustMee 证明了远程证明可以在不牺牲安全性或性能的情况下实现平台无关。通过利用 WebAssembly 将验证逻辑与证据捆绑在一起，它解决了当前异构 TEE 生态系统中的集成和维护瓶颈。
每周获取最佳 computer science 论文。
受到斯坦福、剑桥和法国科学院研究人员的信赖。
请查收邮箱确认订阅。
出了点问题，再试一次？
无垃圾邮件，随时退订。