4. 可信平台模块(TPM)：TPM规范、TPM的功能、TPM在证书保护中的应用
聊到硬件密钥保护，TPM 是个绕不开的话题。我最早接触 TPM 是在做一款工控设备的证书管理时，当时客户要求密钥必须「硬件隔离」，软件方案一律不认。嗯，从那以后我才真正开始研究这个藏在主板上的小芯片。
TPM 的全称是 Trusted Platform Module，说白了就是一个独立的硬件安全芯片。它有自己的处理器、存储器和密码加速器，跟主 CPU 是物理隔离的。你想想看，就算操作系统被攻破了，攻击者也拿不到 TPM 里面的密钥——因为密钥根本就没出过芯片。
4.1 TPM 规范演进
TPM 规范由可信计算组织（TCG）制定。目前主流的有两个版本：TPM 1.2 和 TPM 2.0。我个人建议，新项目直接上 TPM 2.0，别犹豫。
| 特性 | TPM 1.2 | TPM 2.0 |
|---|---|---|
| 算法支持 | 仅 RSA、SHA-1 | RSA、ECC、SHA-256、SM3 等 |
| 密钥层次 | 单层 | 多层（可嵌套） |
| 授权机制 | 单一密码 | 密码 + Policy 会话 |
| 平台兼容性 | 仅 x86 | x86、ARM、RISC-V |
| 国密支持 | 无 | 可通过扩展支持 |
注意：TPM 1.2 的 SHA-1 算法已经不再安全。我在一次合规审计中遇到过客户要求必须禁用 SHA-1，结果发现设备里用的还是 1.2 规范，最后只能换芯片。所以，能上 2.0 就别省那点成本。
4.2 TPM 的核心功能
TPM 不是万能药，但它把几个关键功能做到了硬件级别。我把它总结为「三件套」：
- 密钥生成与存储：在芯片内部生成 RSA/ECC 密钥对，私钥永远不离开 TPM。外部只能拿到公钥。
- 平台度量与远程证明：记录系统启动过程中的度量值（PCR 寄存器），并向远程方证明当前平台状态是否可信。
- 密封与解封：将数据绑定到特定的平台状态。只有 PCR 值匹配时，才能解封数据。
举个例子。我在做一款金融 POS 机时，需要把商户证书的私钥保护起来。做法很简单：在 TPM 内部生成密钥对，然后用 TPM 的密封功能把私钥跟系统启动度量值绑定。一旦系统被篡改（比如换了内核），PCR 值就不匹配，私钥自动失效。攻击者就算把 Flash 拆下来读，拿到的也是一堆乱码。
小技巧：TPM 的密钥可以设置「迁移策略」。如果你需要备份密钥，记得在创建时指定可迁移标志。否则一旦芯片坏了，密钥就真没了——我吃过这个亏。
4.3 TPM 在证书保护中的应用
证书保护的核心是私钥保护。TPM 在这里扮演的角色，说白了就是一个「私钥保险箱」。具体怎么用？我画了一张图来说明。
实际项目中，我通常这样用 TPM 保护设备证书：
- 初始化阶段：在 TPM 内部生成一个 RSA-2048 或 ECC-P256 密钥对，作为设备的主密钥。
- 证书签发：将公钥导出，提交给 CA 签发设备证书。私钥留在 TPM 里。
- 证书存储：设备证书（含公钥）可以存在文件系统里，私钥不需要存——它一直在 TPM 里。
- 使用阶段：当需要 TLS 握手或签名时，应用把待签名数据发给 TPM，TPM 在内部完成签名，返回签名值。
关键点：整个过程中，私钥从未离开 TPM 芯片。即使攻击者获得了 root 权限，也无法导出私钥。这就是硬件隔离的价值。
4.4 实际项目中的避坑指南
TPM 虽好，但用起来有不少坑。我踩过几个，分享给你：
- TPM 芯片损坏：TPM 是有寿命的。写入次数过多会磨损。我曾经在一个频繁更新密钥的项目中，半年就干废了一块 TPM。解决方案是：非必要不写入，尽量用 TPM 的「临时密钥」功能。
- 平台状态变化：如果你用了密封功能，系统升级（比如 BIOS 更新）会导致 PCR 值变化，密封的数据就解不开了。我建议在升级前先解封数据，升级后再重新密封。
- 授权策略太复杂：TPM 2.0 的 Policy 会话非常灵活，但也非常容易配错。我见过有人配了一个永远无法满足的 Policy，导致密钥彻底废掉。建议从简单的密码授权开始，逐步增加策略。
重要提醒：TPM 不是防篡改芯片。它主要防的是软件攻击和远程攻击。如果攻击者能物理接触设备并实施高级侧信道攻击，TPM 也可能被攻破。所以，物理安全同样重要。
4.5 小结
TPM 是硬件密钥保护的基石。它把私钥锁在芯片内部，让软件攻击者无从下手。TPM 2.0 的算法支持和灵活性远优于 1.2，新项目建议直接采用。在实际应用中，密钥生成、密封、平台证明是三个最常用的功能。记住一点：私钥永远不要出 TPM，这是硬件保护的底线。