第2章 对称加密与非对称加密：核心概念对比，各自在车队中的应用场景
加密算法，说白了就是两把钥匙的游戏。
一把钥匙锁门，另一把开门。问题是——这两把钥匙能不能是同一把？
这就是对称加密与非对称加密最本质的区别。我刚开始接触车联网安全时，也搞混过这两个概念。后来在一次实际项目中踩了坑，才真正理解它们各自该用在什么地方。
2.1 对称加密：一把钥匙开两把锁
对称加密，加密和解密用同一个密钥。
你想想看，就像你家大门钥匙——锁门用这把，开门也用这把。简单、直接、速度快。
核心特点：
- 加密密钥 = 解密密钥
- 运算速度快，适合大量数据
- 密钥分发是个大问题
常见的对称加密算法有：
- AES（Advanced Encryption Standard）—— 目前最主流，128/192/256位密钥
- SM4 —— 国密标准，国内车队项目常用
- DES/3DES —— 太老了，别用了
我记得有一次帮某车队做T-Box固件升级方案。当时数据量很大，一个固件包200MB。如果用非对称加密，光加解密就能把ECU跑死。最后用的AES-256-GCM，速度完全没问题。
我的习惯：车队内部通信，只要密钥能安全分发，优先用对称加密。性能优势太明显了。
2.2 非对称加密：公钥私钥，各司其职
非对称加密，加密和解密用不同的密钥。
公钥公开，谁都可以拿。私钥自己藏好，绝不外传。
公钥加密的数据，只有私钥能解开。反过来，私钥签名的数据，公钥能验证。
核心特点：
- 加密密钥 ≠ 解密密钥
- 运算速度慢，比对称加密慢100-1000倍
- 密钥分发简单，公钥随便给
常见算法：
- RSA —— 经典，2048位起步
- ECC（椭圆曲线）—— 密钥更短，性能更好
- SM2 —— 国密标准，基于ECC
为什么会这么慢？因为涉及大数运算。RSA 2048位解密，在普通MCU上可能要几百毫秒。你想想看，如果每一条CAN报文都做非对称解密，总线直接卡死。
2.3 一张图看懂区别
下面这张图，我每次培训都会拿出来讲。它把两种加密的核心逻辑画清楚了。
2.4 车队场景：谁该用在哪？
这个问题，我每次做项目评审都会问一遍。很多人答不上来。
直接给结论：
| 场景 | 推荐加密方式 | 原因 |
|---|---|---|
| T-Box与云端通信 | 非对称（握手阶段）+ 对称（数据传输） | 先交换对称密钥，再用对称加密传输数据 |
| CAN总线报文加密 | 对称加密（AES-128） | 实时性要求高，非对称太慢 |
| OTA固件升级 | 对称加密（AES-256） | 数据量大，性能优先 |
| 数字签名（ECU身份认证） | 非对称（ECC/SM2） | 需要验证来源，不能伪造 |
| V2X消息广播 | 非对称签名 | 接收方只需验证，不需要解密 |
| 车内传感器数据采集 | 对称加密 | 密钥预置在ECU中，分发可控 |
注意：千万不要在CAN报文上用非对称加密。我曾经见过一个方案，每条报文用RSA签名，结果总线负载直接爆了。ECU根本跑不动。
2.5 混合加密：车队项目中的黄金组合
实际项目中，很少只用一种加密方式。
最经典的组合是：非对称加密做密钥交换，对称加密做数据加密。
流程是这样的：
- 云端生成一对密钥（公钥+私钥），公钥预置在T-Box中
- T-Box生成一个随机的对称密钥（Session Key）
- T-Box用云端的公钥加密这个Session Key，发给云端
- 云端用私钥解密，拿到Session Key
- 双方用这个Session Key进行对称加密通信
这样做的好处很明显：
- 密钥交换的安全性由非对称加密保证
- 数据传输的性能由对称加密保证
- Session Key每次会话都变，即使被破解也不影响历史数据
我的建议：车队项目里，能用混合加密就别只用一种。TLS/SSL协议就是这么干的，它已经经过了几十年的验证。
2.6 避坑指南：我踩过的三个坑
做车队安全这些年，有些坑我替你们踩过了。
坑一：密钥硬编码在代码里
我曾经接手过一个项目，AES密钥直接写在C代码里。编译完的二进制文件，用十六进制编辑器一搜就能看到。后来我们改成了从HSM（硬件安全模块）读取，才算真正安全。
坑二：非对称加密当对称用
有个同事觉得RSA很安全，就把所有CAN报文都用RSA加密。结果ECU解密一条报文要300ms，总线上的报文全丢了。嗯，后来他改成了AES。
坑三：忽略密钥更新
很多车队项目，密钥从出厂到报废都不换。这很危险。我建议至少每半年更新一次对称密钥，非对称密钥每两年换一次。
2.7 小结
对称加密和非对称加密，没有谁比谁更好。关键是用对地方。
对称加密快，适合大量数据。非对称加密安全，适合密钥交换和数字签名。
车队项目里，混合加密是常态。记住一句话：用非对称加密解决信任问题，用对称加密解决性能问题。