IoT密钥管理不是选一个加密算法那么简单
做物联网设备安全的工程师，大概率会在某个时间点被同一个问题卡住：设备的密钥到底怎么管。有些团队是在固件被逆向、云平台开始收到大量伪造请求之后，才回头审视自己的密钥体系，结果发现从出厂到退役，设备密钥几乎一直是裸奔状态。
传统 IT 领域的密钥管理已经很成熟，HSM、KMS、证书生命周期工具都是现成方案。但 IoT 设备完全是另一种处境：设备数量动辄几十万，部署在物理可接触的环境里，没有运维人员能随时给设备换钥匙，计算和存储资源也受限。所以 IoT 密钥管理不是选一个加密算法那么简单，而是要从设备还没走下产线的时候就整体设计，一直管到它退役销毁。
出厂注入：设备的第一份信任从哪里来
密钥生命周期里最容易被低估的是起点。很多团队把主要精力放在选算法、定协议上，结果卡在产线环节。原因很现实：设备必须在离开工厂前就拥有可信身份，而产线环境通常并不安全，存在人员流动、外接设备、临时网络等问题。
目前主流的注入方式有两种。一种是在工厂的 HSM 或签名机里生成密钥对，再把私钥通过某种安全通道灌入设备；另一种是让设备端的安全芯片自己生成密钥对，只把公钥或签名请求发给上层。后者的安全性明显更好，因为私钥从产生到销毁都没离开过芯片，连工厂自己都无法导出。代价是产线自动化要求更高，生产节拍会慢一些。
# 产线注入流程示意（设备安全芯片视角）
1. 芯片上电，内部生成密钥对(sk_dev, pk_dev)
2. 使用pk_dev和设备唯一ID组装CSR
3. 产线工具通过安全接口读出CSR
4. 离线签名机验证CSR并签发设备证书
5. 证书写回芯片，同时写入根证书白名单
6. 产线工具擦除工作内存，进入下一台设备
这个流程里真正的关键点很朴素：签名机的私钥绝不能进入产线网络。有些工厂为了方便，把签名私钥放在一台连着内网甚至外网的电脑上，一次入侵就能让整个产品线的信任体系瓦解。类似的教训并不少见，比如某个智能门锁团队为了节省成本，把同一把 AES 密钥写进所有固件，还把密钥注释直接放在代码仓库里；产品上市后固件被提取，所有门锁都能被伪造指令远程打开。这类问题不是算法不够强，而是密钥生命周期缺失。
密钥存哪里：安全元件、TEE 与纯软件
注入完成之后，密钥住在哪里又决定了下半场的安全性。不同存储方式的成本和安全等级差别很大，不能一概而论。
| 存储方式 | 安全等级 | 成本 | 适用场景 | 主要风险 |
|---|---|---|---|---|
| 安全元件SE | 高，私钥不可导出 | 高 | 支付、车联网、高价值设备 | 产线复杂，单颗成本高 |
| TEE/TrustZone | 中高 | 中 | 消费类IoT、智能网关 | 依赖主控SoC安全边界 |
| 纯软件存储 | 低 | 低 | 极低成本传感器、耗材 | 固件被提取后密钥直接暴露 |
并不是所有设备都必须上安全元件。一个几十元的温湿度传感器，零售价可能还不如一颗 SE 芯片，强行堆硬件隔离反而不可持续。比较务实的策略是分级：涉及用户资产、人身安全或高价值业务的设备，优先用 SE；低成本设备至少要把密钥与固件分离、做存储区域加密，并承认密钥存在被提取的可能性。
TEE 处于中间地带。TrustZone 能把密钥放在安全世界，普通世界拿不到，看起来是个不错的折中。但 TEE 与主控 CPU 在同一个芯片上，一旦 SoC 本身存在硬件漏洞或 TEE 镜像有内存破坏问题，密钥保护就形同虚设。芯片越便宜，这种风险往往越高，选型时要结合主控的实际安全文档来判断。
运行时轮换：真正的分水岭
出厂注入和存储解决的是把钥匙管好，轮换解决的是钥匙出现问题之后怎么办。这一环是整个流程里最难的部分，也是很多 IoT 平台缺失的部分。
为什么必须轮换？首先，设备生命周期普遍很长，有的工业设备规划用十年，期间很难保证私钥不泄露；其次，算法或合规要求会变化，比如需要从 RSA 迁移到 ECC；最后，一旦发现某批设备的密钥可能泄露，轮换几乎是唯一的补救手段。
但给一台无人值守的设备换钥匙，远比给服务器换证书麻烦。核心矛盾是：如果攻击者已经拿到了旧密钥，轮换指令本身就是用旧密钥签名的，攻击者完全可以阻止轮换，甚至伪造一条轮换指令把设备变成自己的木马。所以轮换不是简单下发一个新密钥，而是要在设备端建立可验证的信任链，并做好回滚防护。
比较务实的做法是双槽位轮换。设备内预留两个密钥槽位，平时使用 A 槽；需要轮换时，云端先下发新密钥写入空闲的 B 槽，设备校验签名后切换使用 B 槽，再把 A 槽标记为待废弃。整个过程至少有一个槽位可用，避免出现写坏一个槽设备就失联的情况。如果担心旧密钥已被攻击者掌握，还可以引入一个独立的轮换授权密钥，与业务密钥分离，专门负责签轮换指令。
// 双槽轮换消息结构（示意）
{
'device_id': 'abc123',
'target_slot': 'B',
'new_key_payload': '密文，由旧密钥封装的新密钥',
'signature': '由轮换授权密钥签名的摘要',
'version': 2
}
// 设备处理顺序：验证签名 -> 解密写入B槽 -> 切槽 -> 通知云端
轮换策略本身也有多种，选型时可以参考这个对比。
| 策略 | 机制 | 适合场景 | 典型风险 |
|---|---|---|---|
| 直接覆盖写 | 新密钥写入旧位置 | 可远程重刷的高可控设备 | 写坏即变砖，回滚困难 |
| 双槽轮换 | 写入空闲槽后切换 | 大多数IoT设备 | 需要预留双倍存储 |
| 短期证书+续期 | 证书频繁失效并自动续期 | 网络连接稳定的设备 | 离线设备证书过期失联 |
几个容易踩进去的坑
结合大量项目的共同教训，下面几个问题值得特别留意。
- 所有设备共享同一把密钥。一次逆向或一次日志泄露，等于交出全部设备控制权。
- 轮换只做下发，不做签名与回滚保护。攻击者拿到旧密钥后能反客为主。
- 离线设备被排除在轮换之外。等到设备重新上线时，云端已经无法识别它。
- 密钥没有版本标识。后续排查问题时，根本不知道某条消息是用哪把钥匙签的。
- 忽略吊销机制。设备被淘汰或密钥泄露后，云端仍然在接收它的控制指令。
吊销在 IoT 场景里尤其难做，很多设备整天离线，CRL 和 OCSP 这种标准 PKI 手段并不适用。一个相对可行的方向是给设备下发短期的吊销列表，由云端定期把已失效的设备身份摘要推送给关键节点；同时配合较短的证书有效期，让离线设备在到期后自然失去信任。
落地路径建议
如果项目还在早期，建议先把这些事定下来，再开始写代码。
- 先做密钥资产清单：每一类密钥的用途、存储位置、生命周期、责任人和过期策略都写清楚。
- 严格拆分设备身份密钥与业务加密密钥，不要为省存储而混用。
- 产线流程确保私钥明文不触碰任何可联网的机器，能离线完成签名就不要上网。
- 协议里从第一天就预留密钥版本字段，即使 v1 不做轮换，也不要让未来无路可走。
- 轮换前先在少量设备上做灰度，观察成功率和离线设备重连行为，再大规模推送。
实践中最稳的推进顺序是先管住设备身份密钥，把注入流程、存储边界和版本管理做好，再逐步引入双槽轮换。每个环节都可以慢一点，但方向必须从一开始就是对的。
写在最后
IoT 密钥管理真正难的地方，不是某一个技术点，而是把出厂注入、安全存储、运行时轮换和最终废弃串成一条完整链路。很多团队一开始只想把密钥藏起来，等设备大规模铺开之后，才被轮换、吊销、离线设备这些问题压得喘不过气。
换个角度看，密钥生命周期设计其实是设备安全的地基。地基打得踏实，后面的固件签名、安全通信、OTA 更新才有意义；地基松了，再强的算法也只是让攻击者多花一点时间。把这条链路在设计阶段就想清楚，比设备出厂后补救要省力得多。
原创文章，作者：fudengji，如若转载，请注明出处：https://fudengji.cn/article/1026/