信任根与信任链:硬件信任根(RoT)、信任链的建立与传递、TCB(可信计算基)的定义

聊远程证明,绕不开一个最基础的问题:凭什么相信你?

你想想看,一个远程设备说“我是安全的,我的固件没被改过”,我凭什么信它?如果它的测量工具本身就被篡改了,那测量结果就是废纸。所以,我们需要一个绝对可信的起点——这就是信任根(Root of Trust, RoT)。

我个人习惯把信任根比作“信任的锚”。锚必须是物理上不可篡改的,通常是硬件。从这颗锚出发,一级一级往上验证,就形成了信任链。而整个过程中,所有不得不信任的软硬件组件,合起来就是可信计算基(TCB)。

这一节,咱们就把这三个概念彻底掰开揉碎。

2.1 硬件信任根(RoT):一切信任的起点

信任根,说白了就是第一个被信任的实体。它必须满足两个条件:

  • 不可伪造:攻击者无法冒充或篡改它。
  • 行为可预测:它做的事情是确定的,不会撒谎。

在远程证明场景里,最常见的信任根是硬件信任根。为什么必须是硬件?因为纯软件方案可以被恶意代码覆盖。我在项目中遇到过客户坚持用纯软件TPM模拟器做信任根,结果被rootkit直接hook了测量接口——嗯,从那以后,我再也不敢在安全等级要求高的场景里推荐纯软件方案了。

2.1.1 常见的硬件信任根形态

类型 载体 典型能力 我见过的坑
TPM(可信平台模块) 独立安全芯片 平台配置寄存器(PCR)、密钥生成、远程证明签名 TPM 1.2 的PCR扩展算法有长度限制,升级固件时容易溢出
fTPM(固件TPM) CPU安全固件(如Intel PTT) 与独立TPM功能类似,但依赖CPU安全区 曾经遇到fTPM在S3休眠恢复后PCR值丢失,导致证明失败
TEE安全元件 CPU内的安全飞地(如Intel SGX、ARM TrustZone) 隔离执行、远程证明(Quote)、密封存储 SGX的EPC内存有限,Quote生成时如果内存不足会直接报错
PUF(物理不可克隆函数) 芯片制造差异 生成唯一设备指纹,抗物理破解 PUF受温度和电压影响大,我见过同一芯片在不同温度下生成不同密钥的案例
我的建议: 如果设备有独立TPM芯片,优先用独立TPM做信任根。fTPM虽然方便,但它的安全边界和CPU固件深度绑定——一旦CPU固件有漏洞,fTPM也跟着沦陷。

2.2 信任链的建立与传递:从锚点到全系统

有了信任根这颗锚,接下来要解决一个问题:怎么让整个系统都可信?

答案是:逐级度量,逐级验证。这就是信任链(Chain of Trust)。

我习惯把它想象成一场接力赛。信任根是第一棒,它测量并验证第二棒;第二棒验证通过后,接过信任,再去测量第三棒……直到整个系统启动完成。任何一棒如果测量结果和预期不符,就立刻停止,系统进入安全状态。

2.2.1 典型的信任链传递过程(以PC为例)

  1. CRTM(核心信任根度量代码):固化在BIOS ROM里,是CPU复位后执行的第一段代码。它测量BIOS主固件的哈希值。
  2. BIOS/UEFI固件:CRTM验证通过后,BIOS获得控制权。它测量Option ROM(如网卡、显卡固件)和引导加载程序(Bootloader)。
  3. Bootloader:验证操作系统内核的签名和哈希。
  4. 操作系统内核:验证关键内核模块、驱动程序。
  5. 安全服务/应用:内核验证用户态的安全服务,比如远程证明代理。

每一步的度量结果,都会被扩展到TPM的PCR寄存器里。PCR的特点是:只能扩展(Extend),不能重置(除非重启)。扩展操作是:PCR_new = SHA256(PCR_old || 新度量值)。这样,最终的PCR值就包含了整个启动过程的完整指纹。

关键点: 信任链传递的核心是度量(Measure)和验证(Verify)分离。度量者只负责计算哈希并记录,验证者(通常是远程证明服务端)根据PCR值判断系统状态。这种分离设计,保证了即使度量代码有bug,也不会直接影响验证结果。

2.2.2 信任链的SVG流程图

信任链建立与传递流程 ① CRTM(硬件固化) ② BIOS/UEFI 固件 ③ Bootloader ④ 操作系统内核 ⑤ 安全服务/应用 每一步的度量结果(哈希值)都会被扩展到TPM的PCR寄存器中 最终PCR值 = SHA256( SHA256( ... SHA256(初始值 || 度量1) || 度量2) ... || 度量N)

2.3 TCB(可信计算基):不得不信任的那部分

TCB,全称Trusted Computing Base,中文叫可信计算基。定义很简单:系统中所有与安全相关的、必须被信任的软硬件组件的集合。

换句话说,如果TCB里的任何一个组件出了问题,整个系统的安全策略就失效了。所以,TCB的设计原则是:越小越好。

我记得有一次做安全审计,发现某个物联网设备的TCB竟然包含了整个Linux内核和所有用户态库——这哪是TCB,这简直是“全盘信任”。攻击者只要在内核里植入一个模块,整个信任链就崩塌了。

2.3.1 TCB的典型组成

  • 硬件层:CPU、TPM/TEE芯片、内存控制器、安全总线。
  • 固件层:CRTM、BIOS/UEFI安全部分、TEE安全操作系统(如TZOS、SGX PSW)。
  • 软件层:安全监控器(如SMM)、远程证明代理、密钥管理服务。
避坑指南: 我曾经见过一个团队把整个Java运行时环境都放进了TCB,理由是“远程证明服务用Java写的”。这是典型的TCB膨胀。正确的做法是:只把执行证明逻辑的最小代码单元放进TCB,其他部分(如网络通信、日志)放在TCB之外,即使它们被攻破,也不会影响证明结果。

2.3.2 TCB与信任链的关系

信任链是动态的建立过程,TCB是静态的组件集合。两者相辅相成:

  • 信任链的起点(信任根)必须是TCB的一部分。
  • 信任链传递过程中,每个被度量的组件,如果通过了验证,就加入TCB。
  • 最终,TCB包含了信任链上所有被信任的组件。

你想想看,如果信任链传递到Bootloader时,Bootloader的哈希和预期不符,那Bootloader就不会被加入TCB,系统会拒绝启动。这就是“信任链保证TCB的完整性”。

2.4 小结:三个概念,一个体系

咱们把这一节的核心串一下:

  • 硬件信任根(RoT):不可篡改的物理锚点,通常是TPM或TEE。
  • 信任链:从RoT出发,逐级度量、逐级验证的接力过程。
  • TCB:信任链上所有被信任组件的集合,越小越安全。

这三个概念,是远程证明的基石。没有硬件信任根,信任就是空中楼阁;没有信任链,信任无法传递;没有TCB的边界定义,你根本不知道自己在信任什么。