TeeChat seal-sync 协议安全问题说明与关闭公告

2026 年 8 月 30 日，TeeChat 在内部安全审查中发现 seal-sync 协议实现存在严重缺陷。seal-sync 是在蓝绿可信环境之间迁移服务 TLS 密钥的管理协议。

我们在启用支付并开始推广产品前发现了这个问题。

本文是关闭公告。我们已隔离所有已知公网端口，没有发现恶意密钥导出或用户数据泄露的证据，已部署修复版本，替换了「假定已受影响」的服务密钥，并吊销了相关公钥证书。

seal-sync 协议的作用

TeeChat 的所有内部和对外 TLS 连接均使用 TLS 1.3，以提供最高等级的安全保证；同时，所有私钥均在机密容器内部产生（这个过程称为 key ceremony，密钥启用仪式），通过机密容器的密封机制存到磁盘，以保证仅同一容器可以打开。在服务升级时，我们使用 seal-sync 协议 在经过认证的服务组件之间加密传递私钥；私钥从不明文离开机密容器。

问题本质

设计要求是「经证明的 TLS 1.3」，但实现没有完整满足这个安全契约：

• 管理 TLS 监听器不要求客户端证书；
• 请求方测量值可能在未完整验证 AMD SNP 或 Intel DCAP 签名、证书链、TCB 与调试状态时被接受；
• 请求方可以指定二次挑战所访问的端点；
• 网关密封工具仍可能进入开发认证路径；
• 部分 QEMU 转发和 SGX 监听使用全网卡地址，而非回环地址；
• 私钥只受 TLS 传输保护，没有再次加密给一个已被证明属于请求 TEE 的密钥。

攻击者需要先访问 seal-sync 监听器，再通过或绕过上述检查。若成功，攻击者可能直接收到服务 TLS 私钥。

若密钥被盗，攻击者能看到什么、不能看到什么

即便证书私钥被盗，攻击者也不能解密以前录下的 TeeChat 流量。受影响服务强制使用 TLS 1.3，其临时密钥交换提供前向保密。

更严重的可能后果来自攻击者冒充身份，建立连接。然而，攻击者仍然需要控制路由、DNS、代理、上游主机或客户端终端。若成功冒充 OpenAPI 端点，攻击者可能看到之后发往该假端点的新请求与凭据。

我们没有发现这种攻击已经发生的证据。

我们如何发现

这个发现来自 TeeChat 内部安全审查，不是客户报告，也不是外部披露。

我们逐项对比书面协议、Rust 实现、部署模板与实际网络暴露面。只读身份请求确认生产 OpenAPI 和网关的 seal-sync 监听器可以从公网访问。随后，Git 历史确认 QEMU 空主机地址产生了全网卡转发。

最早受影响的 OpenAPI 配置于 7 月 22 日进入代码库；网关为 7 月 26 日；SGX 实验室监听器为 7 月 29 日。全网卡源代码路径和主机防火墙隔离在 8 月 30 日完成。这些日期界定了可能暴露区间。

留存日志显示什么

现存 SGX 实验室日志包含：

• 16 条导出方成功记录；
• 16 条相匹配的导入方「已密封并持久化」记录；
• 2 次与部署测量值变化有关的证明拒绝；
• 25 次公钥已一致、未导出密钥的检查；
• 0 次已确认恶意导出。

这些成功记录与我们的蓝绿实验室迁移相符，因此以中等置信度归类为合法操作。

生产 OpenAPI 与网关当前及上一个留存日志窗口中，成功导出记录均为 0。但这些日志不覆盖整个可能暴露期。

旧审计格式也缺少可靠时间戳、来源地址和经过密码学认证的请求方密钥。

结论

结合成功攻击还需要控制路由、DNS、代理、上游主机或客户端终端等其它要素，我们的结论是：未发生已确认攻击或泄漏，用户数据的安全性未受影响。即便如此，我们仍然发布此公告，以在至关重要的安全性上保持透明。这也将是我们在未来遵循的规范。

立即隔离

我们已经：

1. 阻断所有已识别 seal-sync 端口的非回环入站流量；
2. 将后续 QEMU 和 SGX 启动配置改为只在回环地址监听；
3. 从独立主机检查 OpenAPI、网关与 SGX 实验室的完整端口矩阵；
4. 在受控迁移窗口之外停放密钥仪式导出环境；
5. 增加回归测试，禁止 seal-sync 通配地址转发。

这些措施关闭了公网路径。但「隔离」不等于「协议已经修正」，因此我们接着部署了修复版本并替换了服务密钥。

正式修复

修复版本现在会：

• 完整验证 AMD SNP 与 Intel DCAP 证据，并从证据中推导测量值；
• 拒绝调试环境和不可接受的 TCB 状态；
• 把服务器生成的一次性随机数、请求方密钥、目标身份与导出操作绑定到硬件证明；
• 在请求 TEE 内生成临时 X25519 密钥；
• 使用 HPKE 将导出内容加密给该已证明密钥，使私钥不再以明文形式出现在协议响应中；
• 使用服务器管理的对端策略，不再接受请求方指定的挑战地址；
• 在生产构建中对空白名单、开发证明器、默认密钥和公网监听直接失败；
• 如果持久化的导出前审计或完成审计写入失败，则拒绝释放密钥。

替换假定受影响的密钥

即使没有确认的导出记录，我们仍把现有服务密钥视为「假定已受影响」。

我们在经测量的仪式环境中生成新身份，发布新 SPKI，通过修复版本迁移 OpenAPI 与网关，撤销旧 SPKI，并完成生产与实验室环境的验证（外部端口检查、硬件证明检查和产品回归）。

被盗的私钥仍可能配合尚未过期的公钥证书使用。因此，我们也把相关证书视为「假定已受影响」，并向签发证书的 CA 申请吊销，使检查吊销状态的依赖方拒绝这些旧叶子证书。

← 全部文章