TEE 构建可复现性研究：91% 的部署无法复现

当天发生了什么

2026-09-10（UTC），Annika Wilde、Marco Gutfleisch、Felix Reichmann、Anirban Chakraborty、Yuval Yarom、M. Angela Sasse 与 Ghassan Karame 在 arXiv 提交了论文《They don't care about this》的 v1，系统研究可信执行环境（TEE）软件的构建可复现性。作者指出，远程证明让外部方能检查 TEE 中运行的代码，但前提是被度量的二进制能追溯到源码，这需要可复现构建。他们分析了 115 个 TEE 部署，涵盖 Intel SGX、Intel TDX 和 AMD SEV，发现 91% 无法复现，约 80% 既不提供源码也不提供参考构建。作者联系了 50 个 SGX 项目的维护者并访谈 12 位开发者，只有一位把可复现性列为开发优先事项。论文认为嵌入时间戳等技术原因可以修复，而多方参与时对构建环境控制有限等生态问题更难解决。

对保护应用逻辑的人意味着什么

论文研究的是服务器侧 TEE，不是移动或桌面应用；下面的类比是我们的分析，而非论文结论。应用开发者同样依赖“证明”：签名、公证、App Attest 或 Play Integrity 等机制能说明运行的是某个被签名或被认可的构建，但它的意义取决于你是否清楚这个构建由什么源码、什么工具链、什么保护配置产生。代码混淆等变换常引入随机种子，让构建天然难以复现；如果无法重建同一个发布物，事后就很难确认线上版本到底包含了什么。论文的提醒同样适用：不要把证明机制当作安全徽章。

可以做的检查

第一，为每个发布版本记录构建输入：源码提交、工具链版本、保护工具版本、配置与随机种子。第二，尝试用同样的输入构建两次并对比产物，找出时间戳、路径等不稳定来源，能固定的就固定。第三，保存每个已发布产物的哈希和签名信息，便于事后核对。第四，梳理服务端哪些决定依赖证明结果，以及这些结果实际验证了什么、没有验证什么。第五，如果保护工具使用随机种子，决定是否记录并复用，以便日后能重建并核对某个发布版本。

行动清单

• 记录每次发布的工具链、保护配置与随机种子
• 同输入构建两次并对比产物差异
• 梳理依赖证明结果的服务端决定及其验证范围