密码学基础（上）：对称加密与非对称加密、哈希函数、数字签名
好，咱们开始聊密码学。说实话，很多做OTA的工程师一听到「密码学」三个字就头大，觉得那是数学博士才该碰的东西。但我跟你说，搞OTA安全，你不需要成为密码学家，但必须懂这些基础工具怎么用、用在哪儿。
我见过太多项目，密钥管理一塌糊涂，最后整个升级链路被人从中间捅了个窟窿。嗯，咱们今天就把这几个核心概念掰开揉碎了讲清楚。
一、对称加密：简单粗暴，但有个大麻烦
对称加密，说白了就是加密和解密用同一把钥匙。你想想看，就像你家大门，用一把钥匙锁上，也用同一把钥匙打开。
常见的对称加密算法有：
- AES（Advanced Encryption Standard）—— 目前最主流，我项目里90%的场景都用它
- DES —— 太老了，别用了，56位密钥分分钟被暴力破解
- SM4 —— 国密标准，国内项目必须考虑
核心要点：对称加密速度快，适合加密大量数据。但密钥分发是个死穴——你怎么把密钥安全地交给对方？
我在一个车厂项目里遇到过这种情况：OTA升级包用AES-256加密，但密钥直接硬编码在MCU的固件里。结果呢？有人用JTAG把固件读出来，密钥直接暴露。你说这加密还有啥意义？
⚠️ 避坑指南：我曾经见过一个团队，对称密钥通过网络明文传输。这相当于你把家门钥匙挂在门外，然后跟小偷说「别进来哦」。密钥分发必须用安全通道，比如后面要讲的非对称加密。
二、非对称加密：解决密钥分发难题
非对称加密就聪明多了。它有一对密钥：公钥和私钥。公钥可以公开，私钥自己藏好。
怎么用呢？我给你举个例子：
- 你要给我发密文，用我的公钥加密
- 我收到后，用我的私钥解密
- 别人拿到公钥也解不开，因为没有私钥
常见的非对称加密算法：
| 算法 | 密钥长度 | 特点 | 我的建议 |
|---|---|---|---|
| RSA | 2048位起 | 最成熟，但慢 | 签名场景首选 |
| ECC | 256位 | 同等安全强度下密钥更短 | 嵌入式设备首选 |
| SM2 | 256位 | 国密标准 | 国内项目必须 |
你想想看，非对称加密虽然慢，但它解决了密钥分发这个老大难问题。实际项目中，我们通常这样搭配：
// 混合加密的典型流程
1. 客户端生成随机对称密钥（Session Key）
2. 用服务器的公钥加密这个对称密钥
3. 服务器用私钥解密，得到对称密钥
4. 后续通信全部用对称加密
// 这样既解决了密钥分发，又保证了速度💡 个人经验：我建议在OTA场景中，用ECC做密钥交换，用AES做数据加密。ECC的密钥短，适合资源受限的嵌入式设备，AES速度快，适合加密大容量的升级包。
三、哈希函数：数据的「指纹」
哈希函数，说白了就是把任意长度的数据，压缩成一个固定长度的摘要。这个摘要就像人的指纹，独一无二。
哈希函数有几个关键特性：
- 单向性：从哈希值无法反推出原始数据
- 抗碰撞性：很难找到两个不同的输入，产生相同的哈希值
- 雪崩效应：输入改一个比特，输出完全变样
常用的哈希算法：
- SHA-256 —— 目前最安全，我项目里都用它
- MD5 —— 别用了，已经被攻破，碰撞攻击很容易
- SM3 —— 国密哈希标准
哈希在OTA中的典型用途：下载完升级包后，计算它的哈希值，跟服务器下发的哈希值对比。如果一致，说明文件没被篡改。这就是完整性校验。
我曾经遇到一个案例：某厂商OTA升级包只做了哈希校验，但哈希值本身是通过HTTP明文传输的。攻击者截获升级包，替换成恶意固件，同时把哈希值也改了。嗯，这就是典型的「哈希校验形同虚设」。
⚠️ 注意：哈希值必须通过安全通道获取，或者用数字签名保护起来。否则哈希校验就是个摆设。
四、数字签名：身份认证 + 完整性校验
数字签名，就是把哈希函数和非对称加密结合起来。它解决两个问题：
- 身份认证：确认数据确实来自声称的发送方
- 完整性校验：确认数据没有被篡改
签名过程是这样的：
// 签名方（服务器）
1. 计算数据的哈希值
2. 用私钥加密哈希值 → 得到签名
3. 发送「数据 + 签名」给接收方
// 验证方（设备）
1. 收到「数据 + 签名」
2. 用公钥解密签名 → 得到哈希值A
3. 自己计算数据的哈希值 → 得到哈希值B
4. 对比A和B，一致则验证通过你想想看，这里的关键是什么？公钥必须可信。如果公钥被替换了，那整个签名体系就崩了。
💡 我的做法：在OTA系统中，我会把根公钥烧录在芯片的一次性可编程（OTP）区域。这样攻击者就算拿到固件，也改不了公钥。这是硬件级别的信任根。
我记得有个项目，他们用RSA-2048做签名，但公钥存储在外部Flash里。结果有人通过SPI接口把公钥换成了自己的，然后用自己的私钥签名恶意固件。设备毫无防备地就升级了。你说这锅该谁背？
五、把这些串起来：OTA升级的安全链路
好了，咱们把今天讲的几个概念串起来，看看一个完整的OTA安全升级链路长什么样：
- 镜像签名：服务器用私钥对升级包做数字签名
- 镜像加密：用对称密钥加密升级包（可选，取决于你的安全需求）
- 密钥交换：用非对称加密传输对称密钥
- 设备验证：用公钥验证签名，用哈希校验完整性
- 解密安装：用对称密钥解密，然后刷写固件
核心原则：私钥永远不出设备，公钥可以公开但必须防篡改。哈希保证完整性，签名保证真实性，加密保证机密性。三者缺一不可。
我个人习惯，在设计OTA安全体系时，会先画一张数据流图，标清楚每个环节用了什么密码学工具，密钥在哪里生成、哪里存储、哪里使用。这张图画清楚了，后面实现就不容易出大错。
嗯，今天先聊到这儿。下一节咱们深入讲讲密钥的生命周期管理——怎么生成、怎么存储、怎么轮换、怎么销毁。这些才是真正让工程师头疼的地方。