3、车载网络协议栈安全：CAN总线安全机制与车载以太网安全

各位同学，咱们今天聊点硬核的。车载网络协议栈安全，说白了就是给车上的通信管道加把锁。我做了这么多年汽车电子，见过太多因为通信被篡改而出的事故——虽然不是我的项目，但每次听到都后背发凉。

这一章，咱们重点啃三块硬骨头：CAN总线的安全机制、车载以太网的安全方案，还有SOME/IP的安全扩展。嗯，内容不少，但都是实战中绕不开的。

3.1 CAN总线安全机制：从CAN到CAN-FD再到CANsec

先说说CAN总线。这玩意儿在车上用了三十多年，可靠性没得说，但安全性嘛...说实话，设计之初就没考虑过。你想想看，当年谁会觉得有人会去黑一辆车的CAN总线？

但现实很骨感。我在2018年参与过一个项目，客户要求对CAN报文做认证。那时候CANsec还没普及，我们只能用一些土办法。现在好了，有了CAN-FD和CANsec，事情变得规范多了。

3.1.1 CAN-FD带来的变化

CAN-FD（Flexible Data-rate）相比传统CAN，最大的变化有两个：

• 数据场变大了：从8字节扩展到64字节。这意味着什么？你可以在一个帧里塞下更多的安全信息，比如消息认证码（MAC）。
• 速率可调：仲裁段用标准速率（最高1Mbps），数据段可以飙到8Mbps。这给加密运算留出了时间窗口。

我个人习惯，在设计安全方案时，优先考虑CAN-FD。为什么？因为64字节的数据场，足够放下一个完整的AES-128 CMAC（16字节）加上原始数据。传统CAN的8字节？太挤了，经常要拆帧，麻烦得很。

3.1.2 CANsec：真正的安全方案

CANsec是IEEE 802.1CB的扩展，专门为CAN总线设计的安全协议。它提供了两种服务：

• 完整性保护：通过消息认证码（MAC）确保报文没被篡改
• 可选的机密性：对数据场进行加密

这里有个关键点——CANsec的MAC是怎么算的？我给大家看个简化的流程：

// CANsec MAC计算伪代码
// 输入：CAN帧数据(data)，密钥(key)，新鲜度值(freshness)
// 输出：4字节MAC

function compute_cansec_mac(data, key, freshness):
    // 1. 构建认证数据块
    auth_data = freshness || data
    
    // 2. 使用AES-128 CMAC计算
    mac = aes_cmac(key, auth_data)
    
    // 3. 截取前4字节作为CANsec MAC
    return mac[0:4]

注意看，这里只取了前4字节。为什么不是16字节？因为CAN帧空间有限，4字节是安全性和带宽的折中。我曾经在项目里试过8字节的MAC，结果发现总线负载率直接飙到70%以上，控制器根本跑不动。

3.1.3 密钥管理：CANsec的命门

说实话，CANsec的算法本身没什么大问题，真正的难点在密钥管理。你想想看，一辆车上有几十个ECU，每个ECU都要有密钥，怎么分发？怎么更新？

我建议的做法是：

• 预置密钥：在产线阶段，通过安全通道把根密钥烧录到每个ECU的HSM（硬件安全模块）中
• 派生密钥：每个ECU根据根密钥和自身ID，派生出会话密钥
• 定期更新：通过安全诊断服务（如UDS的0x27服务）触发密钥更新

嗯，这里要注意，千万不要把密钥明文存储在Flash里。我见过有厂商直接把密钥写在代码里，结果被逆向工程扒了个精光。一定要用HSM或者安全元件来保护密钥。

3.2 车载以太网安全：MACsec、IPsec、TLS

车载以太网现在越来越普及，从ADAS到车载信息娱乐系统，都在用。但以太网天生就是为开放环境设计的，安全性嘛...你懂的。

车载以太网的安全方案，主要分三层：

3.2.1 MACsec：最底层的守护

MACsec工作在数据链路层，说白了就是给每个以太网帧加一个安全标签。它的好处是透明——上层应用完全感知不到它的存在。

我在项目中用过MACsec，说实话，配置起来有点麻烦。你需要：

• 在交换机和ECU上启用MACsec
• 配置预共享密钥（CAK）
• 设置密码套件（推荐GCM-AES-128）

但一旦配好了，效果立竿见影。所有以太网帧都被加密和认证，连ARP欺骗都防得住。

3.2.2 IPsec：跨网段的保镖

IPsec在网络层工作，保护的是IP数据包。它的优势在于：

• 端到端安全：不管中间经过多少跳，数据都是安全的
• 支持两种模式：传输模式（只保护载荷）和隧道模式（保护整个IP包）

在车载场景下，我推荐使用传输模式+ESP协议。为什么？因为隧道模式会增加额外的IP头，对于带宽敏感的车载网络来说，有点浪费。

配置IPsec时，有个关键参数——安全关联（SA）的生存周期。我曾经见过一个项目，把SA的生存周期设成了24小时。结果呢？车辆在行驶过程中，SA过期了，通信突然中断，差点造成安全事故。后来我建议把生存周期设为1小时，并在过期前30秒触发重新协商。

3.2.3 TLS：应用层的保险箱

TLS大家应该很熟悉了，HTTPS就是基于它。在车载环境里，TLS主要用于：

• OTA升级：确保升级包在传输过程中不被篡改
• 远程诊断：保护诊断数据的机密性和完整性
• V2X通信：车辆与云端的安全通道

但TLS在车载环境有个大问题——握手延迟。标准的TLS 1.3握手需要1-RTT（往返时间），对于某些实时性要求高的应用来说，这个延迟不可接受。

我个人的建议是：

• 对于实时性要求高的场景，使用预共享密钥（PSK）模式，可以做到0-RTT
• 对于安全性要求极高的场景（如OTA），使用证书模式，但要做好证书链的优化

3.3 SOME/IP安全扩展

SOME/IP是车载以太网上的服务发现和通信协议。它本身没有安全机制，但可以通过扩展来实现安全。

SOME/IP的安全扩展主要基于SOME/IP-SD（服务发现）的认证和SOME/IP消息的加密。具体来说：

• 服务发现认证：在SOME/IP-SD的Offer/Subscribe消息中，加入数字签名
• 消息加密：对SOME/IP的Payload进行加密，使用AES-GCM或ChaCha20-Poly1305

这里有个细节——SOME/IP的头部包含一个Session ID字段，可以用来防止重放攻击。我在项目中就利用了这个字段，配合时间戳，实现了轻量级的防重放机制。

好了，这一章的内容就到这里。CAN总线安全、车载以太网安全、SOME/IP安全扩展，这三块是车载通信安全的基石。下一章，咱们聊聊更具体的——密钥管理和PKI体系。嗯，那才是真正让人头疼的东西。