打破黑盒:基于可重复构建实现托管型 Trustee 的可信验证 背景在当前的 Trustee 机密计算场景下的密钥管理/分发组件部署模式中我们通常面临两种选择托管型 Trustee由云厂商或第三方提供开箱即用集成成本低但用户必须无条件信任托管方存在供应链被篡改的“黑盒”风险。自建型 Trustee用户自行部署运维完全掌握信任根Root of Trust安全性高但部署复杂运维成本高昂。可信验证逻辑用“可重复构建”打破信任僵局从 Trustee 源码出发如果走普通构建路径构建链路中一旦被植入后门最终产出的二进制就可能被篡改而这些来自源头的篡改不仅能让带有后门的 Trustee 二进制通过远程证明也无法借助常规审计手段发现。可重复构建机制的引入消除了这一隐患同一份源码在受控环境下应当稳定生成完全一致的二进制及哈希值。发布端基于可重复构建产出哈希参考值并公开发布用户在本地受信环境中复现同样的构建过程通过比对本地生成的哈希与参考值是否一致来验证云端 TEE 中 Trustee 的度量值未被篡改。同时用户可以对公开的 Trustee 源码进行代码审计从逻辑层面确认其行为安全可靠从而在可审计源码 可重复构建的组合下构建起对托管型 Trustee 的强可信链路。简单来说这一过程包含两层核心验证首先用 Trustee 制品 Owner 生成的参考值去验证 TEE 内 Trustee 产生的度量值以此确保运行时环境中的 Trustee 制品是可信的紧接着再用审计者在本地可重复构建环境中生成的可信参考值去反向校验 Owner 发布的参考值从而确保发布到透明日志上的参考值本身也是未被篡改、绝对可信的。整个方案涉及以下三类关键数据TEE Trustee 的度量值生产者由运行在 TEE 中的 measurement_tool 生成并由 TEE 中的 AAAttestation Agent负责生成远程证明报告的代理服务) 对外提供的 Attestation Report内含 TEE Trustee 的度量值。消费者审计者客户端程序通过远程方式从 AA 获取并在本地执行验证。TEE Trustee 的参考值生产者在 Trustee RPM 二进制发布者的源码构建流水线中随 Trustee 制品一同产生并发布到透明日志上。消费者审计者客户端远程从透明日志上下载并用于验证 TEE Trustee 的度量值以及与审计者客户端本地运行的 Trustee 可重复构建容器环境生成的可信参考值进行比较。TEE Trustee 的可信参考值生产者由审计者客户端手动运行 Trustee 可重复构建容器环境通过 Trustee 源码构建生成。消费者审计者客户端用可信参考值与从透明日志上获取的参考值进行比较。PoC 验证手把手教你验证托管型 Trustee环境要求下列命令可以在 TDVM guest 中单机执行作为演示但完整威胁模型包括本地和远端两个环境。操作系统Alibaba Cloud Linux 3 TDVM软件依赖Docker、wget、git步骤一在远端 TEE 中部署和运行 Trustee 远程证明服务在远端 TEE 中首先安装Trustee 1.7.7RPM 包以及attestation-agent、trustiflux-api-server、measurement_tool等组件。随后配置measurement_tool对 Trustee 的度量声明将 Trustee 相关二进制、配置文件、systemd 服务文件等关键对象加入/etc/measurement_tool/config.toml的files列表。最后启动attestation-agent、trustiflux-api-server和measurement_tool对 Trustee 相关文件执行动态度量并等待审计者远程获取 Trustee 的远程证明报告。步骤二在审计者本地通过可重复构建为 Trustee 生成可信参考值审计者在本地下载 Trustee 可重复构建材料build-materials-v1.7.7.tar.gz构建并运行 Trustee 可重复构建容器镜像重新生成 RPM 制品rpm-out/RPMS/x86_64/Trustee-1.7.7-1.an23.x86_64.rpm。随后对该 RPM 制品计算sha256sum得到审计者本地生成的可信参考值。步骤三审计者获取并验证 Trustee 的度量值和参考值审计者安装attestation-challenge-client-1.7.6-1.al8后依次完成三件事从 Rekor 透明日志中获取 Trustee 制品 owner 事先发布的参考值并保存到reference_values.json。远程访问 AA获取 Trustee 的远程证明报告其中包含 TEE Trustee 的度量值。执行验证比较本地可信参考值、透明日志中的参考值以及远端 TEE 中的实际度量值。验证通过后可以在输出的详情中看到 Trustee 参考值与度量值的比较结果。测试结果示例分析在本地可重复构建完成后审计者得到的制品Trustee-1.7.7-1.an23.x86_64.rpm的可信参考值为78fc83f05f7ac5bf195b9421b86ff986bec369dabd57fd718d3b6fb11cbd1847。从透明日志中可以看到发布的制品Trustee-1.7.7-1.an23.x86_64.rpm的参考值同样为78fc83f05f7ac5bf195b9421b86ff986bec369dabd57fd718d3b6fb11cbd1847。通过比较验证参考值与可信参考值是否一致。另外透明日志中也记录了该 RPM 制品中包含的所有文件的参考值可知这些参考值也和可信参考值一致。在验证阶段会验证参考值是否与度量值一致。具体来说会比较制品Trustee-1.7.7-1.an23.x86_64.rpm中包含的每一个文件的度量值确保其与透明日志中记录的对应文件的参考值一致如下图以二进制可执行文件/usr/bin/kbs为例参考值与度量值一致。经过上述两次验证最终确保 TEE 中运行的制品度量值、制品 owner 发布到透明日志上的参考值、以及审计者本地通过可重复构建生成的可信参考值三者相等再结合审计者对源码审计后的结果联合证明制品 owner 在源码构建过程中没有插入后门或制品 owner 的源码构建流水线未受到攻击制品 owner 发布到透明日志上的参考值未经篡改或制品 owner 的参考值发布环节未受到攻击制品在部署和运行过程中未经篡改或制品在 TEE 内未受到篡改总结本文介绍的基于可重复构建的托管型 Trustee 验证方案成功构建了一条从“源码”到“发布制品”再到“运行时”的强可信链路。通过引入透明日志Rekor和本地构建验证我们打破了传统托管服务的“黑盒”困境。用户不再需要盲目信任云厂商而是可以通过数学哈希值的比对亲手验证所使用的托管服务是否源自可信的、未经篡改的开源代码。这一方案不仅大幅降低了机密计算的准入门槛更为云原生环境下的供应链安全提供了坚实的技术范本。未来龙蜥社区将继续探索更高效的验证机制让信任在云端自由流转。这一方案不仅大幅降低了机密计算的准入门槛更为云原生环境下的供应链安全提供了坚实的技术范本。—— 完 ——关于龙蜥龙蜥社区OpenAnolis是立足中国面向国际的 Linux 服务器操作系统开源根社区引领云智融合技术浪潮下国产操作系统的创新发展。经过五年发展龙蜥社区目前已汇聚 25 家理事会成员海光信息与 AMD 于 2025 年分别晋升为副理事长及理事单位象征着国际主流芯片厂商对龙蜥生态的高度认可。同时龙蜥操作系统累计装机量已突破 1000 万套装机量从社区成立之初的百万级跃升至千万级增比超 900%。超过 2 万名开发者与 1000 余家全产业链伙伴在此共建服务覆盖金融、通信、政务、能源、交通、互联网及 AI 模型等众多行业惠及超过 200 万用户。