1.1 TEE核心概念与信任根

1.1 TEE 核心概念与信任根

本节摘要：可信执行环境（TEE）是处理器内部由硬件强制隔离出来的私有执行空间，即使操作系统或虚拟机监控器被攻陷，里面的代码和数据仍能保持机密与完整。本节从"软件安全为什么不够用"这个痛点切入，讲清 TEE 与富执行环境（REE）的并行关系、信任根（RoT）为什么必须下移到硬件、以及可信计算基（TCB）这个决定安全水位的核心概念。

学习目标

阅读完本节，你应当能够：

1. 用一句话向同事解释 TEE 和"再加密一层"的差别
2. 说出信任根（RoT）必须用硬件实现的两个理由
3. 区分富执行环境（REE）与可信执行环境（TEE）的边界
4. 解释可信计算基（TCB）为什么越小越安全
5. 列出构成一个完整 TEE 系统的四个关键组件

问题与直觉

假设你在做一个移动支付应用，用户的支付密码、指纹模板、交易签名密钥都得放在某个地方。最朴素的做法是放在操作系统管理的文件或内存里，靠操作系统的权限控制保护。问题是，一旦攻击者拿到 root 权限——不管是通过内核漏洞、还是诱导用户越狱——你的所有"秘密"对他就透明了。

再上一层，你把密钥加密存到磁盘。这挡住了"直接读文件"，但只要应用要使用密钥，总得在内存里解密，解密那一刻密钥又是明文的。攻击者只要有内核权限，dump 内存就行。传输加密（TLS）、静态加密（磁盘加密）这两个常见手段，都管不到数据"在使用时"的那段裸露时间。

这个困境的本质是：传统安全体系把操作系统当成可信的根。只要内核可信，上层应用就安全；可一旦内核被攻陷，整个安全架构就像抽掉地基的房子。问题不在于哪一层防护做得不够强，而在于信任链的顶端没有一个真正"够硬"的锚点。

TEE 的思路就是换一个根。与其信任可能被攻破的软件，不如把信任的起点下移到物理上极难篡改的硬件——处理器内部在制造时固化的电路。这就像把保险箱的锁芯焊死在钢板里，而不是用一把也能被软件复制的电子锁。

核心原理

2.1 TEE 与 REE 的并行世界

理解 TEE，先要建立"两个并行世界"的模型。处理器里同时存在两个执行域：

• 富执行环境（REE，Rich Execution Environment）：就是大家熟悉的 Linux、Windows、Android。它功能丰富但攻击面大，运行着成千上万的第三方应用和驱动，任何一处漏洞都可能让整个环境被攻陷。
• 可信执行环境（TEE，Trusted Execution Environment）：一个由硬件隔离出来的精简执行域，只跑少量经过严格审计的可信代码。它和 REE 共享同一颗 CPU，但二者之间存在硬件强制的访问边界。

关键点在于：即便 REE 被完全控制，攻击者也无法直接读取或修改 TEE 内部的内存和寄存器状态。这个边界不是靠软件权限位维持的（权限位本身可以被内核改），而是靠处理器微架构里的特殊机制维持的——具体怎么维持，第 2、4 章会展开。

这两个世界之间的数据交换，必须走预定义的受控接口（比如 ARM 的 SMC 指令、SGX 的 ECALL/OCALL），不能随便互相读写内存。这是 TEE 安全模型的第一道闸门。

2.2 信任根：信任链的起点

"信任"不能凭空产生，它必须从一个公认的、极难伪造的起点传递出来。这个起点就是信任根（Root of Trust，RoT）。

在 TEE 里，信任根通常是处理器内部在芯片制造阶段就固化的一段不可变代码（Boot ROM）和一组唯一的硬件密钥。它的两个关键属性是：

• 不可篡改：Boot ROM 是只读的，硬件熔丝（eFuse）烧录后无法改写，攻击者没法在启动链的最底层塞进自己的代码。
• 不可伪造：硬件密钥在制造时生成并锁死在芯片里，软件层永远读不到明文，只能调用它做签名或加解密。

信任根是整条信任链的发起点。设备上电时，它先验证下一阶段引导程序的签名，验证通过才执行；下一阶段再验证更下一阶段，如此逐级传递，直到 TEE 运行时环境被加载。每一级都"信任"上一级已经验证过的东西，最终把信任从硬件根一路延伸到运行中的可信应用。

💡 关键直觉：信任链的强度等于最薄弱一环的强度。如果信任根本身可以被篡改（比如 Boot ROM 有漏洞），整条链再长也没用。这也是为什么芯片厂商对启动链的最初几级代码极其谨慎——它们是整个安全体系的"零号地基"。

2.3 可信计算基：越小越安全

可信计算基（Trusted Computing Base，TCB） 是指整个系统里"必须信任、无法从外部验证"的那部分代码和硬件。TCB 越大，潜在的漏洞面就越大——因为 TCB 里的任何一个 bug 都可能让整个信任链崩塌。

不同 TEE 架构的 TCB 大小差别很大，这直接决定了它们的安全水位：

SGX 的 TCB 小，是因为它不依赖一个中心化的可信操作系统——每个应用自己管自己的飞地，一个飞地被攻破不会连累别的。TrustZone 的 TCB 大，是因为整个安全世界共用一个可信 OS，一旦这个 OS 有漏洞，所有跑在里面的可信应用都暴露。

⚠️ 常见坑：很多人以为"放进 TEE 就安全了"，却忘了 TEE 内部的可信 OS 本身也是代码，也会有漏洞。历史上 OP-TEE、QSEE 都出过 CVE。TCB 大意味着你的安全水位被那段最不可靠的代码限制着——选 TEE 架构时，TCB 大小是个比"标称安全等级"更实在的指标。

2.4 构成完整 TEE 的四个组件

把上面的概念拼起来，一个完整的 TEE 系统由四个相互配合的组件构成：

这四个组件不是独立工作的。比如远程证明要可信，就离不开可信引导——如果初始状态不可信，后面再怎么证明也是假的。它们环环相扣，少了任何一个，TEE 的安全承诺都站不住。后面几章会把每一个拆开讲。

工程实践要点

3.1 判断"该不该用 TEE"的三个问题

不是所有敏感逻辑都值得放进 TEE。实际选型时，我一般先问自己三个问题：

1. 这个数据"在使用时"必须明文吗？ 如果只是存储和传输，磁盘加密加 TLS 就够了，没必要上 TEE。只有在 CPU 处理那一刻也得保密（比如密钥运算、模型推理、隐私查询），TEE 才有不可替代的价值。
2. 威胁模型里，操作系统或云平台可信吗？ 如果是自己的私有机房、内核你自己控，软件隔离或许够用。如果是公有云多租户、或者设备会落到不可控用户手里（手机、IoT），TEE 才值得考虑。
3. 性能和开发成本能接受吗？ 世界切换、内存加密都有开销，把一个高频调用的逻辑塞进 TEE 可能让吞吐量掉一半。开发上还要改通信模型、处理调试困难。代价和收益要先算清楚。

3.2 从概念到落地的常见误解

3.3 TEE 在系统里的定位

把 TEE 放到整个安全体系里看，它补的是"使用中数据（data-in-use）"这一段。其他几段早有成熟方案：

数据状态    传统方案              TEE 的角色
传输中  --> TLS/IPsec           （不管）
静态    --> 磁盘加密/KMS         （不管）
使用中  --> （以前没有好办法） --> TEE 补这块缺口
​

这个定位很重要——TEE 不是替代 TLS 或磁盘加密，而是和它们配合，把数据生命周期的最后一段裸露补上。理解了这一点，就不会把它和现有安全机制对立起来。

本节要点回顾

• TEE 的根本动机是解决"使用中数据"的明文暴露问题：传统加密管不到 CPU 处理那一刻，TEE 用硬件隔离补上这个缺口。
• 信任根必须下移到硬件：因为软件可被篡改，只有制造时固化的硅片才能提供不可篡改、不可伪造的信任起点。
• REE 与 TEE 是并行的两个执行域：共享 CPU 但由硬件强制隔离，数据交换必须走受控接口。
• 可信计算基（TCB）越小越安全：选 TEE 架构时，TCB 大小比标称等级更实在，TCB 里的任何一个漏洞都会拖垮整个信任链。
• 一个完整 TEE 由隔离、可信引导、远程证明、安全通信四个组件构成：缺一不可，环环相扣。
• TEE 不是银弹：它抬高攻击成本，但不防物理攻击、不替代 TLS、也不免除安全编码的责任。

下一节我们把"我们到底在防谁"这个问题拆开——讲清三类攻击者、TEE 通常的安全边界，以及为什么物理攻击一般被排除在外。

信任根的三种形态辨析

初学者常把"信任根"当成一个具体芯片，实际工程里它有三种形态，辨析清楚才能读懂各厂商的文档。硬件信任根：烧录在芯片中的一段不可篡改代码与密钥（如启动 ROM 和硬件唯一密钥），它是整条信任链的锚点，安全性来自物理不可改写。度量信任根：负责"测量并记录"行为的组件（如可信平台模块里的平台配置寄存器），它本身不阻止任何事，只提供"发生过什么"的可信证据——这个"只记录不拦截"的特性常被误解，很多人以为装了 TPM 就能防住篡改，其实它防的是抵赖而不是篡改。验证信任根：负责在关键动作前比对度量值与期望值的裁决组件（比如安全启动的校验逻辑），拦截能力来自它。三种形态的分工组合成完整信任链：硬件根提供锚，度量根提供证据，验证根执行裁决。工程选型时的实用判断：需要防"设备被改后抵赖"看度量能力，需要防"改了就跑不起来"看验证能力，两者都要就选支持完整信任链的平台，并接受配置复杂度的上升。