4、身份认证机制：设备身份、平台身份与身份绑定
身份认证，说白了就是回答一个问题：「你是谁？」
在远程证明的场景里，这个问题没那么简单。你想想看，一个设备要证明自己是合法的，它得拿出什么凭证？是芯片里烧录的一个序列号，还是某个硬件模块生成的签名？
我个人习惯把设备身份分成两层来看：一层是设备身份，另一层是平台身份。这两者经常被混为一谈，但实际落地时差别很大。
4.1 设备身份（Device Identity）
设备身份，就是设备出厂时被赋予的一个「身份证」。它通常是唯一的、不可篡改的。
我在项目中遇到过不少厂商，直接把 Wi-Fi MAC 地址当设备身份用。嗯，这其实很危险——MAC 地址是可以伪造的。真正的设备身份，应该绑定在硬件层面。
设备身份的常见载体：
- 唯一设备标识符（UDID）：芯片出厂时烧录的 128 位随机数，不可更改。
- 硬件安全模块（HSM）：在安全芯片内部生成并存储的密钥对，私钥永远不离开芯片。
- 一次性可编程存储器（OTP）：芯片内部的一块只写一次的区域，用于存储证书或哈希值。
设备身份的核心要求就两条：唯一性和抗篡改性。缺一不可。
4.2 平台身份（Platform Identity）
平台身份比设备身份高一个层次。它描述的是「这个设备当前运行的环境是否可信」。
举个例子：一台手机，它的设备身份可能是高通芯片里的序列号。但平台身份呢？它要证明这台手机的 Bootloader 没被解锁、系统分区没被篡改、内核是官方签名的。
说白了，平台身份是动态的。它依赖于信任链的度量结果。
| 对比维度 | 设备身份 | 平台身份 |
|---|---|---|
| 生命周期 | 出厂即固定，终身不变 | 每次启动时重新建立 |
| 存储位置 | OTP、安全芯片内部 | TPM 平台配置寄存器（PCR） |
| 证明方式 | 用私钥签名一个挑战值 | 用 AIK 签名 PCR 度量值 |
| 抗伪造能力 | 高（硬件绑定） | 中高（依赖信任链完整性） |
我记得有一次调试一个 IoT 网关，设备身份验证通过了，但平台身份始终报错。查了两天才发现，是 UEFI 安全启动被意外关闭了。你看，设备身份没问题，但平台已经不可信了。
4.3 身份绑定与认证协议
有了设备身份和平台身份，接下来要解决一个问题：怎么把它们绑定在一起，并且让远程验证方相信？
这就涉及到身份绑定协议。常见的做法是：
- 设备身份注册：设备在首次联网时，用设备私钥签名一个注册请求，服务器记录设备公钥。
- 平台身份证明：设备用 AIK（平台身份认证密钥）签名当前的 PCR 值，证明平台状态。
- 绑定凭证生成：服务器将设备身份和平台身份绑定，生成一个联合凭证（如 X.509 证书），下发给设备。
- 后续认证：设备每次通信时，出示这个联合凭证，服务器验证签名链。
避坑指南：我曾经在一个项目里踩过坑——设备身份和平台身份用了两套完全独立的密钥体系，结果验证方需要查两次数据库，延迟直接翻倍。后来我们改用联合证书，把两个身份绑定在一个凭证里，性能提升很明显。
4.4 核心认证协议对比
目前主流的身份认证协议有这么几种，我简单列一下它们的差异：
| 协议 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| TPM 2.0 远程证明 | PC、服务器、网关 | 标准化程度高，生态成熟 | 实现复杂，需要 TPM 芯片 |
| DICE（设备标识组合引擎） | IoT 设备、嵌入式系统 | 轻量级，适合资源受限设备 | 需要硬件支持，灵活性较低 |
| IEEE 802.1AR | 网络设备、交换机 | 与网络层无缝集成 | 仅适用于网络设备 |
| FIDO 2.0 | 用户认证、移动设备 | 用户体验好，支持生物识别 | 偏重用户身份，设备身份较弱 |
我个人比较推荐 DICE 方案，尤其是做 IoT 的朋友。它把设备身份和平台身份在硬件启动阶段就绑定好了，后面不用再折腾复杂的协议栈。
4.5 身份认证的完整流程
下面这张图，是我自己画的一个身份认证流程。它把设备身份、平台身份和绑定协议串在了一起。
注意：身份绑定不是一次性的。设备固件升级、系统更新、硬件更换后，平台身份会发生变化，需要重新执行绑定流程。我曾经见过一个团队，设备升级后忘了重新绑定，结果所有设备都被远程验证方判定为不可信，运维同学差点崩溃。
4.6 小结
身份认证机制，是远程证明的基石。设备身份解决「你是谁」的问题，平台身份解决「你当前是否可信」的问题，身份绑定协议把两者拧在一起。
选型的时候，我建议你根据设备的硬件能力来定。有 TPM 的，走 TPM 2.0 远程证明；资源受限的，用 DICE；网络设备，考虑 802.1AR。别盲目追求高大上的方案，适合的才是最好的。