3、可信根（Root of Trust）：可信根的概念、三种可信根（RTM、RTS、RTR）及其作用
聊到TPM，有个概念绕不开——可信根。说白了，它就是整个信任链条的起点。你想想看，一台电脑怎么证明自己是“可信”的？总得有个绝对可靠的源头吧。这个源头，就是可信根。
我刚开始接触TPM时，觉得这东西挺玄乎。后来在项目中踩过几次坑，才真正理解它的分量。今天咱们就把这个概念掰开揉碎了讲清楚。
3.1 什么是可信根？
可信根（Root of Trust，简称RoT），是一个必须被无条件信任的实体。它可以是硬件、固件，也可以是软件模块。关键在于——它的行为是确定的、可预期的，而且不能被篡改。
打个比方：你信任一把锁，前提是这把锁的制造过程没被动手脚。可信根就是这把锁的“出厂状态”。一旦这个根被污染，整个信任链就崩塌了。
核心原则：可信根不需要被证明是可信的，它本身就是信任的起点。所有其他组件的可信度，都基于对可信根的信任。
在TPM规范里，可信根被细分为三种：度量可信根（RTM）、存储可信根（RTS）、报告可信根（RTR）。它们各司其职，共同构建了可信计算的基础框架。
3.2 三种可信根详解
3.2.1 度量可信根（RTM）
RTM，全称Root of Trust for Measurement。它的任务就一个：测量。测量谁？测量系统启动过程中的每一个组件——BIOS、引导加载程序、操作系统内核、驱动程序……一个都不能少。
RTM通常由CRTM（Core Root of Trust for Measurement）承担。CRTM是BIOS中一段不可修改的代码，系统上电后它第一个执行。它会计算下一个组件的哈希值，然后把结果存到TPM的PCR（平台配置寄存器）里。
我个人的习惯：在设计可信启动流程时，一定要确保CRTM是只读的。我曾经见过一个项目，CRTM被放在可擦写的Flash里，结果一次固件升级把CRTM搞坏了，整条信任链直接断裂。嗯，那场面……相当尴尬。
RTM的工作流程大致如下：
- 系统上电，CPU执行CRTM代码。
- CRTM度量BIOS的下一段代码，将哈希值扩展到PCR[0]。
- 控制权移交给BIOS，BIOS继续度量Option ROM、MBR等。
- 每一步的度量结果都扩展到对应的PCR中。
- 最终，操作系统启动时，可以比对PCR值与预期值，判断系统是否被篡改。
3.2.2 存储可信根（RTS）
RTS，全称Root of Trust for Storage。它的职责是保护敏感数据。TPM内部有专门的存储区域，用于保存密钥、证书、哈希值等。RTS确保这些数据不会被非法读取或篡改。
RTS的核心机制是密封存储（Sealed Storage）。你可以把数据“密封”起来，只有满足特定PCR状态时才能“解封”。换句话说，如果系统被篡改，PCR值变了，数据就打不开。
| 特性 | 说明 |
|---|---|
| 存储位置 | TPM内部非易失性存储器（NVRAM） |
| 保护对象 | 密钥、证书、哈希值、敏感配置 |
| 核心机制 | 密封存储、PCR绑定、授权策略 |
| 防篡改能力 | 硬件级保护，物理攻击也难以读取 |
避坑指南：我曾经遇到一个案例，开发人员把密封数据用的PCR值设错了。结果系统一更新，PCR值变了，所有密封数据都废了。记住：PCR的选择直接影响密封数据的生命周期。升级固件前，务必确认PCR的持久性策略。
3.2.3 报告可信根（RTR）
RTR，全称Root of Trust for Reporting。它的作用是证明——向外部实体证明当前平台的状态是可信的。RTR通过签名来实现这一点。
具体来说，RTR使用TPM内部的背书密钥（EK）或平台身份密钥（AIK），对PCR值进行签名。外部验证方拿到签名后，可以验证PCR值是否被篡改，从而判断平台的可信度。
RTR的工作流程：
- 请求方（如远程服务器）向TPM发起“引用（Quote）”请求。
- TPM读取当前PCR值，用AIK进行签名。
- 签名结果（包括PCR值和签名数据）返回给请求方。
- 请求方用AIK的公钥验证签名，比对PCR值与预期值。
关键点：RTR不负责判断平台是否“安全”，它只负责“报告”。至于报告的内容是否可信，由验证方自己判断。说白了，RTR就是个诚实的信使。
3.3 三种可信根的关系
这三种可信根不是孤立的。它们协同工作，形成一个完整的信任链。我画了一张图，帮你理清它们的关系。
从图中可以看出：
- RTM负责“采集证据”——度量系统状态。
- RTS负责“保管证据”——安全存储度量结果。
- RTR负责“出示证据”——向外界证明平台可信。
这三者缺一不可。没有RTM，你拿不到证据；没有RTS，证据可能被篡改；没有RTR，你没法向别人证明自己可信。
3.4 实际项目中的经验
我在做可信启动方案时，遇到过一个问题：RTM的度量顺序搞反了。当时团队里有人觉得，先度量BIOS还是先度量Option ROM无所谓。结果呢？PCR值跟预期对不上，系统一直报“不可信”。排查了两天才发现，是度量顺序错了。
所以，我建议你在设计可信启动流程时，一定要严格按照规范来。TPM规范里对PCR的分配和度量顺序有明确要求，别自己瞎改。
一个小技巧：调试阶段，可以用TPM工具（如tpm2-tools）手动读取PCR值，跟预期值做比对。这样能快速定位问题。我每次做新平台适配，都会先跑一遍这个流程。
另外，RTS的密封策略也要小心。我曾经见过有人把密钥密封到PCR[0]~PCR[7]上，结果一次BIOS升级，PCR[0]变了，所有密钥都废了。嗯，那哥们后来被老板骂得不轻。记住：PCR的选择要跟你的更新策略匹配。如果固件会更新，就别把密钥密封到跟固件相关的PCR上。
3.5 小结
可信根是整个可信计算体系的基石。三种可信根——RTM、RTS、RTR——分别负责度量、存储和报告。它们相互配合，构建了一条从硬件到软件的信任链。
理解这三种可信根，是掌握TPM的第一步。后面的章节，我们会深入每个可信根的具体实现和编程接口。到时候你会发现，今天讲的概念，全是基础中的基础。