2. 设备身份与凭证管理：唯一标识符、预共享密钥与证书的生成与分发
设备注册的第一步，就是给设备一个「合法身份」。说白了，你得让云端知道：你是谁？你凭什么接入？
我见过不少项目，一上来就急着写业务逻辑，结果设备身份管理做得一塌糊涂。等到设备量上了万，才发现没法区分哪台设备在发数据——那场面，真是灾难。
这一节，我们重点聊三个东西：Device ID、PSK 和 证书。它们怎么生成？怎么分发？有什么坑？
2.1 唯一标识符（Device ID）
Device ID 是设备的「身份证号」。它必须唯一、不可篡改、且能在设备全生命周期内稳定存在。
2.1.1 常见的 Device ID 来源
| 来源 | 优点 | 缺点 |
|---|---|---|
| 芯片唯一序列号（如 MCU UID） | 硬件绑定，不可伪造 | 部分芯片序列号可被读取改写 |
| MAC 地址 | 网络层天然唯一 | 可被篡改，且隐私合规风险高 |
| IMEI / MEID（蜂窝模组） | 运营商级唯一 | 仅限蜂窝设备，且需授权读取 |
| 云端预分配 UUID | 完全可控，长度灵活 | 需安全通道写入设备 |
我个人习惯：优先用芯片 UID + 云端预分配组合。芯片 UID 做硬件锚点，云端再补一个业务 ID，这样既防物理篡改，又方便管理。
注意： 不要直接用 MAC 地址做 Device ID。GDPR 和《个人信息保护法》里，MAC 地址可能被认定为「可关联个人身份的信息」。我在一个智能家居项目里吃过这个亏——后来全部翻工，换成哈希后的设备指纹。
2.1.2 生成规范
- 长度：建议 16-32 字节，太短容易碰撞，太长浪费存储。
- 编码：推荐 hex 或 base64，避免特殊字符导致协议解析出错。
- 不可预测性：不要用自增 ID，防止被枚举扫描。用随机数 + 时间戳 + 硬件指纹做哈希。
// 示例：基于 HMAC-SHA256 生成 Device ID
device_id = HMAC-SHA256(
key = factory_secret,
data = chip_uid || timestamp || nonce
).substring(0, 16)
2.2 预共享密钥（PSK）
PSK 是最轻量的对称凭证。适合资源受限的 MCU、Zigbee 节点、蓝牙传感器。
2.2.1 PSK 的生成策略
PSK 不能是「123456」这种弱口令。我建议用 KDF（密钥派生函数） 从主密钥派生。
// 基于 Device ID 派生出唯一 PSK
psk = HKDF-SHA256(
salt = device_id,
ikm = master_secret,
info = "device-psk-v1",
length = 16
)
这样做的好处：主密钥只保存在云端，设备端只存派生后的 PSK。即使一台设备被物理破解，也拿不到其他设备的密钥。
经验之谈： 我曾经在一个 LoRa 项目里，直接用设备 MAC 地址后 6 位当 PSK。结果被客户的安全审计抓了个正着——所有设备 PSK 可被暴力枚举。后来改成每台设备单独派生，审计才通过。
2.2.2 PSK 的分发方式
| 方式 | 安全性 | 适用场景 |
|---|---|---|
| 出厂预烧录 | 高（需管控烧录环境） | 大批量、同批次设备 |
| 首次上电动态获取 | 中（依赖 TLS 通道） | 消费类 IoT，支持 OOB 绑定 |
| 二维码/蓝牙扫描 | 中（需防中间人） | 智能家居、可穿戴设备 |
嗯，这里要注意：动态分发必须走加密通道。我见过一个项目，PSK 通过明文 HTTP 下发——那跟把家门钥匙挂在门口有什么区别？
2.3 证书（X.509 Certificate）
证书是 IoT 里最安全的凭证方案，但也是实现成本最高的。适合网关、服务器、高安全等级设备。
2.3.1 证书链结构
典型的 IoT 证书链分三层：
- 根 CA：离线保存，只用来签发中间 CA。
- 中间 CA：负责签发设备证书，可在线。
- 设备证书：每台设备独一份，包含 Device ID 和公钥。
核心原则： 根 CA 永远不要联网。我见过有人把根 CA 放在 CI/CD 服务器上——结果一次构建被投毒，整个信任链全废了。
2.3.2 证书生成流程
# 1. 设备生成密钥对（在安全元件内完成）
openssl ecparam -genkey -name prime256v1 -out device.key
# 2. 生成证书签名请求（CSR）
openssl req -new -key device.key -out device.csr \
-subj "/CN=device-{device_id}"
# 3. 中间 CA 签名
openssl x509 -req -in device.csr \
-CA intermediate.crt -CAkey intermediate.key \
-CAcreateserial -out device.crt -days 3650
你想想看，如果私钥在生成过程中被泄露，那证书就是一张废纸。所以，私钥生成必须在设备安全元件（SE / TEE）内完成，私钥永不出芯片。
2.3.3 证书分发与生命周期
| 阶段 | 操作 | 安全要点 |
|---|---|---|
| 生产 | 证书写入设备安全存储 | 防止烧录工具被篡改 |
| 激活 | 设备首次联网上报证书指纹 | 云端校验是否被吊销 |
| 运行 | TLS 握手时双向认证 | 定期检查证书有效期 |
| 到期 | 通过 OTA 更新证书 | 必须签名验证，防中间人 |
| 吊销 | 云端更新 CRL / OCSP | 设备端需支持吊销列表 |
2.4 三种凭证的选型对比
| 维度 | Device ID | PSK | 证书 |
|---|---|---|---|
| 安全等级 | 低（仅标识） | 中 | 高 |
| 计算开销 | 几乎为零 | 低（对称算法） | 高（非对称算法） |
| 存储开销 | 几字节 | 16-32 字节 | 几百字节到几 KB |
| 吊销能力 | 无 | 需云端黑名单 | CRL / OCSP 原生支持 |
| 合规要求 | 基础 | 中等（如 PSA Level 1） | 高（如 PSA Level 2+、FIPS） |
我个人建议：消费类 IoT 用 PSK + Device ID 组合；工业、车联网、医疗设备必须上证书。别为了省几毛钱的安全芯片成本，把整个产品的合规性搭进去。
2.5 知识体系总览
下面这张图，把三种凭证的生成、分发、使用关系串起来了。你可以把它当作本章的「思维导图」。
2.6 合规要点速查
- GDPR / 个人信息保护法：Device ID 不能直接关联个人身份。建议用哈希或匿名化处理。
- PSA Certified / NIST：Level 2 以上要求硬件安全存储凭证，私钥不可读。
- ETSI EN 303 645：消费类 IoT 必须支持凭证更新机制，不能硬编码死密钥。
- 车联网（ISO 21434）：证书吊销列表必须在设备端缓存，支持离线验证。
一个小技巧： 合规审计时，审计员最喜欢问「凭证怎么生成的？密钥存哪了？」。提前准备好一份《凭证管理 SOP》，把生成工具、存储介质、访问权限写清楚，能省很多麻烦。