设备身份基础：定义、区别与生命周期管理
聊远程证明，绕不开一个最基础的问题——设备到底怎么证明「我是我」？
这听起来像哲学问题，但在物联网里，它非常具体。我早年做智能门锁项目时，就吃过这个亏。当时只关注了用户身份认证，觉得设备只要能联网、能上报数据就行。结果呢？设备被克隆了，后台根本分不清哪把锁是真的。那次之后我才真正意识到：设备身份，是物联网安全的基石。
设备身份的定义
设备身份，说白了就是物联网设备在数字世界里的唯一标识。它让一台设备能被系统准确识别、信任和授权。
一个完整的设备身份，通常包含三个要素：
- 唯一标识符：比如设备序列号、MAC 地址、IMEI。这是最基础的「身份证号」。
- 身份凭证：比如数字证书、预置密钥、TPM 中的私钥。这是用来证明「我就是我」的凭据。
- 属性信息：比如设备型号、固件版本、制造商、生产批次。这些描述设备「是什么」。
核心观点：设备身份不是静态的标签，而是一组可验证的、与设备绑定的数字资产。没有身份凭证的标识符，就像没有密码的账号——谁都能用。
举个例子。你家的智能灯泡，MAC 地址是它的标识符。但如果它每次连接云端时，只报 MAC 地址而不带任何签名或证书，那攻击者完全可以伪造一个相同的 MAC 地址来冒充它。这就是为什么设备身份必须包含「可验证」的凭证。
设备身份与用户身份的区别
很多人容易把设备身份和用户身份搞混。我刚开始做 IoT 安全时也犯过这个错。其实它们有本质区别。
| 维度 | 设备身份 | 用户身份 |
|---|---|---|
| 主体 | 物理设备（传感器、网关、控制器） | 自然人（管理员、操作员、终端用户） |
| 生命周期 | 从生产到销毁，通常数年甚至更长 | 从注册到注销，可能随人员变动频繁变化 |
| 凭证类型 | 数字证书、预置密钥、硬件安全模块绑定 | 密码、生物特征、OTP、OAuth Token |
| 交互方式 | 机器对机器（M2M），自动完成 | 人机交互，需要输入或生物识别 |
| 安全目标 | 防克隆、防篡改、防冒充 | 防盗用、防冒用、防钓鱼 |
| 典型场景 | 设备接入认证、固件签名验证 | 用户登录、权限审批、操作审计 |
你想想看，用户身份可以随时改密码、换手机号，甚至注销账号。但设备身份一旦出厂，它的硬件标识和密钥通常是固定的。我见过一个项目，把用户身份的逻辑直接套在设备上，结果设备换了个用户就「变砖」了——因为设备身份和用户身份强绑定了。
我的建议：在设计系统时，一定要把设备身份和用户身份解耦。设备身份用于「这台设备是否可信」，用户身份用于「这个操作者是否有权限」。两者通过访问控制策略关联，而不是硬编码在一起。
设备身份的生命周期管理
设备身份不是一成不变的。它从出生到报废，经历多个阶段。每个阶段都有不同的安全风险和管理要点。
我个人习惯把设备身份生命周期分为六个阶段：
- 生产注入：在工厂产线上，把身份凭证写入设备安全存储区。
- 初始注册：设备首次联网，向平台注册身份并建立信任关系。
- 正常运行：设备在运行期间，持续使用身份凭证进行认证和通信。
- 凭证更新：证书到期或密钥泄露时，安全更换身份凭证。
- 挂起/恢复：设备异常时临时冻结身份，问题解决后恢复。
- 注销销毁：设备报废或退役时，彻底清除身份凭证。
下面这张图，是我常用的设备身份生命周期管理框架：
生产注入阶段
这是设备身份的「出生时刻」。我建议在产线上就把身份凭证写入硬件安全模块（如 TPM、SE、TEE）。
曾经有个客户，为了省成本，把密钥放在固件里明文存储。结果产品上市三个月，就被破解了。嗯，后来他们重新设计了产线注入流程，代价是几百万的召回费用。
避坑指南：千万不要在产线之外生成设备密钥。我曾经见过开发团队在办公室用脚本批量生成密钥，然后通过邮件发给工厂——这等于把钥匙复制了无数份。正确的做法是：在产线的安全环境中，使用 HSM 或专用注入设备，一次性写入且不可导出。
初始注册阶段
设备第一次联网时，需要向平台证明自己的身份。这个过程通常涉及证书链验证或预置密钥的挑战-响应认证。
这里有个细节：初始注册时，设备应该同时上报自己的硬件指纹（如 TPM 的 EK 证书、芯片唯一 ID）。这样即使凭证被替换，平台也能通过硬件指纹发现异常。
正常运行阶段
设备在运行期间，身份凭证用于每次通信的认证。我推荐使用双向 TLS（mTLS），设备和服务端互相验证证书。
但要注意性能问题。有些低功耗设备每次握手都做完整证书链验证，功耗扛不住。我的做法是：首次握手做完整验证，后续使用会话票据（session ticket）或预共享密钥（PSK）来降低开销。
凭证更新阶段
证书会过期，密钥可能泄露。所以设备必须支持凭证更新机制。
我曾经设计过一个 OTA 证书续期方案：设备在证书到期前 30 天，主动向平台发起续期请求。平台验证设备当前身份后，下发新证书。整个过程在后台自动完成，用户无感知。
我的经验：凭证更新一定要有回退机制。如果新凭证写入失败，设备还能用旧凭证继续工作。否则，一次 OTA 失败就可能导致设备永久离线——我在一个智能电表项目里就踩过这个坑。
挂起/恢复阶段
设备被报失、检测到异常行为或固件被篡改时，平台应该能远程挂起设备身份。挂起后，设备无法通过认证，但保留所有数据。
恢复时，需要管理员人工审核，确认设备安全后再解除挂起。这个机制能有效遏制攻击扩散。
注销销毁阶段
设备报废时，必须彻底清除身份凭证。如果只是物理销毁而不清理数字身份，攻击者可能从回收的存储芯片中提取密钥。
我建议的做法是：设备在退役前，向平台发送注销请求，然后安全擦除所有密钥和证书。对于有 TPM 的设备，可以直接调用 TPM2_EvictControl 来清除持久化密钥。
// 设备注销时的安全擦除示例（伪代码）
function decommissionDevice() {
// 1. 向平台发送注销请求
platform.revokeIdentity(deviceId);
// 2. 清除 TPM 中的持久化密钥
tpm2_evictcontrol -H 0x81000001 -o handle.ctx
// 3. 擦除安全存储区
secureStorage.eraseAll();
// 4. 写入销毁标记
secureStorage.write("STATUS", "DECOMMISSIONED");
// 5. 自毁触发（可选）
selfDestruct();
}嗯，设备身份管理这件事，看似基础，但做扎实了，整个远程证明体系才能站得住。下一层我们就要聊——如何用这些身份凭证，去构建可信的远程证明协议。