在计算机安全领域，我们将数据安全粗略分为三个维度：in-transit, at-rest, in-use。

HTTPS 可以保护 in-transit，AES 可以保护 at-rest，而 TEE 就是注重于保护 in-use 时的内存数据安全。理论上，一个妥善配置使用的 TEE，可以让用户放心地在不信任的环境中运行代码。

比如你作为一个版权所有方，可以要求对方提供可验证的 TEE 环境，然后你才会将重要的数据传输进对方的 TEE 加密环境中。即使这台机器完全在对方手中，TEE 硬件也会保障你数据的安全。

然而，这个安全神话最近被无情的打破了。研究者发现，SGX 的 CPU 和内存间的加密通信使用的是确定性的加密算法（deterministic）。那么通过运行一个自定义的 TEE 应用，然后再拦截内存总线上的加密数据流，就可以让 TEE 的内存加密芯片扮演一个 oracle 的角色，从而为攻击者提供充足的包含时序信息的密文，从而推断出 TEE 签名 QE REPORT 所使用的 ECDSA 私钥。

拿到签名私钥后，就可以为任意伪造的 REPORT 签名。而 SGX 正是通过 REPORT 来证明当前程序运行在一个可信的 TEE 环境之中。那么攻击者就可以实际在非加密环境中运行程序，但是仍然提供一个可信的 REPORT，从而骗取数据提供方的信任。

很可惜 Intel 也不打算修复这个问题，那么 TEE 安全性的基础（Trusted Computing Base, TCB）就得包含：

* TEE 硬件
* 可信的 host OS
* 可信的物理机器维护者

作为一个曾经的 TEE 开发者，说实话，前两者还可以通过软件手段来保障。但是最后一条，感觉完全扭曲了 TEE 的意义。如果你愿意信任机器的提供方，那么实际上 TEE 的意义就变成了防内贼而不是外贼。

作为一个开发者，你也可以从中吸取教训，谨记“一事一密”，利用随机数和密钥派生，不复用密钥，确保相同数据的每次加密结果都不一样。在加密以外，完整性验证也是非常重要的（integrity & authentic）。

扩展阅读:

* 我以前写过一系列介绍 TEE 的文章
* https://wiretap.fail/
* Intel 的回应: More Information on Encrypted Memory Frameworks for Intel Confidential Computing
* next