2024年底德国某智慧交通试点城市发生了一起安全事件攻击者向路侧单元RSU发送了伪造的 SPAT信号灯相位与配时消息导致一个路口的数十辆C-V2X车辆接收到错误的绿灯信号险些造成事故。事后溯源发现该 RSU 没有对接收消息做签名验证任何设备只要在通信范围内发送符合格式的消息都会被接受。这件事揭示了一个行业共识V2X 的安全不只是车端的问题路侧单元才是更危险的突破口。一、为什么路侧单元比车辆更容易被攻击直觉上车辆是移动的路侧单元是固定的固定的应该更安全。但现实恰恰相反物理暴露度更高路侧单元部署在路口、高速护栏、隧道入口任何人都可以近距离接触。车辆至少有车主、停车场等隔离层RSU 往往就是个没有物理防护的铁盒子。运维疏忽率更高路侧基础设施属于交通管理部门或建设方安全补丁的更新频率远低于车端OTA。我们在某城市做排查时发现已部署的 RSU 中有近 40% 运行的固件存在已知 CVE 漏洞且从未做过更新。覆盖范围影响放大一辆车被攻击影响的是这辆车。一个路口的 RSU 被攻击影响的是这个路口所有的联网车辆——天然的单点影响多点。二、V2X 路侧安全的攻击面拆解攻击者可以从哪些角度入手2.1 消息伪造攻击V2X 消息类型BSM/SPAT/MAP/RSM都有标准格式如果 RSU 不做签名验证攻击者只需要一台支持 C-V2X 的软件无线电设备就能广播任意内容发送虚假 SPAT 消息红灯说绿灯广播伪造的道路危险预警没有事故说有事故诱导车辆规避注入虚假 BSM伪造前车位置干扰自适应巡航2.2 RSU 本体渗透RSU 通常运行嵌入式 Linux对外有多个接口RSU 对外接口 ├── 空口 (PC5/DSRC) → V2X 消息收发 ├── 以太网 → 与中心平台通信上行 ├── 4G/5G → 云端管理通道 └── 本地调试口 → 物理接触攻击面攻击路径举例通过管理通道漏洞拿下 RSU 控制权 → 篡改其广播内容通过暴露的调试串口刷入恶意固件中间人攻击 RSU 与中心平台的通信信道注入假数据2.3 证书基础设施攻击V2X 安全的根基是 PKI 证书体系SCMS/C-SCMS。如果证书签发机构被攻破或者 RSU 的私钥被提取攻击者就能以合法身份广播恶意消息而且根本无法被检测到。三、路侧安全防护体系的四层架构有效的 V2X 路侧安全防护需要从以下四个层次同时布防第一层消息安全密码学基础所有 V2X 消息必须使用ECDSA椭圆曲线数字签名算法进行签名接收方在处理消息前完成验签。中国标准下推荐使用SM2 算法国密对应的证书体系采用符合 GB/T 20518 的 PKI 架构。# V2X 消息签名验证伪代码示例defverify_v2x_message(message,signature,sender_cert):# 1. 验证发送方证书有效性未过期、未吊销ifnotcert_authority.verify(sender_cert):raiseCertificateInvalidError(证书无效或已吊销)# 2. 提取发送方公钥public_keysender_cert.get_public_key()# SM2 公钥# 3. 验证消息签名ifnotsm2_verify(message,signature,public_key):raiseSignatureVerificationError(消息签名验证失败丢弃)# 4. 验证消息新鲜度防重放ifmessage.timestampcurrent_time()-REPLAY_WINDOW:raiseReplayAttackDetected(消息过期可能为重放攻击)returnTrue关键点证书必须定期轮换建议单次通信使用假名证书防止通过长期证书追踪车辆轨迹。第二层RSU 设备安全RSU 本体的硬件安全基础安全能力推荐实现方式私钥存储内置 HSM 或 SE安全元件私钥不出硬件固件完整性启动时验证固件签名Secure Boot调试口管控量产设备物理禁用 JTAG/UART 调试接口物理防篡改开盖检测传感器 触发密钥自毁私钥安全是核心中的核心。如果 RSU 的私钥可以被提取所有的消息签名机制就完全失效。安当 KSP密钥服务平台在路侧场景中的价值正是为 RSU 提供硬件级的密钥保护和远程密钥注入能力——私钥在设备出厂时注入 HSM全程不以明文形态出现在任何地方。第三层通信信道安全RSU 与云端中心平台之间的通信必须加密和认证RSU ←→ 中心平台通信安全架构 ├── 双向 TLSmTLS认证 │ ├── RSU 持有设备证书SM2 │ └── 中心平台持有服务端证书 ├── 数据加密SM4-GCM 全程加密 └── 数据完整性每包附带 HMAC-SM3特别注意RSU 的 4G/5G 管理通道如果只做了服务器端认证而没有做设备端认证等于只锁了门不锁窗。第四层异常行为监测即使做好了前三层仍然需要实时监测异常行为路侧异常检测规则举例同一位置短时间内出现大量来源相同但内容矛盾的消息 → 疑似消息注入攻击RSU 接收到的消息中签名有效但位置信息与已知地理范围严重偏离 → Sybil 攻击女巫攻击伪造多个虚假身份RSU 固件 Hash 与基线不匹配 → 可能存在固件篡改这部分能力需要整合进 VSOC车辆安全运营中心路侧安全事件和车端安全事件统一关联分析。四、证书体系路侧安全的隐患往往藏在这里很多团队把注意力放在 RSU 的通信加密上反而忽略了证书基础设施本身。一个典型的血泪教训某试点城市部署的 RSU使用的是自签名证书没有接入任何 CA 体系。这意味着任何人都可以生成一个看起来有效的证书没有吊销机制设备私钥泄露了也无法撤销跨域互认完全无法实现正确的做法证书层级架构符合 GB/T 20518 要求 根CARoot CA └── 中间CAIntermediate CA按地区/运营商分级 ├── 注册机构 RA负责身份审核 └── 假名证书颁发机构 PCA ├── RSU 设备证书长期设备身份 └── 车辆假名证书短期通信隐私保护证书吊销响应时间是另一个关键指标。设备私钥泄露后从触发吊销到全网 RSU 同步 CRL证书吊销列表理论上不应超过4 小时。五、路侧安全建设的优先级建议对于正在做 V2X 部署的团队给个实用的优先级排序P0必须做否则等于没有安全全部 RSU 接入合规 PKI 证书体系所有 V2X 消息强制签名 验签RSU 私钥存储在 HSM 内P1三个月内完成RSU 固件 OTA 更新机制 签名验证RSU 与中心平台 mTLS 双向认证异常消息检测规则上线P2规划阶段VSOC 集成路侧安全事件跨运营商/跨城市证书互认路侧安全红蓝对抗演练六、总结V2X 路侧安全的核心逻辑很简单RSU 是整个车路协同系统中权重最高、防护最薄弱的节点攻击一个 RSU 能影响过往所有联网车辆而它又往往暴露在公开环境中、更新滞后。做好路侧安全需要把密码学基础消息签名/验签、硬件安全HSM私钥保护、信道安全mTLS、持续监测异常行为检测四层拧成一股绳——任何一层缺失整体的安全等级都会退化为最弱环节的水平。车路协同真正落地的那天路侧安全的重要性会更加凸显。从现在开始做总比出了事故后再补强要值。你们做 V2X 部署时路侧安全是同步规划的还是作为后续工作先跳过去了评论区聊聊真实情况。
