2、信任根与信任链：从一颗“种子”说起
聊远程证明，绕不开一个核心概念——信任根（Root of Trust，RoT）。
说白了，信任根就是整个安全体系的“第一块砖”。它本身不能被验证，因为它是验证一切的起点。你想想看，如果连起点都不靠谱，后面再长的链条也是白搭。
我早年做嵌入式安全时，遇到过客户问：“我的代码在安全芯片里跑，那安全芯片本身怎么证明自己是安全的？”这个问题问得好。答案就是：我们不需要证明信任根，我们只负责把它设计得足够坚固，物理上、逻辑上都难以篡改。
2.1 什么是信任根？
信任根是一个绝对可信的实体，通常是一个硬件模块或固件片段。它负责执行一组核心安全功能，比如：
- 安全存储密钥（特别是设备私钥）
- 提供真随机数
- 执行安全度量（测量代码或配置的哈希值）
- 作为身份的唯一锚点
核心原则：信任根的行为必须是可预期的、不可伪造的、不可绕过的。一旦信任根被攻破，整个安全体系就归零了。
我个人习惯把信任根比作“保险箱的锁芯”。你可以换保险箱的外壳、改密码、加报警器，但只要锁芯本身有后门，一切防御都是纸老虎。
2.2 硬件信任根的两种主流形态
目前业界最常用的硬件信任根，主要是 TPM 和 TEE。它们思路不同，但目标一致。
2.2.1 TPM（可信平台模块）
TPM 是一个独立的安全芯片，专门干脏活累活。它有自己的处理器、非易失性存储、密码加速器，跟主CPU完全隔离。
TPM 的核心能力包括：
- 平台配置寄存器（PCR）：存储度量值的“小黑板”，只能扩展（extend），不能直接写。
- 背书密钥（EK）：芯片出厂时烧录的唯一身份，相当于TPM的“身份证”。
- 存储根密钥（SRK）：保护用户密钥的顶层密钥，存在TPM内部，永远不对外暴露。
我记得有一次帮客户做服务器启动完整性验证，用的就是TPM的PCR机制。每次BIOS加载一个模块，就把它的哈希值扩展进PCR。最后比对PCR值跟预期值是否一致——不一致就说明启动链被动了手脚。
小提示：TPM 2.0 相比 1.2 增加了算法灵活性（支持ECC、SM3/SM4），并且不再强制使用LPC总线，可以通过SPI/I2C连接。如果你做国产化方案，务必确认TPM芯片是否支持国密算法。
2.2.2 TEE（可信执行环境）
TEE 的思路不一样。它不搞独立芯片，而是在主CPU内部划出一块“安全飞地”。这块飞地有独立的运行内存、独立的执行上下文，普通操作系统（REE）完全看不到里面的数据。
典型的TEE实现包括：
- ARM TrustZone：通过硬件总线隔离，将SoC分为安全世界和普通世界。
- Intel SGX：在内存中创建加密的飞地（Enclave），连操作系统都无法访问。
- RISC-V 物理内存保护（PMP）：通过物理地址区间限制访问权限。
TEE 的优势是性能好、集成度高，适合对延迟敏感的场景（比如移动支付、DRM）。但它的物理隔离强度不如独立TPM芯片——毕竟攻击者如果能物理探针直接量测总线，TEE的隔离就可能被绕过。
| 特性 | TPM | TEE |
|---|---|---|
| 物理形态 | 独立芯片或固件模块 | CPU内部安全区域 |
| 隔离强度 | 高（物理隔离） | 中高（逻辑+总线隔离） |
| 性能 | 低（专用芯片，带宽有限） | 高（共享CPU资源） |
| 典型用途 | 启动度量、密钥存储、平台证明 | 运行时保护、支付、生物识别 |
| 成本 | 增加BOM成本 | SoC内部集成，成本较低 |
注意：不要以为用了TPM或TEE就万事大吉。我在项目中见过不少“伪安全”设计——比如TPM的PCR值没被正确扩展，或者TEE的密钥被调试接口泄露。硬件信任根只是工具，怎么用才是关键。
2.3 信任链的建立与传递
有了信任根，下一步就是把信任传递出去。这个过程叫信任链（Chain of Trust）。
信任链的核心思想很简单：每一级在启动或加载下一级之前，先度量它，再把度量结果存到信任根里。如果度量值跟预期一致，就继续；否则就停止或报警。
典型的信任链流程（以PC为例）：
- CRTM（核心根度量信任）：固化在BIOS ROM中的一小段代码，是信任链的起点。它度量BIOS主固件。
- BIOS：度量Option ROM（如网卡、显卡固件）和Bootloader。
- Bootloader：度量操作系统内核。
- 操作系统内核：度量关键内核模块和驱动程序。
- 应用层：度量安全服务或容器镜像。
每一级的度量值都会被扩展进TPM的PCR寄存器。最终，远程验证方可以通过读取PCR值，判断整个启动链是否完整可信。
嗯，这里要注意：信任链的强度取决于最弱的一环。如果CRTM本身有漏洞，或者度量过程被跳过，那后面的链条再长也没用。
我曾经在一个IoT项目里踩过坑：设备用的是某款国产MCU，号称支持安全启动。结果我发现它的信任链只覆盖了Bootloader到内核，但Bootloader本身没有被度量——也就是说，攻击者可以直接替换Bootloader。后来我帮他们加了一级ROM Boot，才把链条补全。
2.4 信任链的图形化理解
下面这张图展示了从信任根到应用层的完整信任传递过程。每个箭头代表“度量并授权”。
从图中你可以看到，信任是一级一级“接力”上去的。每一级都把自己的度量结果交给下一级，同时把度量值存到信任根里。这样，远程验证方只需要读取信任根中的PCR值，就能知道整个链条是否被篡改过。
2.5 信任链在远程证明中的角色
远程证明的核心，就是向远程方证明“我的信任链是完整的”。具体来说：
- 设备端：信任根（TPM/TEE）保存了从启动到现在的所有度量值。
- 证明请求：远程方要求设备提供PCR值，并附带一个签名（用信任根保护的私钥签名）。
- 验证：远程方验证签名有效，并比对PCR值是否与预期一致。
如果PCR值匹配，说明设备的启动链没有被篡改，当前运行的软件栈是可信的。这就是远程证明的底层逻辑。
实战建议：在设计信任链时，不要只度量代码本身。我建议把配置数据（比如安全策略、网络白名单）也纳入度量范围。我在一个项目中遇到过攻击者不改代码，只改配置文件就绕过了安全策略——幸好度量覆盖了配置，才没出事。
2.6 避坑指南
最后，分享几个我踩过的坑：
- 信任根选型不当：有些低端MCU号称有“安全启动”，但它的信任根是软件实现的，存在Flash里。攻击者直接读Flash就能改。硬件信任根必须是物理不可克隆的。
- 度量范围不全：只度量了内核，没度量设备树或ACPI表。攻击者可以通过修改这些配置来劫持系统。
- 忽略运行时度量：信任链只在启动时建立，但系统运行后可能被动态加载恶意模块。需要配合IMA（完整性度量架构）等运行时度量机制。
- 签名验证绕过：有些实现把公钥硬编码在代码里，但攻击者可以通过替换公钥来伪造签名。公钥必须由信任根保护。
我曾经在一个客户现场排查问题，发现他们的TPM PCR值始终跟预期不一致。查了两天，最后发现是BIOS里有个选项叫“Fast Boot”，跳过了Option ROM的度量。关掉这个选项，问题就解决了。所以，信任链的完整性，往往取决于那些不起眼的配置项。