3. TPM/TCM芯片：TPM结构、PCR寄存器、密钥层次、TCM与国密标准
好，我们进入芯片级可信根的核心。TPM和TCM，说白了就是一颗专门干“信任”这活儿的独立安全芯片。我早年做服务器安全启动时，第一次接触TPM，当时觉得这东西不就是个加密协处理器吗？后来踩了坑才明白——它真正的价值，是提供了一个不可篡改的硬件信任锚点。
3.1 TPM硬件结构：一个微型安全计算机
TPM芯片内部，其实就是一个完整的微型计算机系统。它有自己的CPU、ROM、RAM、非易失性存储器（NVRAM），还有专门的密码引擎。我个人习惯把它的结构分成三大块：
- I/O 接口：通过LPC总线或SPI总线与主CPU通信。嗯，这里要注意，SPI接口的TPM现在更常见，因为速度更快。
- 密码协处理器：硬件加速RSA、ECC、SHA-256、AES等算法。我见过一些低端方案用软件模拟，那性能根本没法看。
- 非易失性存储：存放EK（背书密钥）、SRK（存储根密钥）和PCR值。这部分是物理防篡改的，你拿探针去读，芯片会自毁。
为什么说它安全？因为主CPU上的操作系统哪怕被攻破了，也无法直接读取TPM内部的密钥材料。所有敏感操作都在TPM内部完成，外部只能通过命令接口请求服务。
核心原则：TPM是一个“黑盒”安全模块。你给它数据，它给你签名或解密结果，但你永远拿不到它肚子里的密钥。
3.2 PCR寄存器：平台配置的“指纹”
PCR（平台配置寄存器）是TPM里我最看重的部分。你可以把它理解成一组只能扩展、不能重置（除非重启）的哈希累加器。
PCR的工作原理很简单：
- 每次度量一个组件（比如BIOS代码、引导加载器），计算其哈希值。
- 将新哈希值与PCR当前值拼接，再做一次哈希：
PCR_new = SHA256(PCR_old || new_measurement)。 - 这个新值写入PCR，覆盖旧值。
为什么用扩展而不是直接覆盖？因为这样能记录完整的度量链。你想想看，如果只存最后一个哈希，中间被篡改过你也发现不了。扩展操作保证了任何一步的改动，都会导致最终PCR值完全不同。
标准TPM 2.0规范定义了至少24个PCR寄存器，每个有特定的用途：
| PCR索引 | 用途 | 度量内容 |
|---|---|---|
| 0-1 | BIOS/固件 | 主机平台固件代码 |
| 2-3 | Option ROM | 扩展卡固件 |
| 4 | MBR/引导加载器 | 主引导记录或UEFI引导加载器 |
| 5 | 引导加载器配置 | GRUB配置、内核命令行 |
| 6 | 状态转换/休眠 | 平台状态恢复信息 |
| 7 | 安全策略 | 平台制造商定义的安全策略 |
| 8-15 | 操作系统使用 | 内核、initramfs、模块等 |
| 16-23 | 调试/厂商自定义 | 调试用途或厂商特定度量 |
避坑指南：我曾经在一个项目中，发现PCR值总是对不上。查了两天才发现，BIOS在POST阶段会动态加载不同的Option ROM，导致PCR 2-3的度量顺序不固定。解决方案是——在度量前先锁定Option ROM的加载顺序，或者使用PCR 0-1的静态固件度量作为基准。
3.3 密钥层次：从根密钥到会话密钥
TPM的密钥管理，是一个严格的树形层次结构。我习惯把它比作一个“密钥家族”：
- 根节点：背书密钥（EK）和存储根密钥（SRK）。EK是芯片的身份证明，由厂商在制造时注入，全球唯一。SRK是存储层次的总根，所有其他存储密钥都由它保护。
- 中间节点：存储密钥（Storage Key）。用于加密保护子密钥或数据。可以有多层，形成密钥树。
- 叶子节点：签名密钥、身份认证密钥、绑定密钥。这些是实际业务使用的密钥。
密钥的生成和使用，都遵循一个原则：父密钥加密子密钥。比如，SRK加密一个存储密钥，这个存储密钥再加密一个签名密钥。要使用签名密钥，必须先加载父密钥并验证口令。
我建议你在设计密钥层次时，遵循以下规则：
- EK永远不用于日常操作，只用于远程证明时的身份验证。
- SRK的授权数据（AuthValue）必须妥善保管，丢失意味着所有子密钥无法恢复。
- 每个业务模块使用独立的存储密钥，避免一个泄露导致全盘皆输。
重要提醒：TPM 2.0引入了“主密钥”概念（Primary Key），可以从种子派生，不需要存储在NVRAM中。这减少了NVRAM的磨损，但种子本身必须安全。我见过有人把种子明文写在配置文件中——那还不如不用TPM。
3.4 TCM与国密标准：本土化的可信计算
TCM（可信密码模块）是中国国家标准的TPM实现，核心差异在于密码算法。TPM使用RSA、SHA-256、AES等国际算法，而TCM强制使用国密算法：SM2（椭圆曲线公钥密码）、SM3（哈希算法）、SM4（对称加密）。
从结构上看，TCM和TPM 2.0非常相似，都有PCR、密钥层次、非易失性存储。但有几个关键区别：
| 特性 | TPM 2.0 | TCM |
|---|---|---|
| 公钥算法 | RSA (1024/2048/4096) | SM2 (256位椭圆曲线) |
| 哈希算法 | SHA-1, SHA-256 | SM3 (256位) |
| 对称算法 | AES (128/192/256) | SM4 (128位) |
| 密钥层次 | EK → SRK → 子密钥 | EK → SMK（存储主密钥）→ 子密钥 |
| PCR数量 | 至少24个 | 至少16个 |
| 标准规范 | ISO/IEC 11889, TCG规范 | GB/T 29829-2013, GM/T 0012-2012 |
在实际项目中，选择TPM还是TCM，主要看合规要求。如果是等保三级以上的政务系统，或者涉及国密改造的项目，必须用TCM。我参与过一个金融项目，客户明确要求所有密码操作必须使用国密算法，那TPM就完全不能用，只能上TCM。
实践建议：如果你的产品需要同时支持TPM和TCM，可以在软件层抽象一个“可信密码模块接口”。底层根据硬件类型调用不同的驱动，上层业务代码完全不用改。我做过一次这样的封装，后续切换芯片时省了至少两个月的开发量。
3.5 核心逻辑关系图
下面这张图，展示了TPM/TCM内部的核心组件和它们之间的数据流。我建议你把它打印出来贴在工位上——每次设计度量方案时，对照这张图检查一遍，能避免很多低级错误。
3.6 实践中的几个关键点
最后，分享几个我在项目中积累的经验：
- PCR选择要精准：不要一股脑把所有PCR都度量一遍。只度量你关心的组件。比如，如果你只验证内核完整性，度量PCR 4和PCR 8就够了，多了反而增加复杂度和性能开销。
- 密钥授权数据要管理好：TPM的每个密钥都可以设置口令（AuthValue）。我建议为不同安全级别的密钥设置不同强度的口令，并定期轮换。曾经有个项目，所有密钥都用同一个弱口令，结果一个泄露全完蛋。
- TCM的SM2签名性能：SM2签名比RSA-2048快，但验证稍慢。在高并发场景下，要注意TPM/TCM的吞吐量瓶颈。我遇到过每秒签名请求超过芯片处理能力的情况，最后加了本地缓存才解决。
- 固件升级要保留PCR值：升级BIOS或固件后，PCR值会变。如果你依赖PCR值做平台验证，记得在升级前记录基准值，升级后重新度量并比对。否则，所有基于旧PCR值的密钥和密封数据都会失效。
个人习惯：我在设计度量方案时，会先画一张“度量链图”，从硬件复位开始，到操作系统启动，每一步度量哪个PCR、用什么算法、预期值是多少，全部列清楚。这张图既是设计文档，也是调试时的排查工具。你试试看，真的很有用。