3、TPM技术详解：TPM的架构与功能、TPM密钥层次结构、TPM在证明中的作用
TPM，全称Trusted Platform Module，说白了就是一颗专门干脏活累活的加密安全芯片。我最早接触TPM是在做一款金融POS机的时候，当时客户要求必须支持TPM 2.0，我心想不就是个存密钥的芯片吗？后来踩了不少坑才明白，TPM远不止是个“钥匙柜”。
3.1 TPM的物理架构与核心功能
TPM本质上是一个独立的SoC，有自己的CPU、ROM、RAM、非易失性存储（NVRAM），以及真随机数发生器（TRNG）。它跟主CPU通过LPC或SPI总线通信，操作系统通过内核驱动访问它。
我个人习惯把TPM的功能拆成三块：
- 度量（Measure）：对代码和配置做哈希，把结果存到平台配置寄存器（PCR）里。这个过程叫“度量启动”，也叫信任链传递。
- 存储（Store）：密钥可以密封（Seal）到特定PCR值上。PCR值不对，密钥就解不开。这比单纯加密要狠得多。
- 证明（Attest）：用AIK（Attestation Identity Key）对PCR值签名，远程验证方就能确认你的平台状态是否可信。
核心概念：TPM不是用来加速运算的，它是用来“担保”的。它担保你的固件没被改过，担保你的密钥只在安全环境里被使用。你想想看，如果攻击者改了你的Bootloader，PCR值就会变，后续所有密封操作都会失败——这就是硬件信任根的价值。
3.2 TPM密钥层次结构
TPM的密钥管理是个树形结构，我刚开始看Spec的时候差点被绕晕。后来我画了一张图，一下就清楚了。
这张图里，EK是硬件身份，SRK是存储保护的总闸门。所有子密钥（AIK、SK、BEK）都由SRK加密保护。叶子密钥是真正干活的，但它们不能离开TPM——除非你显式设置成“可迁移”。
避坑指南：我曾经在一个项目中，把AIK设置成了可迁移密钥。结果远程证明时，验证方发现AIK的签名密钥可以被导出，直接判定平台不可信。记住：AIK必须标记为“fixedTPM”和“fixedParent”，否则证明就没有意义。
3.3 TPM在证明中的核心作用
远程证明（Remote Attestation）是TPM最性感的功能。它的流程其实不复杂，我拆成四步讲：
- 挑战（Challenge）：验证方（比如云平台）发一个随机数Nonce给设备，防止重放攻击。
- 度量（Measure）：设备用TPM对当前固件、Bootloader、OS内核做哈希，扩展到PCR里。
- 签名（Sign）：TPM用AIK对PCR值和Nonce做签名，生成一个Quote结构。
- 验证（Verify）：验证方拿到Quote，用AIK的公钥验签，再比对PCR值是否跟预期一致。
你想想看，如果攻击者篡改了内核，PCR值就会变，Quote里的签名自然对不上。验证方直接拒绝接入——这就是硬件级信任。
关键点：TPM的证明不是证明“你是谁”，而是证明“你是什么状态”。它回答的是：你的启动链是否完整？你的固件是否被篡改？你的安全配置是否合规？
3.4 实际项目中的TPM选型与配置
我做过几个IoT网关项目，TPM选型上踩过不少坑。下面这张表是我个人总结的对比：
| 特性 | TPM 1.2 | TPM 2.0 |
|---|---|---|
| 算法支持 | 仅SHA-1、RSA | SHA-256、ECC、SM3/SM4（国密） |
| 密钥层次 | 固定三层 | 灵活多级，支持自定义 |
| PCR数量 | 固定24个 | 可配置，最多32个 |
| 远程证明 | 仅支持AIK签名 | 支持AIK + 匿名证明（DAA） |
| 国密支持 | 不支持 | 原生支持SM2/SM3/SM4 |
我个人建议：新项目直接上TPM 2.0。1.2的SHA-1已经不安全了，而且国密场景下1.2完全没法用。我在一个政务项目中就吃过这个亏——客户要求SM2签名，结果TPM 1.2根本不支持，最后只能外挂加密芯片，折腾了两个月。
警告：TPM 2.0虽然灵活，但配置复杂度也上去了。尤其是PCR的扩展策略，如果配置不当，可能导致每次重启PCR值都不一样，远程证明永远失败。我建议在开发阶段就写好PCR预期值的白名单，并做自动化测试。
3.5 一个简单的TPM Quote示例
下面是一个用tpm2-tools生成Quote的典型流程。嗯，这里要注意：实际生产环境中，Nonce必须由验证方生成，不能设备自己生成。
# 1. 获取AIK句柄（假设AIK已经创建）
tpm2_getcap handles-persistent
# 2. 验证方生成Nonce（这里用随机数模拟）
nonce=$(openssl rand -hex 16)
echo "Nonce: $nonce"
# 3. 对指定PCR（比如PCR 0-7）生成Quote
tpm2_quote \
--key-context 0x81000001 \
--pcr-list sha256:0,1,2,3,4,5,6,7 \
--message quote.msg \
--signature quote.sig \
--qualification "$nonce"
# 4. 验证方验签（需要AIK公钥）
tpm2_checkquote \
--public aik.pub \
--message quote.msg \
--signature quote.sig \
--qualification "$nonce"这段代码里，tpm2_quote会读取PCR值，用AIK签名，输出一个签名结构。验证方用tpm2_checkquote验签，同时比对PCR值。如果PCR值跟预期不符，验签会失败。
小技巧：我在项目中习惯把PCR预期值存到区块链或可信数据库中。每次验证时，不光验签，还要查一下这个PCR组合是否在“白名单”里。这样可以防止攻击者用合法签名但篡改过的PCR值来欺骗验证方。
TPM的证明机制，说白了就是“硬件担保+密码学签名”。它不解决所有安全问题，但它给了你一个可信的起点。没有TPM，你的远程证明就只能依赖软件——而软件是可以被篡改的。嗯，这就是TPM不可替代的原因。