4. 车载网络通信协议
各位同行，咱们接着聊OTA安全。上一章我们把升级包的完整性校验讲透了，但光有校验还不够——升级包在传输过程中如果被截获，里面的固件、配置、密钥就全裸奔了。所以这一章，我们重点解决「加密传输」这个硬骨头。
说白了，OTA升级包加密要回答三个问题：用什么算法加密？密钥怎么安全地交给车端？加密会不会把ECU算死？我一个个拆开讲。
4.1 为什么不用纯非对称加密？
有人可能会问：RSA或者ECC直接加密整个升级包不就行了？嗯，理论上可以，但实际项目里没人这么干。原因很简单——慢。
我记得有一次做POC，用RSA-2048加密一个50MB的固件包，在云端服务器上跑了将近3分钟。这还只是加密，车端解密更慢，ECU的算力可没服务器那么强。你想想看，一辆车在4S店或者地库里升级，让车主等半小时解密？这体验太糟糕了。
所以业界通用的做法是：混合加密。用非对称加密保护对称密钥，用对称加密保护实际数据。这样既安全，又高效。
4.2 对称加密选型：为什么是AES-GCM？
对称加密算法很多，AES-CBC、AES-CTR、AES-GCM……我个人习惯在OTA场景里首选AES-GCM。为什么？因为它同时提供了加密和完整性校验，一步到位。
GCM模式（Galois/Counter Mode）本质上是CTR模式加上GMAC认证标签。加密的同时计算MAC，不需要额外再跑一次HMAC。这对嵌入式设备来说，省了代码量，也省了CPU周期。
我在项目中遇到过一个问题：早期用AES-CBC + HMAC-SHA256做加密和校验，结果在某个低端MCU上，HMAC计算占了解密总时间的40%。后来切到AES-GCM，同样的安全强度，总耗时降了30%。
| 特性 | AES-CBC + HMAC | AES-GCM |
|---|---|---|
| 加密强度 | 高 | 高 |
| 完整性校验 | 需要额外HMAC | 内置GMAC |
| 计算开销 | 较高（两次计算） | 较低（一次计算） |
| 并行性 | 不支持 | 支持 |
| 硬件加速 | 常见 | 常见 |
4.3 非对称加密：密钥协商协议
对称密钥怎么安全地交给车端？这就是非对称加密的舞台了。OTA场景里常用的密钥协商方式有两种：
- 直接加密传输： 云端用车端的公钥加密对称密钥，车端用私钥解密。简单直接，但需要提前部署公钥基础设施。
- ECDH密钥协商： 云端和车端各自生成临时密钥对，通过椭圆曲线Diffie-Hellman协议协商出共享密钥。安全性更高，支持前向保密。
我个人更推荐ECDH方案。为什么？因为即使长期私钥泄露，历史会话的密钥也不会被破解——这就是前向保密的价值。我在一个Tier-1的项目里就吃过亏，早期用直接加密方案，后来发现某个批次的车端私钥被提取了，所有历史升级包都能被解密。切到ECDH之后，这个问题彻底解决了。
下面是一个典型的ECDH密钥协商流程：
// 车端生成临时密钥对
EC_KEY *car_key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
EC_KEY_generate_key(car_key);
// 车端将公钥发送给云端
// 云端生成临时密钥对
EC_KEY *cloud_key = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
EC_KEY_generate_key(cloud_key);
// 云端计算共享密钥
unsigned char shared_secret[32];
ECDH_compute_key(shared_secret, 32, EC_KEY_get0_public_key(car_key), cloud_key, NULL);
// 云端用共享密钥派生AES-GCM密钥
// HKDF或简单SHA256截断
unsigned char aes_key[16];
SHA256(shared_secret, 32, aes_key); // 取前16字节作为AES-128密钥
// 云端用aes_key加密升级包，发送给车端
// 车端用同样的方式计算共享密钥，解密升级包4.4 加密性能优化：别让ECU卡死
车端ECU的算力差异很大。高端座舱芯片跑AES-GCM毫无压力，但低端MCU（比如Cortex-M0+）可能连128字节的数据块都要算半天。所以加密性能优化是实战中的必修课。
我总结了几条优化经验：
- 硬件加速优先： 现代MCU大多内置AES硬件引擎。一定要用硬件加速，软件实现慢10倍以上。我在一个项目里发现，某款MCU的硬件AES引擎跑GCM模式，吞吐量能达到200Mbps，而软件实现只有15Mbps。
- 分块加密： 升级包再大，也要分块加密。每块1MB左右，既保证内存不爆，又方便断点续传。我建议每块用独立的nonce，这样即使某块解密失败，也不影响其他块。
- 预计算密钥： 密钥协商只在会话开始时做一次，后续所有数据块都用同一个派生密钥。避免每块都跑ECDH，那太慢了。
- 异步解密： 车端接收升级包时，可以边收边解密。用DMA+双缓冲机制，解密和接收流水线并行。我见过一个优化案例，把解密时间从30秒压缩到8秒，就是靠这个。
4.5 整体加密传输架构
把上面这些串起来，一个完整的OTA升级包加密传输架构就清晰了。我画了一张图，方便你理解：
这个架构里，性能瓶颈主要在步骤3和步骤5。云端加密可以用多线程并行，车端解密就得靠硬件加速和分块策略了。我建议在项目初期就做性能摸底测试，用实际升级包大小和ECU型号跑一遍，看看解密时间是否在可接受范围内。
4.6 实战中的几个坑
最后，分享几个我在项目中踩过的坑，希望能帮你少走弯路：
- nonce重复： 有一次测试发现，车端连续两次升级用了相同的nonce，结果攻击者通过密文对比直接推断出部分明文内容。后来我们强制nonce里包含时间戳和会话ID，保证全局唯一。
- 密钥存储： 车端的私钥不能明文存。我建议用HSM或TEE保护，至少也要用MCU的OTP区域。曾经有个项目把私钥写在Flash里，被调试接口读出来了，整个安全体系瞬间崩塌。
- 性能测试要覆盖最差情况： 加密性能测试不能只在实验室理想环境下跑。我记得有一次，在-40°C低温环境下，某款MCU的硬件AES引擎启动时间比常温多了3倍。所以一定要做全温度范围的性能摸底。