设备身份与密钥管理：Device ID、Pre-shared Key 与 Certificate
设备注册的第一步，就是给设备一个「合法身份」。说白了，你得让服务器知道：你是谁？你凭什么来注册？
我见过不少项目，一上来就急着写注册逻辑，结果设备身份管理一团糟。上线后才发现设备 ID 冲突、密钥被硬编码、证书过期没人管……嗯，这些坑我都踩过。今天咱们就把这块彻底捋清楚。
3.1 设备唯一标识（Device ID）
Device ID 是设备的「身份证号」。它必须在整个系统中唯一，且不可篡改。我个人习惯用芯片的硬件唯一标识（如 MCU UID、EUI-64）作为基础，再拼接产品型号和批次号。
3.1.1 生成方式对比
| 方案 | 唯一性 | 安全性 | 适用场景 |
|---|---|---|---|
| 芯片 UID | 高（出厂烧录） | 中（可读） | MCU 类设备 |
| UUID v4 | 极高（随机） | 高（不可预测） | 软件生成 |
| MAC + 时间戳 | 中（可能冲突） | 低（可伪造） | 不推荐 |
| 自定义组合 | 高（需管理） | 中 | 企业私有协议 |
我在一个智能门锁项目里用过芯片 UID 方案。结果发现同一批次有 3 颗芯片 UID 完全一样——供应商烧录出了问题。从那以后，我坚持在 UID 后面追加生产序列号，双重保险。
3.1.2 存储与保护
Device ID 必须存储在安全区域。对于有 SE 的设备，直接写入 SE 的不可读寄存器。没有 SE 的话，至少要做以下保护：
- 写一次后锁定：防止生产后被篡改
- CRC 校验：检测存储区是否被破坏
- 备份区：主区损坏时自动恢复
3.2 预置密钥（Pre-shared Key）
PSK 是设备与服务器之间的共享秘密。它用于注册阶段的身份验证，以及后续通信的加密基础。
3.2.1 密钥生成策略
PSK 不能是简单的固定密码。我建议采用「设备主密钥 + 派生因子」的方式：
// 伪代码示例：PSK 派生
master_key = HSM 生成的主密钥（每批次不同）
device_salt = SHA256(Device_ID + batch_secret)
PSK = HKDF-Expand(master_key, device_salt, 32)
这样做的好处是：即使某个设备的 PSK 泄露，也不会影响同批次的其他设备。
3.2.2 密钥注入流程
- 生产环境：在安全工位通过 HSM 或 SE 写入
- 传输保护：使用 TLS 或物理隔离通道
- 写入验证：写入后立即回读校验
- 销毁临时密钥：注入完成后清除中间变量
3.3 证书（Certificate）
证书是比 PSK 更高级的身份凭证。它基于 PKI 体系，支持双向认证和证书链验证。说实话，对于大规模 IoT 部署，证书管理比 PSK 复杂得多，但安全性也高一个量级。
3.3.1 证书生命周期
| 阶段 | 操作 | 关键点 |
|---|---|---|
| 生成 | 在 SE 内生成密钥对 | 私钥永不出 SE |
| 签名 | CSR 提交到 CA | CA 离线或云端 |
| 分发 | 证书写入 SE | 与私钥绑定 |
| 使用 | TLS 握手时出示 | 验证证书链 |
| 续期 | 到期前重新签发 | OTA 更新 |
| 撤销 | 加入 CRL 或 OCSP | 设备报废时 |
3.3.2 证书格式与存储
IoT 设备常用 X.509 v3 证书，但要注意精简：
- 去除不必要的扩展项：减少证书体积
- 使用 ECC 而非 RSA：密钥更短，计算更快
- 证书链只保留中间 CA：根 CA 预置在固件中
// 证书结构示例（精简版）
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 0x12345678
Signature Algorithm: ecdsa-with-SHA256
Issuer: CN = IoT Device CA
Validity:
Not Before: Jan 1 00:00:00 2025 GMT
Not After : Dec 31 23:59:59 2025 GMT
Subject: CN = device-001234
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
EC Public Key: (256 bit)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
3.4 三种身份方案的选择
你可能会问：到底该用 PSK 还是证书？我的建议是：
- 低成本设备（如传感器）：PSK + Device ID，够用
- 中等安全需求（如网关）：PSK + 动态令牌
- 高安全场景（如金融支付）：证书 + SE
但说实话，现在芯片成本越来越低，我倾向于直接上证书。你想想看，PSK 一旦泄露，你得挨个设备换密钥，那运维成本……嗯，谁干谁知道。
3.5 核心流程总览
下面这张图概括了设备身份与密钥管理的完整流程。从生产到注册，每一步都环环相扣。
3.6 避坑指南
最后，分享几个我亲身踩过的坑：
- 密钥硬编码：我曾经在一个项目里发现，测试用的 PSK 被直接编译进了 release 固件……那批设备全部召回重刷。
- 证书链不完整：设备只存了设备证书，没存中间 CA。结果服务器验证时找不到中间证书，握手失败。记住：设备至少要存完整证书链。
- Device ID 重复：生产时多线烧录，计数器没同步，导致两个设备 ID 一样。后来我强制要求用芯片 UID + 产线时间戳，再没出过问题。
- 忽略密钥销毁：PSK 注入后，临时变量没清空。被黑客通过 JTAG 读出了内存镜像……嗯，从那以后我每次写完密钥都 memset 清零。