4、密码学基础（下）：非对称加密（ECC、RSA）、哈希函数（SHA-2/3）、消息认证码（CMAC、HMAC）
好，咱们接着聊。上一节我们把对称加密和随机数聊透了，这一节要啃的可是硬骨头——非对称加密、哈希函数，还有消息认证码。说实话，这些概念在车载CAN FD安全通信里，一个都绕不开。
我刚开始接触车载安全时，总觉得非对称加密太慢，不适合CAN总线。后来被现实狠狠教育了一回——没有非对称加密，密钥分发就是个死局。你想想看，成千上万辆车，每辆车几十个ECU，光靠预置密钥？维护成本能让你哭出来。
4.1 非对称加密：RSA与ECC
非对称加密的核心思想，说白了就是「公钥加密，私钥解密」。公钥随便发，私钥自己藏。这玩意儿在车载场景下，主要用来做密钥交换和数字签名。
4.1.1 RSA——老牌选手
RSA基于大整数分解难题。两个大素数相乘容易，但反过来分解就难了。嗯，这个原理本身没问题，但我在项目中遇到过一个问题：RSA的密钥长度太长了。
在CAN FD上，一个数据帧最多64字节。你用2048位的RSA密钥，光签名就256字节，一个包根本装不下。更别提RSA的计算量，在那些主频只有几十兆的MCU上，跑一次签名验证能卡住几百毫秒。
RSA在车载中的典型参数：
- 密钥长度：2048位（最低安全要求）
- 签名长度：256字节
- 典型计算时间（Cortex-M4 @ 120MHz）：签名约200ms，验签约10ms
注意：我曾经见过一个方案，用RSA-1024做ECU固件签名。嗯，1024位现在已经被证明不够安全了。如果你还在用，赶紧升级到2048位以上。
4.1.2 ECC——车载新宠
ECC（椭圆曲线密码学）的优势在于：同样的安全强度，密钥长度短得多。256位的ECC，安全性和3072位的RSA差不多。但ECC的签名长度只有64字节，刚好能塞进一个CAN FD帧里。
我个人习惯在车载项目里优先选ECC。原因很简单：
- 密钥短，带宽占用小
- 计算量相对小，适合嵌入式环境
- 支持ECDH密钥交换，完美解决对称密钥分发问题
你可能会问：「ECC这么香，那RSA是不是该淘汰了？」也不尽然。有些老旧的ECU只支持RSA加速指令，这时候你还得用RSA。我建议的做法是：新设计用ECC，兼容老平台时保留RSA。
实战建议：在CAN FD安全通信中，我通常用ECDH做密钥协商，然后用协商出的对称密钥做AES加密。这样既解决了密钥分发问题，又保证了通信效率。
4.2 哈希函数：SHA-2与SHA-3
哈希函数，说白了就是「数据指纹」。不管输入多长，输出固定长度。而且，好的哈希函数要满足：
- 单向性：从哈希值推不出原始数据
- 抗碰撞：找不到两个不同输入有相同哈希值
- 雪崩效应：输入改一比特，输出大变样
4.2.1 SHA-2系列
SHA-2是目前最主流的哈希算法。包括SHA-224、SHA-256、SHA-384、SHA-512。在车载领域，SHA-256用得最多，输出32字节，不长不短刚刚好。
我记得有一次做CAN FD刷写验证，需要校验固件的完整性。用SHA-256算一下哈希，和预置的哈希值比对，简单可靠。但要注意一点：SHA-2本身不防篡改，它只保证完整性。如果有人同时改了固件和哈希值，你根本发现不了。
SHA-2在车载中的典型应用：
- 固件完整性校验
- 数字签名中的哈希计算
- 密钥派生函数（KDF）的基础
4.2.2 SHA-3——新一代选手
SHA-3和SHA-2没有继承关系。它用的是海绵结构，和SHA-2的Merkle-Damgård结构完全不同。SHA-3的优势在于：
- 对长度扩展攻击天然免疫
- 硬件实现效率高
- 安全性冗余更大
不过说实话，在车载领域，SHA-3目前还没大规模铺开。我建议你先把SHA-2吃透，等SHA-3的硬件加速模块普及了再切换也不迟。
避坑指南：我曾经见过有人用MD5做固件校验。MD5已经被破解了，碰撞攻击成本极低。千万别用！SHA-1也建议退役，虽然还没完全破解，但已经不安全了。
4.3 消息认证码：CMAC与HMAC
消息认证码（MAC）解决的是「消息是谁发的」和「消息有没有被改过」这两个问题。它和哈希的区别在于：MAC需要密钥。
4.3.1 HMAC——哈希+密钥
HMAC的构造很简单：把密钥和消息混在一起算哈希。公式大致是：
HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))嗯，看着有点复杂，但核心思想就是：密钥参与哈希计算，没有密钥的人伪造不了有效的MAC。
在CAN FD安全通信中，HMAC常用于：
- 会话消息的完整性保护
- 诊断请求的认证
- 密钥更新协议的验证
个人经验：用HMAC时，密钥长度不要小于哈希输出的长度。比如用SHA-256，密钥至少32字节。短密钥会降低安全性，这是我踩过的坑。
4.3.2 CMAC——基于分组密码的MAC
CMAC（也叫OMAC1）是基于AES等分组密码构造的MAC。它的好处是：如果你已经在用AES做加密，那CMAC可以复用AES的硬件加速模块，省资源。
CMAC的计算过程大致是：
- 用AES加密消息的最后一个分组
- 如果消息长度不是分组大小的整数倍，需要填充
- 输出就是MAC值
我建议在以下场景优先用CMAC：
- 硬件已经支持AES加速
- 消息长度固定（比如CAN FD帧）
- 需要同时做加密和认证（用同一个密钥）
HMAC vs CMAC 对比：
| 特性 | HMAC | CMAC |
|---|---|---|
| 基础算法 | 哈希函数（SHA-2/3） | 分组密码（AES） |
| 输出长度 | 可变（取决于哈希） | 固定（分组大小） |
| 硬件加速 | 需要哈希加速 | 可复用AES加速 |
| 典型应用 | 会话认证、密钥派生 | 消息完整性、帧认证 |
4.4 实战：在CAN FD上实现安全通信
好了，理论讲完了，咱们来点实际的。假设你要在CAN FD上实现一个安全通信方案，我会怎么做？
- 密钥协商阶段：用ECDH在ECU之间协商一个共享密钥。公钥可以通过证书链验证，防止中间人攻击。
- 会话密钥派生：用协商出的共享密钥，通过HKDF（基于HMAC的密钥派生函数）生成加密密钥和认证密钥。
- 消息加密：用AES-128-CTR模式加密CAN FD数据场。CTR模式不需要填充，适合短消息。
- 消息认证：用CMAC计算加密后的消息的MAC值，附加在数据场末尾。
- 防重放：在消息中加入单调递增的计数器，接收方检查计数器是否合法。
你可能会问：「为什么不用RSA做密钥交换？」嗯，RSA的密钥对生成太慢了，在ECU上跑一次能等半天。ECDH快得多，而且密钥长度短，适合CAN FD的带宽限制。
重要提醒：以上方案只是基础框架。实际部署时，还要考虑密钥存储安全（比如用HSM或Secure Element）、安全启动、安全刷写等。安全是一个系统工程，不是加几个算法就完事了。
好了，这一节的内容就到这儿。下一节我们聊聊「CAN FD安全帧格式设计」，到时候我会把这一节的知识点串起来，给你一个完整的实战方案。
课后思考：如果让你在CAN FD上实现一个「安全刷写」功能，你会怎么设计密钥管理和认证流程？欢迎带着这个问题来下一节课。