第4章：密码学基础：对称加密与非对称加密、哈希函数与数字签名、密钥管理基础

各位同学，欢迎来到密码学基础这一章。

说实话，很多做OTA的工程师，一听到「密码学」三个字就头大。觉得那是数学家的事，跟自己没关系。我以前也这么想，直到有一次在项目里，因为密钥存储不当，差点让整个升级流程被人逆向。嗯，从那以后，我再也不敢轻视密码学了。

这一章，我不跟你扯那些复杂的数学公式。咱们就聊聊OTA升级里，密码学到底怎么用。说白了，就是三件事：加密、签名、管好钥匙。

4.1 对称加密：快，但有个大麻烦

对称加密，顾名思义，加密和解密用的是同一把钥匙。

你想想看，就像你家里的大门，用一把钥匙锁上，也用同一把钥匙打开。简单吧？

在OTA里，最常见的对称加密算法是 AES（高级加密标准）。我个人习惯用 AES-128 或者 AES-256，具体看芯片算力。

核心要点：

  • 优点：速度快，适合加密大文件。比如固件包本身，用对称加密就很合适。
  • 缺点：密钥分发困难。你想想，车端和设备端都得有同一把钥匙。这把钥匙怎么安全地给到每一台车？这是个头疼的问题。

我在项目中遇到过一件事：有个同事图省事，把AES密钥硬编码在代码里。结果固件被反编译，密钥直接暴露。整个升级流程形同虚设。所以，对称加密虽然快，但密钥管理是命门。

4.2 非对称加密：慢，但安全多了

非对称加密，用的是「密钥对」——一把公钥，一把私钥。

公钥可以公开，谁都能拿。私钥自己藏好，打死也不给别人。

举个例子：你给别人寄一个上锁的箱子。你用你的私钥锁上，别人用你的公钥打开。反过来也行，别人用你的公钥锁上，只有你能用私钥打开。

在OTA里，最常用的非对称加密算法是 RSA 和 ECC（椭圆曲线密码学）。

算法 密钥长度 安全性 速度 适用场景
RSA 2048 / 4096 位 高 慢 签名验证、少量数据加密
ECC 256 位（相当于 RSA 3072） 更高 较快 资源受限的嵌入式设备

我个人建议，在嵌入式设备上优先考虑 ECC。为什么？因为密钥短，算得快，省电。你想想看，车机芯片资源有限，用 RSA 4096 做一次签名验证，可能要几百毫秒。而 ECC 256 可能几十毫秒就搞定了。

避坑指南：

我曾经在项目里用过 RSA 1024，后来发现业界已经不建议用了。现在最低标准是 RSA 2048 或 ECC 256。别为了省那点算力，把安全性搭进去。

4.3 哈希函数：指纹识别

哈希函数，说白了就是给数据算一个「指纹」。

不管你的固件包是 1MB 还是 1GB，哈希函数都能算出一个固定长度的值。比如 SHA-256，算出来永远是 256 位（32 字节）。

哈希函数有几个特点：

  • 不可逆：从哈希值推不出原始数据。
  • 抗碰撞：很难找到两个不同的数据，哈希值一样。
  • 雪崩效应：数据改一个比特，哈希值完全变样。

在OTA里，哈希函数主要用来做两件事：

  1. 完整性校验：下载完固件后，算一下哈希值，跟服务器给的对比。不一样？说明数据被篡改了。
  2. 数字签名的第一步：先对固件算哈希，再对哈希值签名。这样效率高，因为哈希值很小。

常用哈希算法：

  • SHA-256：目前最推荐，安全性足够，性能适中。
  • SHA-1：已经过时了，有碰撞攻击的风险。别用了。
  • MD5：绝对不要用。我在项目里见过有人用 MD5 做固件校验，结果被轻松伪造。

4.4 数字签名：证明这固件是我发的

数字签名，就是把哈希函数和非对称加密结合起来。

流程是这样的：

  1. 服务器对固件包算一个哈希值。
  2. 服务器用私钥对这个哈希值加密，得到「签名」。
  3. 车端收到固件和签名后，用公钥解密签名，得到哈希值 A。
  4. 车端自己算固件的哈希值 B。
  5. 对比 A 和 B。一样？说明固件是服务器发的，而且没被改过。

你想想看，这个流程解决了两个问题：

  • 身份认证：只有持有私钥的服务器才能生成有效签名。
  • 完整性校验：固件被改了，哈希值就对不上。

注意：

签名验证必须在安全环境中执行。我见过有人把签名验证放在 Bootloader 里，但 Bootloader 本身没做安全启动。结果攻击者直接替换了 Bootloader，签名验证形同虚设。记住，信任链要从根开始。

4.5 密钥管理基础：最容易被忽视的一环

说实话，加密算法本身没什么秘密。真正决定安全性的，是密钥管理。

你算法再强，密钥被人偷了，一切白搭。

在OTA升级里，密钥管理有几个关键点：

4.5.1 密钥生命周期

密钥不是永久的。它有自己的生命周期：

  • 生成：在安全环境中生成，比如 HSM（硬件安全模块）。
  • 分发：通过安全通道分发到设备。比如在产线上预置。
  • 使用：在安全环境中使用，比如在 TEE（可信执行环境）里做签名验证。
  • 更新：定期更换密钥。我建议每 1-2 年更新一次。
  • 销毁：密钥不再使用时，彻底销毁，不可恢复。

4.5.2 密钥存储

这是个大坑。很多设备把密钥存在普通 Flash 里，一读就出来。

正确的做法：

  • 硬件安全模块（HSM）：专用芯片，密钥出不来。
  • 可信执行环境（TEE）：在 CPU 内部隔离区域存储和使用密钥。
  • 安全元件（SE）：类似 SIM 卡，独立芯片，防篡改。

我的经验：

如果预算有限，至少也要用 MCU 内部的唯一 ID（UID）来派生密钥。别把密钥明文存着。我曾经见过一个项目，密钥直接写在配置文件的注释里……嗯，那画面太美我不敢看。

4.5.3 密钥分级

别所有场景用同一把钥匙。我建议分级管理：

密钥等级 用途 存储位置
根密钥 派生其他密钥 HSM / TEE
固件签名密钥 签名固件包 服务器端 HSM
会话密钥 每次升级临时使用 内存，用完即销毁

你想想看，就算会话密钥被截获，也只能解密这一次的通信。根密钥和签名密钥还在，系统整体安全。

4.6 实战中的组合拳

在实际的OTA升级里，我们不会只用一种加密方式。而是组合使用：

// 伪代码示例：OTA升级安全流程
1. 服务器生成会话密钥（对称密钥，AES-256）
2. 服务器用会话密钥加密固件包 → 得到密文
3. 服务器用私钥（RSA/ECC）对固件包的哈希值签名 → 得到签名
4. 服务器将会话密钥用设备的公钥加密 → 得到加密的会话密钥
5. 服务器发送：密文 + 签名 + 加密的会话密钥

6. 车端收到后，先用私钥解密会话密钥
7. 用会话密钥解密密文，得到固件包
8. 计算固件包的哈希值
9. 用服务器公钥验证签名
10. 验证通过？开始升级。不通过？丢弃。

这个流程里，对称加密负责速度，非对称加密负责安全分发密钥，哈希和签名负责完整性验证。各司其职，完美配合。

总结一下：

  • 对称加密：快，适合加密大文件。密钥管理是难点。
  • 非对称加密：慢，适合加密小数据（如密钥）。ECC 比 RSA 更适合嵌入式。
  • 哈希函数：算指纹，做完整性校验。SHA-256 是底线。
  • 数字签名：证明身份 + 保证完整。是OTA安全的基石。
  • 密钥管理：别把钥匙放在门口垫子下。用 HSM、TEE 或安全元件。

好了，这一章的内容就到这里。密码学不难，难的是用对地方、管好钥匙。下一章，咱们聊聊具体的OTA升级协议设计，看看怎么把这些密码学工具用到实际流程里。

← 上一章 📖 返回目录 下一章 →