4、密码学基础：对称加密、非对称加密、哈希函数在OTA中的应用
好，咱们进入正题。这一章聊的是密码学基础，说白了就是OTA升级安全的“地基”。你想想看，一辆车在路上跑，突然收到一个升级包，如果这个包是假的、被篡改过的，那后果不堪设想。所以，加密、签名、完整性校验，这三板斧必须得搞清楚。
4.1 对称加密：速度快，但密钥怎么分？
对称加密，就是加密和解密用同一个密钥。就像你和你老婆共用一把家门钥匙，你锁门，她开门，都拿同一把。
在OTA里，对称加密主要用来加密升级包本身。因为升级包往往很大，动辄几百兆甚至几个G，用对称加密效率高，不费CPU。常用的算法有AES-128、AES-256。
核心要点：对称加密解决的是“机密性”问题，防止升级包在传输过程中被偷看。
但问题来了——密钥怎么安全地分发给车端？你想想看，如果密钥本身在传输过程中被截获了，那加密就等于白干。我在项目中遇到过，有些团队直接把密钥硬编码在固件里，结果被逆向工程扒了个精光。嗯，这绝对是个坑。
所以，对称加密的密钥分发，通常要依赖非对称加密来帮忙。这个我们后面会讲。
4.2 非对称加密：公钥随便给，私钥藏好
非对称加密，有一对密钥：公钥和私钥。公钥可以公开，谁都可以拿；私钥只有你自己知道。用公钥加密的数据，只能用私钥解密；反过来，用私钥签名的数据，只能用公钥验证。
在OTA场景里，非对称加密主要干两件事：
- 数字签名：云端用私钥对升级包的哈希值签名，车端用公钥验证签名。这样能确保升级包确实是官方发的，没被篡改。
- 密钥交换：车端用云端的公钥加密一个临时生成的对称密钥，云端用私钥解密。这样就能安全地传递对称密钥了。
常用的算法有RSA-2048、ECC（椭圆曲线）。我个人习惯用ECC，因为同样的安全强度下，ECC的密钥更短，计算量也更小，对车端MCU更友好。
避坑指南：我曾经见过一个项目，公钥居然是从云端下载的，没有预埋在车端。结果中间人攻击直接把公钥换了，签名验证形同虚设。记住，车端的根公钥必须出厂时烧死，不可更新。
4.3 哈希函数：指纹一样的存在
哈希函数，就是把任意长度的数据，压缩成一个固定长度的“指纹”。这个指纹是唯一的，哪怕原数据只改了一个比特，哈希值也会变得面目全非。
在OTA里，哈希函数的作用非常明确：
- 完整性校验：下载完升级包后，计算它的哈希值，跟云端下发的哈希值对比。如果一致，说明数据没损坏。
- 签名的基础：非对称签名不是直接对升级包签名，而是对升级包的哈希值签名。因为升级包太大，直接签名太慢。
常用的算法有SHA-256、SHA-384。我个人建议用SHA-256，安全性和性能平衡得最好。
注意：千万别用MD5或SHA-1做OTA完整性校验。这两个算法已经被证明有碰撞风险，说白了就是可能两个不同的数据算出同一个哈希值。我在2017年就踩过这个坑，后来全部换成了SHA-256。
4.4 三者如何配合？一个典型的OTA安全流程
光讲理论没意思，咱们直接看一个实际流程。假设云端要推送一个升级包给车端：
- 云端侧：
- 计算升级包的SHA-256哈希值。
- 用云端的私钥对这个哈希值签名，生成签名文件。
- 用对称密钥（AES-256）加密升级包本身。
- 用车端的公钥加密这个对称密钥。
- 把加密后的升级包、签名文件、加密后的对称密钥，一起下发。
- 车端侧：
- 用预埋的私钥解密出对称密钥。
- 用对称密钥解密升级包。
- 计算解密后升级包的SHA-256哈希值。
- 用预埋的云端公钥验证签名文件。
- 如果签名验证通过，且哈希值一致，才允许刷写。
你看，对称加密、非对称加密、哈希函数，各司其职，缺一不可。对称加密负责快，非对称加密负责安全分发密钥，哈希函数负责完整性校验。
一句话总结：哈希函数保证“没改过”，非对称签名保证“是官方发的”，对称加密保证“别人看不到”。
4.5 代码示例：用OpenSSL模拟签名和验证
光说不练假把式。我写个简单的示例，用OpenSSL模拟一下签名和验证过程。你可以在Linux环境里跑跑看。
# 1. 生成私钥（ECC P-256）
openssl ecparam -genkey -name prime256v1 -out private.pem
# 2. 从私钥导出公钥
openssl ec -in private.pem -pubout -out public.pem
# 3. 计算升级包的哈希值
openssl dgst -sha256 -binary firmware.bin > firmware.hash
# 4. 用私钥签名哈希值
openssl pkeyutl -sign -inkey private.pem -in firmware.hash -out firmware.sig
# 5. 车端验证签名
openssl pkeyutl -verify -pubin -inkey public.pem -in firmware.hash -sigfile firmware.sig
嗯，这里要注意，实际项目中签名和验证的流程会更复杂，比如还要考虑防重放攻击、版本号校验等。但核心的密码学逻辑，就是上面这几步。
4.6 性能考量：别让加密拖慢升级速度
车端的MCU性能有限，尤其是那些老旧的Cortex-M4或者M7芯片。我曾经在一个项目里，用RSA-2048做签名验证，结果一次验证花了将近3秒。用户升级一次要等十几分钟，体验极差。
所以，我建议：
- 签名算法优先选ECC：同样的安全强度，ECC的验证速度比RSA快一个数量级。
- 对称加密用硬件加速：很多车规级MCU都内置了AES硬件加速模块，记得用起来，别用软件实现。
- 哈希计算可以分块：升级包太大时，可以分块计算哈希，边下载边校验，不用等全部下载完再算。
我的习惯：在项目初期，我就会用性能分析工具（比如IAR的Cycle Counter）测一下加密算法的耗时。如果发现瓶颈，提前换方案，别等到量产了再改。
4.7 小结
这一章的内容，说白了就是三句话：
- 对称加密：加密数据，快。
- 非对称加密：签名和密钥交换，安全。
- 哈希函数：完整性校验，防篡改。
三者结合，才能构建一个可靠的OTA安全体系。下一章，我们会聊到具体的OTA协议栈实现，到时候你会看到这些密码学知识是怎么落地到代码里的。
好，今天就到这儿。有问题随时交流。