3、TPM与设备身份：从芯片信任根说起
聊设备身份，绕不开TPM。我最早接触TPM是在做一款工业网关的时候，客户要求设备启动时必须证明自己是“原厂正品”，而不是被替换过的冒牌货。那时候我才真正意识到——TPM不只是一个安全芯片，它是设备数字身份的物理锚点。
说白了，TPM就是一颗专门干“脏活累活”的密码协处理器。它独立于主CPU，有自己的存储、随机数发生器和加密引擎。最关键的是，它内部有一组被称为“屏蔽寄存器”的区域，一旦写入，外部软件就再也读不出来了。嗯，这就是信任的起点。
3.1 TPM基础：一块“不会说谎”的芯片
TPM的全称是Trusted Platform Module，可信平台模块。它不是什么新东西，早在2005年就被标准化了，但真正大规模落地是在IoT设备上。我见过很多开发者把TPM当成普通的SE（安全元件）来用，其实两者思路完全不同。
TPM的核心能力可以归纳为四点：
- 密钥生成与存储：在芯片内部生成RSA或ECC密钥对，私钥永远不离开TPM
- 平台度量：记录系统启动过程中的每个组件哈希值，存到PCR（平台配置寄存器）里
- 远程证明：用AIK对PCR值签名，向远程验证方证明当前系统状态
- 密封存储：将数据与特定PCR值绑定，只有系统状态匹配时才能解密
我个人习惯把TPM比作一个“保险箱里的公证员”。它不参与业务逻辑，只负责两件事：证明“我是谁”，以及证明“我现在的状态是可信的”。
核心认知：TPM不是用来加密业务数据的，它是用来建立信任链的。设备身份的核心，就是TPM中那两把永远拿不出来的密钥——EK和AIK。
3.2 身份密钥：EK与AIK
TPM中有两把最重要的密钥，很多人搞混过，包括我刚开始的时候。咱们一个一个说清楚。
3.2.1 EK（Endorsement Key，背书密钥）
EK是TPM的“出生证明”。它在TPM出厂时就被写入，是一对RSA-2048密钥（或ECC密钥）。私钥永远锁死在TPM内部，公钥则随证书一起发布。
EK的特点：
- 唯一性：每个TPM的EK都不同，相当于芯片的“身份证号”
- 不可变：一旦生成，无法修改或删除
- 隐私风险：如果直接用EK做身份认证，所有设备的行为都会被追踪——因为EK是固定的
我在项目中遇到过一个问题：客户想直接用EK做设备登录凭证。我赶紧拦住了。为什么？因为EK一旦泄露（虽然私钥出不来，但公钥和证书是公开的），攻击者就能关联设备的所有通信记录。这在隐私合规上是大忌。
避坑指南：EK绝对不能直接用于身份认证或签名。它只用来做两件事：一是向CA证明“我是合法TPM”，二是协助生成AIK。我曾经见过一个方案把EK公钥直接写在设备证书里，结果被审计打回来重做——隐私保护不达标。
3.2.2 AIK（Attestation Identity Key，证明身份密钥）
AIK是EK的“替身”。它由TPM内部生成，私钥同样不出芯片。AIK的作用只有一个——对平台状态（PCR值）做签名，用于远程证明。
AIK的特点：
- 可派生：一个TPM可以生成多个AIK，每个用于不同的场景
- 可撤销：如果某个AIK泄露，可以吊销并生成新的
- 匿名性：AIK不直接暴露设备身份，验证方只知道“这是一个合法TPM签的数据”，但不知道是哪个设备
你想想看，EK和AIK的关系，就像你的身份证和酒店房卡。身份证（EK）证明你是你，但你不会每次进房间都刷身份证——太敏感了。你会用房卡（AIK），房卡是酒店临时发的，丢了可以补，而且酒店不知道你拿房卡去了哪个房间。
| 特性 | EK（背书密钥） | AIK（证明身份密钥） |
|---|---|---|
| 生成时机 | TPM出厂时 | 运行时按需生成 |
| 私钥位置 | TPM内部，永久锁定 | TPM内部，可删除 |
| 用途 | 证明TPM合法性、签发AIK证书 | 对PCR值签名、远程证明 |
| 隐私保护 | 弱（固定标识） | 强（可更换、匿名） |
| 证书颁发者 | TPM厂商或CA | 由EK向CA申请签发 |
| 生命周期 | 永久 | 按需创建/销毁 |
3.3 TPM在设备身份中的应用
讲完理论，咱们看看实际怎么用。TPM在设备身份中主要扮演三个角色：
3.3.1 设备身份注册
设备出厂时，TPM中已经烧录了EK及其证书。设备第一次上线时，会做这么几步：
- 设备向注册服务器发起请求，附带EK证书
- 服务器验证EK证书的合法性（是否由可信CA签发）
- 服务器生成一个挑战（随机数），要求设备用AIK签名
- 设备在TPM内部生成AIK，并用EK证明“这个AIK是我生成的”
- 服务器为AIK签发证书，完成设备身份注册
这个过程我称之为“零信任注册”。服务器不需要提前知道设备信息，完全靠TPM的密码学能力完成身份绑定。
3.3.2 远程证明
设备运行过程中，服务器可能需要验证设备是否被篡改。这时候就用到了远程证明：
- 服务器发送一个随机数nonce给设备
- 设备读取当前PCR值（包含BIOS、Bootloader、内核、关键配置的哈希）
- TPM用AIK对“PCR值 + nonce”做签名
- 设备将签名结果和PCR值一起返回给服务器
- 服务器用AIK公钥验签，并比对PCR值是否与预期一致
如果PCR值变了，说明系统被篡改过——可能是固件被替换，或者内核被注入了恶意代码。我在做车联网项目时，就用这套方案检测过某款T-Box的固件完整性，效果很好。
经验之谈：远程证明的nonce一定要用真随机数，不能是时间戳或递增序列。我曾经见过一个方案用设备启动时间做nonce，结果被重放攻击打穿——攻击者只要在相同时间窗口内重放签名数据，服务器就认为设备是健康的。
3.3.3 安全通道建立
设备身份确认后，下一步就是建立加密通信。TPM可以协助完成TLS握手：
- 用AIK签名的证书作为设备端证书
- TPM内部的密钥对用于TLS的密钥交换
- 私钥操作全部在TPM内部完成，主CPU接触不到私钥
这样做的好处是：即使攻击者拿到了设备的文件系统，也偷不走私钥。私钥在TPM里，物理上拿不出来。
3.4 一张图看懂TPM身份体系
下面这张图展示了EK、AIK、PCR和远程证明之间的协作关系。我画这张图的时候，特意把“信任传递”的路径标了出来——从硬件信任根（EK）到运行时证明（AIK + PCR），再到远程验证。
3.5 实际部署中的几个坑
TPM虽然强大，但部署起来有不少细节。我踩过几个坑，分享出来：
- EK证书的获取：不是所有TPM厂商都预置了EK证书。有些廉价TPM只烧了公钥，证书需要你自己向CA申请。我建议采购时确认清楚，否则设备注册流程会卡住。
- PCR值的基准管理：每次固件升级，PCR的基准值都会变。你需要一套机制来同步更新服务器端的白名单。我见过有人手动维护，结果漏更新导致大批设备被判定为“不可信”。
- AIK的存储数量：TPM内部存储空间有限，一般只能同时存几个AIK。如果你的设备需要同时连接多个平台，记得设计AIK的复用或轮换策略。
- 性能开销：RSA-2048签名在TPM中大约需要100-200ms。如果设备需要频繁做远程证明（比如每5秒一次），CPU会被拖垮。我一般建议证明间隔不少于30秒。
我的建议：刚开始做TPM集成时，先用模拟器（比如IBM的TPM模拟器或swtpm）把流程跑通，再移植到真芯片上。真芯片的调试手段有限，出了问题很难定位。我在第一个项目中直接在真芯片上调试，结果一个PCR值对不上，查了三天才发现是TPM驱动版本不匹配。
TPM与设备身份的结合，本质上是在硬件层面建立了一个不可伪造的信任锚点。EK是出生证明，AIK是工作证，PCR是体检报告——三者配合，才能让远程验证方确信：对面那台设备，确实是它声称的那个“它”，而且没有被篡改过。