4、车载网络协议安全（CAN）：从物理层到攻防实战
大家好，我是老周。今天我们来聊聊CAN总线——这个在汽车里服役了几十年的“老兵”。说实话，我刚入行那会儿，觉得CAN总线挺简单的，不就是两根线嘛。直到我第一次参与实车渗透测试，才发现这里面的水有多深。
嗯，咱们先从最基础的说起。
4.1 CAN总线协议基础：两根线的江湖
CAN总线，全称Controller Area Network。它最早是博世在80年代搞出来的。你想想看，那时候的车还没什么电子系统，现在呢？一辆车里有几十个ECU（电子控制单元），全靠CAN总线串起来。
物理层上，CAN总线就两根线：CAN_H和CAN_L。它用的是差分信号传输，说白了就是两根线上的电压差来决定是0还是1。这样做的好处很明显——抗干扰能力强。我在一个项目中遇到过，发动机舱里电磁干扰那么严重，CAN总线照样跑得稳稳的。
数据链路层呢，CAN用的是帧结构。标准帧长这样：
SOF | 11位ID | RTR | IDE | r0 | DLC | 数据段(0-8字节) | CRC | ACK | EOF这里有个关键点——CAN帧没有源地址和目标地址。它用的是“广播”模式，所有节点都能收到所有消息。那怎么知道这条消息是发给谁的呢？靠ID来识别。每个ID代表一种消息类型，比如“车速信号”、“发动机转速”等等。
核心要点：CAN总线是一个多主总线，任何节点都可以随时发送消息。没有主从关系，大家平等。
4.2 CAN ID与仲裁机制：谁先说话谁有理
好，问题来了。如果两个节点同时发送消息，怎么办？这就涉及到仲裁机制了。
CAN总线的仲裁机制，说白了就是“谁的数字小谁赢”。ID值越小，优先级越高。比如ID=0x001的消息，优先级就比ID=0x7FF高得多。
具体怎么仲裁的呢？每个节点在发送时，会同时监听总线。如果它发送的是隐性位（1），但总线上出现了显性位（0），它就立刻停止发送，转为接收模式。这个过程是实时的，不会丢数据。
我记得有一次调试一个刹车系统，发现刹车信号总是被其他消息延迟。查了半天，原来是刹车信号的ID设得太大了。后来把ID改小，问题就解决了。嗯，这就是仲裁机制在实际中的影响。
个人经验：设计CAN网络时，一定要把关键安全消息（如刹车、转向）的ID设得最小。我曾经见过一个项目，把空调控制消息的ID设得比刹车还小，结果刹车响应慢了200ms——这在高速上可是要命的。
4.3 CAN总线常见攻击：黑客的“三板斧”
讲完了基础，咱们来看看攻击。CAN总线在设计之初，根本没考虑安全。它没有认证、没有加密、没有访问控制。说白了，就是“裸奔”的。所以攻击起来，其实挺容易的。
4.3.1 重放攻击
这是最简单的攻击方式。攻击者先监听总线，记录下一些关键消息，比如“解锁车门”、“启动引擎”。然后找个机会，把这些消息重新发一遍。
你想想看，如果攻击者录下了你按遥控钥匙时的CAN消息，他随时可以重放这条消息，把你的车门打开。这就是重放攻击。
警告：重放攻击不需要破解任何密码，只需要一个CAN总线监听设备（比如PCAN-USB）就能实现。成本不到2000块钱。
4.3.2 DoS攻击（拒绝服务攻击）
DoS攻击更狠。攻击者持续发送高优先级消息（比如ID=0x000），把总线带宽占满。其他节点想发消息？对不起，总线一直被占用，发不出去。
后果是什么？刹车信号发不出去、转向信号发不出去、仪表盘收不到车速数据……整个车就“瘫痪”了。
我在一个测试项目中模拟过这种攻击。当时用的是CANoe，持续发送ID=0x000的消息，结果发动机ECU直接报错，车辆进入了跛行模式。嗯，这要是发生在高速上，后果不堪设想。
4.3.3 篡改攻击
篡改攻击比前两种更隐蔽。攻击者不是简单地重放或阻塞消息，而是修改消息内容。比如，把车速信号从“60km/h”改成“0km/h”，让仪表盘显示错误的速度。
更危险的是，篡改攻击可以绕过一些简单的安全检测。比如有些ECU会检查消息的连续性，但攻击者可以伪造出连续的消息序列，让ECU以为一切正常。
关键点：这三种攻击可以组合使用。比如先用DoS让某个ECU下线，然后冒充这个ECU发送伪造消息。这就是所谓的“中间人攻击”。
4.4 CAN安全增强方案：给老古董穿上防弹衣
既然CAN总线这么不安全，那怎么防护呢？目前业界主要有两种方案：SecOC和CAN-FD。
4.4.1 SecOC（安全车载通信）
SecOC是AUTOSAR标准里定义的安全方案。它的核心思想是：给每条CAN消息加上一个“认证码”。
具体怎么做呢？发送方在发送消息时，会计算一个MAC（消息认证码），附在数据后面。接收方收到后，用同样的密钥计算MAC，比对一下。如果一致，说明消息是合法的；如果不一致，就丢弃。
这里要注意，SecOC不是加密消息内容，而是做认证。消息本身还是明文传输的，但攻击者无法伪造合法的消息。
// SecOC消息格式示例
原始数据: 0x11 0x22 0x33 0x44
MAC: 0xAA 0xBB 0xCC 0xDD
发送数据: 0x11 0x22 0x33 0x44 0xAA 0xBB 0xCC 0xDD避坑指南：我曾经在一个项目中部署SecOC，发现计算MAC的时间太长，导致消息延迟超标。后来优化了算法，把MAC计算从软件实现改成了硬件加速，才解决了问题。所以，部署SecOC时一定要考虑实时性。
4.4.2 CAN-FD（灵活数据速率）
CAN-FD是CAN总线的升级版。它有两个主要改进：
- 更高的数据速率：传统CAN最高1Mbps，CAN-FD可以到8Mbps甚至更高。
- 更大的数据段：传统CAN最多8字节数据，CAN-FD可以到64字节。
这两个改进对安全有什么帮助呢？
首先，更高的速率意味着可以传输更多的安全信息（比如更长的MAC）。其次，更大的数据段让SecOC的实现更容易——传统CAN只有8字节，去掉数据后留给MAC的空间很小；CAN-FD有64字节，空间充裕多了。
不过要注意，CAN-FD和传统CAN不完全兼容。CAN-FD节点可以和传统CAN节点通信，但只能以传统CAN的速率和帧格式。所以升级到CAN-FD时，需要逐步替换节点。
我的建议：新设计的车型，尽量直接上CAN-FD。虽然成本高一点，但为以后的安全升级留出了空间。我见过一些老车型，想加安全功能，结果CAN总线带宽不够，只能大改——那成本更高。
4.5 小结：安全是设计出来的，不是补上去的
好了，今天的内容就到这里。总结一下：
- CAN总线基础：两根线、广播模式、多主架构
- 仲裁机制：ID越小优先级越高
- 常见攻击：重放、DoS、篡改
- 安全方案：SecOC做认证，CAN-FD提供带宽和空间
最后说一句心里话：安全不是事后补丁，而是从设计之初就要考虑的。我见过太多项目，功能做完了才想起来加安全，结果改得面目全非。嗯，希望你们能少走这些弯路。
下一章，咱们聊聊车载以太网安全。那个比CAN复杂多了，但也更有意思。