3、身份认证协议：AK的生成与管理、EK的角色、证书链验证流程
身份认证是远程证明的基石。说白了，设备要证明“我是我”，而不是某个冒牌货。TPM（可信平台模块）里有两把核心钥匙——EK（背书密钥）和AK（认证密钥）。很多人搞混它们的角色，甚至在生产环节就把密钥管理搞砸了。今天我把这些坑一个个说清楚。
3.1 EK：设备的“出生证明”
EK是TPM在出厂时烧录的一把RSA密钥对，私钥永远锁在TPM硬件里，无法导出。它的作用只有一个：证明这颗TPM芯片是合法的。
你可以把EK想象成设备的身份证号。它唯一、不可变，但你不能拿身份证号到处用——因为会泄露隐私。EK也一样，直接拿EK做身份认证会暴露设备身份，容易被追踪。
核心原则：EK只用于解密和签名少量关键数据，绝不用于日常通信认证。
我在项目中遇到过一家厂商，直接把EK证书塞进TLS握手里做设备认证。结果呢？所有设备的EK证书都是明文传输，攻击者抓包就能拿到全球唯一的设备标识。这等于把身份证号贴在了脑门上。
3.2 AK：设备的“临时工牌”
AK才是真正用于远程证明的身份凭证。它由TPM内部生成，私钥同样不可导出。但与EK不同，AK可以创建多个，可以定期轮换。
AK的生成流程是这样的：
- 调用TPM2_Create，指定密钥用途为“sign”（签名）
- TPM内部生成RSA或ECC密钥对
- 私钥加密存储在TPM的NVRAM中
- 公钥通过EK签名后导出，形成AK证书
我的习惯：AK的密钥强度至少RSA 2048位或ECC P-256。别为了省那几毫秒用1024位，现在云平台基本都拒收弱密钥了。
为什么要用EK来签名AK？因为验证方需要确认：这把AK确实来自一颗合法的TPM。EK就是那个担保人。
3.3 证书链验证流程
完整的验证链条分三步走。我画了一张图，你看完就明白了。
验证方向是从AK往上回溯，直到信任的根CA。每一步都要检查签名、有效期、吊销状态。
避坑指南：我曾经见过一个项目，验证服务只检查了AK证书的签名，跳过了EK证书的验证。结果攻击者用自己的TPM生成AK，伪造了EK签名。整个信任链瞬间崩塌。记住：每一级证书都必须验证，不能跳过任何一环。
3.4 AK的生成与管理
AK管理有几个关键点，搞错了就是灾难。
| 管理环节 | 推荐做法 | 常见错误 |
|---|---|---|
| 生成时机 | 设备首次注册时生成 | 每次连接都生成新AK |
| 存储位置 | TPM NVRAM，加密持久化 | 明文存文件系统 |
| 轮换周期 | 90天或按安全策略 | 从不轮换 |
| 吊销处理 | 维护AK吊销列表 | 只增不删，列表无限膨胀 |
生成AK时，TPM会返回一个公钥和一份由EK签名的声明。这个声明就是AK证书的雏形。验证方拿到后，先验签名，再验EK证书链。
我建议：AK证书里一定要带上设备ID、生成时间、密钥用途等扩展字段。别嫌麻烦，后期做审计和吊销时你就知道这些字段有多重要了。
3.5 实际部署中的坑
嗯，这里有几个我踩过的坑，你注意一下。
- EK证书过期：TPM厂商的EK证书有效期通常10年。但有些设备部署在恶劣环境，TPM内部时钟漂移严重，导致证书验证失败。解决办法是用挑战-响应机制获取TPM的当前时间戳。
- AK私钥丢失：TPM的NVRAM有写入寿命。频繁生成AK会磨损存储单元。我见过一台设备连续生成5000次AK后，NVRAM直接报废。控制生成频率，别让TPM累死。
- 证书链不完整：有些TPM只返回EK证书，不返回中间CA证书。验证方如果没有预置中间CA，链就断了。记得在设备端预置完整的证书链，或者让TPM返回整条链。
一句话总结：EK是设备的根身份，AK是会话身份。EK只用来担保AK，AK用来做日常认证。证书链必须逐级验证，缺一环都不行。
身份认证协议这块，说白了就是信任的传递。EK信任根CA，AK信任EK，验证方信任根CA。只要这个链条不断，设备身份就是可信的。但链条上的每一环都可能出问题——证书过期、签名算法弱、吊销信息不同步。你想想看，如果验证方用的根CA证书是5年前的，而设备EK证书是今年签发的，中间CA可能已经换过一轮了。链还能接上吗？
所以，部署前一定要做完整的证书链测试。别等到设备上线了才发现验证失败。