3、TEE安全模型：信任根、安全启动、隔离执行、内存加密与远程认证
这一章，我们聊聊TEE的骨架——安全模型。说白了，就是TEE凭什么能保证安全。
我刚开始接触TEE时，觉得这东西就是个黑盒子。后来踩了不少坑，才慢慢理清这五个核心支柱：信任根、安全启动链、隔离执行、内存加密、远程认证。它们缺一不可。
3.1 信任根（Root of Trust）
信任根，是整个安全体系的起点。没有它，后面全是空中楼阁。
你想想看，如果连最底层的代码都不值得信任，那上层再怎么加固也没用。信任根通常固化在硬件中，比如CPU内部的一个只读ROM区域。
信任根的核心特征：
- 不可篡改性：出厂后无法修改，物理上只读
- 最小化：代码量极少，便于形式化验证
- 唯一性：每个芯片拥有唯一的身份密钥
我记得有一次做项目，客户问：“我把信任根放在Flash里行不行？”我直接摇头。Flash可以被重写，信任根一旦可写，整个安全模型就崩塌了。信任根必须是硬件级别的，比如Intel的fuses或ARM的Boot ROM。
3.2 安全启动链（Secure Boot Chain）
有了信任根，接下来就是怎么把信任传递下去。这就是安全启动链做的事。
安全启动链，说白了就是一级验证一级。信任根先验证第一级Bootloader的签名，第一级Bootloader再验证第二级，以此类推，直到操作系统和TEE本身。
我的经验： 安全启动链的每一级都要做签名验证。我曾经见过一个方案，只验证了前两级，后面就放开了。结果攻击者直接替换了第三级镜像，整个系统沦陷。记住，链条的强度取决于最弱的一环。
典型的启动链流程如下：
- ROM Code：信任根，验证Bootloader 1的签名
- Bootloader 1：验证Bootloader 2的签名
- Bootloader 2：验证TEE OS和REE OS的签名
- TEE OS：验证TA（可信应用）的签名
这里有个关键点：每一级的公钥通常由上一级内置，或者通过证书链传递。公钥本身不能存储在可写介质中。
3.3 隔离执行（Isolated Execution）
隔离执行是TEE的看家本领。它确保TEE内的代码和数据，不会被REE（富执行环境）或其他应用偷看或篡改。
怎么做到的？硬件层面做隔离。ARM用TrustZone，Intel用SGX，RISC-V用PMP或TEE扩展。原理大同小异：把物理内存或CPU核心分成两个世界——安全世界和普通世界。
| 隔离机制 | 实现方式 | 隔离粒度 |
|---|---|---|
| ARM TrustZone | CPU模式切换 + 内存总线过滤 | 系统级（安全/非安全世界） |
| Intel SGX | CPU内存加密引擎 + 飞地（Enclave） | 进程级（每个Enclave独立） |
| RISC-V PMP | 物理内存保护寄存器 | 区域级（可配置） |
我个人习惯把隔离执行比作“保险箱里的保险箱”。REE是普通房间，TEE是带锁的保险箱。攻击者就算进了房间，也打不开保险箱。
注意： 隔离执行不是万能的。侧信道攻击（比如缓存时间攻击）可以绕过隔离。我曾经在调试一个支付TA时，发现REE侧可以通过测量响应时间推断TA内部的操作。后来加了随机延迟才解决。
3.4 内存加密（Memory Encryption）
隔离执行保护了运行时的数据，但物理内存本身是暴露的。如果有人拿着逻辑分析仪去读内存条，怎么办？内存加密就是干这个的。
内存加密，顾名思义，数据在写入内存前加密，读出时解密。密钥由CPU内部生成，软件拿不到。
Intel SGX用的就是MEE（Memory Encryption Engine）。它会在每次内存访问时自动加解密，对软件完全透明。
// 伪代码：内存加密流程
void memory_write(void *addr, uint8_t *data, size_t len) {
uint8_t *encrypted = aes_encrypt(data, len, cpu_key);
memcpy(addr, encrypted, len);
}
void memory_read(void *addr, uint8_t *buf, size_t len) {
uint8_t *encrypted = malloc(len);
memcpy(encrypted, addr, len);
aes_decrypt(encrypted, buf, len, cpu_key);
free(encrypted);
}嗯，这里要注意：内存加密不是免费的。每次读写都有加解密开销，大概会带来5%-15%的性能损失。我在做性能调优时，会把频繁访问的热数据尽量放在CPU缓存里，减少内存加密的触发次数。
3.5 远程认证（Remote Attestation）
最后一个支柱，也是实际部署中最容易被忽视的——远程认证。
你部署了一个TEE应用，怎么让远端服务器相信你确实运行在TEE里？不是随便一个程序都能冒充TEE的。远程认证就是解决这个信任传递问题。
流程大致如下：
- 挑战：服务器发送一个随机数（Nonce）给TEE
- 度量：TEE计算自身代码和数据的哈希值（度量值）
- 签名：TEE用硬件私钥对“Nonce + 度量值”签名
- 验证：服务器用TEE的公钥验证签名，并检查度量值是否匹配预期
关键点： 签名用的私钥必须由硬件信任根保护，且每个TEE实例的密钥唯一。这样服务器才能确信：这个签名确实来自一个真实的TEE，而不是一个模拟器。
我曾经遇到一个坑：远程认证的度量值只包含了TEE OS的哈希，没包含TA的哈希。结果攻击者替换了TA，度量值却没变。后来我强制要求度量值必须包含整个信任链——从信任根到TA。
3.6 五者关系：一张图说清楚
下面这张图，是我自己画的TEE安全模型框架。五个支柱如何协同工作，一目了然。
从图里能看出来，信任根在最上方，是所有安全的起点。安全启动链和隔离执行分别向左、向右延伸，一个负责启动时的信任传递，一个负责运行时的隔离保护。内存加密和远程认证则是在底层和网络层做补充。
这五个支柱，少了任何一个，TEE的安全模型都不完整。我在实际部署中见过只做隔离执行、不做内存加密的方案，结果被物理攻击直接打穿。也见过只做远程认证、不做安全启动链的，攻击者直接替换了TEE镜像。
我的建议： 设计TEE方案时，先把这五个支柱列出来，逐个检查是否覆盖。缺一个，就补一个。别偷懒，安全没有捷径。
3.7 避坑指南
最后，分享几个我踩过的坑：
- 信任根选型：别用Flash或EEPROM存信任根代码。用硬件ROM或eFuse。
- 启动链验证：每一级都要验签名，别跳过。我曾经见过只验前两级、后面直接跳过的，结果被攻击者利用。
- 隔离执行粒度：根据场景选粒度。系统级隔离（TrustZone）适合全系统保护，进程级隔离（SGX）适合细粒度保护。
- 内存加密性能：热数据尽量放缓存，减少加密次数。我做过测试，优化后性能损失从15%降到5%。
- 远程认证度量：度量值必须包含整个信任链，从信任根到TA。别只度量TEE OS。
好了，这一章就到这里。记住这五个支柱，后面讲签名验签部署时，你会反复用到它们。