采用基于模型的方法实现车辆SOA威胁分析自动化

尽管采用面向服务架构（SOA）有助于实现自动驾驶、空中下载更新等功能，但同时也增加了车辆遭受攻击的风险，可能对道路使用者造成伤害。为解决这一问题，相关标准（ISO 21434 / 联合国欧洲经济委员会（UNECE）标准）要求制造商通过开展适当的威胁分析，提供安全论证及证据。由于威胁分析的关键步骤（如损害 / 威胁场景分析、攻击路径枚举）往往依赖人工完成，且缺乏严谨性，导致安全论证缺乏精确保障（例如，在系统更新情况下，与安全目标的可追溯性不足）。本文提出一种基于模型工程方法的自动化威胁分析技术，该技术能针对安全目标提供精确保障。为实现这一目标，本文构建了一个汽车 SOA 入侵者模型，将该模型与系统架构、安全分析确定的损失场景共同作为输入，用于计算资产、影响等级、损害 / 威胁场景及攻击路径。为验证所提方法的有效性，本文基于广泛使用的开源自动驾驶框架 —— 阿波罗（Apollo）框架，构建了其自动驾驶功能的忠实模型。研究表明，所提方法能够自动枚举阿波罗框架中的多条攻击路径，其中包括文献中尚未报道过的攻击路径。

为应对自动驾驶、空中下载更新等功能实现过程中的挑战，汽车行业正经历重大变革。如今的车辆不再采用基于特定领域硬件的分布式架构，而是采用软件密集型的面向服务架构（SOA），并配备功能强大的中央计算单元。开源的阿波罗（Apollo）框架便是这一变革的典型代表，该框架提供的自动驾驶功能已应用于自动驾驶出租车、自动驾驶公交车等实际自动驾驶应用的开发中。

这一变革也引发了人们对攻击者如何影响道路使用者安全的担忧。尽管十多年前人们就已意识到安全面临的威胁（但 ISO 21434 标准（ISO/SAE 21434，2020）和联合国欧洲经济委员会（UN，2021）标准仍推动行业改变其开发流程，以打造具备安全设计与防护设计特性的车辆。例如，ISO 21434 标准高度重视开发流程及威胁分析（如损害 / 威胁场景 / 攻击路径枚举），要求在车辆上路前完成这些工作并解决相关问题。最终，原始设备制造商（OEM）需提供充分的论证和证据（即安全档案），证明其车辆在安全方面同样具备可靠性。

如果原始设备制造商（OEM）在开发自动驾驶功能时，未事先开展分析、论证并提供支持车辆安全防护的证据，可能会付出高昂代价。若缺乏这些资料，一旦相关标准得到更严格的执行，这些车辆将难以获得认证机构的认可，也无法在多个国家投入使用。更棘手的是，已有多起攻击事件被报道，这些攻击可能对道路使用者造成严重危害，例如导致车辆碰撞。正如本文所指出的，若在系统架构设计阶段采用 “功能安全与网络安全设计” 方法，并借助自动化工具开展适当的威胁分析，许多此类攻击本可被提前识别。

开发具备 “功能安全与网络安全设计” 特性的车辆，关键挑战在于应对其中涉及的巨大复杂性。例如，若缺乏适当的防护措施，SOA 允许任何软件组件发布任何数据，包括可能被安全关键功能调用的数据。这一特性已成为权限滥用攻击（Hong 等人，2020）的根源之一：当安全关键功能错误地调用恶意组件（甚至是失效组件）发布的数据时，就可能引发危害情况。再如，恶意组件可能利用 SOA 通信漏洞实施中间人攻击。此外，摄像头、GPS 接收器等传感器也可能成为攻击者利用的攻击面，从而引发危害。

1.1 功能安全与网络安全设计方法及贡献

本文提出的功能安全与网络安全方法及三大核心贡献如图1所示。该方法基于汽车功能安全与网络安全协同工程领域文献中的以下核心理念构建：

图1：所提出的 “设计即安全可靠” 方法论、工具链及核心贡献（C1、C2、C3）示意图

软件密集型系统的分析技术：系统理论过程分析（STPA）（Leveson 和 Thomas，2018）已被 ISO 21448（预期功能安全，SOTIF）（SOTIF，2021）等标准推荐用于自动驾驶功能的安全分析，以确保自动驾驶等功能的安全性。这是因为 STPA 不假设线性因果关系，而是更侧重于故障 / 恶意组件之间的交互。

从功能安全到网络安全：博世（Bosch）工程师提出的方法将安全目标、危害等安全要素作为防护分析的输入。采用这一做法主要基于两点原因：1）安全分析通常先于防护分析进行；2）将安全分析结果作为防护分析的输入，通过建立适当的可追溯性，能够确保防护分析结果与安全分析结果的完整性。例如，可通过检查所有危害成因（在 STPA 术语中称为损失场景）是否都能追溯到相应的防护分析来实现这一目标。

基于模型的工具链：基于模型的工程方法以待设计系统的形式化抽象为基础，与传统的基于文档的方法相比，借助自动化分析、设计和验证工具，有助于降低当今软硬件架构的复杂性，同时提高开发速度和质量。

尽管上述方法已被提出，但本文首次将它们整合到一个针对 SOA 车辆架构的、全面的基于模型的方法中。如图 1 所示，该方法从（SOA）车辆模型入手，明确关键功能、逻辑组件和平台（又称物理）架构。这些模型元素是确保该方法合理性的基础，后续的功能安全与网络安全分析均需追溯到该模型。通过危害分析与风险评估（HARA）和 STPA 分析，确定关键安全功能、通道和物理元素，这些元素从防护角度被视为需要保护的资产。将 STPA 分析得到的损失场景（即可能导致危害的情况）转化为损害场景和威胁场景，明确攻击者如何引发安全危害。在此基础上，开展防护分析，例如利用逻辑架构和平台架构识别可能导致威胁场景的攻击路径。最后，探讨应对这些威胁的潜在防护措施。

该方法的核心优势体现在三个方面：第一，实现了安全分析、防护分析与车辆模型之间的全面可追溯性。这意味着分析结果能够反映到将在车辆上部署的实际实现中。第二，该方法能够确保防护分析涵盖所有危害的所有损失场景，例如所有损失场景都能追溯到损害 / 威胁场景。这意味着所有已识别的安全问题都需从防护角度加以考虑。第三，基于模型的方法支持采用自动化技术，例如基于入侵者模型自动枚举攻击路径。

本文的主要贡献如下：

基于阿波罗的车辆模型（C1）：通过研究阿波罗代码库中与自动驾驶功能相关的代码，设计了一个忠实反映阿波罗系统的车辆模型。该模型体现了 SOA 的发布 - 订阅模式，以及阿波罗各组件之间的信息（即主题）交互。据我们所知，这是首个基于阿波罗 v7.0.0 代码库构建的模型。

车辆 SOA 入侵者模型（C2）：通过研究车辆 SOA 防护领域的相关文献，构建了车辆 SOA 的形式化入侵者模型。该入侵者能够实施中间人（MITM）攻击，并通过公共接口渗透到系统内部实施欺骗攻击，例如对激光雷达（LiDAR）、摄像头等感知传感器进行攻击。

攻击路径自动化（C3）：开发了一个用于自动枚举车辆系统架构中攻击路径的工具（LAUFEN）。LAUFEN 将车辆模型、资产、损害 / 威胁场景以及入侵者模型的实现作为输入，输出所有可能的攻击路径。

本文在构建的阿波罗车辆模型上对所提方法和自动化工具进行了演示和验证。研究重点关注安全资产，因为安全是自动驾驶的核心关注点。所开发的工具共识别出 246 条攻击路径，其中包括文献中已报道的攻击路径。由于该工具能够追溯到安全分析过程，因此还识别出了更多需要通过防护措施加以缓解（或需提供相关防护依据）的攻击路径。事实上，基于生成的攻击路径，本文发现了一些尚未被文献报道的潜在攻击。

阿波罗（Apollo，2021）是一个开源自动驾驶框架，能够支持高度自动化的车辆功能（更准确地说，达到了美国汽车工程师学会（SAE）定义的 L4 级别），例如高速公路自动驾驶和交通拥堵辅助驾驶，在这些场景下车辆可在有限人工监控下行驶。阿波罗 v7.0.0 版本（Apollo，2021）包含超过 50 万行 C++ 代码。

阿波罗框架实现的核心部分是 Cyber RT 中间件。Cyber RT 提供发布 - 订阅模式，支持运行于其上的软件组件之间的通信。组件可通过带标签的通道（即主题）进行通信。组件可通过向指定主题写入消息来发布数据，也可通过指定主题名称来订阅感兴趣的任何主题。当发布者向某个主题写入数据时，所有订阅该主题的订阅者都会接收到这些数据。Cyber RT 允许多个组件向同一主题发布数据，也允许多个组件订阅同一主题。新主题的发布以及组件对主题的订阅通过一种名为服务发现的机制实现。

本节将介绍为演示本文方法而设计的阿波罗模型。该模型重点关注代码库中与自动驾驶功能相关的部分，即传感器（摄像头、激光雷达）、定位、感知、预测、规划、控制和人机交互界面（HMI）。

本文采用基于模型的系统工程工具 AutoFOCUS3对阿波罗系统架构进行建模。该模型包含 9 个功能、61 个逻辑组件、341 个端口，传输 73 种数据结构（含 361 个成员）、16 个执行单元、12 个传输单元和 6 个传感器。为描述发布 - 订阅通信，本文在 AutoFOCUS3 中扩展了一个实验性元模型，通过专用的主题端口数据类型来实现发布 - 订阅通信的描述。由于篇幅限制，本节仅介绍逻辑架构和平台架构的部分关键内容，因为本文呈现的防护分析结果主要聚焦于这两种架构。

2.1 逻辑架构

所设计的逻辑架构较为复杂，包含四个层级，且每个层级都有多个组件。图 2 展示了阿波罗模型中第二高层级的架构，该层级包含主要的自动驾驶组件。

图2：逻辑架构：主要自动驾驶组件

定位组件接收全球导航卫星系统（GNSS）的传感器数据，并计算车辆位置。车辆位置信息会被以下组件接收：感知组件接收来自摄像头、雷达和激光雷达的传感器数据以及车辆位置信息，进而识别障碍物（如道路上的其他车辆）和交通信号灯状态；预测组件接收来自感知组件的障碍物列表和车辆位置信息，尝试预测障碍物（可能是其他车辆或行人）的运动意图，例如车辆是否打算变道；相对地图组件整合障碍物列表，并将其与包含道路信息（如车道、交通信号灯位置）的地图数据相结合；规划组件接收来自定位、感知、预测和相对地图组件的所有数据，据此规划车辆安全且舒适的行驶轨迹；控制组件接收规划好的行驶轨迹，并生成控制指令（如转向、加速等），使车辆能够沿规划轨迹行驶。

确保模型与阿波罗代码的一致性是一项关键挑战。为实现这一目标，本文通过人工检查阿波罗代码提取模型元素。例如，为找出阿波罗中所有基于 Cyber RT 实现的组件，需检查代码中所有cyber::Component类的实现。下一步是确定主题以及哪些组件向这些主题发布数据、哪些组件订阅这些主题。阿波罗通过以下三种机制定义主题通信：有向无环图（DAG）配置文件、实现主题读取器和主题生成器的 C++ 代码，以及库代码。本文对这三种机制均进行了检查，以确定组件订阅和发布的主题。例如，图 3 展示了规划组件的 DAG 配置文件，该文件表明规划组件订阅了/apollo/prediction、/apollo/canbus/chassis和/apollo/localization/pose这三个主题。

图3：从DAG配置文件中建模规划的用户端口

2.2 平台架构

图 4 展示了本文设计的平台架构，该架构遵循现代智能汽车架构的发展趋势，即采用数量较少但性能强大的电子控制单元（ECU），并通过网络接口（如交换机）实现 ECU 之间的连接。

图4：基于现代智能汽车架构的平台架构（黄色阴影表示系统边界）

平台架构中的主要ECU包括：

1. MDC（移动数据中心）：该硬件负责处理与自动驾驶功能相关的组件，例如从摄像头输入中识别目标、预测环境中目标的运动轨迹、规划行驶路径等。MDC 进一步细分为多个子系统，每个子系统配备不同类型的处理单元，且这些处理单元具有不同的安全防护等级，例如符合汽车安全完整性等级 D（ASIL-D）的微控制器（MCU）。

2. CDC（智能座舱）：该硬件负责所有与座舱相关的功能，例如驾驶员监控系统、娱乐功能等。

3. VDC（车辆控制器）：该硬件负责基本的车辆控制功能，例如电动助力转向、电池管理、防抱死制动等功能。

4. VIU 1-4（车辆集成单元）：这些硬件是功能强大的网关，通过网络接口连接 MDC、CDC 和 VDC，并通过 CAN 总线连接特定领域的硬件。

模型中的黄色区域代表系统边界（又称项目边界）。本文将逻辑架构中实现的所有组件均视为系统的一部分。例如，传感器（如激光雷达、GPS 接收器）本身并非系统的一部分，它们是连接到系统的第三方设备，用于从环境中获取输入信息。本文将这些传感器视为系统外部的公共接口，外部用户可能会访问这些接口。

本文的核心目标是识别与安全相关的资产、损害场景和威胁场景，因为安全是自动驾驶的首要关注点。本节将阐述防护分析师如何利用关键安全要素来识别重要的防护要素，从而建立防护关注点与安全关注点之间的可追溯性。通过这种追溯关系，可以证明防护分析相对于安全分析的（相对）完整性，即确保识别出所有可能导致安全损失场景的威胁。尽管已有文献主张在功能安全与网络安全之间建立类似的可追溯性，但这些文献未采用 ISO 21434 标准中提及的损失场景和相关要素，因此本文仅以阿波罗系统架构为例，对该方法进行说明。

3.1 功能安全分析

本文对阿波罗系统架构开展了功能安全分析。根据 ISO 26262-3 标准（ISO26262，2018），采用危害分析与风险评估（HARA）方法识别危害。此外，运用系统理论过程分析（STPA）确定这些危害可能发生的方式。

本文重点关注 HARA 分析得出的危害和 STPA 分析得出的损失场景。危害是指由项目（即阿波罗系统架构）的失效行为可能导致损失（如人员伤亡）的潜在根源。损失场景则描述了可能导致危害发生的因果因素。

本文共识别出 4 种危害和 21 个损失场景。为演示 1.1 节所述的基于模型的威胁分析方法，本节将以表 1 中描述的危害（HZ1）和损失场景（LS1）为例进行说明。HZ1 是与自动驾驶功能相关的高风险等级（ASIL D）危害。LS1 是可能导致 HZ1 发生的原因之一，且可追溯到模型中的两个组件（规划组件和控制组件）以及规划组件生成的轨迹所对应的主题。LS1 指出，如果计算出的轨迹存在错误（例如，本应推荐小加速度，却错误地推荐大加速度），则可能引发 HZ1，即车辆可能与障碍物发生碰撞。

表 1：功能安全分析结果示例

3.2 基于安全分析的资产与损害 / 威胁场景

根据 ISO 21434 标准（ISO/SAE 21434，2020），资产是指其网络安全属性若被破坏，可能导致项目受损的对象（如软件组件、硬件单元）。损害场景是指由于资产网络安全属性被破坏而产生的不利后果。威胁场景是指可能对资产实施的、可能导致损害场景发生的潜在行为（或简称为攻击）。安全分析得出的危害和损失场景可直接用于识别此类与安全损害相关的防护要素。

损害场景可追溯到危害。与 HZ1 对应的损害场景明确指出，从防护角度出发，也应避免车辆与其他物体之间出现非预期的距离。从损失场景中可追溯到三类主要资产：

· 安全功能：与安全相关的功能（通常以软件片段的形式实现）需要受到保护。对于 LS1 而言，规划和控制功能就是此类资产。

· 主题 / 消息：损失场景中提及的与安全相关的信号 / 消息需要受到保护。对于 LS1 而言，传输轨迹信息的主题属于此类资产。

· 硬件 / 物理设备：部署安全功能的硬件需要受到保护。与 LS1 相关的功能部署在 MDC 内部的 MCU 硬件单元上。

此外，损失场景的故障模式指明了这些资产应具备的网络安全属性（CIA 三元组属性，即机密性、完整性、可用性）。其中，“错误” 和 “丢失” 这两种失效模式分别表明需要确保相应资产的完整性和可用性。需要注意的是，无法从安全分析中提取机密性属性，因为机密性缺失不会导致与安全相关的损害。

基于损失场景及其衍生的资产，可借助 STRIDE 方法等工具构建威胁场景。例如，安全功能和物理资产的完整性可能会遭受篡改攻击，而主题 / 消息的完整性则可能会遭受欺骗攻击和权限提升攻击。

这些要素被用于枚举需要关注的攻击路径，即那些可能导致威胁场景发生的路径。攻击路径的枚举取决于所采用的技术。例如，若软件可通过空中下载（OTA）机制进行更新，那么在枚举攻击路径时，就需考虑攻击者如何利用这些机制通过恶意更新篡改软件。对于本文所研究的阿波罗系统架构，需重点考虑 SOA 机制的使用（如服务发现协议、发布 - 订阅通信模式、传感器）以及蓝牙、WiFi 等其他公共接口。这些内容将在下文详细阐述。

本文通过图5中的规则构建了 SOA 入侵者模型的形式化定义。该入侵者模型基于第 6 节中描述的针对集中式架构车辆 SOA 的主要攻击方式。从直观角度来看，若未部署适当的防护措施，SOA 存在两个主要的攻击面可能被攻击者利用。

图5:SOA的入侵者模型

· 外部攻击者：可利用传感器、通信接口等公共接口渗透到系统内部，攻击车辆资产（如安全功能）。例如，攻击者可通过欺骗 GPS 坐标，破坏定位组件发布的位置信息的完整性。

· 内部攻击者：可利用底层 SOA 协议中的漏洞实施中间人（MITM）攻击，从而破坏主题的完整性。例如，攻击者可在定位组件与感知组件之间实施中间人攻击，破坏位置信息的完整性。

图 5 展示了反映这类攻击的入侵者模型规则。这些推理规则推导出下文所述的三种判定结果。其中，Γ 包含从车辆模型中提取的系统规范，这些规范通过表 2 中描述的谓词符号形式化为原子公式。Γ ` wrt(X,Y) and Γ ` rd(X,Y)分别表示模型元素的端口 X 可向 Y 写入数据和从 Y 读取数据。

规则 write1 规定：若组件的输出端口 co 分配给 ECU 的输出端口 eo（由谓词(c, co),alloc(co, eo)指定），且存在从 eo 到网络元素输入端口 ni 的通道（由谓词ch(eo,ni)指定），则 ECU 的输出端口 eo 可向网络元素的输入端口 ni 写入数据。规则 write4 与 write1 类似，但适用于公共元素。规则 write2 规定：ECU 的输入端口可向其自身的输出端口写入数据 —— 本文假设 ECU 内部存在传输通道ch(ei, eo)，例如 ECU 内部组件之间的消息交互。规则 write3 与 write2 类似，但适用于网络接口。规则 read2 规定了 ECU 从网络接口读取数据的条件（与 write1 类似）。规则 read1 规定：订阅端口可从发布端口读取数据。

Γ ` i reach(X) 表示入侵者可访问模型元素的端口 X。规则 basic out 规定：架构中公共元素的任何端口都可被（外部）入侵者访问。规则 reach wrt 规定：若端口 p1 可向端口 p2 写入数据，且（外部）入侵者可访问端口 p1，则其也可访问端口 p2。相应地，规则 reach rd 规定：若端口 p2 可从端口 p1 读取数据，且（外部）入侵者可访问端口 p1，则其也可访问端口 p2。规则 basic ins 规定：架构中的任何发布端口都可被（内部）入侵者访问。规则 reach ins rd 规定：若订阅端口 ci 可从已被访问的发布端口 co 读取数据，则（内部）入侵者可访问订阅端口 ci。

Γ ` i attack(X)表示主题 X 可能遭受攻击。规则 at out 规定：若某主题通过已被访问的 ECU 输入端口的信息流（if(ecu,p,tp)）发布，则该主题可能遭受攻击。规则 at ins 规定：若发布端口与订阅端口之间的主题未受保护，且（内部）入侵者可访问这些端口，则该主题可能遭受攻击。

4.1 外部入侵者（示例）

以图 6 所示的平台架构为例。与硬件单元相连的黑色圆形和白色圆形分别代表输出端口和输入端口。本文假设传感器是一个公共接口，根据规则 basic out，外部入侵者可访问传感器的输出端口 o1。输出端口 o1 向网络接口 Network1 的输入端口 i1 写入数据，根据规则 reach wrt，入侵者可访问端口 i1 和 o2。假设组件 CP1 的订阅端口（浅蓝色方形）分配给 ECU1 的输入端口 i2，且 i2 可从 o2 读取数据，根据规则 reach rd，入侵者可访问端口 i2 和 o3。而端口 i3 和 o4 则无法被入侵者访问。由于 o3 可向 i4 写入数据，入侵者可访问 i4，但无法访问 i5 和 o5。最终，入侵者可通过传感器实施欺骗攻击，破坏 CP1 或 CP2 发布的主题的完整性，因为存在来自 i2 的信息流（依据规则 at out）。

图6：外来入侵者的示意图

4.2 内部入侵者（示例）

以图 7 所示的逻辑架构为例。与组件相连的深蓝色方形和浅蓝色方形分别代表发布端口和订阅端口。根据规则 basic ins，内部入侵者可访问所有发布端口 o1...o6。根据规则 reach ins rd，由于订阅端口 i1...i7 可从发布端口读取数据（例如，i7 通过端口 o5 从定位组件读取数据），因此入侵者可访问这些订阅端口。而订阅端口 i8 无法被访问，因为信息娱乐系统并非发布者。假设端口 o4 和 o5 发布的主题受到保护，且入侵者的攻击目标是规划组件通过端口 o2 发布的主题。在此情况下，入侵者可通过以下方式实施中间人攻击：在路由组件与规划组件之间，甚至在感知组件与预测组件之间实施攻击（因为感知组件发布的主题可能会影响规划组件发布的主题）。由于定位组件与规划组件之间、感知组件与预测组件之间以及预测组件与规划组件之间的主题均受到保护（依据规则 at ins），入侵者无法在这些组件之间实施攻击，也无法从信息娱乐系统发起攻击。

图7：内部入侵者示意图

LAUFEN（面向服务架构的车辆威胁分析自动化工具，vehicLe threAt analysis aUtomation For sErvice-orieNted architectures）是一款 SOA 工具，能够实现威胁评估与缓解分析（TARA）中多项活动的自动化计算。基于本文提出的 “功能安全与网络安全设计” 方法，LAUFEN 可计算资产、损害场景、影响等级、威胁场景和攻击路径。本节重点关注可能导致车辆 SOA 遭受威胁场景的攻击路径的自动化计算，即破坏资产网络安全属性的路径（第 3 节）。为此，LAUFEN 在逻辑编程工具 DLV中实现了上述入侵者模型。逻辑编程方法不仅具有声明性和足够的表达能力，可用于实现车辆 SOA 入侵者模型，而且在路径可达性等路径推理问题上具有成熟的应用。LAUFEN 采用表 2 中描述的谓词将系统规范编码为事实，并结合第 4 节中描述的入侵者模型，随后利用 DLV 求解器枚举攻击路径。本文在构建的阿波罗系统架构模型上对 LAUFEN 进行了验证。

表2：用于定义入侵者能力的谓词描述

由于阿波罗模型复杂度较高，若基于可达性进行朴素的攻击路径计算（尤其针对外部入侵者），其可扩展性较差。为解决这一问题，本文将计算过程分为两个步骤：第一步为 “入侵者可达性计算”，根据读写规则和可达性规则，计算入侵者可访问的所有模型元素。由于此步骤不计算具体路径，DLV 引擎可在毫秒级时间内计算出可访问元素。第二步为 “路径计算”，将第一步得到的可访问元素作为输入，利用攻击规则进行计算。本文采用目标导向的搜索方式，仅枚举针对资产的攻击路径（即 “以资产为中心” 的方法），而非枚举所有路径，这意味着 DLV 无需计算全部路径。

实验在配置为 1.90GHz Intel Core i7-8665U 处理器、16GB 内存、运行 Ubuntu 18.04 LTS 操作系统（内核版本 5.4.0-113-generic）和 DLV 2.1.1 工具的设备上进行。表 3 展示了 LAUFEN 识别出的攻击路径数量及执行时间。枚举攻击路径的执行时间较短，外部入侵者和内部入侵者的攻击路径枚举时间分别为 1.11 秒和 0.06 秒。由于系统复杂度较高（如架构中存在大量公共元素和信息流），识别出的攻击路径数量较多。为确保全面覆盖入侵者可能利用的攻击步骤，本文未排除任何攻击路径。第 5.1 节将详细阐述可缓解部分已识别攻击路径的潜在防护措施。

表 3：识别出的攻击路径数量，以及 LAUFEN 计算这些攻击路径所花费的执行时间

本文针对可能攻击安全关键主题的攻击路径展开分析，并将部分攻击路径按外部攻击者和内部攻击者实施的攻击类型整理于表 4 中。

表 4：从选定攻击路径推导得出的潜在攻击。“来源（From）” 和 “目标（To）” 分别表示攻击起始和结束的模型元素。“受影响主题（Affected Topic）” 表示攻击者的实际攻击目标。表格上半部分和下半部分分别描述外部入侵者和内部入侵者实施的选定攻击（包括文献中提及的攻击）。“攻击路径数量（#Attack Paths）” 表示 “来源（From）” 到 “目标（To）” 的计算得出的攻击路径数量 

计算得到的攻击路径包括：外部攻击者利用蓝牙、激光雷达、摄像头、GPS 和雷达攻击安全关键主题，引发损失场景并对道路使用者造成伤害；内部攻击者利用 SOA 通信漏洞攻击相关主题。

通过模型及其与阿波罗代码的关联，本文对部分攻击展开了深入分析，以明确这些攻击如何引发安全问题。

5.1 V2X 交通信号灯篡改攻击

LAUFEN 识别出了外部和内部攻击者针对车对车（V2V）代理的攻击路径。图 9 展示了外部攻击的过程：V2V 代理组件发布从道路基础设施获取的交通信号灯状态数据，交通灯组件订阅该数据，同时也订阅摄像头获取的数据以识别并发布交通信号灯状态。由于阿波罗模型与源代码之间存在可追溯性，可轻松找到与漏洞相关的类。研究发现，TrafficLightsPerceptionComponent函数会优先采用 V2V 代理接收的数据，而非摄像头接收的数据。图 8 展示了TrafficLightsPerceptionComponent函数的代码片段。因此，攻击者可通过外部（欺骗攻击）或内部（中间人攻击）方式操纵交通信号灯状态。如图 9 所示，攻击者通过远程信息处理终端（T-Box）实施欺骗攻击，操纵交通信号灯状态，可能导致车辆闯红灯，对乘客和行人造成严重伤害。

图8:Apollo的代码片段：用V2X数据覆盖交通灯状态

图9:T-Box操纵v2v代理接收到的交通灯状态的欺骗攻击示意图

表5：攻击路径分析（外部入侵者）

5.2 路线 / 地图注入攻击

从安全角度来看，部分已识别攻击路径的危害性可能并不显著。例如，LAUFEN 识别出了一条针对路由响应主题、涉及 “路由 - 规划” 组件的攻击路径：内部攻击者可在路由组件与规划组件之间实施中间人攻击，为目标车辆提供恶意路线。从安全角度而言，路由组件向规划组件输出错误信息这一损失场景的可控性较强，因此可能仅导致低风险等级的危害（如 ASIL A 或 ASIL B）。然而，从防护角度来看，这种攻击可能引发诸多严重后果，包括劫持乘客。此外，规划组件还可能受到相对地图组件发布的道路地图的影响，因为规划组件在计算车辆行驶轨迹时会参考该地图数据。

5.3 潜在防护措施

本文通过攻击路径分析，确定了实施防护措施的潜在位置。分析重点针对外部入侵者的攻击路径，因为研究发现许多此类攻击路径具有相同的前缀，这为防护措施的部署提供了线索。

表 5 展示了攻击路径分析的主要结果，包括外部入侵者可访问的公共元素、LAUFEN 计算出的来自该公共元素的攻击路径数量，以及所有来自同一公共元素的攻击路径的共同前缀。

“前缀” 列中最后一个架构元素可能是部署防护措施的合适位置，从而可应对相应的攻击路径。从 “前缀” 列还可发现，网关 VIU 3 是来自右前摄像头和 GPS 的攻击路径的共同节点，而 CAN 总线与 MDC 之间的连接则是来自前雷达和后雷达的攻击路径的共同节点。这表明可在 VIU 3 前方以及 CAN 总线与 MDC 之间部署防护措施，以应对这些攻击路径（共 62 条）。

例如，有文献建议采用防火墙保护车辆架构免受此类攻击。可在 “前缀” 列最后一个架构元素的前方部署防火墙，过滤网络流量，防止恶意入侵。对于网络接口（如 T-Box 和蓝牙），还可实现双向认证机制（如 mTLS），确保仅接收经过认证的消息。

此外，还可部署安全架构模式（如异构双工模式）作为第二层防护。以外部攻击者实施的 V2X 交通信号灯篡改攻击为例，该攻击通过 T-Box 破坏交通灯主题的完整性。一种可行的防护措施是在交通灯组件中添加一个校验器，同时接收来自 V2V 代理和摄像头的输入（即异构输入）—— 若两种输入不一致，交通灯组件可向驾驶员发出警报，或使系统切换至安全状态。

内部攻击者实施的中间人攻击（如路线注入攻击）会利用 SOA 通信漏洞破坏主题的完整性。数字签名是确保服务器（如发布者）与客户端（如订阅者）之间真实性和完整性的常用防护措施。为应对中间人攻击，可在阿波罗系统中实现数字签名机制：每个发布者对其发布的消息进行签名，每个订阅者在接收消息时验证签名。Fast-DDS 提供了一个加密插件，可用于消息认证码的计算和验证。在阿波罗系统中采用数字证书应对中间人攻击的思路，源于相关文献中提出的防护措施 —— 该文献建议采用数字签名缓解阿波罗系统中发布 - 订阅权限滥用问题。

理论上，实施数字签名可应对所有 94 条内部入侵者攻击路径。然而，使用数字签名会导致软件组件在执行时产生性能损耗，需从防护、安全和成本等多个角度分析这种性能损耗。但由于所有已识别的攻击路径均涉及安全关键问题，因此必须实施防护措施以确保车辆安全。

6.1 功能安全与网络安全设计

功能安全与网络安全协同设计领域已有丰富的研究成果，本文的方法正是基于这些成果构建的。本节将详细介绍与本文方法联系最为紧密的关键方法，并进行对比分析。

系统理论过程分析的防护扩展（STPA-SEC）是对 STPA 方法的扩展，可同时计算安全要素和防护要素（即漏洞）。“STPA 与六步模型” 方法（Sabaliauskaite 等人）将安全要素与防护要素整合到自动驾驶车辆的分析中，该方法结合 STPA 和六步模型确定功能安全与网络安全要素，尤其通过危害分析与风险评估（HARA）识别可能导致危害事件的故障，并据此推导威胁。“安全感知危害分析与风险评估（SAHARA）”方法对 ISO 26262 标准中的 HARA 分析进行了扩展，将可能影响安全的防护威胁纳入分析范围。SAHARA 方法借助 STRIDE 方法推导防护威胁。

STRIDE 方法是微软提出的一种知名威胁建模方法，代表六种威胁类型，即欺骗（Spoofing）、篡改（Tampering）、否认（Repudiation）、信息泄露（Information disclosure）、拒绝服务（Denial of service）和权限提升（Elevation of privilege）。这些威胁类型可从系统应满足的安全属性推导得出，例如，篡改威胁可从完整性属性推导得出。

博世工程师提出的方法建议从 HARA 分析得到的安全要素中推导威胁评估与缓解分析（TARA）的防护要素，具体包括：（1）从安全目标推导资产；（2）从安全目标的破坏推导威胁；（3）从危害推导损害场景；（4）从 ASIL 等级的严重程度 / 可控性推导影响等级。

本文图 1 所示的 “功能安全与网络安全设计” 方法受到上述方法的启发。与博世方法一致，本文方法要求先开展安全分析，再基于安全分析结果推导防护要素。同时，本文方法认同博世方法中 “从危害推导损害场景” 和 “从 ASIL 等级的严重程度 / 可控性推导影响等级” 的思路。本文将功能、主题和硬件单元均视为需从防护角度保护的资产，但认为无法按照博世方法的建议从安全目标中推导出这些资产。因此，与 STPA-SEC 和 “STPA 与六步模型” 方法类似，本文的 “功能安全与网络安全设计” 方法除了利用 HARA 分析结果外，还结合了 STPA 分析结果，即从 STPA 分析得到的损失场景中推导资产。与 SAHARA 方法一致，且符合 ISO 21434 标准的建议，本文基于 STRIDE 方法构建威胁模型：（a）从损失场景的故障模式中推导系统（如某一功能）应满足的安全属性；（b）从期望的安全属性中推导威胁类型。本文重点关注可能破坏安全关键主题完整性的欺骗和篡改威胁。

6.2 针对车辆 SOA 的攻击

以下研究成果为本文构建车辆 SOA 入侵者模型提供了启发。一篇最新的综述文献总结了该领域的研究现状，分析了 53 篇相关文献，并基于传感器攻击等安全关键方面对文献进行了分类。在 “与魔鬼同行（Drift with the devil）” 一文中，研究人员指出，入侵者可通过欺骗 GPS 无线电信号操纵位置信息，即便定位组件采用多传感器融合技术，这种攻击依然有效。激光雷达传感器信号可能被欺骗，导致道路上的障碍物被 “移除”。由于摄像头传输的数据流未加密，攻击者可通过欺骗摄像头信号操纵视频帧（Jha 等人，2020）。攻击者还可向雷达传感器注入信号，使其 “感知” 到不存在的障碍物。此外，攻击者可利用蓝牙协议栈的漏洞实施攻击，导致车辆刹车锁死。

研究人员调查了车辆 SOA（尤其是采用 SOME/IP 协议的 SOA）的服务发现机制中可能存在的安全问题，攻击者可利用这些漏洞在发布者与订阅者之间实施中间人攻击。在 AVGuardian 相关研究中，研究人员调查了阿波罗系统中可能存在的发布 - 订阅权限滥用问题。AVGuardian 工具在阿波罗 5.0 代码库中检测到多个权限滥用实例，例如：（a）GNSS 驱动程序可能利用 tf 主题中的发布权限滥用字段，重新定位道路上感知到的障碍物的估计位置；（b）补偿器可能利用 PointCloud 主题中的发布权限滥用字段，从道路感知结果中 “移除” 障碍物。

本文提出的入侵者模型在架构层面明确了攻击者实施上述攻击所需的核心能力，包括：（a）外部攻击者通过传感器等外部接口实施欺骗攻击的能力；（b）内部攻击者在组件之间实施中间人攻击的能力，这两类攻击均可能破坏安全关键主题的完整性。其中，权限滥用攻击可视为中间人攻击的一种特殊情况。

6.3 威胁分析自动化

目前，能够为威胁和攻击路径计算提供计算机辅助支持的工具较少。一项关于威胁建模的综述表明，大多数威胁建模工作仍需人工完成。本节简要介绍汽车领域中部分提供计算机辅助支持的安全 / 威胁分析工具。

AVGuardian是一款静态分析工具，用于检测汽车 SOA 源代码中的权限滥用实例。该工具检查每个模块的源代码，自动检测模块定义的主题字段中存在的发布者和订阅者权限滥用情况，但需要系统的行为规范才能检测权限滥用实例。而 LAUFEN 工具的设计目标是在系统架构设计阶段识别威胁和攻击路径，无需依赖系统的行为规范，且能够自动计算可能导致 AVGuardian 检测到的攻击的攻击路径。当然，若能获取行为规范，可得到关于资产和潜在攻击更准确的信息（例如，主题的哪个字段与权限滥用实例相关）。

ProVerif和 Tamarin Prover是知名的自动化推理工具，基于 Dolev-Yao 入侵者模型验证系统（尤其是安全协议）的安全属性。这些推理工具需要系统行为的形式化规范才能验证其属性。未来一个有前景的研究方向是在阿波罗模型中加入行为规范，并利用这类推理工具验证 SOME/IP 或 DDS 等 SOA 协议的安全属性。

已有研究提出了基于网络物理系统模型的形式化威胁分析方法，例如针对工业 4.0 应用的分析方法。与安全协议相关研究类似，这些方法也需要系统行为的形式化规范。正如所指出的，由于存在状态空间问题，这些方法在可扩展性方面存在局限 —— 分析时间随组件数量的增加呈指数级增长。因此，这类方法单独使用时，难以适用于包含 60 多个组件的阿波罗系统。未来一个有趣的研究方向是，将本文提出的攻击路径识别方法与基于行为形式化规范的推理方法相结合，从而兼具基于行为规范方法的分析精度和本文方法的可扩展性。

另有研究提出了一种针对汽车安全关键功能的攻击传播方法。商业工具 ThreatGet支持按照 ISO 21434 标准识别攻击路径。微软 SDL 威胁建模工具是另一款知名的商业威胁计算工具，基于 STRIDE 方法计算威胁，并通过数据流图展示每条计算出的威胁对应的攻击路径。据我们所知，这些工具均不支持针对车辆 SOA 的入侵者模型能力。因此，本文通过构建基于车辆 SOA 真实形式化入侵者模型的工具，推动了该领域的技术发展。

本文提出了一种基于模型工程方法的自动化威胁分析技术。为此，本文完成了以下工作：（a）构建了忠实反映阿波罗框架自动驾驶功能的车辆模型；（b）基于文献综述构建了车辆 SOA 的形式化入侵者模型；（c）开发了 LAUFEN 工具 —— 一款用于执行威胁分析多项活动（包括攻击路径计算）的 SOA 工具。