4、TPM与硬件信任根：TPM架构与功能、平台配置寄存器(PCR)、远程证明中的TPM角色
聊远程证明，绕不开一个硬核的东西——TPM。说白了，TPM就是一颗专门干脏活累活的加密芯片。它不跑你的业务代码，只管密钥、度量、签名这些信任相关的操作。我早年做IoT网关项目时，第一次把TPM集成进去，当时觉得这东西就是个“黑盒子”，后来踩了几个坑才真正摸透它的脾气。
4.1 TPM的架构与核心功能
TPM的全称是Trusted Platform Module，它不是一个软件库，而是一个独立的硬件安全模块。你可以把它理解成设备的“信任保险柜”。
它的架构大致分三层：
- I/O接口层：通过LPC、SPI或I2C与主CPU通信。IoT设备里常用SPI，速度快，引脚少。
- 密码引擎层：内置RSA、ECC、AES、SHA-256等硬件加速器。这些运算在硬件里跑，比CPU软件实现快得多，也安全得多。
- 非易失性存储(NV)：存储密钥、证书、PCR值。这部分数据掉电不丢失，而且有物理防篡改保护。
我个人习惯把TPM的功能归纳为四个核心：
| 功能 | 说明 | 我在项目中遇到的坑 |
|---|---|---|
| 密钥生成与存储 | 在芯片内部生成RSA/ECC密钥对，私钥永远不离开TPM | 有一次我试图把私钥导出备份，结果发现TPM根本不允许——这是设计如此，不是bug |
| 平台度量 | 对固件、引导加载程序、OS内核进行哈希度量，并记录到PCR | 度量顺序搞反了，PCR值对不上，折腾了两天才发现是启动顺序的问题 |
| 远程证明 | 用AIK(证明身份密钥)对PCR值签名，把度量报告发给验证方 | AIK证书链没配好，验证方不认，后来老老实实补了CA签发流程 |
| 密封与解封 | 将数据绑定到特定PCR状态，状态不对就解不开 | 固件升级后PCR变了，密封的数据全废了——后来加了升级策略才解决 |
核心要点：TPM的私钥永不出芯片。这意味着即使攻击者拿到了设备的物理访问权，也无法提取私钥。这是硬件信任根的根本优势。
4.2 平台配置寄存器(PCR)——信任的“账本”
PCR是TPM里最精妙的设计之一。你想想看，怎么证明一个设备没有被篡改？答案是记录下它从开机到现在的每一步状态。PCR就是干这个的。
PCR有几个关键特性：
- 不可逆扩展：PCR的值只能通过扩展操作更新。扩展公式是：
PCR_new = SHA256(PCR_old || 新度量值)。你不能直接写一个值进去，只能追加。 - 复位清零：系统重启时PCR会复位到初始值（通常是全0或全1）。这保证了每次启动的度量都是从零开始的。
- 固定数量：TPM 2.0规范定义了至少24个PCR，每个用于不同用途。比如PCR 0存BIOS/固件，PCR 2存Option ROM，PCR 8存引导加载程序。
我举个例子你就明白了。假设一个设备的启动链是这样的：
初始状态: PCR[0] = 0x0000...0000
第1步: 度量BIOS固件 → Hash = H_BIOS
PCR[0] = SHA256(0x0000...0000 || H_BIOS)
第2步: 度量Bootloader → Hash = H_BL
PCR[0] = SHA256(PCR[0] || H_BL)
第3步: 度量OS内核 → Hash = H_OS
PCR[0] = SHA256(PCR[0] || H_OS)
最终: PCR[0] = SHA256(SHA256(SHA256(0 || H_BIOS) || H_BL) || H_OS)
这个链式结构保证了：只要中间任何一个环节被篡改，最终的PCR值就会完全不同。而且你没法伪造——因为你不知道前面的度量值是什么。
我的经验：调试PCR时最容易犯的错误是度量顺序。我曾经在移植U-Boot时，把度量BIOS和度量Bootloader的顺序搞反了，结果PCR值怎么都对不上参考值。后来加了一行日志打印每个阶段的度量值，才定位到问题。建议你在开发阶段把每个PCR扩展的中间值都打出来，方便对照。
4.3 远程证明中的TPM角色
好了，现在我们有TPM，有PCR，那远程证明到底怎么跑？说白了，就是设备向验证方证明：“我的PCR值是合法的，我没有被篡改。”
但这里有个问题：PCR值本身是明文，如果直接发出去，中间人完全可以伪造。所以TPM引入了AIK（Attestation Identity Key）。
整个流程大致分四步：
- 挑战：验证方发送一个随机数（nonce）给设备，防止重放攻击。
- 度量：设备TPM读取当前PCR值，并用AIK私钥对“PCR值 + nonce”进行签名。
- 响应：设备把签名后的度量报告（包含PCR值、签名、AIK证书）发回验证方。
- 验证：验证方用AIK公钥验签，然后比对PCR值是否与预期一致。
这里AIK的作用很关键。AIK是TPM内部生成的一对密钥，它的公钥会由CA签发证书。验证方信任CA，所以信任AIK，进而信任TPM签名的PCR值。
注意：AIK不能用于加密数据，只能用于签名。这是TPM规范明确规定的。我曾经见过有人试图用AIK做TLS握手，结果发现TPM根本不支持——AIK的用途是证明，不是通信。
下面这张图展示了远程证明的完整数据流：
这张图把整个流程串起来了。你注意看，TPM在整个过程中扮演了三个角色：
- 度量记录器：PCR存储了设备的启动状态，这是信任的根基。
- 签名引擎：AIK私钥在TPM内部完成签名，私钥不会暴露给CPU或OS。
- 信任锚点：验证方通过AIK证书链追溯到CA，最终信任TPM的签名结果。
避坑指南：我曾经在一个项目中，设备端TPM签名成功了，但验证方始终验签失败。查了两天发现是AIK证书链不完整——我只发了叶子证书，没发中间CA证书。验证方无法构建完整的信任链，自然不认。记住，响应消息里一定要带上完整的证书链。
4.4 TPM 2.0在IoT中的特殊考量
TPM 2.0相比1.2有了很大改进，特别是在IoT场景下。我个人觉得最重要的三点：
| 特性 | TPM 1.2 | TPM 2.0 | IoT影响 |
|---|---|---|---|
| 算法支持 | 仅RSA/SHA-1 | RSA/ECC/SHA-256/SM3等 | ECC更适合低功耗设备 |
| PCR数量 | 固定24个 | 可配置(最少24) | 可裁剪，节省资源 |
| 授权机制 | 仅口令 | 口令/PIN/生物/策略 | 策略授权更灵活 |
| NV索引 | 有限 | 可动态创建 | 适合存储设备证书 |
嗯，这里要注意一点。很多IoT设备用的是MCU级别的芯片，资源非常有限。传统的独立TPM芯片可能塞不进去。这时候可以考虑fTPM（固件TPM）——它在TrustZone或TEE里用软件模拟TPM功能。虽然安全性比独立芯片差一点，但胜在成本低、集成方便。
警告：fTPM依赖TEE的安全性。如果TEE本身有漏洞，fTPM的信任根就崩塌了。我在一个项目里遇到过TEE侧信道攻击，攻击者通过功耗分析拿到了fTPM的密钥。如果你的设备对安全性要求极高（比如金融支付终端），还是老老实实用独立TPM芯片吧。
最后总结一下。TPM是远程证明的硬件根基，PCR是信任的“账本”，AIK是证明的“印章”。这三者缺一不可。你想想看，没有TPM，远程证明就只能依赖软件实现——那跟裸奔有什么区别？