1. 车载通信安全概述
各位同学，今天咱们聊聊车载通信安全。说实话，这个领域我干了快十年，踩过的坑真不少。先从最基础的讲起——车载网络架构的演进。
1.1 车载网络架构演进
早期的汽车，说白了就是个机械装置。电子系统很少，一个ECU就能搞定一切。但现在呢？一辆高端车可能有上百个ECU，它们之间要通信、要协同。这就催生了各种车载网络总线。
CAN总线——这个大家应该不陌生。我最早接触车载网络就是CAN，那时候觉得这东西真简单，两根线就能跑。CAN总线速度最高1Mbps，对于动力系统、车身控制这些实时性要求高的场景，够用了。但它的缺点也很明显：广播式通信，所有节点都能听到；帧ID优先级机制，低优先级消息可能被饿死。
LIN总线——说白了就是CAN的廉价替代方案。速度只有20kbps，用于车窗、座椅、门锁这些不要求实时性的场景。我见过不少项目，为了省几毛钱，把LIN用在安全关键系统上，结果出过问题。嗯，这里要注意：LIN只适合非安全场景。
FlexRay——这个可能接触的人少一些。它比CAN快，最高10Mbps，而且支持时间触发和事件触发两种模式。我在做线控转向项目时用过FlexRay，它的确定性确实好，但成本高、生态不完善，现在用得越来越少了。
车载以太网——这才是未来的方向。100BASE-T1、1000BASE-T1，速度从100Mbps到1Gbps。为什么需要这么快？因为ADAS、自动驾驶、车载娱乐系统，这些动辄传输摄像头数据、雷达数据，CAN那点带宽根本不够看。我个人习惯，新项目能上以太网就上以太网，别犹豫。
| 总线类型 | 速度 | 典型应用 | 安全特性 |
|---|---|---|---|
| CAN | 最高1Mbps | 动力、车身控制 | 无原生安全 |
| LIN | 20kbps | 车窗、座椅 | 无原生安全 |
| FlexRay | 10Mbps | 线控、底盘 | 无原生安全 |
| 车载以太网 | 100Mbps-1Gbps | ADAS、娱乐、诊断 | 支持MACsec、IPsec |
核心观点：车载网络从单一总线走向混合架构，以太网将成为骨干网。但CAN不会消失，它会作为子网继续存在。安全设计必须覆盖所有总线类型。
1.2 车载通信面临的安全威胁
你想想看，一辆车上有这么多ECU在通信，如果被攻击了会怎样？我参与过几个安全事件的分析，说实话，触目惊心。
窃听——CAN总线是广播式的，你只要接上OBD接口，就能听到所有消息。我在做渗透测试时，用一台树莓派加CANtact就能抓取所有报文。什么车速、油门、刹车信号，一览无余。这还不是最可怕的，可怕的是这些数据可以被用来分析驾驶行为。
篡改——窃听只是第一步。如果你能发送伪造的CAN消息呢？我曾经在实验室里做过一个实验：伪造一个刹车信号，让ECU误以为刹车被踩下。结果呢？车辆自动减速了。你想想看，如果这个攻击发生在高速公路上...嗯，后果不堪设想。
重放攻击——这个更隐蔽。攻击者先记录一段合法的CAN消息，比如「解锁车门」的指令，然后在合适的时候重放。我见过一个真实案例：攻击者用无线设备记录遥控钥匙的信号，等车主离开后重放，轻松打开车门。为什么能成功？因为很多车载系统没有时间戳或序列号机制。
拒绝服务（DoS）——这个最简单也最粗暴。往CAN总线上狂发高优先级消息，把总线带宽占满。我做过测试，只要持续发送ID为0x000的消息（最高优先级），其他ECU就发不出任何消息了。这意味着什么？发动机控制、刹车控制全部失效。你说危不危险？
警告：我曾经在某个项目中，发现OBD接口直接暴露在车内，没有任何访问控制。这意味着任何人都可以物理接入CAN总线。这是最基础的安全漏洞，但很多OEM居然忽略了。
1.3 车载通信安全目标
好，既然有这么多威胁，那我们的安全目标是什么？说白了，就是五个词：机密性、完整性、可用性、真实性、不可否认性。我一个个讲。
机密性——防止信息被窃听。说白了就是加密。但车载通信对实时性要求极高，加密不能引入太大延迟。我建议用对称加密，比如AES-128，硬件加速后延迟可以控制在微秒级。非对称加密？太慢了，不适合实时通信。
完整性——防止信息被篡改。这个靠消息认证码（MAC）来实现。发送方计算MAC，接收方验证。如果MAC不匹配，说明消息被篡改了。我在项目中常用CMAC或HMAC，具体用哪个取决于硬件支持情况。
可用性——防止拒绝服务攻击。这个最难。因为车载网络是实时系统，你不能说「等一会儿再处理」。我见过一些方案：消息优先级管理、速率限制、异常检测。但说实话，没有银弹。你只能尽量降低攻击面。
真实性——确认消息来源是合法的。说白了就是身份认证。每个ECU要有唯一的身份标识，通信时要验证对方身份。我建议用数字证书或预共享密钥。但要注意：密钥管理是个大问题，不能硬编码在代码里。
不可否认性——防止发送方否认自己发过某条消息。这个在车载场景中主要用于事后审计。比如事故分析时，要能证明某个ECU确实发送了某个指令。数字签名可以实现不可否认性，但计算开销大，一般只在关键事件中使用。
| 安全目标 | 威胁 | 技术手段 | 我的建议 |
|---|---|---|---|
| 机密性 | 窃听 | 加密 | AES-128，硬件加速 |
| 完整性 | 篡改 | 消息认证码 | CMAC或HMAC |
| 可用性 | 拒绝服务 | 速率限制、异常检测 | 多层防御 |
| 真实性 | 伪造 | 身份认证 | 数字证书或预共享密钥 |
| 不可否认性 | 抵赖 | 数字签名 | 仅用于关键事件 |
避坑指南：我曾经在一个项目中，为了追求「绝对安全」，给每条CAN消息都加了加密和签名。结果呢？ECU的CPU负载飙升到90%，实时性完全无法保证。后来我学乖了：安全要分级，关键消息（刹车、转向）用强保护，非关键消息（车窗、座椅）用弱保护甚至不保护。你想想看，车窗消息被篡改了能怎样？最多玻璃碎了。但刹车消息被篡改了，那是要出人命的。
好了，这一章就讲到这里。下一章咱们聊聊具体的加密算法和认证协议，我会结合我在实际项目中的经验，给大家讲讲哪些方案靠谱，哪些方案是坑。记住一句话：车载安全没有银弹，只有权衡。