2. 车载网络与安全基础

车载电子电气架构正从分布式 ECU 向“域集中—中央计算”演进,通信链路也从单一 CAN 总线扩展到 CAN FD、车载以太网、LIN、FlexRay 以及 V2X 无线通信。理解这些协议的分层位置、报文特征与信任边界,是后续设计 TLS 与双向认证方案的前提。本节先建立“协议—攻击面—安全需求—威胁模型”的完整认知链条。

一、核心原理:车载通信协议的分层与特征

车载网络可按“有线主干 + 无线外联”划分。有线侧以 CAN/CAN FD 承担动力、车身、底盘等实时控制;LIN 用于车窗、座椅等低速从节点;FlexRay 用于线控等确定性场景;车载以太网(100BASE-T1/1000BASE-T1)承担诊断、摄像头、域控间高带宽通信。无线侧包括蓝牙、Wi-Fi、蜂窝 5G 与 V2X(C-V2X/DSRC),实现车云、车车、车路协同。

关键差异在于:CAN 是广播式、无源地址、无认证、无加密的短帧总线,仲裁靠 ID 优先级;以太网具备 MAC/IP/端口寻址与交换能力,可承载 TLS/TCP;V2X 则依赖 PKI 证书体系与广播安全消息(BSM)。因此,安全机制不能“一刀切”,必须按链路能力分层部署。

车载通信协议分层与信任边界 无线外联层(不可信 / 强认证) V2X / C-V2X 蜂窝 5G / 车云 Wi-Fi / 蓝牙 OTA 升级通道 T-Box / 网关 中央网关 / 域控制器(信任锚点) 防火墙 · IDS · 安全启动 · 密钥存储 有线主干层(分区信任 / 需隔离) CAN / CAN FD 广播 · 无认证 · 短帧 动力 / 车身 / 底盘 车载以太网 100/1000BASE-T1 可承载 TLS / IPsec LIN / FlexRay 低速从节点 确定性线控 诊断接口 OBD / UDS 物理访问风险 典型攻击面(按入口标注) 无线注入 / 伪基站 V2X 伪造 BSM CAN 重放 / 洪泛 ID 伪造 / 总线嗅探 以太网 ARP 欺骗 中间人 / 端口扫描 OBD 物理接入 固件提取 / 刷写

二、常见攻击面:从物理到无线的四类入口

车载攻击面可归纳为四类。第一类是物理接口:OBD-II 诊断口、USB、调试串口、JTAG,攻击者可直连总线读取或刷写固件。第二类是短距无线:蓝牙、Wi-Fi、无钥匙进入(RKE/PKE)的射频重放与中继攻击。第三类是远距无线:蜂窝网络、V2X 广播、OTA 通道,典型如伪造 BSM 引发误制动、劫持 OTA 下发恶意包。第四类是车内总线:CAN 无认证导致报文重放、ID 伪造、总线洪泛;以太网侧存在 ARP 欺骗、VLAN 跳转、DoS。

注意:CAN 报文没有源地址与完整性校验,任何接入总线的节点都能伪造“刹车”“转向”等关键信号。因此,网关必须做域间隔离与报文白名单过滤,而不是仅依赖应用层加密。

三、安全需求:CIA 在车载场景的落地

车载安全需求围绕机密性、完整性、可用性与真实性展开,但优先级与 IT 系统不同:可用性与实时性优先,安全机制不能引入不可接受的时延。具体需求包括:

  • 身份真实性:ECU、T-Box、V2X 节点需具备唯一身份与证书,支持双向认证。
  • 报文完整性:关键控制报文需防篡改,CAN 可用 SecOC(AUTOSAR)加 MAC 与新鲜度值。
  • 机密性:OTA 包、诊断数据、位置与用户隐私需加密传输。
  • 可用性:防总线洪泛、防 DoS,保证安全关键功能降级可控。
  • 可审计:安全事件日志、密钥生命周期与证书吊销可追溯。

四、威胁模型:STRIDE 与攻击树结合

威胁建模建议采用 STRIDE 分类,并结合攻击树定位高价值路径。以“远程控制车辆”为目标,攻击树可拆为:进入 T-Box → 提权到网关 → 跨域到 CAN → 伪造控制报文。对应 STRIDE 映射如下表:

STRIDE 类别 车载典型威胁 受影响协议/接口 缓解方向
仿冒 Spoofing 伪造 ECU、伪基站、伪造 V2X 证书 CAN、V2X、以太网 双向认证、证书 PKI、SecOC
篡改 Tampering 修改 OTA 包、篡改诊断请求 OTA、UDS、以太网 签名校验、TLS、安全启动
抵赖 Repudiation 否认下发过危险指令 车云、诊断 操作日志、数字签名审计
信息泄露 总线嗅探、位置与用户数据外泄 CAN、蜂窝、Wi-Fi 加密、最小化采集、访问控制
拒绝服务 CAN 洪泛、以太网 DoS CAN、以太网 优先级隔离、限流、IDS
提权 Elevation 从信息娱乐域提权到动力域 网关、域控 域间防火墙、最小权限

五、案例与误区复盘

某车型 T-Box 通过蜂窝网络接收远程指令,未对下行指令做双向认证,攻击者仅凭重放即可解锁车门。复盘发现:T-Box 与车云之间使用了单向 TLS(仅验证服务器),未校验客户端身份,且指令缺少时间戳与序列号。修复方案是启用 mTLS、加入 nonce 与防重放窗口,并在网关侧对 CAN 控制报文启用 SecOC。

常见误区:一是认为“CAN 是内网所以安全”,忽略物理接入与网关被攻破后的横向移动;二是把 TLS 当作万能药,忽略 CAN 无法直接承载 TLS,需要 SecOC 或网关代理;三是只做加密不做认证,导致中间人仍可转发合法密文。

综上,车载安全必须按“协议能力—攻击面—安全需求—威胁模型”逐层映射:无线侧强认证、网关侧强隔离、总线侧强完整性。只有把信任边界画清楚,后续的 TLS 与双向认证设计才有明确的落点。