3、数据加密基础：对称加密与非对称加密、车载场景下的密钥管理、TLS/SSL协议在车云通信中的应用
3.1 对称加密：一把钥匙开一把锁
对称加密，说白了就是加密和解密用同一把钥匙。就像你家里的门锁，用这把钥匙锁门，也得用这把钥匙开门。
我在项目中遇到过不少刚入行的同事，觉得对称加密太简单，随便选个算法就行。嗯，这里要注意——算法选错了，车可能就被人远程开走了。
常见的对称加密算法有：
- AES（高级加密标准）：目前最主流的选择。我个人习惯用AES-256，密钥长度256位，暴力破解基本不可能。
- DES（数据加密标准）：老古董了，56位密钥，现在一台普通电脑几小时就能破解。千万别用。
- 3DES：DES的升级版，但效率低，也不推荐。
核心要点：车载场景下，对称加密主要用于ECU之间的通信、CAN总线数据的加密。速度快，适合大数据量。
警告：对称加密最大的问题是密钥分发。你想想看，如果每辆车都用同一个密钥，那破解一辆就等于破解全部。我曾经见过某厂商因为密钥管理不当，导致整个车系被远程攻击——教训深刻。
3.2 非对称加密：公钥私钥，各司其职
非对称加密就聪明多了。它有一对钥匙：公钥和私钥。公钥可以公开，私钥自己藏着。你用公钥加密，只有对应的私钥能解开。
为什么会这样？因为数学原理。RSA算法基于大整数分解难题，ECC（椭圆曲线加密）基于椭圆曲线离散对数问题。你不需要懂数学细节，只要知道：私钥永远不出设备。
常见的非对称加密算法：
| 算法 | 密钥长度 | 特点 | 车载适用场景 |
|---|---|---|---|
| RSA | 2048/4096位 | 成熟、广泛支持 | 数字签名、证书验证 |
| ECC | 256位（相当于RSA 3072位） | 密钥短、计算快 | 车云通信、TLS握手 |
| SM2 | 256位 | 国密标准 | 国内车企合规要求 |
我个人更推荐ECC。为什么？车载芯片资源有限，ECC用更短的密钥达到同等安全强度，省电省算力。我在做T-Box项目时，从RSA切到ECC后，握手时间缩短了40%。
小技巧：实际项目中，很少单独用非对称加密加密大量数据。通常是混合使用——非对称加密用来协商对称密钥，然后用对称加密传输数据。这叫"混合加密"，后面会讲到。
3.3 车载场景下的密钥管理
密钥管理，是车载安全里最容易被忽视、也最容易出问题的地方。我曾经见过一个项目，密钥硬编码在代码里——嗯，这相当于把家门钥匙贴在门上。
车载密钥管理有几个关键点：
- 密钥生命周期管理：从生成、分发、使用、更新到销毁，每一步都要有记录。
- 安全存储：密钥不能明文存。要用HSM（硬件安全模块）或SE（安全元件）来保护。
- 密钥分级：不同安全级别的数据用不同密钥。比如，启动授权用高安全密钥，娱乐系统用低安全密钥。
- 远程更新：车卖出去后，密钥可能泄露，要能远程更换。OTA（空中下载技术）更新密钥时，必须用安全通道。
避坑指南：我曾经在测试中发现，某款车机在升级固件时，密钥竟然以明文形式传输。攻击者只要抓包就能拿到密钥。后来我们强制要求：所有密钥传输必须经过TLS加密通道，且密钥本身要用KEK（密钥加密密钥）再次加密。
车载密钥管理的架构，我画了一张图帮你理解：
3.4 TLS/SSL协议在车云通信中的应用
TLS（传输层安全协议），就是HTTPS里那个"S"。它解决了三个问题：你是谁（身份认证）、数据有没有被改（完整性）、别人能不能看（机密性）。
车云通信为什么必须用TLS？你想想看，车在路上跑，通过4G/5G和云端通信。如果没有TLS，攻击者可以伪造基站，拦截你的指令——比如让刹车失效。
TLS握手过程，我简化一下：
- 客户端问候：车端说"我想建立安全连接，支持这些加密套件"
- 服务器问候：云端说"好的，我们用这套加密算法"
- 证书验证：云端出示数字证书，车端验证证书是否可信
- 密钥交换：双方用非对称加密协商出一个对称密钥（会话密钥）
- 安全通信：之后所有数据都用这个会话密钥加密传输
关键点：车载TLS和普通HTTPS有区别。车载芯片性能弱，不能支持所有加密套件。我建议只保留：TLS 1.3 + ECDHE + ECC证书。TLS 1.3比1.2少了一次往返，延迟更低。
代码示例——车端TLS配置（伪代码）：
// 车载TLS客户端配置示例
TLSConfig config;
config.version = TLS_1_3; // 使用最新版本
config.cipher_suites = {
TLS_AES_128_GCM_SHA256, // 对称加密
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 // 密钥交换
};
config.certificate = load_cert("/sec/ca.crt"); // 根证书
config.verify_depth = 2; // 证书链验证深度
// 建立连接
TLSConnection conn = tls_connect("cloud.xxx.com", 443, config);
// 发送加密数据
conn.send(encrypt(sensor_data, session_key));注意：证书验证不能跳过！我曾经见过某项目为了省事，把证书验证关了——结果中间人攻击一打一个准。证书过期也要有处理机制，不能直接断连，可以降级到安全模式。
车载TLS的几个特殊要求：
- 会话恢复：车频繁断连重连，每次重新握手太慢。用会话ID或会话票证机制，快速恢复。
- OCSP Stapling：证书吊销状态检查。车端网络不稳定，不能每次都去查，用OCSP Stapling让服务器主动提供状态。
- 双向认证：不仅云端验证车端，车端也要验证云端。防止伪造的云端服务器。
个人经验：我在做量产项目时，发现TLS握手在弱网环境下经常超时。后来我们加了重试机制，并优化了握手超时时间——从默认的10秒改成30秒。同时，在握手期间，车端先缓存数据，等连接建立后再发送。这样用户体验好很多。
总结一下：对称加密快但密钥分发难，非对称加密安全但慢，两者结合才是王道。密钥管理是车载安全的地基，TLS是车云通信的护城河。这三样东西，缺一不可。