4. 密钥层次结构：持久化层次、EK、SRK、Platform
TPM 的密钥不是随便扔在内存里的。它有一套严格的层次结构，像一棵倒挂的树。根在硬件里，叶子在应用层。
我第一次接触这个结构时，觉得有点绕。后来在项目中调试一个密钥加载失败的问题，才真正理解了它的设计意图。说白了，每一层都有自己的职责，不能越级。
4.1 持久化层次（Persistent Hierarchy）
这是 TPM 里最特殊的一层。密钥一旦写入，除非你主动删除，否则它永远在那里。断电不会丢，重启不会丢。
核心特点：
- 密钥存储在 TPM 的 NVRAM 中
- 生命周期由平台所有者控制
- 通常用于存储根密钥、平台固件密钥
我遇到过一种情况：某厂商的 BIOS 在更新后，把持久化密钥的索引给改了。结果所有依赖该密钥的应用全部报错。嗯，这种问题排查起来特别头疼，因为你得先确认 TPM 里到底存了啥。
实用建议： 生产环境中，持久化密钥的索引号最好写死在配置管理里。别靠枚举去猜，容易翻车。
4.2 背书层次（EK - Endorsement Key）
EK 是 TPM 的身份证。每颗 TPM 芯片在出厂时，会生成一对唯一的 EK 密钥。私钥永远不出 TPM，公钥可以拿出来用。
你想想看，如果一台服务器要证明自己是正品，靠的就是 EK。它由 TPM 厂商或平台厂商签发证书，形成一条信任链。
| 属性 | 说明 |
|---|---|
| 生成时机 | TPM 出厂时预置，或首次初始化时生成 |
| 私钥可导出 | 否，永远锁在 TPM 内部 |
| 用途 | 身份证明、远程认证（Remote Attestation） |
| 证书 | 由 TPM 厂商或平台 OEM 签发 |
注意： EK 私钥一旦泄露，整颗 TPM 芯片的身份就废了。所以 TPM 规范里明确规定：EK 私钥不能用于加密数据，只能用于签名和认证。
4.3 存储层次（SRK - Storage Root Key）
SRK 是 TPM 存储体系的根。所有用户密钥、应用密钥，最终都受 SRK 保护。它就像一把万能锁，锁住了整个密钥树。
我个人习惯把 SRK 理解为「保险柜的柜门锁」。你往保险柜里放再多东西，最终都得靠这把锁来保护。SRK 的私钥同样不出 TPM，所有子密钥的加密解密操作，都在 TPM 内部完成。
SRK 的关键职责：
- 保护存储层次下的所有子密钥
- 支持密钥迁移（Key Migration）策略
- 提供密钥派生（Key Derivation）能力
我曾经在项目中踩过一个坑：SRK 的密码（AuthValue）忘了。结果所有基于该 TPM 的加密数据全部无法解密。后来我们强制要求：SRK 密码必须纳入密码管理系统，不能只靠人脑记。
4.4 平台层次（Platform Hierarchy）
这一层由平台固件（BIOS/UEFI）控制。它主要用于平台启动过程中的信任度量。说白了，就是测量从开机到操作系统加载这段过程中，每个组件的完整性。
平台层次的密钥生命周期很短。系统一重启，大部分平台密钥就失效了。这样做的好处是：攻击者即使拿到了平台层次的密钥，也无法用于后续攻击，因为系统已经重启了。
避坑指南： 我曾经见过有人把应用密钥放在平台层次里。结果系统一重启，密钥全丢了。记住：平台层次只适合存放启动过程中的临时密钥，不适合持久化存储。
4.5 层次结构总览
下面这张图把四个层次的关系画清楚了。你可以看到，每一层都有自己的根，互不干扰。
4.6 层次间的协作关系
这四个层次不是孤立的。它们在实际使用中会互相配合。举个例子：
- 系统启动时，平台层次测量 BIOS 和引导加载器的哈希值
- 操作系统加载后，应用通过 SRK 保护自己的加密密钥
- 需要远程证明身份时，使用 EK 进行签名
- 持久化层次存储关键的根证书和平台配置
关键原则： 每个层次只做自己该做的事。不要试图把应用密钥塞进持久化层次，也不要把平台密钥当成 SRK 用。层次清晰，系统才安全。