智能网联汽车对外通信安全概述

引言

图1 智能网联汽车对外通信架构[1]

在很多人的认知里，汽车安全往往等同于刹车是否可靠、控制是否稳定，或者再进一步，是否存在车内 CAN 总线、ECU 被攻击的问题。但在我们长期参与汽车信息安全测试与评估的过程中，一个变化越来越明显------真正暴露风险最多的，往往不是"车内"，而是"车外"。

随着智能网联技术的普及，汽车早已不再是一个封闭运行的机械系统，而是演变为一个长期在线、持续通信、不断升级的软件系统。车辆在运行过程中，会持续与云端平台、路侧设施以及各类第三方服务发生数据交互，而这些"对外通信能力"，正在成为整车安全体系中不可忽视的关键环节。

从行业实践来看，越来越多安全问题并非源于控制算法本身的设计缺陷，而是出现在以下场景中：

车辆通过公网与云平台进行远程通信
车辆依赖第三方服务完成定位、内容分发或功能扩展
车辆通过 OTA 机制持续接收配置或软件更新

这些场景的共同特征在于：通信对象多、链路复杂、生命周期长，一旦安全边界设计不当，风险往往具备"远程性"和"规模性"。

智能网联汽车的对外通信方式

在很多讨论中，"对外通信"往往被当作一个整体概念来看待，似乎只要车辆能够联网，与外部系统进行数据交互，就完成了对外通信能力的构建。

但从工程体系和安全视角来看，这种理解是明显不够的。

智能网联汽车的对外通信，并不是一条链路，而是多种通信机制长期并存、相互叠加的结果。[2]

这些通信机制在设计目标、工程实现和风险特征上差异显著，如果不加区分地讨论，很容易在后续安全分析中失焦。

2.1 V2X：以"消息协同"为核心的实时通信机制

V2X 通信的核心目标，是实现车辆与道路基础设施、其他车辆之间的实时协同，其工程特点高度集中在"消息"本身。

与传统客户端---服务器通信不同，V2X 通信强调：

高发送频率
实时性要求高
消息类型和触发场景复杂

在工程实现中，车辆需要持续接收并处理来自外部环境的协同信息，而这些信息往往会直接影响车辆行为决策或系统状态。

这意味着，V2X 并不仅仅是一种"联网能力"，而是一种高度依赖消息可信性与行为约束的通信机制。

图2 V2X通信架构

图3 协同组网与控制场景

2.2 蜂窝通信（4G/5G）：公网环境下的远程通信主干

基于 4G/5G 的蜂窝通信，是当前智能网联汽车最核心、也是覆盖范围最广的对外通信方式。

它主要承担以下职责：

车辆与云平台之间的持续通信
远程服务、远程控制与运维能力
OTA 升级与策略下发

从工程角度看，蜂窝通信的显著特征在于：

通信链路长期在线
依赖公网环境
一旦能力失控，影响具备远程性和规模性

也正因如此，蜂窝通信往往成为对外通信安全评估中最复杂、也是最容易被低估的一部分。

2.3 GNSS：以"数据输入"为主的基础能力通信

GNSS 在智能网联汽车中通常不被直观理解为"通信"，但从系统角度看，它本质上是一种持续从外部环境接收数据的通信机制。

GNSS 提供的核心能力包括：

位置信息
时间同步
运动状态相关数据

在工程实现中，这类数据往往被视为"基础输入"，并被广泛用于导航、调度、决策甚至安全相关逻辑中。

因此，GNSS 的关键特征并不在于"是否可用"，而在于：系统是否对这类外部数据的可信性具备足够的工程约束。

2.4 Wi-Fi：局部场景下的高权限通信能力

Wi-Fi 通信在车辆中通常用于：

诊断与维护
特定功能配置
局部场景下的数据交互

与蜂窝通信相比，Wi-Fi 的使用范围更有限，但其工程特点恰恰在于：

通信距离近
接入后权限往往较高
使用场景高度集中

这使得 Wi-Fi 成为一种"不常用，但一旦使用就影响较大"的通信机制，在安全讨论中不应被简单忽略。

2.5 蓝牙：低门槛接入背后的能力扩展通道

蓝牙通常被认为是一种"低风险、短距离"的通信方式，但在智能网联汽车中，其工程角色远不止如此。

蓝牙通信常用于：

车机与移动终端交互
近距离控制与状态获取
功能触发与身份关联

其工程特征在于：

接入门槛低
配对成功后通信能力可能被持续保留
容易成为其他系统能力的触发入口

这使得蓝牙在对外通信体系中，往往承担着"入口级通信机制"的角色。

2.6 对外通信，本质上是多种通信机制的叠加系统

综合来看，智能网联汽车的对外通信，并不是单一能力，而是由多种通信机制共同构成的复杂系统：

V2X：实时协同、消息驱动
蜂窝通信：远程、公网、规模化
GNSS：外部数据输入、基础能力
Wi-Fi / 蓝牙：本地接入、高权限入口

这些通信机制在工程目标、使用场景和风险特征上差异巨大，也正因如此：后续所有关于对外通信安全的讨论，都必须回到"具体通信机制"本身。

这将成为理解后续风险分析、测试难点和评估方法的关键前提。

对外通信链路的风险

在单一通信场景下，安全问题往往相对清晰：通信对象明确、数据类型有限、工程假设相对稳定。

但在智能网联汽车中，对外通信并不是"选择其中一种"，而是 V2X、蜂窝通信、GNSS、Wi-Fi、蓝牙等多种机制同时存在、长期并行运行[3]。

从工程与安全视角看，风险并不是简单相加的，而是在机制叠加过程中被放大、被放宽、被转移。

3.1 不同通信机制的"安全假设"并不一致

每一种通信机制，在设计之初都隐含了一组前提假设：

V2X 假设：

消息高频但短生命周期，核心在于完整性与实时性

蜂窝通信假设：

基于公网环境，通过协议、加密与鉴权建立安全边界

GNSS 假设：

定位与时间数据在大多数情况下是可信输入

Wi-Fi / 蓝牙假设：

通信距离近、使用场景受限、触发条件明确

单独看这些假设，往往是合理的；但当它们在同一系统中同时成立时，就会出现一个工程现实问题：系统往往默认"所有假设同时成立"，却缺乏机制去验证这些假设是否在同一时刻依然成立。

这正是系统性风险的起点。

3.2 通信机制之间并非"相互隔离"，而是存在能力传导

不同通信机制通常并不是完全独立的模块，而是通过系统架构发生耦合，例如：

蓝牙或 Wi-Fi 用于本地接入或触发操作
蜂窝通信用于将结果同步到云端
GNSS 数据作为多种功能的基础输入
V2X 消息参与协同决策或状态判断

这意味着，一个通信机制中的输入或触发，很可能通过系统内部逻辑，间接影响另一种通信机制的行为[4]。

从安全视角看，风险往往并不来自"单一通信链路失效"，而来自：低门槛或低风险假设的通信机制，间接触发了高权限或高影响力的通信能力。

3.3 不同通信机制的生命周期差异，导致安全边界不一致

从工程生命周期看，不同通信机制的变化节奏存在明显差异：

蜂窝通信协议、云接口、服务策略更新频繁
第三方服务与平台能力持续演进
GNSS 与 V2X 相关能力更新节奏较慢
Wi-Fi / 蓝牙通常在早期设计阶段就已确定

当这些机制在同一车辆生命周期内长期共存时，很容易出现：

某一通信机制的安全策略已更新
但其他机制仍然基于旧的工程假设运行

这会导致系统整体安全边界在时间维度上逐渐失衡。

换句话说：不是系统"突然不安全"，而是安全假设在不知不觉中失效。

3.4 多通信机制叠加，使系统状态空间急剧扩大

从工程建模角度看，系统安全高度依赖于"状态可控"。

但当多种通信机制并行运行时，系统状态将同时受到以下因素影响：

网络状态变化（公网、局域网、短距通信）
外部输入变化（定位、协同消息）
平台与服务状态变化（策略、配置、版本）

在这种情况下，系统实际运行在一个高维状态空间中，而大多数测试与验证，只覆盖其中极少数"典型状态"。

这意味着：即便每一种通信机制在单独测试时表现正常，它们在某些状态组合下的行为，仍可能超出原始设计预期。

3.5 风险往往不是"新增"，而是被"放大和转移"

在多通信机制并存的系统中，安全问题的表现形式往往具有一个共同特征：

风险并非某一机制独有
而是在机制之间被放大、被转移、被组合利用

例如：

原本低影响的数据输入，被用于更高风险决策
原本局部通信能力，触发了远程或集中式操作
原本短生命周期的消息，被系统长期保存或复用

这些问题在单一机制下并不明显，但在叠加系统中却具备现实可行性。

对外通信安全问题的原因

图4 智能网联汽车的协同应用场景

在智能网联汽车中，对外通信安全问题并不一定来自"恶意设计"。

大量风险，实际上产生于功能完全正常的工程实现方式------当通信机制的设计假设、实现细节或演进路径缺乏约束时，系统就会逐步暴露出可被滥用的空间[7]。

4.1 V2X：消息机制可用，但"消息可用行为"边界不清

V2X 通信以消息为核心，其工程实现重点并不在传统意义上的接口调用，而在于消息的接收、解析与处理逻辑。在工程实践中，常见的风险来源包括：

（1）消息完整性与处理逻辑脱节

系统能够校验消息是否合法，但在工程实现中，消息一旦通过校验，其后续处理路径往往缺乏更细粒度的约束，不同类型消息的安全策略强度不一致。

（2）异常或非典型消息缺乏工程级约束

在高频通信环境下，系统往往更关注"正常消息是否能被及时处理"，而对异常频率、异常组合或非常规时序的消息缺乏足够的工程限制。

（3）消息被直接用于协同行为或状态判断

当 V2X 消息被用于影响车辆行为或系统状态时，其工程风险不在于"消息能否收到"，而在于系统是否假设消息始终可信、始终合理。

4.2 蜂窝通信（4G/5G）：协议存在，但工程实现假设过于理想

基于蜂窝网络的通信，是智能网联汽车对外通信中最成熟、也是最复杂的一部分。

在多数系统中，协议、加密与鉴权机制是默认配置，但工程风险往往隐藏在"默认合理"的实现假设中。常见问题包括：

（1）通信协议存在兼容或降级路径

为满足不同环境或历史系统兼容需求，工程实现中可能保留多种通信方式，而安全策略并不一定在所有路径中保持一致。

（2）鉴权凭据生命周期过长

通信凭据在工程上被设计为长期有效，且缺乏使用频率、作用范围或车辆状态绑定等约束，使得凭据一旦被滥用，其影响具有远程性和规模性。

（3）远程接口在工程上可被组合使用

单个接口在设计时看似合理，但在系统层面，多个接口或能力被组合后，可能突破原有业务或安全假设[6]。

4.3 GNSS：功能正常，但"数据可信性假设"缺乏工程验证

GNSS 在系统中通常被视为一种稳定可靠的数据输入，其风险并不体现在"定位是否可用"，而体现在系统如何使用这些数据。工程机制层面的常见问题包括：

（1）对定位数据缺乏合理性与一致性校验

系统往往直接使用 GNSS 数据，而缺乏对异常跳变、时间一致性或运动逻辑的工程级校验。

（2）GNSS 数据被用于高风险决策场景

当定位或时间数据被直接用于调度、协同或安全相关逻辑时，其可信性假设一旦失效，影响往往被放大。

（3）缺乏多源数据交叉验证机制

在工程实现中，系统可能依赖单一数据源，而未对外部输入建立冗余或校验路径。

4.4 Wi-Fi：局部通信能力，但工程权限往往过高

Wi-Fi 通信在车辆中通常用于诊断、维护或特定功能场景，其使用频率不高，但一旦建立连接，往往具备较高系统权限。常见工程风险包括：

（1）接入条件与使用场景脱节

Wi-Fi 接入在工程上可能仅验证连接条件，而未严格限制其使用时机与系统状态。

（2）调试或维护能力被长期保留

原本用于开发或运维的通信能力，在量产环境中仍然存在，成为潜在的高权限入口。

（3）连接后能力边界缺乏收敛机制

一旦建立通信，系统往往默认其行为合理，而缺乏进一步的权限收敛与行为限制。

4.5 蓝牙：配对成功，并不等于通信行为始终可控

蓝牙通信在车辆中被广泛用于近距离交互，其工程风险并不来自通信距离，而来自配对关系与系统能力之间的映射关系。工程层面常见问题包括：

（1）配对关系长期有效且缺乏清理机制

历史配对关系在工程上被长期保留，即使使用场景已发生变化，通信能力仍然存在。

（2）配对成功后能力被放大

一旦配对完成，蓝牙通道可能被用于触发更高权限的系统能力，而这一过程缺乏足够的工程约束。

（3）蓝牙成为其他通信能力的触发入口

蓝牙通信本身看似低风险，但其在系统中可能作为其他对外通信或控制能力的"入口"。

面向不同通信机制的对外通信安全测试重点

在智能网联汽车中，不同对外通信机制在协议特性、数据交互方式以及工程实现路径上存在显著差异，因此其安全测试重点也不尽相同。实际测试工作通常需要围绕各类通信方式的技术特征展开，分别验证其在工程实现层面的安全性与可控性。

在 V2X 通信场景下，安全测试的核心关注点通常集中在消息机制本身。测试需要验证协议栈及相关安全机制是否按设计生效，确保消息在传输与处理过程中具备完整性、时效性与可信来源校验能力。同时，还需要关注系统对不同类型消息的处理边界，例如在面对异常频率、非典型时序或组合消息时，是否仍能保持稳定且可预期的处理行为。由于 V2X 消息往往直接参与协同行为或状态判断，安全测试还需要评估系统在异常消息条件下是否具备合理的收敛与保护策略。

基于 4G/5G 的蜂窝通信是车辆与云平台及远程服务交互的主要通道，其安全测试通常围绕通信链路、身份鉴权与远程能力边界展开。一方面，需要验证通信过程中是否始终采用预期的安全协议与配置，避免出现明文传输或策略不一致的实现路径；另一方面，还需对凭据与会话管理进行检查，评估其生命周期、权限范围及一致性控制是否合理。此外，由于蜂窝通信承载了远程指令、策略下发与 OTA 等关键能力，安全测试还应关注这些远程能力在工程上是否具备明确的使用场景约束、审计记录与异常回退机制。

在 GNSS 相关测试中，关注点并不在于定位精度本身，而在于系统如何使用来自外部的定位与时间数据。安全测试通常需要验证系统是否对 GNSS 输入建立了基本的合理性与一致性校验机制，以及在定位或授时出现异常特征时是否能够触发相应的降级或保护策略。同时，还需要梳理 GNSS 数据在系统中的使用范围，评估其是否被直接用于关键决策或协同行为，从而确认外部输入在工程上是否始终处于可控的使用边界内。

Wi-Fi 通信在车辆中多用于本地接入、维护或诊断场景，其安全测试重点通常放在接入控制与权限边界上。测试需要验证 Wi-Fi 接入是否采用了合理的认证与加密配置，并与具体使用场景和车辆状态进行绑定，避免非预期条件下的接入行为。同时，还应评估连接建立后系统所暴露的服务和能力范围，确认是否存在权限过高或调试、维护能力在量产环境中长期保留的情况。此外，对连接生命周期和操作审计能力的验证，也有助于评估本地通信通道的整体安全成熟度。

蓝牙通信作为近距离交互的重要手段，其安全测试通常围绕配对关系管理与能力映射展开。测试需要关注配对流程和信任关系的建立与回收机制，确保历史配对关系在设备更换或使用场景变化后能够被有效清理。同时，还应评估配对成功后系统所授予的能力是否遵循最小权限原则，以及蓝牙通道是否可能在工程上触发更高权限的系统功能或其他对外通信能力。通过这些测试，可以验证蓝牙在作为本地入口时，其安全边界是否始终受到有效控制。

总结

在实际工程中，上述各类通信机制的安全测试如果分散开展，往往容易形成"点状结论"，难以支撑对整车对外通信安全性的整体判断。因此，行业中逐渐形成了一种更为可行的思路：以通信机制为主线，将 V2X、蜂窝通信、GNSS、Wi-Fi 与蓝牙等测试能力进行统一整合，在同一测试体系内完成协同验证与关联分析。

基于这一思路，上海控安推出了专为工业互联网与网联汽车场景设计的对外通信安全测试解决方案，并在此基础上构建了自动化智能模糊渗透测试工具 SmartRocket TestSec。该工具深度融合模糊测试技术与仿真分析能力，能够将不同通信方式的安全测试能力统一纳入同一技术框架之下，面向 V2X 消息通信、4G/5G 远程通信、GNSS 外部输入以及车载 Wi-Fi、蓝牙本地通信等典型场景，开展协议与配置检查、通信行为测试以及权限边界验证。

图5 SmartRocket TestSec智能网联汽车渗透测试用例

SmartRocket TestSec 既支持针对单一通信机制开展专项安全测试，也能够从系统层面验证多种通信机制并行运行时的整体安全边界。例如，在远程通信与本地无线通道共存的场景下，可用于评估本地接入是否可能触发远程能力；在 GNSS 与 V2X 协同使用的场景中，则可以结合仿真分析能力，对外部输入数据对协同行为和系统决策的影响范围进行验证。通过这种方式，测试结论不再停留在单点风险描述，而是能够反映整车对外通信能力在真实运行环境下的整体安全状态。

总体来看，面向网联汽车的对外通信安全测试，正在从"单一接口或单一协议的检测"逐步走向"多通信机制协同验证"的阶段。通过以上海控安 SmartRocket TestSec 为代表的统一测试体系，覆盖 V2X、蜂窝通信、GNSS、Wi-Fi 与蓝牙等关键通信方式，可以更系统地识别对外通信中的潜在风险，为智能网联汽车的安全设计、测试验证和持续演进提供工程化、可落地的技术支撑。

引用：

1\]https://www.catarc.tech/xwzxDetail/f88a19dd4cab449da83a692f97c8a272?utm_source=chatgpt.com \[2\]https://www.eet-china.com/mp/a245994.html?utm_source=chatgpt.com \[3\]《智能网联汽车安全白皮书》 \[4\]https://www.auto-testing.net/news/show-124912.html?utm_source=chatgpt.com \[5\]"Contents," in Journal of Communications and Information Networks, vol. 1, no. 2, pp. 1-1, Aug. 2016. \[6\]Dibaei, M., Zheng, X., Jiang, K., Maric, S., Abbas, R., Liu, S., ... \& Yu, S. (2019). An overview of attacks and defences on intelligent connected vehicles. \*arXiv preprint arXiv:1907.07455\*. \[7\]Wang, B., Han, Y., Wang, S., Tian, D., Cai, M., Liu, M., \& Wang, L. (2022). A review of intelligent connected vehicle cooperative driving development. \*Mathematics\*, \*10\*(19), 3635.