2. 密码学基础回顾：对称加密（AES-GCM）、非对称加密（ECC、RSA）、哈希函数（SHA-256）、消息认证码（HMAC）、数字签名（ECDSA）
各位同学，咱们今天聊点硬核的。密码学，说白了就是车载通信安全的基石。你想想看，车跟云端通信，车跟车通信，要是没点加密手段，那数据就跟裸奔一样。
我个人习惯，每次做安全方案设计前，都会先把这些基础工具在脑子里过一遍。就像老司机上车前先检查轮胎和刹车，一个道理。咱们今天就把这五样东西掰开揉碎了讲清楚。
2.1 对称加密：AES-GCM
对称加密，顾名思义，加密和解密用的是同一把钥匙。效率高，适合大数据量。但在车载场景下，我最推荐的是 AES-GCM 模式。
为什么是 GCM？因为它不光加密，还带认证。说白了，它既能保证数据不被偷看（机密性），又能保证数据没被篡改（完整性）。
核心要点：AES-GCM = AES加密 + GMAC消息认证。一次搞定两件事。
我在项目中遇到过一个问题：早期用 AES-CBC 模式，结果有人搞了个 padding oracle 攻击，差点把密钥给猜出来。后来全切到 GCM 模式，再没出过这类幺蛾子。
看个简单的代码示例，感受一下：
// 伪代码示例：AES-GCM 加密
key = 随机生成16字节密钥
nonce = 随机生成12字节随机数（重要！不能重复）
ciphertext, tag = AES_GCM_encrypt(key, nonce, plaintext, aad)
// 解密时
plaintext = AES_GCM_decrypt(key, nonce, ciphertext, tag, aad)
// 如果 tag 校验失败，直接返回错误，不要尝试解密避坑指南：我曾经见过有人把 nonce 设成固定值，结果加密结果每次都一样，这跟没加密有啥区别？记住：nonce 必须每次不同，且不能重复使用！
2.2 非对称加密：ECC 与 RSA
非对称加密，有一对钥匙：公钥和私钥。公钥随便发，私钥自己藏好。适合做密钥交换和数字签名。
现在车载领域，ECC（椭圆曲线密码学） 越来越流行。为啥？因为同样的安全强度，ECC 的密钥长度比 RSA 短得多。
| 安全等级 | RSA 密钥长度 | ECC 密钥长度 |
|---|---|---|
| 80 位 | 1024 位 | 160 位 |
| 112 位 | 2048 位 | 224 位 |
| 128 位 | 3072 位 | 256 位 |
| 256 位 | 15360 位 | 512 位 |
你看这表，128 位安全等级下，RSA 要 3072 位，ECC 只要 256 位。车载 ECU 资源有限，你想想看，哪个更合适？
但 RSA 也不是一无是处。我记得有个老项目，硬件加速器只支持 RSA，那没办法，只能硬着头皮用。不过现在新设计的平台，我建议直接上 ECC。
我的建议：新项目首选 ECC，曲线推荐 NIST P-256 或 Curve25519。兼容性好，性能也够用。
2.3 哈希函数：SHA-256
哈希函数，就是把任意长度的数据，压缩成固定长度的摘要。而且这个过程不可逆。你没法从摘要反推出原始数据。
SHA-256 是目前最常用的哈希算法。输出 256 位（32 字节），碰撞概率极低。在车载通信中，我常用它来做固件完整性校验。
举个例子：
// 计算固件哈希
固件文件 = "firmware.bin"
哈希值 = SHA256(固件文件) // 输出 32 字节
// 车端收到固件后，重新计算哈希
// 如果跟云端下发的哈希一致，说明固件没被篡改嗯，这里要注意：哈希函数只保证完整性，不保证真实性。什么意思？如果有人把固件和哈希值一起改了，你照样发现不了。所以哈希值本身也需要被保护——通常用数字签名来保护。
2.4 消息认证码：HMAC
HMAC（Hash-based Message Authentication Code），说白了就是带密钥的哈希。它解决了哈希函数的一个痛点：没有密钥，谁都能算。
HMAC 的公式长这样：
HMAC(K, m) = H( (K' ⊕ opad) || H( (K' ⊕ ipad) || m ) )看着复杂？其实核心思想就是：把密钥混进哈希计算里。只有知道密钥的人，才能算出正确的 MAC 值。
我在项目中遇到过一个问题：用简单的哈希做消息校验，结果被中间人攻击了。攻击者截获消息后，重新计算哈希，然后替换掉原来的哈希值。后来换成 HMAC，密钥只有通信双方知道，攻击者算不出来，问题就解决了。
关键区别：哈希函数（SHA-256）→ 完整性校验；HMAC → 完整性校验 + 身份认证（基于共享密钥）。
2.5 数字签名：ECDSA
数字签名，是非对称加密的典型应用。私钥签名，公钥验签。它解决了 HMAC 的一个局限：HMAC 需要双方共享密钥，而数字签名不需要。
在车载场景下，ECDSA（椭圆曲线数字签名算法） 是主流选择。配合 ECC 公钥体系，签名短、性能好。
签名过程：
- 对消息计算哈希（SHA-256）
- 用私钥对哈希值签名，生成签名值 (r, s)
- 发送消息 + 签名值
验签过程：
- 接收方对消息计算哈希
- 用公钥验证签名 (r, s) 是否匹配哈希值
- 匹配则通过，否则拒绝
// ECDSA 签名示例
私钥 = 随机生成256位私钥
公钥 = 私钥 * G // G 是椭圆曲线基点
// 签名
消息 = "CAN ID 0x123: 车速 80km/h"
哈希 = SHA256(消息)
签名值 = ECDSA_sign(私钥, 哈希)
// 验签
验签结果 = ECDSA_verify(公钥, 哈希, 签名值)
// 返回 true 或 false避坑指南：我曾经见过一个案例，签名时随机数生成器出了问题，导致两次签名用了同一个随机数。结果攻击者直接算出了私钥。记住：ECDSA 的随机数必须真随机，且每次不同！
2.6 小结：怎么选？
好了，五种工具都过了一遍。最后给个选择建议：
- 大数据量加密：用 AES-GCM，效率高，自带认证
- 密钥交换：用 ECDH（基于 ECC 的密钥交换协议）
- 身份认证：用 ECDSA 数字签名
- 消息完整性：用 HMAC 或数字签名，看场景
- 固件哈希：用 SHA-256
你想想看，车载通信安全，说白了就是把这些工具组合起来，搭一个坚固的防护体系。下一章咱们就聊聊怎么把这些工具用到实际的 CAN 通信和以太网通信中去。
嗯，今天就到这儿。有问题随时问我。