汽车面向服务架构（SOA）网络安全对策

摘要

从客户和制造商的角度来看，在产品生命周期内添加新软件功能等新需求，要求未来汽车采用变革性的架构设计。为提高更新和升级能力，已沿用多年的面向信号通信范式将越来越多地被面向服务的方法所取代。本文概述了基于面向服务架构（SOA）范式的汽车架构当前所使用的协议和通信模式，并将其与面向信号的方法进行对比。同时，阐述并探讨了面向服务架构在网络安全方面面临的挑战与机遇。为此，本文解释了不同的网络安全对策，并阐述了汽车领域在防火墙、入侵检测系统（IDS）以及身份与访问管理（IAM）方面的研究现状。最后，基于一个典型的混合架构（兼具面向信号和面向服务特性）展开讨论，分析现有安全措施的适应性及其特定安全功能。

1、引言

现代汽车正从硬件定义平台向软件定义平台转变，软件已成为新创新的主要驱动力。例如，通过自动驾驶功能提高道路安全性、通过与互联网整合并为用户提供应用商店从而更好地将车辆融入日常生活、通过电气化和共享出行服务实现更环保的出行等功能，均离不开软件的支持。因此，电子控制单元（ECU）已从过去简单的微控制器，发展成为能够执行自动驾驶人工智能等高级任务的高度复杂的计算机器。由电子控制单元、其网络以及运行于其上的软件构成的电气和电子架构（E/E 架构），是汽车行业实现新创新的关键因素之一。软件和电气电子市场的增长预计将大幅超过整个汽车市场的增长，这一预期也印证了上述观点。

为支持联网、电气化、共享出行或自动驾驶等新技术，汽车电气电子架构设计领域正经历一场真正的范式变革。当前车辆架构最多可包含 150 个电子控制单元，并实现约 300 万个功能，这些电子控制单元通过控制器局域网（CAN）等总线系统相互连接，并按不同领域（如动力传动系统、底盘）进行组织。以往以电子控制单元为核心、在设计阶段静态定义发送方 - 接收方依赖关系的开发方法，在扩展和修改方面存在很大局限性。

由于客户需求和市场变化具有动态性，为提高未来车辆系统的更新和升级能力，未来的架构将更加集中化。在这一变革过程中，面向服务架构正日益得到应用，该架构允许在运行时建立动态通信关系，而无需在电子控制单元上映射静态依赖关系。面向服务架构被视为提供更高灵活性、更好地对底层硬件和传感器进行抽象以及整合外部服务和按需功能的关键要素之一。结合标准化操作系统的兴起，面向服务架构能够实现整个车辆生态系统内信息的动态、透明且简化的访问。因此，当应用程序需要传感器信息时，该信息既可以由车辆的内部控制单元提供，也可以由原始设备制造商（OEM）后端通过空中下载（OTA）方式提供环境数据。此外，对于已投入使用的车辆，其功能的变更或新功能的集成也变得更加容易，因为其他信息或功能可作为服务进行订阅。

此外，新的网络技术和协议正被用于整合这一新的通信范式。数十年来一直用于车辆内部通信的可靠 CAN 协议，正日益被汽车以太网技术所取代，以满足在数据速率、互操作性和网络安全方面不断变化的需求。在 ISO/OSI 模型的第 5 - 7 层（较高层），使用的是如基于 IP 的可扩展面向服务中间件（SOME/IP）或数据分发服务（DDS）等协议，这些协议在汽车开放系统架构（AUTOSAR）自适应标准中进行了规定。尽管其中部分技术是汽车行业专用的，但结合基于标准化操作系统的通用计算平台，电气电子架构正朝着普通信息技术（IT）网络架构的方向发展，这已成为一种普遍趋势。

随着车辆联网程度的提高以及车辆服务数量的不断增加，网络安全需求也大幅提升。安全性将日益成为车辆的一项重要质量指标。近年来，已有多篇文献证明，基于面向信号通信（主要基于 CAN 协议）的早期车辆架构存在遭受攻击的风险。

因此，汽车安全已成为学术机构、行业和标准化委员会关注的重点领域。一方面，学术界提出了多种应对车辆攻击的网络安全对策；另一方面，诸如 SAE J3061、ISO/SAE 21434 或 AUTOSAR 安全车载通信（SecOC）等各类标准和指南也已制定完成。

1.1 问题

车辆架构中从面向信号通信向面向服务通信的转变，引发了根本性的范式变革。由于通信设计不再完全静态确定，以往的安全措施无法直接应用于面向服务架构。通信的动态性、不断提高的数据速率、大量新协议的出现、第三方服务的集成以及标准化软件组件的应用，都给汽车安全措施带来了新的挑战和要求，而这些在以往面向信号的电气电子架构安全理念中并未涉及。

1.2 解决方案

由于通信特性发生了变化，需要对面向信号领域中现有的安全解决方案能否迁移到面向服务范式中进行研究。鉴于面向信号的方法在一定程度上基于传统信息技术安全措施，因此还应研究适用于汽车面向服务架构的现有信息技术安全解决方案。信息技术网络与电气电子架构的融合，进一步推动了这一研究方向的发展。

1.3 贡献

本文全面概述了汽车面向服务架构和电气电子架构领域当前的标准、协议及发展动态，重点阐述了面向服务架构在安全方面新出现的挑战。此外，本文既解释了各类安全措施（防火墙、访问控制、入侵检测系统）的一般原理，也介绍了专门针对车辆领域已发表的相关研究方法。在讨论部分，本文分析了汽车领域和信息技术领域现有方法在面向服务架构中的适用性，并通过一个整合了面向信号和面向服务特性的典型混合电气电子架构案例，详细阐述了不同安全措施的部署方式。最后，本文确定了未来研究所需的方向，为提升面向服务架构的安全性奠定基础。

本文结构如下：第 2 章阐述电气电子架构中面向信号和面向服务通信的原理；第 3 章介绍现有的汽车协议、面向服务架构安全相关的漏洞与攻击，并指出其与传统信息技术的差异；第 4 章介绍各类网络安全对策，并对已发表的汽车网络研究方法进行分类；第 5 章研究并讨论现有安全方法在汽车面向服务架构中的适用性；最后，第 6 章总结全文。

2、面向服务与混合电气电子架构

电气电子架构中面向服务特性的不断整合，给车辆网络安全带来了新的挑战。为评估现有网络安全对策的可迁移性，有必要明确面向信号和面向服务这两种通信范式之间的差异，这些差异体现在总体架构、所使用的运行时栈以及通信协议等方面。

2.1 电气电子架构

电子控制单元组成的分布式系统通过不同的总线系统进行通信，相互连接的总线系统、电子控制单元以及运行于其上的软件共同构成了电气电子架构。最主要的总线系统技术包括控制器局域网（CAN）、本地互联网络（LIN）、FlexRay、面向媒体的系统传输（MOST）以及汽车以太网。当前车辆中，上述每种技术都可能会有多个实例在使用。例如，2019 款奥迪 A8 的电气电子架构包含 7 条 CAN 总线、1 条 MOST 总线和 1 条 FlexRay 总线 [23]；为满足诊断需求，还额外配备了 1 条 CAN 总线和 1 个以太网端口；此外，该架构中还包含多个 LIN 系统和专用系统。LIN 系统尤其适用于作为低成本方案连接座椅控制等简单设备。然而，本文重点关注未来架构的发展，这类架构的发展主要受自动驾驶、联网等汽车行业创新驱动力的推动。目前，CAN 总线是主流系统，但未来总线系统的种类将有所减少，以太网将在车辆中占据主导地位；不过，CAN 总线仍有可能作为一种低成本方案，用于低数据速率和高可靠性需求的场景。众多研究人员均认为，未来架构将具有混合性和层次性，既包含以太网，也包含传统总线系统。通常而言，当前 CAN 总线用于面向信号范式，而以太网则主要用于面向服务通信。

2.1.1 控制器局域网（CAN）

CAN 总线是一种串行多主总线，支持多种数据速率，高速 CAN 总线的最大数据速率为 1Mbps，而具备灵活数据速率的 CAN 总线（CAN - FD），其数据速率根据物理收发器的不同可高达约 8Mbps。现代车载网络由多条 CAN 总线组成，必要时，这些 CAN 总线通过网关和骨干网络实现互联。每条消息都包含一个唯一的标识符（ID），该标识符用于定义消息的优先级。消息的数据载荷会被分解为多个任意长度的信号，但具有特定标识符的消息中信号的顺序在车辆开发过程中就已确定。

在某一特定 CAN 总线上，具有特定 ID 的消息最多只能由一个电子控制单元发送。车辆网络中的所有电子控制单元都可以订阅任意消息 ID，但如果发送方电子控制单元和接收方电子控制单元分别连接在不同的总线上，则需要通过网关对消息进行路由。CAN 消息的发送方式有两种：一种是周期性发送，这种方式主要用于实现多个电子控制单元之间的控制和反馈回路；另一种是基于事件发送，通常用于与用户交互（例如，激活转向灯、车窗升降器）。此外，总线上的其他参与者也可以请求发送特定 ID 的消息。

2.1.2 汽车以太网

自动驾驶和联网功能增加了对带宽的需求。因此，除了用于电子控制单元的诊断和程序刷写外，以太网在车辆内部通信中的应用也日益广泛。在现代以太网网络中，每个参与者仅与其连接的交换机进行通信，交换机在所有连接的设备之间建立无冲突的点对点连接。车辆需要专用的物理层以满足抗干扰等环境要求。依据 100BASE - T1 标准（前身为 BroadRReach 标准），数据速率可达 100Mbps；而依据 1000BASE - T1 标准，数据速率甚至可达到 1Gbps。最近有文献报道，数据速率可进一步提升至 1Gbps 以上。为填补 CAN - FD 与 100BASE - T1 标准之间的数据速率差距，同时又能保持 CAN 总线的低成本优势，相关机构制定了 10BASE - T1S 物理层标准。未来，对于低成本和硬实时性要求的场景，10BASE - T1S 可能成为 CAN 总线的一种可行替代方案。作为 IEEE 802.1Q 标准的扩展，时间敏感网络（TSN）已被引入汽车领域，以实现更高的实时性。此外，IEEE 802.1Q 标准还规定了所谓的标记虚拟局域网（VLAN），该技术可实现子网的逻辑隔离。

在汽车专用物理层之上，使用的是 TCP/IP（互联网协议（IP）、传输控制协议（TCP）、用户数据报协议（UDP））等信息技术标准协议栈。此外，还引入了诊断 IP 协议（DoIP）、SOME/IP 等汽车专用协议。

2.1.3 运行时平台

电子控制单元的软件架构正越来越多地基于不同的操作系统和标准化运行时栈。例如，操作系统和中间件开发工作量的年均增长率，预计将与自动驾驶功能开发工作量的增长率相当。其中最重要的两个平台是由 AUTOSAR 基金会制定的 AUTOSAR 经典平台和 AUTOSAR 自适应平台。经典平台适用于对实时性要求极高的场景，而自适应平台则利用更强的计算能力，旨在将面向服务架构范式引入汽车行业。本文所参考的当前标准为 19 - 11 版本。2013 年至 2016 年间，采用 AUTOSAR 的电子控制单元数量从约 5000 万个增至近 3 亿个。除 AUTOSAR 外，信息娱乐领域还存在其他不同平台，例如 GENIVI、QNX。本文重点关注基于 AUTOSAR 的电子控制单元，因为这些电子控制单元承担着大部分安全关键功能。对转向控制等安全关键功能的成功攻击，可能会对车辆乘员及其周围环境造成严重危害，因此这些平台的安全性至关重要。

表 1 总结了 AUTOSAR 经典平台与自适应平台的主要差异。从对比结果可以看出，AUTOSAR 自适应平台的动态性远高于经典平台。在自适应平台中，应用程序可实现动态调度和安装；此外，自适应平台依赖于嵌入式实时系统的标准 POSIX 接口子集，因此所有应用程序和软件组件与机器操作系统之间的接口都实现了标准化。另外，自适应平台和经典平台中应用程序通过网络进行通信的范式也有所不同。尽管经典平台规定可使用 SOME/IP 协议，但它并不支持面向服务架构范式，而只是实现了从面向信号的 CAN 通信到以太网通信的转换，并定义了信号到特定服务的静态映射。

表 1、AUTOSAR 经典平台与自适应平台对比

2.1.4 未来架构示例

图1 展示了未来车辆的一个典型电气电子架构示例。自动驾驶和联网趋势推动了架构的集中化发展，并催生了功能更强大的计算平台。例如，引入了运行 AUTOSAR 自适应平台的中央计算集群，该自适应平台可能由多个处理器和电子控制单元组成，这些处理器和电子控制单元通过交换式以太网连接。在本示例中，功能领域（底盘、高级驾驶辅助系统（ADAS）、信息娱乐、车身）在物理上的隔离仍然存在，但对于分层以太网网络而言，也可以通过为每个领域分配不同的虚拟局域网标签，实现逻辑上的隔离。底盘和高级驾驶辅助系统相关功能通过分层以太网拓扑结构连接到中央单元，由于这些功能对安全性和时序性有严格要求，因此运行于 AUTOSAR 经典平台之上。对于对可靠性要求高且循环周期短的控制功能，可通过 CAN 总线将电子控制单元连接到交换式以太网网络。在本示例中，除中央集群外，输入 / 输出（I/O）集群和联网控制网关也属于 AUTOSAR 自适应平台。联网控制模块负责处理智能充电、诊断以及无线联网等外部通信功能。在本示例中（见图1），信息娱乐和车身领域的 AUTOSAR 经典平台通过 CAN 总线或 LIN 总线连接到输入 / 输出集群，这是因为信息娱乐和车身功能大多由用户输入 / 输出驱动，对数据速率要求较低，因此相比以太网，更倾向于选择成本更低的 CAN 总线或 LIN 总线。

图1、基于AUTOSAR经典和自适应的示例性混合E/E架构。ECU颜色表示它们所连接的相应总线系统

综上所述，图1 展示了一种混合架构，该架构中，基于 AUTOSAR 经典平台的电子控制单元主要通过 CAN 总线以面向信号的范式进行通信，而自适应平台则利用以太网构建面向服务架构。此外，该架构既包含基于 POSIX 的高性能计算集群，也包含低性能的微控制器。

2.2 相关协议与中间件

在汽车面向服务架构中，有多种相关的协议和中间件方案，其中最重要的是 SOME/IP 和 DDS，因为它们在 AUTOSAR 中已实现标准化，从而成为行业内的首选解决方案。此外，本节还将介绍学术界提出的一种在 CAN 总线上实现面向服务架构的方案。

2.2.1 通信模式

在面向信号和面向服务通信中，涉及不同的通信模式，这些模式的典型控制流程如图2 所示。图2a 至图2c 展示了面向服务架构的典型模式，发布 - 订阅模式、远程过程调用（RPC）模式以及 “即发即弃” 模式均由客户端驱动，因此，仅在客户端需要时才会向其传输数据。相比之下，图2d 展示的面向信号通信中，无论是否存在订阅者，数据都会以广播形式发布，但订阅者对发布者的订阅必须在静态情况下预先确定。

因此，面向服务架构与面向信号通信模式的主要区别在于通信路径的配置时机（即客户端能够与服务器交换数据的时间）。通常，通信路径可在设计时、车辆启动时或运行时进行配置。在面向信号通信中，配置完全在设计时静态完成，会明确规定哪个电子控制单元有权使用静态消息 ID 发送数据载荷，同时，在设计时也会为消息 ID 分配相应的订阅者。相比之下，面向服务架构范式允许在启动时或运行时进行配置。如果在设计时就确定了对某项服务的订阅，那么在启动时，只需订阅提供该服务的已知服务器，即可实例化通信路径；若要在运行时进行配置，则需要一种服务发现和订阅的方法。图2e 和图2f 展示了两种服务发现方式：一种是基于注册中心的服务发现，即由专门的注册中心服务器处理服务的提供和查找；另一种是无注册中心的服务发现，即通过发现协议使服务器和客户端能够相互发现。

图2、汽车架构中的通信模式概述

2.2.2 基于 IP 的可扩展面向服务中间件（SOME/IP）

SOME/IP 的规范不仅是一种通信协议，更是一种中间件，并且已在 AUTOSAR 中实现标准化。该中间件在应用程序与网络之间建立了一定程度的抽象层，例如，应用程序无需知道所需功能由哪个电子控制单元提供。如果所需功能集成在同一电子控制单元上，那么软件组件之间会建立本地连接；如果功能位于另一个电子控制单元上，中间件则会在两个应用程序之间建立相应的网络连接。

通信原理：SOME/IP 规范定义了客户端与服务器之间通信的三种基本类型，SOME/IP 中的服务由事件、字段和方法组成。

· 事件：SOME/IP 中的基于事件通信，为客户端提供了一种从服务提供者订阅所需信息的方式。服务提供者能够按照指定的时间间隔，或者在信息值发生变化时，将信息传输给客户端。此外，还可以创建多个事件组，每个事件组包含供订阅客户端使用的不同字段。

· 字段：服务允许定义字段，客户端可通过 “获取”（get）和 “设置”（set）方法对这些字段进行读取或修改。此外，字段还采用了与事件相同的通知机制，但字段和事件的用途有所不同：字段适用于具有历史记录的状态类属性，而事件则用于仅在短时间内有效的信息。

· 方法：此外，SOME/IP 还支持远程过程调用（RPC），客户端可通过该方式调用服务器提供的方法。远程过程调用有两种不同的形式：一种形式中，服务提供者会返回一个值；另一种是 “即发即弃” 形式，客户端调用方法后不会收到返回值，因此这种形式主要适用于控制指令。

字段和事件实现了发布 - 订阅模式；标准方法以及字段的 “获取 / 设置” 方法实现了请求 - 响应模式；最后，通过 SOME/IP 方法的 “即发即弃” 选项，可实现 “即发即弃” 模式。

此外，SOME/IP 服务发现（SOME/IP - SD）协议支持事件和字段的发布与订阅。客户端若要使用特定服务，要么预先知晓该服务，要么能够发现该服务。SOME/IP 服务发现协议提供了两种在系统启动过程中查找或宣告服务的机制：服务提供者可通过 “提供服务”（offerService）机制在网络中以广播形式宣告其提供的服务；客户端则可通过 “查找服务”（findService）机制查找尚未宣告的特定服务。SOME/IP - SD 采用基于注册中心的模式。

传输方式：SOME/IP 使用 TCP/IP 或 UDP/IP 协议栈进行数据传输。为实现 AUTOSAR 自适应平台与经典平台之间的跨平台通信（Inter - Platform Communication），SOME/IP 协议已针对这两个平台进行了规范。这使得同时连接到 CAN 等传统总线系统的经典平台电子控制单元能够充当网关，将信号转换为服务，以便为自适应平台电子控制单元提供服务。如果经典平台控制单元不支持 SOME/IP 通信，则只能在自适应平台电子控制单元上实现信号到服务的转换。

2.2.3 数据分发服务（DDS）

DDS 是另一种近年来在汽车行业得到应用的中间件，它由对象管理组织（OMG）制定标准，并在多个行业中得到应用。DDS 是一种以数据为中心的中间件，基于发布 - 订阅模式控制不同节点之间的数据流转。自 2018 年 11 月发布的 AUTOSAR 自适应平台 18 - 10 版本起，DDS 标准已在汽车行业中实现应用。不过，AUTOSAR 仅包含 DDS 标准的部分内容。

通信原理：DDS 的以数据为中心的发布 - 订阅（DCPS）接口对基于 DDS 的通信中的数据流进行管理。生成的信息以样本形式发布到不同的主题（topic）中，每个主题都有唯一的名称进行标识。DDS 通信包含一个或多个域（domain），每个域中包含多个主题，不同域之间相互隔离，因此域之间无法进行数据交换。DDS 的一个重要特性是，订阅者可以对主题发布的数据进行内容过滤和数据速率过滤，这样，中间件仅会将订阅者感兴趣的数据发布到主题并进行传输。例如，仅传输值大于 300 且消息速率为每秒 5 条的样本。主题构成了定义数据模型的逻辑全局数据空间，每个主题都与一种数据类型相关联，因此中间件能够正确处理数据并进行类型检查。

对象管理组织还通过 DDS 制定了远程过程调用标准，以支持请求 - 应答模式。该标准在 DDS 基础上构建了高层抽象，复用了 DDS 的核心部分，将请求方定义为客户端，将应答方定义为服务。在这种模式下，每个请求 - 应答连接都包含两个主题，即请求主题和应答主题。AUTOSAR 自适应平台也采用了这一理念，以通过 DDS 实现远程过程调用模式。

传输方式：在底层数据传输模型方面，DDS 采用实时发布 - 订阅协议 DDS 互操作有线协议（DDSI - RTPS）。DDSI - RTPS 规定，所有 DDS 实现都至少需支持通过 UDP/IP 进行通信，但大多数供应商还提供了 TCP 实现方案，同时也支持共享内存访问。只要支持特定单播地址和端口的概念，并且能够识别不完整或错误的消息，就可以使用其他传输协议。在 AUTOSAR 中，DDS 规范允许同时使用 UDP 和 TCP 协议。

2.2.4 嵌入式面向服务通信（eSOC）

Wagner 等人提出的嵌入式面向服务通信（eSOC）协议，基于 CAN 协议实现了面向服务通信。该协议定义了一个 64 位的服务描述符和一个更短的 29 位标识符，以实现面向服务架构。这种架构既保留了 CAN 总线的优先级原则，又能够与 SOME/IP 实现简单集成。由于短标识符可适配标准 CAN 标识符的长度，因此在运行过程中，eSOC 协议不会产生额外开销。在 eSOC 通信启动过程中，会通过注册服务器使用 64 位服务描述符进行服务初始化。该注册服务器并非通信的代理，仅负责为服务提供者分配短标识符。eSOC 协议支持发布 - 订阅和请求 - 响应这两种基本通信原理：采用发布 - 订阅原理时，服务器会基于事件或按特定频率向客户端发送信息；采用请求 - 响应原理时，可远程调用方法，并通过一次性传输实现数据交换。此外，该协议还提供了 “查找 / 提供” 模式，使请求方电子控制单元和提供方电子控制单元之间能够实现服务发现。

2.3 对比

表 2 总结了相关协议之间的主要差异，同时也包含了传统的面向信号方案作为对比参考。CAN 标准同样规定了请求帧，但在传统的面向信号方案中，该请求帧通常不用于实现请求 - 响应模式。若使用 SOME/IP 和 DDS 的发现协议，这些协议之间的主要差异体现在服务发现机制上。DDS 的动态性最强，即订阅者只需订阅特定主题，无需与服务器建立静态链接，在服务发现过程中会调用服务 ID，且服务器在初始阶段是未知的。相比之下，SOME/IP 基于服务器，客户端必须订阅特定服务器的事件。此外，SOME/IP 要求在设计时对服务到 UDP/TCP 特定端口的映射以及指定的服务 ID 进行系统级定义。不过，若不使用发现协议，AUTOSAR 也允许在设计时或启动时对 DDS 和 SOME/IP 的通信路径进行配置。

表 2、汽车面向服务架构相关协议与中间件对比

3、面向服务架构网络安全

随着面向服务架构在车载网络中的应用，现有安全措施面临新的挑战。这一方面源于新协议的多样性，另一方面由于通信路径不再是静态定义的。以下各节将详细阐述这些问题。

3.1 协议

以往的 CAN 等通信协议仅基于 OSI 模型的第 1 层和第 2 层（诊断协议除外）。表 3 根据 ISO/OSI 模型对常见的车载网络协议进行了分类。通过在第 1 层和第 2 层使用汽车以太网，在第 3 层和第 4 层采用了 TCP/IP 等传统信息技术领域的常规协议。这种发展趋势除了带来互操作性提升、带宽增加等优势外，也给网络安全带来了新的风险。过去几年中，信息技术领域已开发出大量黑客工具，这些工具使得相关攻击技术的实施更加容易。以太网所使用的协议种类不断增加，这不仅增加了网络和数据包处理的复杂性，也使得协议设计和实现过程中出现漏洞的风险更高，未来可能会发现协议栈中的新漏洞。此外，为保护信息资产的机密性，这些协议具备在 OSI 模型不同层对报头和数据载荷进行加密的功能。因此，在整合安全措施时，必须考虑到某些信息可能无法在整个网络路径中的每个网络节点上获取。

表3、ISO/OSI模型中的通用汽车协议。（诊断专用协议以斜体显示）

表 2 概述了面向服务架构协议和面向信号通信中已包含的安全措施。为实现面向信号通信中消息的认证和新鲜性，AUTOSAR 经典平台标准引入了 SecOC。通过在消息的数据载荷后附加消息认证码和新鲜值，可防范重放攻击、伪造攻击等多种攻击。生成消息认证码需要使用对称密钥，但 SecOC 是一种适用于低成本嵌入式设备的轻量级协议，无法对 CAN 总线上的数据载荷进行加密。由于 SOME/IP 和 DDS 已纳入 AUTOSAR，它们可以依赖 AUTOSAR 中规定的传输层安全协议。AUTOSAR 自适应平台规定了以下安全通信概念：

· 基于 UDP 的安全通信：DTLS 协议

· 基于 TCP 的安全通信：TLS 协议

· 基于 IP 的安全通信：IPSec 协议

然而，SOME/IP 本身并未提供额外的安全措施。研究人员 Iorio 等人提出了一种解决方案，他们为基于以太网的 SOME/IP 通信设计了一个安全框架。相比之下，DDS 包含额外的安全标准，通过 DDS 的额外安全措施，可实现访问控制、认证、加密以及数据标记（如 “机密” 标记）等功能。其中，访问控制机制允许开发人员为 DDS 域和主题分别授予读写权限。

3.2 网络路径

与面向信号通信不同，面向服务架构的网络路径仅在系统运行时或启动时才确定。这导致从开发阶段确定的通信矩阵中提取周期时间、路由表等静态特征的可行性大大降低。因此，必须研究这种特性对入侵检测系统、防火墙等安全措施设计的影响（详见第 4 章）。这意味着，车辆安全防护还需涵盖原始设备制造商后端、基础设施等相关系统。此外，还需考虑到，空中下载服务等外部服务的使用扩大了车辆这一系统边界，因此车辆安全防护也应包括原始设备制造商后端或基础设施等系统。

3.3 漏洞

目前，面向服务架构技术在车辆架构中的整合仍处于初期阶段（例如，大众汽车的 MEB 平台），因此在本文撰写时，尚未出现针对这类架构的已知攻击案例。不过，已经可以对未来的协议和可能的架构设计进行相应的安全分析。Kreissl发表的一篇关于 SOME/IP 的详细文章，对 18 种已识别的威胁进行了威胁分析、风险评估，并提出了相应的应对措施建议。此外，研究表明，SOME/IP 传输协议分段扩展协议（SOME/IP - TP，基于 UDP 的 SOME/IP 传输协议分段）容易受到选择性拒绝服务攻击。一项早期研究对诊断协议 DoIP 的漏洞进行了分析，发现该协议存在多种漏洞，例如易遭受伪造攻击、拒绝服务攻击，以及可能通过协议中的原始设备制造商专用字段被指纹识别等。

如第 3.1 节所述，采用标准协议和操作系统也会引入常见漏洞。例如，IP 分片可能导致的缓冲区溢出漏洞，这种漏洞在 AUTOSAR 实现中也可能存在；另一个例子是，如果地址解析协议（ARP）表不是静态定义的，那么就可能发生 ARP 缓存中毒攻击。

除了上述威胁分析结果外，还需注意的是，随着面向服务架构的应用，AUTOSAR 自适应平台也被引入汽车领域作为运行时平台。由于采用了标准化的 POSIX 内核和通用操作系统，因此所有运行特定 AUTOSAR 自适应平台实现的车辆，都会面临该内核和操作系统所存在的漏洞风险。因此，运行时平台的任何潜在漏洞，对整个行业造成的影响都将大于原始设备制造商专用运行时平台的漏洞。

3.4 汽车攻击

为保障未来车辆架构的安全，有必要对已知攻击及其所利用的漏洞进行研究。研究人员 Sommer 等人发布了一个汽车攻击分类体系，并建立了一个包含 162 起已发布攻击案例的数据库。该分类体系包含 23 个不同类别和多个抽象层次，例如攻击的简要描述、被破坏的安全属性、对所利用漏洞的解释等。由于车辆攻击通常包含多个攻击步骤，该数据库的扩展版本包含了 413 个攻击子步骤的详细信息。基于这些信息，可以进行详细的攻击分析。除学术机构外，行业内也有一些商业机构提供汽车安全事件知识库，这些知识库中的数据不仅关注车辆本身遭受的攻击，还包括后端系统或车辆应用程序中已知的漏洞。

此外，联合国欧洲经济委员会（UNECE）自动和联网车辆工作组（GRVA）制定的法规预计将于 2021 年生效，这将是首个针对车辆网络安全的法规。该法规将对相关成员国的所有原始设备制造商具有约束力，适用于新车辆的国际整车型式批准（IWVTA）。该法规还包含一份高级威胁和漏洞清单，并将这些威胁和漏洞与基于车辆系统的实际攻击方法进行了映射。

目前，采用成熟的面向服务架构或混合架构的车辆在道路上并不常见，因此尚未出现专门针对面向服务架构的公开攻击案例。然而，鉴于面向服务架构技术存在已知漏洞（见第 3.3 节），且早期车辆架构已发生过成功的攻击事件，未来面向服务架构很可能成为攻击目标并被利用。尤其是随着面向服务架构技术应用的不断普及，利用其漏洞进行攻击只是时间问题。

3.5 与网络技术安全的对比

尽管车载网络在物理层（即以太网）方面呈现出向通用信息技术网络发展的趋势，但在汽车安全措施设计中，仍需考虑两者之间存在的重大差异。这些特定要求并非面向服务架构所特有，而是汽车安全领域普遍存在的。然而，面向服务架构在网络方面所获得的动态性和灵活性，是以牺牲网络流量的静态预定义为代价的。在安全方面，静态行为便于实现简单的基于规则的控制，这曾是车载网络相较于信息技术网络的优势之一。

一般而言，传统信息技术网络安全无需考虑安全关键系统，而汽车安全若出现问题，在最坏情况下可能导致物理损害。例如，控制转向或动力传动系统功能可能会直接产生物理影响，因此必须对这些系统采取极高的安全防护措施。与之密切相关的是，安全措施需满足确定性和实时性要求。例如，若防火墙因误报而错误地拦截制动指令，或因分析速度过慢而导致指令延迟，那么这类防火墙就不适合在车辆中使用。

信息技术安全与车辆安全的另一个区别在于用户交互方式。在信息技术领域，每个用户在其个人设备上都可能会接触到安全措施，而车辆安全措施必须在后台完全自动运行，在驾驶过程中无法依赖用户做出反应，这与信息技术领域的情况不同。最后，汽车专用协议和技术（如 CAN、DoIP、SOME/IP）以及系统平台（如 AUTOSAR 经典平台和自适应平台）需要专门的解决方案。对于采用通用信息技术的领域（如信息娱乐系统），通用信息技术安全措施可能已足够，但随着电气电子架构日益集中化，安全关键系统或汽车专用系统与通用信息技术组件之间往往难以实现明确分离。

4、网络安全对策

保护信息技术网络和汽车架构通常应遵循纵深防御原则。该原则基于整合多个防护层，以最大程度降低攻击成功的风险，因此攻击者必须突破多个防护机制才能完全侵入系统。本文重点关注防火墙、入侵检测系统以及身份与访问管理这三类网络安全对策，并分析它们在面向服务架构中的适用性。

4.1 防火墙

防火墙属于访问控制类安全措施，在信息技术领域，防火墙作为核心组件，以访问限制的形式实现预先定义的安全策略。根据 RFC 4949的定义，防火墙是一种网关，允许两个不同网络（如互联网和公司内部网络）之间的数据传输，以保护资源免受来自其他网络的威胁。在过去几十年中，已形成了多种类型的防火墙系统，这些系统可分为不同类别（包过滤型、代理型和应用层型），具体如表 4 所示。这些过滤类型可应用于不同架构，且通常会组合使用。

表4、已建立防火墙类型概述

经典的包过滤防火墙基于 OSI 模型的第 3 层和第 4 层（网络层和传输层），能够基于这两层的协议信息构建过滤表，以执行预先定义的访问控制策略。静态包过滤防火墙的扩展形式是动态包过滤防火墙，这类防火墙能够存储已分析的数据包信息，并在后续的过滤决策中加以考虑。由于访问决策依赖于过往行为，这类过滤器也被称为状态检测过滤器。

代理防火墙是包过滤防火墙的进一步发展，同样工作在 ISO/OSI 模型的传输层。防火墙在两个网络之间充当代理，仅向客户端提供有限的可访问服务。这样，防火墙可以为每个客户端定义可访问的服务数量。与包过滤防火墙相比，代理防火墙的规则中可包含特定的上下文信息，还可以限制并发连接数量和吞吐量，以防范拒绝服务（DoS）攻击。

应用层过滤器（应用层防火墙）工作在 ISO/OSI 模型的最高层（应用层）。这类过滤器通过获取所使用应用程序的精确信息，扩展了代理防火墙的过滤能力。因此，由于防火墙为每个应用程序都提供了专用代理，应用层过滤器能够对特定于应用程序的用户数据进行深度包检测（DPI）。此外，还可以在用户（客户端）与代理之间建立认证机制，以增加伪造攻击的难度。根据实现方式的不同，这类防火墙还可能具备一定的入侵检测系统功能。

4.1.1 汽车防火墙

近年来，传统信息技术领域的防火墙技术在汽车领域也受到了关注。表 5 对以下所评述的几种汽车防火墙方案进行了分类。2014 年，Seifert 和 Obermaisser提出了一种适用于时间触发、事件触发以及流通信的网关防火墙。作者采用分层时间自动机来描述不同的通信行为，例如，为 CAN 网络中事件触发通信或 FlexRay 网络的动态部分定义了带有最小和最大阈值的帧间到达时间，以检测通信行为的偏差。他们还指出，所提出的方案专门针对静态定义的通信场景。

Pesé 等人提出了另一种防火墙方案，该方案同时考虑了软件和硬件方面的因素以及汽车领域的特定要求。为检测攻击，他们采用了三种不同类型的过滤器：在现场可编程门阵列（FPGA）上实现了经典的包过滤功能，而速率限制和状态检测包过滤则通过软件实现。他们的评估包括对端到端延迟、抖动、吞吐量、内存占用和 CPU 负载的测试。此外，作者认为该方案有望扩展到应用层，以实现对 DoIP 或 SOME/IP 协议的过滤。

表 5、所综述的汽车防火墙分类

Holle 和 Shukla提出了一种用于汽车以太网交换机的网关防火墙设计，该防火墙包含包过滤和应用层过滤功能，但作者并未详细说明这些过滤技术的具体细节。此外，他们概述了未来以太网架构的发展趋势，并阐述了整合防火墙的必要性。

Luo 和 Hou 采用攻击树对潜在攻击进行了风险分析。为此，他们分析了不同的攻击向量（如传感器、电子控制单元、接口），并基于已识别的攻击路径计算了暴露概率。在此基础上，他们提出了一种包含状态检测包过滤和入侵检测系统功能的网关防火墙安全方案，该方案采用信息熵技术。他们还指出，传统的嵌入式实时操作系统不支持任何形式的访问控制，因此他们在所使用的 FreeRTOS 系统中集成了自主访问控制（DAC）功能。

4.2 入侵检测系统

与防火墙或加密方法等主动防护措施不同，入侵检测系统属于被动防护措施，因为入侵检测系统仅在攻击发生时才能检测到可能的攻击行为，而主动防护措施则旨在预防性地减小系统潜在的攻击面。为检测攻击，入侵检测系统会分析网络中的数据流、评估系统日志文件或监测用户行为。根据部署位置的不同，入侵检测系统主要分为基于主机的入侵检测系统（HIDS）和基于网络的入侵检测系统（NIDS）。基于主机的入侵检测系统仅用于工作站或服务器，以检测该系统边界内的异常情况，例如用户试图修改系统关键文件或使系统处于危险状态的行为。

此外，基于网络的入侵检测系统通过复制所有数据包来分析网络内的数据流，检查数据包是否存在协议异常或恶意用户数据。这两类系统的检测技术均可分为两种类型：基于特征的检测技术基于从已知攻击中提取的特征，并定期更新这些特征库，但这种方法的局限性在于只能检测到与已知攻击高度相似的攻击行为，而无法检测新型攻击；与之相反，基于异常的检测方法通过对比从正常行为中提取的预定义特征来检测异常情况，通常会采用统计技术、协议特定技术、基于规则的技术和启发式技术等。

4.2.1 汽车入侵检测系统

除传统信息技术领域外，汽车领域对入侵检测系统的研究也在不断增加，旨在尽早检测攻击，并为防火墙等主动防护措施提供支持。由于汽车架构中采用 SOME/IP 等协议的动态通信部分不断增加，基于静态过滤表的防火墙已无法确保足够的安全性。此外，前文提到的联合国欧洲经济委员会 WP.29 法规特别要求在车辆中集成车载入侵检测系统。表 6 概述了以下将介绍的汽车领域入侵检测系统方案。

表 6、所综述的汽车入侵检测系统（IDS）分类

Müter 等人较早提出了八种不同的异常检测传感器（如消息的格式、来源、合理性等），用于检测 CAN 总线上的入侵行为。他们重点对比了这些传感器在六个不同标准下的适用性，例如，传感器是否仅能基于车辆规格开发，或者检测是否需要考虑来自不同总线系统的消息。近年来，研究人员开发了多种可用于检测异常的特征。Al - Jarrah 等人于 2019 年发表了一篇关于车载入侵检测系统方案的综合综述。根据他们的详细分析，这些研究成果可分为三大类（基于流的、基于数据载荷的和混合式的）。为便于比较，他们为每个大类定义了七个特征（技术、特征、数据集、攻击类型、性能指标和基准模型）。作者还详细分析了用于入侵检测的特征。

与传统信息技术系统不同，车辆是由传感器、处理逻辑和执行器组成的综合体，并且具备与外部系统（如原始设备制造商后端）的接口，因此车辆可被定义为网络物理系统（CPS）。与信息技术系统相比，车辆入侵检测除了可利用网络特征外，还可利用物理特征。网络特征包括协议和通信属性（如周期时间、消息长度）；相反，物理特征（如速度、位置、信号变化过程）可用于确定车辆当前的状态。根据对42 篇入侵检测系统相关文献的综述，81% 的文献采用了网络特征，5% 采用了物理特征，10% 则结合使用了两种特征。此外，还有一些基于物理特征的方案，这些方案利用发送方 / 接收方的物理特性（如传输比特的电压变化过程、特性阻抗）和传输信道的物理特性来进行检测 。

此外，Grimm 等人通过定义三个维度（监测视角、操作领域、响应动作），对汽车领域的安全监测进行了分类。每个维度包含不同的类别，例如外部通信或子网根源等。然后，为每个类别分配相应的汽车网络代表（如中央网关、骨干网络、以太网网络交换电子控制单元）。他们还指出，当前入侵检测系统的研究主要集中在面向信号的通信领域，而针对以太网和面向服务架构的入侵检测研究则相对较少。

4.3 身份与访问管理（IAM）

访问控制通常可定义为自动防止主体对资源的未授权访问。此外，还可以制定特定规则（策略）来控制和实现这一目标。因此，访问控制能够确保资源的使用符合规则要求。在信息技术发展的数十年间，已开发或扩展了多种用于授权的访问控制模型。这些模型用于确定系统中的哪个主体（如用户或服务）有权访问特定资源 / 对象（如文件、服务）。访问权限可分为不同的授权级别（读、写、执行），这些级别通过为每个主体或资源制定的访问策略来定义。以下将按时间顺序介绍四种最重要的访问控制模型。

4.3.1 自主访问控制（DAC）

在自主访问控制模型中，资源所有者全权负责为资源分配权限。例如，在公司中，部门负责人可能拥有大量数据，可作为资源所有者分配权限。为了为每个主体分配和管理权限，会为每个资源关联一个访问控制列表（ACL），该列表定义了各主体的访问权限。

4.3.2 强制访问控制（MAC）

强制访问控制模型提供了一种严格控制和执行权限的访问控制方式。与自主访问控制不同，强制访问控制并非将资源权限映射到主体，而是为资源和主体分配安全标签。这些标签可能包含不同的安全级别（公开、机密、秘密或绝密）。同时，组织中的参与主体也会被分配相应的安全标签。当主体试图访问资源时，会有一个中央机构检查主体和资源是否具有相应的标签或安全级别。

4.3.3 基于角色的访问控制（RBAC）

在基于角色的访问控制模型中，权限被集合分配给特定角色。例如，这些角色可以对应公司的不同部门（采购部、运输部、管理层）。这样就无需为每个主体或对象单独分配权限，系统或网络会集中控制和执行基于角色的访问控制。当新员工入职时，只需将其分配到相应角色，即可获得该角色所对应的权限集合。此外，这种方式还减少了负责权限管理的信息技术人员的管理工作量，因为权限变更可在中央位置统一进行。

4.3.4 基于属性的访问控制（ABAC）

基于属性的访问控制模型的核心思想是通过属性来允许或拒绝服务用户对资源的访问。属性可分为以下几类：

· 用户属性：用于详细描述服务用户（如年龄、部门、职位）。

· 操作属性：描述对资源执行的操作（如读、写、删除）。

· 资源属性：描述被访问的对象（如银行账户、文档）。

· 环境属性：与访问控制场景的时间、地点或动态因素相关的属性，例如仅在特定时间段内授予访问权限。

通过引入属性，基于属性的访问控制模型打破了基于角色的访问控制模型中用户与角色、角色与权限之间的刚性关联，从而具备更高的灵活性。

为满足分布式系统的动态需求，需要动态的访问控制决策机制。为此，在运行时会评估用户属性，并将其与存储的安全策略进行比较。这样，无需预先了解特定主体即可定义权限。当主体试图访问对象时（1），基于属性的访问控制模块会根据策略检查是否允许该访问（2），并相应地执行访问决策（允许或阻止）（3）。因此，不再需要为每个主体单独指定权限。实施基于属性的访问控制模型时，建议采用可扩展访问控制标记语言（XACML）标准。此外，该标准支持在访问策略中整合主体和对象的属性，而属性正是基于属性的访问控制模型的核心要素。XACML 架构及相关模块定义了基于属性的访问控制模型所需的授权基础设施。

4.3.5 访问控制技术

对于上述访问控制模型，主要有两种将访问权限映射到主体和对象的技术，这两种技术都可以通过访问控制矩阵（见表 7）来表示。这种矩阵形式通常用于自主访问控制模型，权限既可以映射到主体能力（Capability），也可以映射到对象（访问控制列表）。

表7、用于说明ACL和功能的访问控制矩阵

a. 能力表（Capability Table）这类表格为特定主体定义了一组权限。在表 7 中，针对三个不同对象（文件 1、文件 2、文件 3），横向定义了每个主体的能力。能力可以通过不同形式表示（令牌、密钥或票据）。当主体试图访问对象时，底层系统或应用程序会检查所传递的能力中包含的权限是否足以执行请求的操作。

b. 访问控制列表（ACL）访问控制列表通常用于操作系统、应用程序或网络设备（如交换机、路由器）中。访问控制列表包含不同主体的条目，这些主体被授权以特定权限访问某个对象。此外，访问控制列表也用于基于角色的访问控制模型，为特定角色分配对对象的权限。

4.3.6 汽车身份与访问管理

在 2018 年 AUTOSAR 自适应平台 18 - 03 版本发布之前，除诊断应用外，车载嵌入式系统一直缺乏完善的身份与访问管理机制。对于诊断类功能，通过安全访问（Security Access）服务实现了轻量级的访问控制。该服务基于挑战 - 响应原理，为诊断应用提供认证和授权流程。当启动扩展诊断会话时，外部诊断设备会向车载电子控制单元发送请求；随后，电子控制单元会向诊断设备返回一个随机数，诊断设备使用秘密算法计算出一个密钥；接着，诊断设备将该密钥发送给电子控制单元，电子控制单元验证密钥计算的正确性，从而确认认证的有效性；最后，通过授予执行扩展诊断服务的权限来完成授权过程。然而，多项研究已表明该流程存在安全漏洞，因此其安全性难以保障。研究表明，若能整合细粒度的身份与访问管理机制，许多车辆被利用的漏洞本可避免。

出于这些原因，近年来学术界加大了对车辆权限管理方案的研究力度，相关标准制定工作也在推进。表 8 对以下将介绍的几种方案进行了分类。2016 年，Kim 等人提出了一种去中心化的授权管理方案，该方案在 AUTOSAR 经典平台中集成了一个基于属性的访问控制模块。预定义的属性包括 CAN 消息、电子控制单元服务和环境属性，利用这些属性在每个网络节点上创建访问控制列表。

表 8、所综述的汽车身份与访问管理（IAM）分类

Hamad提出了另一种基于策略的安全通信方案，该方案重点关注在整个开发过程中，联合各相关方（原始设备制造商和各级供应商）制定可靠的安全策略。这些策略包含软件组件内所提供或所需服务接口的特定规范（如完整性等安全属性或安全协议要求）。此外，为每个电子控制单元引入了一个安全模块，该模块作为分布式代理防火墙，用于车载 TCP/IP 通信，能够基于存储的策略，对每个应用程序访问底层网络栈的行为进行细粒度的访问控制。

Gupta 和 Sandhu的研究重点关注车辆与外部环境联网程度的不断提高以及由此带来的安全漏洞风险。为此，作者首先阐述了基于云和雾计算的不同车载物联网（IoT）架构，然后详细介绍了其授权框架的结构，该框架包含适用于静态和动态通信的不同级别和类型的访问控制方案（访问控制列表、基于能力的访问控制（CapBAC）、基于属性的访问控制），并结合单云和多云等使用场景对其方案进行了说明。

Lopez 和 Rubio 发表了一篇综述文章，分析了传统访问控制模型（如自主访问控制、强制访问控制）和现代访问控制模型（如基于能力的访问控制、基于任务角色的访问控制（T - RBAC）、隐私感知的基于角色的访问控制（P - RBAC））在网络物理系统中的应用。作者基于一个典型的未来工业系统确定了访问控制的需求，并通过引入动态性、可扩展性、灵活性等比较标准（分为高、中、低三个等级），分析了现有访问控制模型的适用性。

随着 AUTOSAR 自适应平台的推出，其中规定了一个身份与访问管理模块，该模块能够基于服务实现全面的权限管理。具体而言，可以为每个应用程序或服务（主体）分配对其他资源或服务（对象）的访问权限列表。因此，AUTOSAR 自适应平台规范基于一种基于能力的访问控制模型。当服务在运行时试图访问相关对象时，该规范中规定的策略决策点（PDP）和策略执行点（PEP）模块会在应用程序和服务外部对权限进行控制和执行。此外，AUTOSAR 自适应平台还支持利用所支持的 DDS 协议对域和主题的细粒度访问控制功能。

Hugot 等人提出了一种在汽车中间件中整合动态访问控制的方案。作者首先阐述了以往车载电子控制单元在访问管理方面存在的不足，然后明确了访问控制的需求（如应在 OSI 模型第 5 层及以上层进行控制、中间件应根据车辆当前状态控制服务等）。例如，作者以自适应巡航控制（ACC）为例，指出该系统仅在开启状态下才被允许与变速箱控制模块（TCM）通信。所提出的方案基于一种动态强制访问控制模型，该模型利用状态机控制源端与目的端之间的信息流及其传输顺序。作者还通过阐述和评估三种不同方法，展示了该方案在 SOME/IP 协议中的整合过程。

5、讨论

本节将探讨第 4 章中提到的安全措施在整合到面向服务架构中时可能面临的挑战和带来的益处。分析和讨论基于图1 所示的混合电气电子架构以及不同的部署点。

5.1 总体建议 / 说明

在保障网络安全时，通常可以发现，静态通信（面向信号）比动态通信（面向服务）更易于防护。这是因为静态通信在运行时不会发生变化，例如，不会添加新的网络节点，且节点会根据规范发送预定义的消息。对于防火墙或入侵检测系统的配置而言，这意味着可以直接从规范中推导过滤规则或正常行为。这种基于面向服务架构的范式变革，也给传统信息技术等其他领域带来了新的挑战。因此，我们认为，在开发新系统时，必须明确新系统的需求，判断是否绝对需要动态通信，或者静态规范是否同样适用。一般而言，在保障新电气电子架构安全时，应首先进行威胁和风险分析，以便推导相应的安全措施。然而，本文旨在分析面向信号和面向服务通信中特定安全措施的情况，而不将其整合到具体的威胁和风险分析中。

为更准确地分析不同安全措施，我们做出以下假设：

· 从车辆的角度来看，原始设备制造商后端服务器始终具有相同的静态网络地址。

· 信号 / 服务映射是静态定义的。

· 车载诊断（OBD）接口可被多种外部设备使用。

5.2 防火墙

传统信息技术领域的防火墙技术已发展超过 25 年，最初是为解决协议和软件在安全设计方面的缺陷而提出的防护措施。防火墙并非用于解决当前通信协议存在的不足，而是试图通过额外的检查来限制这些不足所带来的影响。然而，存在这样一种风险：攻击者可能会绕过这些额外的控制措施，利用协议中持续存在的漏洞。此外，防火墙无法对数据进行语义检查，只有应用层防火墙能够基于已知攻击技术的特征进行检测，但应用层防火墙无法实时检查安全关键消息，也无法结合车辆当前状态考虑相关上下文。此外，若采用端到端加密（如在第 7 层），则需注意防火墙无法在该层对数据进行检查。

对于未来的车载网络，不应沿用传统信息技术领域的设计缺陷，而应采用安全协议。因此，网络协议必须能够在 ISO/OSI 模型的不同层保障机密性、完整性 / 真实性和可用性等网络安全属性。此外，还需考虑：结合安全协议使用防火墙是否为最佳解决方案（鉴于上述局限性以及防火墙以往的应用目的），或者当前是否有更合适的其他安全措施。

为更详细地分析防火墙的防护能力，我们对以下三个部署点进行了研究：

5.2.1 经典平台 / 自适应平台网关

该部署点负责实现面向服务通信与面向信号通信之间的转换。从面向服务方向来看，每项服务都静态地对应于特定消息及其数据载荷，因此可以对静态已知的映射关系和信号值范围进行过滤。在反向方向上，网关作为服务提供者，将来自传统设备（如发动机转速传感器、车轮转速传感器）的信号信息以服务的形式提供给 AUTOSAR 自适应平台的客户端。从防火墙的角度来看，反向方向的过滤更具挑战性。理论上，任何客户端（假设具有必要权限）都可以订阅服务，这意味着在运行时，源 IP 地址并非始终是静态且可预测的。因此，传统的包过滤防火墙（针对 OSI 模型第 3 层、第 4 层）并不适用，只能基于 SOME/IP 或 DDS 等更高级别的协议过滤特定属性。然而，需要考虑的是，防火墙是否能够全面实现与应用相关的过滤，或者这一功能是否应通过身份与访问管理功能来实现。

5.2.2 联网电子控制单元

考虑联网网关中车载 / 车外通信接口的情况，根据外部网络节点的不同，防火墙过滤存在多种可能的方案。在第一个使用场景中，我们分析车辆与原始设备制造商后端之间的连接。理论上，可以在 ISO/OSI 模型的第 3 层和第 4 层实施过滤，具体而言，可以阻止除后端静态 IP 地址以外的所有 IP 地址的访问，此外，还可以更细粒度地限制允许使用的端口。

5.2.3 车载诊断网关

在该部署点，多个外部网络参与者能够与车辆内部网络建立连接，例如，不同制造商的诊断设备以及允许与智能手机或第三方后端连接的车载诊断加密狗。若采用 DoIP 协议进行诊断，会为每个外部设备分配一个动态 IP 地址，这意味着通常无法基于特定 IP 地址进行过滤。当某个设备连接后，可以激活白名单，在该会话期间阻止所有其他 IP 地址的访问。此外，还可以在 OSI 模型第 4 层对可用端口进行限制，但需注意不同应用程序可能会使用相同的端口。若采用 CAN 协议及相应的传输协议 ISO TP 进行诊断，则需考虑其他因素。由于连续帧之间存在间隔时间，且缺乏流量控制，因此难以整合速率限制功能。此外，必须确保能够并行请求不同的诊断服务（例如，在生产线末端（End - of - Line）场景中，使用相同的 CAN ID）。

5.3 入侵检测系统

迄今为止，汽车领域的入侵检测系统主要侧重于检测基于信号的 CAN 总线上的异常情况，尚未考虑面向服务架构和以太网。在讨论面向服务架构的汽车入侵检测系统时，必须考虑其与 CAN 总线入侵检测系统相比存在的四个主要差异和挑战：首先，由于数据性质与面向信号范式不同，需要明确应分析哪些网络数据和特征；其次，由于面向服务架构导致架构本身发生变化，需要讨论入侵检测系统的部署和放置策略；这进而引出第三个问题，即除了基于网络的检测外，还需要基于主机的检测；最后，除了基于异常的入侵检测系统外，基于特征的入侵检测系统也可能具有应用价值。

5.3.1 （面向服务架构网络）入侵检测的特征

许多 CAN 总线入侵检测系统侧重于数据载荷分析，这是因为 CAN 总线的数据速率较低，且数据载荷的结构在车辆开发过程中已确定。除了分析信号外，Al - Jarrah 等人还提到了基于流的分析方法。在传统信息技术领域，基于流的分析是基于网络的入侵检测系统最常用的方法，入侵检测系统会在 OSI 模型第 2 层或第 3 层捕获所观察的特征。对于汽车面向服务架构的以太网而言，其具有多层结构、报头、加密以及相较于 CAN 总线更大的数据载荷，因此基于数据载荷的检测并不可行。因此，在汽车架构中，对于以太网和面向服务架构，采用基于流的入侵检测系统是合理的选择。然而，目前尚不清楚汽车面向服务架构流应包含哪些特征。

相比之下，Müter 等人明确了汽车入侵检测系统（尤其是针对 CAN 总线的基于异常的检测）应观察的信息。他们提出了八种所谓的传感器，并对比了它们的适用性。我们分析了这些传感器中哪些也适用于面向服务架构，以及在使用过程中会面临哪些挑战，结果如表 9 所示。如上所述，数据载荷分析具有一定难度，因此在网络层面，“范围”（Range）、“合理性”（Plausibility）和 “一致性”（Consistency）这三种传感器通常不适用。

表9、车载异常检测传感器的适用性-根据SOA要求采用和讨论

对于传感器 / 执行器层面，由于其范围受到物理约束且数据速率适中，这些传感器仍然适用。发布 - 订阅和请求 - 响应通信模式不再由发送方的规范驱动，而是由数据或请求方驱动。因此，对于面向服务架构，“范围”“频率”（Frequency）和 “协议”（Protocol）并非预先确定（表中用橙色标记），这使得分析难度加大（例如，需要采用机器学习技术）。数据的 “格式”（Formality）在一定程度上仍有规范可循，但相较于面向信号范式，规范程度更低（协议种类更多，自由度更大，例如消息大小），因此检测能力也相对较弱。此外，“总线系统数量”（Number of Bus Systems）这一标准对于面向服务架构而言并无意义，因为整个架构是一个分层的以太网拓扑结构。因此，对于面向服务架构，该标准可改为考虑所分析的流数量、数据主题数量或虚拟局域网数量等。“位置”（Location）传感器可用于识别虚拟局域网跳跃等攻击，但需要注意的是，每当车辆中引入新服务、更新后的服务请求更多数据，甚至在每次启动时，都会建立新的通信路径，因此正常的位置（即正常的通信路径）具有高度动态性。“相关性”（Correlation）传感器也存在类似问题。

综上所述，许多传感器无法直接迁移到面向服务架构中，或者在面向服务架构中不再适用。为每个服务配备监控功能与基于数据载荷的分析类似，均不可行。因此，有必要开发适用于中间件层的智能特征，以构建适用于汽车面向服务架构的基于网络的入侵检测系统。然而，这些特征必须对所有面向服务架构中间件具有通用性，以便在整个行业中推广应用。除了信息技术领域中基于流的入侵检测系统特征外，我们建议纳入从面向服务架构中间件或以太网协议中提取的服务质量（QoS）参数相关特征，因为服务质量参数可用于指定数据的优先级，并分离不同重要性的数据。另一个可行的方案是纳入对数据载荷的统计度量（无需进行深度包检测），例如信息熵，因为这类度量即使在加密流量中也可计算，且计算开销较低。

5.3.2 基于特征的检测与基于主机的检测

一方面，随着标准化操作系统和常见信息技术协议的应用，未来针对车辆的攻击可能会针对多种车型或多个制造商；另一方面，Auto - ISAC等机构共享的威胁和漏洞信息，使行业能够开发攻击特征库。因此，未来对于以太网和汽车面向服务架构，采用基于特征的检测比在 CAN 总线和面向信号范式中更具可行性。这种检测方式可作为基于异常的检测的补充，提高车辆检测已知和未知攻击的准确性。

此外，随着标准化 POSIX 操作系统的应用、进程的动态调度以及第三方服务在车辆中的引入，基于主机的入侵检测必须成为学术界和行业关注的重点。引入面向服务架构后，不仅网络层面会出现更多动态变化，软件和应用层也会如此。考虑到在网络层面无法对每个服务进行数据载荷分析或监控，对主机行为的观察就显得更为重要。AUTOSAR 基金会也关注到了基于主机的入侵检测系统，即将发布的入侵检测系统标准已为基于 AUTOSAR 的电子控制单元定义了一些基于主机的监控功能。

5.3.3 部署

从架构角度来看，CAN 总线入侵检测系统可部署在总线上的任何位置，因为所有数据都以广播形式传输。而对于以太网和面向服务架构，入侵检测系统的部署必须考虑数据的可用性以及处理更高数据速率所需的更强计算资源。因此，在图1 所示的示例架构中，为实现基于网络的检测，必须确保入侵检测系统能够获取所有数据。例如，摄像头与电子稳定程序（ESP）电子控制单元之间交换的数据无法在中央计算集群中观察到，因为与 CAN 总线不同，交换机在电子控制单元之间建立的是单播通信。因此，需要在包含交换机的电子控制单元上捕获网络数据。交换机（硬件层面）或相应的电子控制单元（软件层面）需计算以太网和面向服务架构通信中的流信息。此外，联网电子控制单元需捕获与外部通信相关的网络行为。随后，可将计算得到的流信息收集到自适应平台的某个高性能控制器上进行分析。

因此，通过在车辆网络中对面向服务架构通信行为进行分布式监控，并在中央计算集群等位置部署分布式或集中式入侵检测系统，可利用机器学习等先进分析技术对整个面向服务架构进行监控。同时，仍需在经典平台 / 自适应平台网关上部署针对 CAN 总线和面向信号通信的监控和入侵检测系统，因为该网关负责信号到服务的映射，且可在此处观察高频实时控制指令。然而，将 CAN 总线入侵检测系统与面向服务架构入侵检测系统整合到统一的车辆监控方案中，目前仍处于初步阶段。不过，当前正在推进的车辆入侵检测系统标准化工作，为实现这些监控功能奠定了技术基础。

5.4 身份与访问管理

基于 Sommer 等人的数据库进行的分析表明，过去电子控制单元上要么未实施身份与访问管理，要么仅实施了有限且薄弱的身份与访问管理（用于诊断）。这使得攻击者能够在电子控制单元上执行或修改多种功能。在 CAN 或以太网网络中整合安全连接措施（认证 / 完整性保护），可通过限制中间人攻击来降低攻击成功的风险，但仍无法防范内部攻击。在内部攻击中，攻击者从已被攻陷的电子控制单元或其他被接收方视为可信的网络节点发起攻击，因此不会违反机密性、完整性等安全属性。

因此，始终坚持最小权限原则变得更为重要。通过 AUTOSAR 中身份与访问管理模块的规范，汽车系统正越来越多地采用基于能力的访问控制方法为服务分配权限，从而践行最小权限原则。然而，需要注意的是，仅为每项服务指定权限仍存在安全风险。由于车辆属于网络物理系统，会处于不同的物理状态，因此这一因素对于访问控制至关重要。但挑战在于如何准确判断当前状态，以便据此做出恰当的访问决策。因此，在为执行器控制指令授权时，必须考虑当前的上下文信息。

与高度分布式的架构相比，图1 所示的未来架构可能具有一定优势。由于中央计算集群包含所有传感器 / 执行器信息，并执行大量功能计算，因此可在该集群中集中进行上下文分析。

在访问控制模型中，另一个需要考虑的重要方面是权限撤销。若访问控制模型基于能力，权限撤销会比基于访问控制列表的模型更困难。在汽车面向服务架构中，根据 AUTOSAR 规范，所有服务权限在开发阶段或生命周期内添加新服务时存储在清单文件中。若服务部署在多个电子控制单元上，撤销权限时需修改每个电子控制单元上的清单文件。为避免权限配置错误，必须对权限进行充分的验证和确认。Hu 等人发表了多篇关于访问控制策略和模型验证与测试方法的文献。与基于属性的访问控制等还需结合多种属性信息进行决策的模型相比，基于能力的访问控制（基于预定义权限的静态模型）的验证更为容易。

6、结论

综上所述，面向信号这一旧范式与面向服务架构这一新兴发展在安全性方面存在两个主要差异：一方面，面向服务架构基于交换式以太网及其安全协议栈，可减小攻击面；此外，物理架构的设计考虑了 “安全设计” 原则，而非仅依赖 “通过模糊实现安全”。另一方面，数据、网络连接和软件应用的动态性不断增强，对车辆安全机制提出了更高要求。

从安全角度来看，在设计阶段确定的内容越多，攻击面就越小，在运行时通过基于规范的简单措施进行检查和验证的可行性就越高。然而，若无法实现应用程序的动态部署、动态网络路径或使用 POSIX 操作系统，未来的汽车架构将无法满足客户对频繁更新和新功能的需求。因此，动态性将会不断增强，未来的面向服务架构和混合架构将需要防火墙、入侵检测系统、访问控制等所有主动安全措施。

但是，随着防火墙、入侵检测系统和访问控制机制的功能日益交叉融合，需要采用结构化方法来合理部署这些措施，明确在何处分析哪些数据。这种系统级策略还应结合威胁建模结果。此外，有多种网络安全对策可用于保障特定安全属性，但需分析哪些措施组合能以最高效率满足汽车领域的约束条件（如实时性、带宽）。

此外，为应对不断增强的动态性，需要采用先进的防御机制。静态规则、阈值或访问列表已不足以保护未来的车辆，否则可能会产生误报或遗漏攻击。网络安全决策和分析需纳入车辆状态、环境行为、外部接口信息等上下文信息。