路侧单元被劫持，交叉路口的车全部收到了假信号——V2X路侧安全该怎么做？

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_key=sender_cert.get_public_key()# SM2 公钥# 3. 验证消息签名ifnotsm2_verify(message,signature,public_key):raiseSignatureVerificationError("消息签名验证失败，丢弃")# 4. 验证消息新鲜度（防重放）ifmessage.timestamp<current_time()-REPLAY_WINDOW:raiseReplayAttackDetected("消息过期，可能为重放攻击")returnTrue

关键点：证书必须定期轮换（建议单次通信使用假名证书），防止通过长期证书追踪车辆轨迹。

第二层：RSU 设备安全

RSU 本体的硬件安全基础：

私钥安全是核心中的核心。如果 RSU 的私钥可以被提取，所有的消息签名机制就完全失效。安当 KSP（密钥服务平台）在路侧场景中的价值，正是为 RSU 提供硬件级的密钥保护和远程密钥注入能力——私钥在设备出厂时注入 HSM，全程不以明文形态出现在任何地方。

第三层：通信信道安全

RSU 与云端中心平台之间的通信必须加密和认证：

RSU ←→ 中心平台通信安全架构 ├── 双向 TLS（mTLS）认证 │ ├── RSU 持有设备证书（SM2） │ └── 中心平台持有服务端证书 ├── 数据加密：SM4-GCM 全程加密 └── 数据完整性：每包附带 HMAC-SM3

特别注意：RSU 的 4G/5G 管理通道，如果只做了服务器端认证而没有做设备端认证，等于只锁了门不锁窗。

第四层：异常行为监测

即使做好了前三层，仍然需要实时监测异常行为：

路侧异常检测规则举例：

• 同一位置短时间内出现大量来源相同但内容矛盾的消息 → 疑似消息注入攻击
• RSU 接收到的消息中，签名有效但位置信息与已知地理范围严重偏离 → Sybil 攻击（女巫攻击，伪造多个虚假身份）
• RSU 固件 Hash 与基线不匹配 → 可能存在固件篡改

这部分能力需要整合进 VSOC（车辆安全运营中心），路侧安全事件和车端安全事件统一关联分析。

四、证书体系：路侧安全的隐患往往藏在这里

很多团队把注意力放在 RSU 的通信加密上，反而忽略了证书基础设施本身。

一个典型的血泪教训：某试点城市部署的 RSU，使用的是自签名证书，没有接入任何 CA 体系。这意味着：

1. 任何人都可以生成一个"看起来有效"的证书
2. 没有吊销机制，设备私钥泄露了也无法撤销
3. 跨域互认完全无法实现

正确的做法：

证书层级架构（符合 GB/T 20518 要求） 根CA（Root CA） └── 中间CA（Intermediate 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 部署时，路侧安全是同步规划的，还是作为"后续工作"先跳过去了？评论区聊聊真实情况。