离网设备的加密解密方案

针对这种无网络、完全离线的 Linux 嵌入式设备，业界有一套成熟的"密钥注入"与"密钥轮换"标准方案。

一、 密钥在什么阶段存入设备？如何存放？

1. 注入时机：出厂生产阶段（Factory Provisioning）

对称密钥绝对不能在设备出厂后通过明文或简单的调试口下发。密钥的第一次注入，必须在受信任的工厂环境中完成。

2. 存储介质：硬件安全区域（eFuse / OTP）

在 Linux 嵌入式平台（如 NXP i.MX 系列等）上，密钥不应该以文件的形式存储在 Flash 的普通文件系统中。

• 最佳实践： 将密钥烧录进芯片内部的 eFuse（一次性可编程只读存储器）或 OTP 区域。

• 硬件隔离： 烧录后，可以通过配置锁死该区域的读权限。Linux 内核或应用程序无法直接读取密钥明文，只能将需要解密的密文送入芯片的硬件加密引擎（如 CAAM 模块），由硬件直接从 eFuse 获取密钥进行解密并输出明文。即使黑客把 Flash 拆下来读取，也拿不到密钥。

二、 如何避免一把钥匙开所有锁？（一机一码机制）

为了防止"一台设备密钥泄漏导致全线崩溃"，应当采用**一机一码（一机一密）**的策略。

• 不需要在出厂时为每一台设备随机生成并记录几万个不同的密钥。

• 通常的做法是：在工厂阶段向所有设备烧录同一个高强度的根密钥（Root Key）。

• 设备启动时，读取自身芯片内部不可篡改的唯一设备 ID（SoC UID），利用密钥派生函数（Key Derivation Function）在内存中动态生成当前设备专属的对称密钥：

  Key_{device} = KDF(Root Key, Device UID)

• 这样一来，你的配置和固件打包工具在生成升级包时，只需要根据目标设备的 UID，就能推导出该设备专属的对称密钥来进行加密。

三、 对称密钥泄漏后，如何安全更换？（密钥轮换）

在离线场景下，如果发现某批次或某台设备的对称密钥（或根密钥）已经暴露，你需要将新的对称密钥传递给设备。这时候就必须引入非对称加密（RSA/ECC）来构建数字信封（Digital Envelope）。

这种机制与通过上位机收集请求、再下发授权的流程高度契合。

具体更新流程：

1. 收集请求（上位机阶段）：

   • 设备端在本地生成一对非对称密钥（公钥 + 私钥），私钥严密保存在设备端。

   • 当笔记本（上位机）通过 USB 或串口连接设备时，上位机工具收集该设备的公钥 、设备 UID 以及当前的固件版本信息，并导出一个 Request_Info.req 文件（可以保存在 U 盘或笔记本上）。

2. 生成信封（开发者/服务器阶段）：

   • 你（开发者）拿到这个 Request 文件后，在受信任的电脑上生成一个全新的对称密钥。

   • 使用该设备的公钥，对这个"新对称密钥"进行非对称加密，制作成一个"数字信封"。

   • 使用这个"新对称密钥"，对你要更新的配置或固件进行对称加密。

   • 将【数字信封】+【加密后的固件】打包成一个新的升级文件。

3. 离线导入与解密（现场设备端）：

   • 上位机将升级包导入嵌入式设备。

   • 设备首先使用自己的私钥 拆开"数字信封"，安全地获取到新对称密钥。

   • 设备使用新对称密钥，解密固件和配置文件，并用新密钥替换掉旧的业务密钥。

方案总结：

非对称加密虽然运算速度慢，但用来传递只有几十个字节的"对称密钥"是非常完美的；而对称加密速度快，用来加密几十兆的"固件实体"正好发挥优势。两者结合，就彻底解决了离线状态下密钥的分发与更换难题。