3、TPM与可信启动：TPM芯片功能、PCR寄存器、度量启动与远程证明

聊到可信启动，TPM 芯片是绕不开的核心。很多人觉得 TPM 就是个“存密钥的保险箱”，其实远不止这么简单。我最早接触 TPM 是在一台老旧的工控机上，当时为了满足等保三级要求，硬着头皮啃了一周 TCG 规范。后来才明白，TPM 真正的价值在于——它能让平台“说实话”。

3.1 TPM 芯片到底在干什么？

TPM（Trusted Platform Module）是一个独立的安全微控制器。它有自己的处理器、非易失性存储、甚至内置了真随机数发生器。说白了，它不依赖主 CPU 和操作系统，自己就能完成一系列密码学操作。

我个人习惯把 TPM 的功能归纳为三类：

• 密钥管理：生成、存储、使用密钥，私钥永远不离开芯片。
• 平台度量：记录系统各组件的哈希值，并保证这些记录不可篡改。
• 远程证明：向外部验证者证明当前平台的“身份”和“状态”。

3.2 PCR 寄存器——平台的“指纹记录仪”

PCR（Platform Configuration Register）是 TPM 内部的一组寄存器。每个 PCR 存储一个 20 字节（SHA-1）或 32 字节（SHA-256）的哈希值。关键特性是：PCR 只能扩展，不能直接写。

扩展操作是这样的：

PCR_new = SHA256( PCR_old || new_measurement )

嗯，这里要注意。这意味着一旦某个组件被度量，它的哈希值就“融入”了 PCR 的当前值。你想回滚？不可能。因为要找到另一个输入使得扩展后的结果等于之前的值，这在计算上是不可行的。

我在项目中遇到过一个问题：某次固件升级后，TPM 始终不释放某些密钥。查了半天，发现是 BIOS 升级导致 PCR 值变了，而密钥策略绑定了旧的 PCR 值。这就是 PCR 的“刚性”——它不会因为你觉得“应该没问题”就放行。

常见的 PCR 分配如下：

PCR 索引	度量内容	典型用途
0	BIOS/固件代码	验证固件完整性
1	主板配置	检测硬件变更
2	Option ROM 代码	验证扩展卡固件
3	Option ROM 配置	检测扩展卡配置
4	MBR/引导加载程序	验证引导扇区
5	引导加载程序配置	检测引导参数
6	状态转换/唤醒	休眠恢复检测
7	制造商保留	厂商自定义
8-15	操作系统使用	IMA、LUKS 等

3.3 度量启动——从按下电源键开始

度量启动（Measured Boot）是可信启动的核心流程。它不像 Secure Boot 那样直接阻止未签名代码运行，而是记录每一个启动组件的哈希值，然后交给 TPM 保管。

流程大致是这样的：

1. CRTM（Core Root of Trust for Measurement）是第一个运行的代码。它度量 BIOS 固件，将结果扩展到 PCR 0。
2. BIOS 度量 Option ROM 和引导加载程序，扩展到 PCR 2、PCR 4。
3. 引导加载程序（如 GRUB）度量内核和 initramfs，扩展到 PCR 8 或 PCR 9。
4. 内核 继续度量后续模块，通过 IMA（Integrity Measurement Architecture）扩展到 PCR 10。

你想想看，这一连串的度量就像一条信任链。每个环节都测量下一个环节，并把测量值存进 PCR。只要有一个环节被篡改，PCR 的值就会和预期不同。

我曾经帮一个客户排查服务器无法远程证明的问题。折腾了两天，最后发现是 GRUB 的配置文件里多了一个启动参数。那个参数本身无害，但导致 PCR 5 的值变了，远程证明服务器直接拒绝了连接。这就是度量启动的“诚实”——它不管你有没有恶意，只认哈希值。

3.4 远程证明——如何让第三方相信你是“干净的”

度量启动只是把证据存进了 TPM。但怎么让网络上的另一台机器相信你的平台是可信的呢？这就需要远程证明（Remote Attestation）。

远程证明的核心思想是：

• 验证者（Verifier）向证明者（Attester）发送一个随机数（Nonce）。
• 证明者用 TPM 的 AIK（Attestation Identity Key）对当前 PCR 值和 Nonce 进行签名。
• 验证者收到签名后，用 AIK 的公钥验证签名，然后比对 PCR 值是否与预期一致。

这里的关键是 AIK。AIK 是由 TPM 内部生成的密钥对，私钥永远不离开芯片。验证者可以通过 TPM 的背书密钥（EK）证书来确认 AIK 确实来自一个真实的 TPM。

我习惯把远程证明比作“体检报告”：PCR 值是体检指标，AIK 签名是医院的公章，EK 证书是医院的资质证明。三者缺一不可。

下面这张图展示了远程证明的完整交互流程：

3.5 日志分析：从 PCR 值反推启动过程

TPM 只存 PCR 的最终值，不存历史记录。那如果远程证明失败了，怎么知道是哪个环节出了问题？答案是：度量日志（Event Log）。

度量日志是 BIOS 和引导加载程序在度量过程中同步写入内存的。它记录了每个度量事件的详细信息，包括：

• PCR 索引
• 度量值（哈希值）
• 被度量组件的描述信息
• 度量时的类型标识

分析日志时，我会这样做：

1. 从 TPM 中读出当前的 PCR 值。
2. 从 /sys/kernel/security/tpm0/binary_bios_measurements 读取度量日志。
3. 按照日志顺序，重新计算 PCR 的预期值。
4. 比对预期值和实际值。如果一致，说明日志可信；如果不一致，说明日志被篡改或度量过程有遗漏。

我曾经用这个办法定位过一个诡异的问题：某台服务器每次重启后 PCR 4 的值都不同，但度量日志看起来是正常的。后来发现是硬盘的 MBR 区域有坏道，GRUB 在读取时自动做了纠错，导致实际加载的代码和日志记录的不一致。嗯，这种硬件层面的问题，光看日志是看不出来的，得结合硬件诊断工具。