背景
在当前的 Trustee （机密计算场景下的密钥管理/分发组件）部署模式中，我们通常面临两种选择：
- 托管型 Trustee：由云厂商或第三方提供，开箱即用，集成成本低，但用户必须无条件信任托管方，存在供应链被篡改的“黑盒”风险。
- 自建型 Trustee：用户自行部署运维，完全掌握信任根（Root of Trust），安全性高，但部署复杂，运维成本高昂。
可信验证逻辑：用“可重复构建”打破信任僵局
从 Trustee 源码出发，如果走普通构建路径，构建链路中一旦被植入后门，最终产出的二进制就可能被篡改，而这些来自源头的篡改不仅能让带有后门的 Trustee 二进制通过远程证明，也无法借助常规审计手段发现。
可重复构建机制的引入，消除了这一隐患：同一份源码在受控环境下应当稳定生成完全一致的二进制及哈希值。发布端基于可重复构建产出哈希参考值并公开发布，用户在本地受信环境中复现同样的构建过程，通过比对本地生成的哈希与参考值是否一致，来验证云端 TEE 中 Trustee 的度量值未被篡改。同时，用户可以对公开的 Trustee 源码进行代码审计，从逻辑层面确认其行为安全可靠，从而在"可审计源码 + 可重复构建"的组合下，构建起对托管型 Trustee 的强可信链路。
简单来说，这一过程包含两层核心验证：首先，用 Trustee 制品 Owner 生成的参考值，去验证 TEE 内 Trustee 产生的度量值，以此确保运行时环境中的 Trustee 制品是可信的；紧接着，再用审计者在本地可重复构建环境中生成的可信参考值，去反向校验 Owner 发布的参考值，从而确保发布到透明日志上的参考值本身也是未被篡改、绝对可信的。
整个方案涉及以下三类关键数据：
TEE Trustee 的度量值
- 生产者：由运行在 TEE 中的 measurement_tool 生成，并由 TEE 中的 AA（Attestation 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.7 RPM 包，以及 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 万用户。
