SOME/IP车载服务的形式化安全分析和防护

车载以太网在现代汽车中的应用日益广泛，它对控制器局域网（CAN）等传统总线系统起到了补充甚至替代作用。以太网还支持通过基于 IP 的可扩展面向服务中间件（SOME/IP）实现面向服务的通信。本文对 SOME/IP 进行了形式化与实用性安全分析，明确了其中存在的中间人（MITM）攻击风险，并提出了两种安全扩展方案。即便 SOME/IP 与链路层安全机制结合使用，这些攻击仍有可能发生。攻击者可冒充提供服务的服务器和使用服务的客户端，而请求 / 响应和发布 / 订阅这两种最常见的通信方式均存在漏洞。在多数通信场景下，攻击者能够将所有消息劫持到自己的通信路径中。本文提出的用于服务提供与使用的认证和授权安全扩展方案，可有效防范这些攻击。我们通过形式化方法分析了方案的安全性，并结合实际实现评估了其额外开销。

当前汽车行业正经历重大技术变革，例如为实现新型信息娱乐功能或高级驾驶辅助系统（这些功能也是自动驾驶所必需的）而进行的技术升级。这些功能需要高且灵活的通信带宽，并且越来越多地通过车载以太网（如 BroadR-Reach）和基于 IP 的通信来实现。与仅支持静态通信的控制器局域网（CAN）总线不同，以太网和 IP 的使用能够实现动态、面向服务的通信，且带宽利用效率更高。基于 IP 的可扩展面向服务中间件（SOME/IP）可作为车载中间件解决方案，支持远程过程调用、事件通知以及底层的序列化 / 有线格式。SOME/IP 的开发旨在满足车载需求（如融入汽车开放系统架构（AUTOSAR）、实现快速响应等），并支持不同规模和操作系统的设备。电子控制单元（ECU）通过 SOME/IP 宣布自身提供的服务（作为服务器）或使用其他设备提供的服务（作为客户端）。由于 SOME/IP 规范未考虑任何安全机制，它通常会与媒体访问控制安全（MACsec）或 AUTOSAR 安全车载通信（SecOC）等链路层安全机制结合使用。

本文主要有两大贡献。首先，我们提出了针对 SOME/IP 的中间人攻击方案，即便部署了链路层安全机制，这类攻击仍能实施。若攻击者攻陷了车辆电子 / 电气（E/E）系统中的任一 ECU（无论是通过物理访问，还是像吉普汽车黑客攻击事件那样通过远程方式），就能同时冒充 SOME/IP 服务器和客户端，将通信流量劫持到自身路径中。为此，我们使用 Tamarin 定理证明器对攻击进行了形式化分析，以明确中间人攻击的可能性，并结合开源参考 SOME/IP 实现（vsomeip）以及车载开发测试工具 CANoe开展了实用性评估。其次，我们提出了两种 SOME/IP 协议扩展方案，用于保护 SOME/IP 服务发现过程及后续所有 SOME/IP 通信。这些方案能够实现 SOME/IP 服务提供与使用过程中的认证和授权功能。第一种方案最初利用证书和数字签名建立对称密钥，再通过该对称密钥保护后续的 SOME/IP 通信；第二种方案仅采用高效的对称加密技术，但要求在电子 / 电气（E/E）架构中额外部署一个授权服务器（AS）。这两种方案均对服务的提供和使用进行了限制，从而降低了攻击者通过攻陷 ECU 可能造成的危害。我们通过 Tamarin 定理证明器对两种方案的安全性进行了形式化分析，并结合实际实现评估了其引入的额外开销。

本文结构如下：第 2 章讨论相关工作；第 3 章概述 SOME/IP；第 4 章介绍我们用于识别第 5 章所述中间人攻击的形式化安全分析方法；第 6 章阐述攻击的实现与评估过程；第 7 章详细说明两种 SOME/IP 安全扩展方案、其形式化分析及实用性评估；最后，第 8 章对全文进行总结。

在使用控制器局域网（CAN）等传统车载总线系统的车载网络中，复杂的中间人攻击并不常见，因为总线系统中路由功能并非必需。因此，以往针对车载网络的攻击研究主要集中在对 CAN 及其他总线系统的重放攻击或注入攻击上。Koscher 等人在文献中提出了通过 CAN 总线实现对车辆制动和加速系统控制的攻击方法；文献研究了如何通过车载诊断系统（OBD-II）、光盘（CD）、无线网络（WiFi）、蓝牙或蜂窝网络等方式，直接或间接向车载网络发送消息；Miller 和 Valasek 在文献中展示了如何通过 CAN 网络控制车辆的转向、制动、加速系统及显示屏，并在文献中提出了一种远程控制车辆的攻击方案。

为保障车载电子 / 电气（E/E）架构中的通信安全，研究人员已提出多种方案。SecOC 是由 AUTOSAR 标准化的方案，采用对称加密技术保障 CAN 通信安全，其安全性已在文献中通过形式化方法进行了分析。随着计算能力的提升和带宽的增加，非对称加密技术也逐渐应用于车载领域。例如，传输层安全协议（TLS）已被纳入 AUTOSAR（包括经典平台和自适应平台），相关研究已在文献等文献中有所探讨；自适应平台同样支持 IP 安全协议（IPsec）。此外，研究人员已通过 Tamarin和 ProVerif 对 TLS 1.3 协议进行了形式化分析；Tamarin 还被用于分析车联网（V2X）吊销协议和电动汽车充电协议。

文献探讨了 SOME/IP 的安全防护问题，提出在事件组订阅过程中利用（数据报）传输层安全协议（(D) TLS），通过一个中央实体实现密钥材料的分发，但未对服务提供和服务查找过程进行保护。该方案还在 SOME/IP 中扩展了时间同步的高效流签名算法（TESLA），以支持广播通信。然而，在广播消息中使用 TESLA 协议进行延迟认证存在明显缺陷：一是需要修改 SOME/IP 的处理流程（需缓存消息直至验证消息到达），二是引入的延迟不适用于时间敏感型数据。

为检测针对 SOME/IP 的攻击，Herold 等人在文献中提出了一种基于复杂事件处理（CEP）的 SOME/IP 入侵检测系统（IDS），该系统可检测三类攻击：畸形数据包攻击、协议违规攻击和时序异常攻击。但该方案与其他入侵检测系统方案存在相同问题，即可能产生误报和漏报。

Iorio 等人提出了一个保护 SOME/IP 通信的安全框架。在该框架中，请求服务的每个客户端与提供服务的服务器之间需先通过证书和非对称加密技术执行单独的握手过程，以建立共享对称密钥，随后使用该密钥保护后续消息。但该方案存在与 TLS 类似的主要缺陷：非对称加密会引入额外开销，且无法再通过广播方式发送服务提供消息，需发送 “服务查找” 消息以执行单独的密钥交换。

其他领域也对面向服务通信的安全防护问题进行了研究。例如，为保障机器人操作系统（ROS）的安全，其分支版本 Secure ROS通过建立 IPsec 连接实现 ROS 节点间的安全通信，并通过预定义允许的 IP 地址限制服务提供者和请求者。但该方案与动态网络和服务发现的理念相悖。

基于 IP 的可扩展面向服务中间件（SOME/IP）是一种中间件规范，主要用于控制信号的传输和序列化，尤其适用于车载场景。SOME/IP 运行在（车载）TCP/IP 或 UDP/IP 协议栈之上，为应用程序提供抽象的面向服务接口（见图1）。因此，应用程序无需处理 IP 地址和端口，只需关注服务本身即可。SOME/IP 的核心目标是实现灵活且带宽高效的通信。

图1、SOM/IP架构

SOME/IP 大致可分为三部分：服务发现（SD）、远程过程调用（RPC）和过程数据访问。服务发现（SD）功能支持服务器 ECU 在车载网络中发布服务，客户端 ECU 在网络中订阅服务。服务通过服务 ID（Service ID）进行标识，必要时还可通过端点选项（即 IP 地址、传输协议（UDP/TCP）和端口号）等附加选项进一步区分。网络中可存在同一服务（具有相同服务 ID）的多个实例，这些实例通过不同的实例 ID（Instance ID）进行唯一标识。客户端可通过远程过程调用（RPC）访问已发布的服务，并能接收事件通知。应用程序可通过 “设置（set）” 和 “获取（get）” 操作访问过程数据。

SOME/IP 服务发现（SOME/IP-SD）用于定位服务实例、检测服务实例是否处于运行状态，并实现发布 / 订阅管理。服务器若要提供某个服务实例，需发送多播服务提供消息 OfferService（包含服务 ID、实例 ID），并可附加端点选项等可选参数；若要停止提供某个服务实例，服务器需发送 StopOffer 消息（包含服务 ID、实例 ID）。若客户端未收到包含所需服务 ID 的合适服务提供消息，可主动发送 FindService 消息（包含服务 ID、实例 ID），提供该请求服务的服务器会对该消息进行响应。实例 ID 既可以设为特定值，也可设为 0xFFFF（表示查找所有服务实例）。

当客户端需要从服务器获取一组信号，但不希望每次需要时都手动请求时，可采用发布 / 订阅机制。客户端通过发送 SubscribeEventgroup 消息（包含服务 ID、实例 ID）订阅某个事件组，服务器通过发送 SubscribeEventgroupACK 消息（包含服务 ID、实例 ID）进行确认；客户端通过发送 StopSubscribeEventgroup 消息（包含服务 ID、实例 ID）取消订阅。订阅生效期间，服务器会定期向客户端发送事件消息。此外，SOME/IP 还为服务实例提供负载均衡选项：服务器可在其服务提供消息中设置优先级（priority）和权重（weight），客户端应选择优先级最高的服务；若存在多个优先级相同的服务实例，则需根据服务实例的权重随机选择。

在远程过程调用（RPC）方面，SOME/IP 支持多种通信模式，其中最常见的是请求 / 响应模式：客户端发送请求消息，服务器对该消息进行响应。无需响应的请求被称为 “即发即弃（fire&forget）”。若客户端已通过 SOME/IP-SD 订阅某项服务，服务器会定期向客户端发送通知事件。在某些情况下（如数值更新或事件发生时），服务器也会主动向客户端发送通知事件。SOME/IP 负责事件数据的传输，SOME/IP-SD 则负责事件的发布与订阅。

SOME/IP 协议规范和 SOME/IP 服务发现协议规范均未充分考虑安全问题（参见第 2 章）。由于 SOME/IP 未提供任何安全机制，攻击行为极易发生。因此，近年来车辆开始引入媒体访问控制安全（MACsec）或 AUTOSAR 的安全车载通信（SecOC）等网络安全协议，以确保 ECU 仅接收来自其他 ECU 的可信消息，例如防止攻击者通过物理访问向网络注入恶意消息。

SOME/IP 通常用于车载以太网网络，该网络可替代控制器局域网（CAN）总线、媒体定向系统传输（MOST）或 FlexRay 等部分传统车载网络技术。以太网的使用还使网络拓扑从总线结构转变为包含多个交换机的星形结构。根据文献的研究，第一代采用 SOME/IP 的车载以太网网络包含少量交换机和数量为两位数的以太网 ECU，每个 ECU 可提供数十项服务。

本章将概述我们用于评估 SOME/IP 及所提安全扩展方案的形式化安全分析方法。

4.1 符号模型

我们在符号模型（也称为 Dolev-Yao 模型）中分析 SOME/IP 及所提扩展方案的安全性。在该模型中，假设加密原语具有完美安全性，即攻击者无法破坏其安全属性。例如，只有掌握相应的解密密钥，才能对加密消息进行解密。因此，符号模型中的安全分析重点在于这些加密原语的组合方式。这种简化使模型更易于自动化分析，且目前已有功能强大的工具可支持在该模型内验证安全属性。尽管存在简化，符号模型中的分析仍具有很强的实用性，能够识别协议中大多数实际存在的攻击（参见第 2 章）。

由于 SOME/IP 本身未提供任何安全机制，在对其进行分析时，我们假设使用 SecOC 或 MACsec 等底层认证协议，以限制攻击者的能力。但我们允许攻击者攻陷 ECU。众多攻击案例，如吉普汽车黑客攻击、奔驰汽车黑客攻击、宝马汽车攻击、大众信息娱乐系统攻击以及特斯拉 Model S 攻击等，均表明 ECU 被攻陷是真实且严重的安全威胁。在分析所提安全扩展方案时，我们假设攻击者具备 Dolev-Yao 模型中的强大能力，即能够完全控制网络，且可攻陷 ECU。

4.2 符号模型中的安全属性

本文分析的核心是认证属性，该属性是防止 SOME/IP 通信被未授权篡改（尤其是中间人攻击）的关键。我们采用 Lowe 定义的认证属性，这些属性构成了一个层级结构，从相对较弱的 “存活（aliveness）” 属性，到更强的 “注入一致性（injective agreement）” 属性。

对于消息认证协议而言，“存活” 属性要求：当协议实体接收并接受一条消息时，该实体所认定的消息发送方此前确实发送过一条消息（但不要求该消息与接收的消息完全一致）。顾名思义，该属性仅验证所认定的发送方 “存活”，即其此前曾与对应角色运行过同一协议。

在验证所提安全扩展方案（参见第 7.3 节）时，我们采用 “注入一致性” 属性。本质上，该属性要求：当接收方接收并接受一条消息时，所认定的发送方此前确实向该接收方发送过完全相同的消息；此外，接收方对该消息仅接受一次，从而防止攻击者对消息进行重放。因此，实现 “注入一致性” 属性是防范中间人攻击的有效手段。尽管 “注入一致性” 是很强的认证属性，但它并未考虑广播通信模式。Lauser 等人提出了 “一次性组一致性（One-time group agreement）” 属性，该属性是对 “注入一致性” 属性的改进，适用于分析在共享密钥环境下支持广播通信的协议（如他们所分析的 SecOC 协议）。“一次性组一致性” 属性要求：当接收方接收并接受一条消息时，该消息此前确实由合法发送方发送，且每个接收方仅接受一次。因此，该属性比 “注入一致性” 属性稍弱，因为它不验证消息是否专门针对该接收方，也不区分不同的发送方，若攻击者模型中考虑协议实体被攻陷的情况，该属性无法提供足够的安全防护。

此外，我们要求所提扩展方案中使用的密钥具备 “语法保密性（syntactic secrecy）”，即模型中不存在任何有效轨迹可使攻击者获取该密钥。“前向保密性（forward secrecy）” 则进一步要求：即使相关参与方的长期凭证在协议运行后泄露，该密钥仍不会被攻击者获取。

4.3 Tamarin 定理证明器

Tamarin 定理证明器是符号模型中用于形式化分析的成熟工具，它能根据协议模型自动生成安全属性的证明或反例，且支持对无限数量的协议实体和会话进行分析。协议模型以多集重写系统的规则形式进行定义，系统状态通过事实表示，这些事实可通过规则进行操作 —— 规则的前提事实会被消耗，同时生成结论事实。此外，规则可通过动作事实进行标记，以便在安全引理中引用；还可通过添加约束条件要求进行输入验证，以限制规则的适用范围。安全属性通过基于动作事实和时间点的一阶逻辑子集进行定义。然而，由于底层问题的不可判定性，Tamarin 可能无法终止分析，此时可能需要人工干预或优化（如引入中间安全引理）。

我们使用 Tamarin 定理证明器对结合链路层安全机制的 SOME/IP 进行形式化安全分析。

我们假设 ECU 通过具有重放保护功能的组认证通道进行通信，并重点分析服务发现消息的认证过程。不出所料，在未攻陷任何合法 ECU 的情况下，我们可证明 SOME/IP 具备较强的认证属性，尤其是 “一次性组一致性” 属性，此时攻击者无法注入有效的 OfferService 消息。然而，若存在能够攻陷 ECU 的更强攻击者，即便考虑 “存活” 这一相对较弱的认证属性（该属性是我们所考虑的所有其他认证属性的基础，参见第 4.2 节），消息认证也无法得到保障：

定义 5.1（基于 OfferService 的存活属性）：对于诚实的服务器 S 和诚实的客户端 C，当且仅当 C 接受一条声称来自 S 的 OfferService 消息 m 时，S 此前处于活跃状态。

在 Tamarin 语法中，该引理表示如下：其中，E_C_ReceiveOfferService 表示客户端接收 OfferService 消息（声称来自服务器）的事件；E_S_Created 表示服务器通过规则创建（即处于活跃状态）的事件；随机数（nonce）参数用于其他引理区分不同的 OfferService 消息；最后两行要求服务器和客户端均未被攻陷。

该属性不成立的原因是，攻击者可轻易伪造来自任意服务 ID（Service ID）的消息。SOME/IP 中没有任何机制能将 OfferService 消息中的服务 ID 与发送方绑定，服务请求中包含的客户端 ID（Client ID）也存在类似问题 —— 攻击者可利用被攻陷的 ECU 发送请求时使用任意客户端 ID。结合这两个漏洞，攻击者只需掌握极少的系统先验知识，即可实施中间人攻击。下文将详细介绍通过形式化分析得出的这些实用中间人攻击方案。

5.1 针对服务提供的模仿攻击（Copycat Attack）

模仿攻击的核心思路是：监听正常服务器 S 发送的广播服务提供消息，随后立即发送一条服务提供消息，但将其中的端点选项替换为攻击者 A 自身的端点信息。

图 2 通过示例展示了该攻击过程。首先，正常服务器 S 发送服务提供消息 OfferService（0x1234, 0x5678），其中服务 ID 为 0x1234，实例 ID 为 0x5678，端点选项为 Endpoint（10.0.0.2:30509）。攻击者 A 一旦接收到该消息，便发送一条相同的服务提供消息，但将端点选项替换为自身的 Endpoint（10.0.0.4:30510）。由于攻击者无法影响底层通信，客户端 C 通常会接收到这两条服务提供消息，并可能选择攻击者 A 作为服务提供者，向其发送请求。此时，攻击者 A 可将这些请求转发给原始服务器 S，并将 S 的响应转发回客户端 C。处于中间人位置的 A 还可实施进一步攻击，例如篡改消息内容或（选择性地）丢弃消息。

图2、对服务报价的模仿攻击

在 Tamarin 模型中，可通过以下方式验证该攻击的存在：若客户端从服务器接收的响应中包含服务器新生成的、攻击者在发送事件前未知的随机数据，则需验证该响应是否由服务器发送至正确的客户端端点。针对该引理，Tamarin 会生成与上述攻击对应的攻击轨迹。

在实际场景中，模仿攻击（从攻击者角度）存在几个问题：首先，客户端可能已与服务器建立连接，不会切换到其他服务器；其次，即便客户端未建立连接，也无法保证其会选择攻击者作为服务提供者 —— 由于原始服务器的服务提供消息总是先于攻击者发送，客户端可能始终不会选择攻击者；此外，该方案与 SOME/IP 规范相悖，因为规范要求 SOME/IP 服务实例具有唯一性，这可能使入侵检测系统（IDS）能够检测到该攻击。然而，正如我们的实现与评估所示（参见第 6 章），正常服务器会直接忽略此类消息。

另外，攻击者可使用不同的实例 ID。若客户端接受其他服务实例，仍有可能选择攻击者，但依旧无法保证客户端一定会选择攻击者的服务实例；而且，攻击者需要知道客户端接受的有效实例 ID（若客户端不接受所有实例 ID）。

若使用负载均衡选项（参见第 3 章），攻击者还可发送优先级和权重最高的服务提供消息。若存在其他优先级和权重相同的实例，攻击者仍有被随机选中的可能。

5.2 针对服务提供的解关联攻击（De-association Attack）

为解决上述模仿攻击的问题，我们对其进行扩展，提出了解关联攻击：使客户端 C 相信正常服务器 S 的服务已不再可用。为此，攻击者 A 会额外发送一条单播 StopOffer 消息（包含正常服务器的端点选项），使客户端 C 与服务器 S 解关联。

图 3 展示了该攻击的示例过程：服务器 S 发送 OfferService（0x1234, 0x5678）消息，端点为 Endpoint（10.0.0.2:30509）；随后，攻击者 A 立即向对该服务感兴趣的客户端 C 发送单播 StopOffer 消息（包含服务器 S 的端点 10.0.0.2:30509）；与模仿攻击类似，攻击者 A 也会立即发送自身的服务提供消息，以获取中间人位置。

图3、对服务提供的去关联攻击

若将上一节中的引理进一步限制为 “客户端此前已知该服务器” 的场景，Tamarin 会生成该攻击的轨迹。

StopOffer 消息采用单播方式发送给客户端，因为若服务器 S 接收到该消息，会认为有其他服务器接管服务而停止提供自身服务，这将使攻击者 A 无法获取中间人位置。攻击者的 OfferService 消息可采用广播方式发送，因为服务器 S 会直接忽略该消息。

解关联攻击存在一个缺陷：攻击者 A 需要知道对该服务感兴趣的客户端，否则无法向它们发送单播 StopOffer 消息。因此，攻击者需识别这些客户端。由于 A 只能监听广播通信，其可通过以下方式识别客户端：监听客户端发送的广播 FindService 消息，或监听其他可标识客户端及其 IP 地址的广播消息；或者，攻击者可直接向网络的整个 IP 范围（排除正常服务器）发送 StopOffer 消息。

5.3 针对发布 / 订阅的攻击

基于通过 Tamarin 发现的请求 / 响应攻击，我们设计了针对发布 / 订阅的攻击，如图 4 所示：正常服务器发送 OfferService（0x1234, 0x5678）消息，端点为 Endpoint（10.0.0.2:30509）；随后，客户端 C 和攻击者分别发送 SubscribeEventgroup 消息（0x1234, 0x5678），并附带各自的端点选项（客户端 C 的端点为 10.0.0.3:3333，攻击者的端点为 10.0.0.4:4444）；服务器 S 通过发送 SubscribeEventgroupACK（0x1234, 0x5678）消息进行确认。

图4、发布/订阅攻击

攻击者 A 还会尽快实施上述针对服务提供的攻击之一，使客户端 C 相信攻击者提供了所需服务。客户端 C 向攻击者 A 发送 SubscribeEventgroup 消息（0x1234, 0x5678），端点为 10.0.0.4:3334；攻击者 A 向服务器 S 发送 StopSubscribeEventgroup 消息（包含客户端 C 的端点 10.0.0.3:3333），以取消客户端 C 的订阅，阻止服务器 S 向客户端 C 发送事件消息；同时，攻击者 A 向客户端 C 发送 SubscribeEventgroupACK 消息（0x1234, 0x5678）。

此时，攻击者 A 可实施中间人攻击：当服务器 S 发送服务对应的事件消息 Event（0x1234, 0x5678）时，这些消息会发送给攻击者 A 而非客户端 C；攻击者 A 可决定如何处理这些消息，例如篡改后转发给客户端，或直接丢弃。

本章简要介绍我们使用 vsomeip 和 CANoe 实现攻击的过程及评估结果。

6.1 攻击实现

我们的第一套实现方案包含客户端、提供服务的服务器和中间人攻击者，三者均部署在运行 Linux Debian 系统（内核版本 4.19）和 vsomeip （版本 3.1.16.1）的 ARM1176JZF-S 开发板上。三块开发板通过交换机连接，采用 UDP 协议通信（使用 TCP 协议时结果类似）。我们以 vsomeip 自带的示例为测试用例，验证请求 / 响应和发布 / 订阅通信场景下的攻击效果。

在请求 / 响应场景中，服务器提供服务的时长约为 10 秒，并定期（最迟每 2.5 秒）发送 OfferService 消息；10 秒后，服务器发送 StopOffer 消息，等待约 10 秒后重新开始提供服务。客户端在服务可用期间，约每秒发送一次请求。需注意，消息发送时间会因系统负载和网络状况存在微小差异。

发布 / 订阅场景的初始流程与请求 / 响应场景相同，但客户端在服务可用后会发送订阅消息，服务器确认后，每秒向订阅的客户端发送事件消息。攻击者通过 Scapy工具实现。

我们的第二套实现方案中，SOME/IP 客户端和服务器部署在运行 CANoe 9.0.137（带有 SOME/IP 库）的 PC 上，并结合 VN5610 车载以太网接口；PC 与 VN5610 通过交换机连接；攻击者部署在该 PC 的 Linux 虚拟机中。SOME/IP 通信的实现方式与 vsomeip 方案一致。

6.2 服务提供攻击评估

针对服务提供的模仿攻击和解关联攻击（参见第 5.1 节和第 5.2 节）的目标是将消息路由至攻击者。在评估中，我们运行请求 / 响应示例 1000 秒，统计直接从服务器发送到客户端的响应消息数量，以及通过攻击者转发的响应消息数量。

表 1 展示了使用 vsomeip 和 CANoe 的评估结果，对比了无攻击、模仿攻击和解关联攻击三种场景。“直接（Direct）” 列表示从正常服务器直接发送到客户端的响应消息数量（即攻击未成功的消息）；“中间人（MITM）” 列表示通过中间人攻击者转发的响应消息数量（即攻击成功的消息）。

表 1、模仿攻击与解关联攻击评估结果

使用 vsomeip 实现攻击时，结果如下：无攻击场景下，共发送 458 条响应消息（即在 10 秒发送周期内发送 9-10 条消息），所有消息均从正常服务器直接发送到客户端；模仿攻击场景下，共发送 471 条消息，且全部为直接发送 —— 该实现仅在原始服务的生存时间（TTL）过期后，才接受相同服务 ID 下不同 IP 的新服务，而在我们的示例应用中，只有发送 StopOffer 消息后 TTL 才会过期，因此模仿攻击完全未成功；解关联攻击则效果显著，在总共 475 条响应消息中，仅 2 条从服务器直接发送到客户端，其余 473 条均通过攻击者转发，这 2 条未被劫持的消息是由于时序的不确定性（服务器在攻击者发送 StopOffer 消息前已发送响应）。

与 vsomeip 不同，在 CANoe 的 SOME/IP 实现中，两种攻击在请求 / 响应场景下均成功，所有消息均通过中间人攻击者转发。这一结果表明，该实现倾向于选择最后接收的 ServiceOffer 消息，而 vsomeip 则相反。由于该实现为闭源，我们无法验证这一观察结果。

6.3 发布 / 订阅攻击评估

针对发布 / 订阅的攻击可与模仿攻击或解关联攻击结合实施。表 2 展示了无攻击、结合模仿攻击、结合解关联攻击三种场景下，使用 vsomeip 和 CANoe 的评估结果。

表 2、发布 / 订阅攻击评估结果

使用 vsomeip 实现攻击时，结果如下：无攻击场景下，1000 秒评估期间内，服务器向客户端直接发送 556 条事件通知；结合模仿攻击场景下，服务器为 556 个事件生成事件消息并发送给攻击者，但同时也为部分事件生成 380 条消息直接发送到客户端，导致客户端接收部分重复事件 —— 这是因为该实现与请求 / 响应处理不同，客户端在收到 ServiceOffer 后会立即订阅所有合适的服务，而服务器会定期发送 OfferService 消息，客户端每次都会重新订阅，攻击者无法及时发送 StopSubscribeEventgroup 消息，从而导致服务器向客户端发送部分事件；结合解关联攻击场景下，由于 vsomeip 参考实现存在某种实现错误，客户端会忽略 StopOffer 消息后的第一条 OfferService 消息（表中用 “（0）” 标识），我们通过在发送 StopOffer 消息后发送两条 OfferService 消息解决了该问题，使中间人攻击成功 —— 服务器向攻击者发送 422 条事件消息，攻击者转发给客户端，同时服务器还向客户端直接发送 385 条事件消息，但客户端因已收到针对该服务器的 StopOffer 消息而拒绝接收。客户端最终接收的事件消息数量（422 条）低于前两种场景（556 条），原因是攻击者获取中间人位置需完成一系列攻击步骤（攻击者与服务器的订阅握手、攻击者与客户端的订阅握手、发送 StopSubscribeEventgroup 消息、发送 StopOffer 消息、发送两条 OfferService 消息），这需要一定时间。

在 CANoe 的 SOME/IP 实现中，两种攻击在发布 / 订阅场景下均有效。与 vsomeip 不同，即便攻击者发送 StopSubscribeEventgroup 消息，CANoe 实现中的服务器仍不会停止向客户端发送消息，但客户端在收到 StopOffer 消息后会忽略这些消息（表中括号内数字表示服务器发送的直接消息数量）。

即便在底层部署了安全机制，上述针对 SOME/IP 服务发现（SOME/IP-SD）的应用层攻击仍有可能发生。攻击者只要攻陷一个 ECU（不一定是提供服务的服务器），就能以网络合法成员的身份进行认证，并实施中间人攻击。

第 2 章已讨论了相关的 SOME/IP 安全防护工作，包括基于入侵检测系统（IDS）的方案、基于 TLS 的方案、基于 TESLA 的方案以及基于非对称加密数字签名的方案。TLS 和非对称加密数字签名方案能实现较高的安全性，且满足车载领域的一般需求（如零误报、低延迟），可防止外部攻击者实施中间人攻击。但在我们的攻击者模型中，还需考虑内部攻击者 —— 他们能够通过认证并实施中间人攻击；此外，TLS 和文献提出的方案无法用于服务发现（SD）的广播通信。

下文将提出两种 SOME/IP 安全扩展方案。为防范或至少缓解内部攻击者针对 SOME/IP 服务发现的中间人攻击，我们建议将密钥限制为 ECU 被授权提供和 / 或使用的服务。这样，即便攻击者攻陷 ECU 并获取密钥，也只能提供和使用被授权的服务，从而降低攻击造成的影响。

7.1 基于受限证书和数字签名的安全 SOME/IP 服务发现与会话建立（SESO-RC）

该方案（SESO-RC）可保护 SOME/IP 服务发现广播消息及后续所有 SOME/IP 通信。与文献的方案类似，SESO-RC 最初利用非对称加密的数字签名建立对称密钥，再通过该对称密钥保护后续通信；证书中包含被授权服务的信息，以限制 ECU 被攻陷后可能造成的危害。与文献的方案不同，SESO-RC 仍支持服务发现的广播通信，无需修改 SOME/IP 规范定义的协议流程。

每个 ECU 均配备一个私有密钥skECU和对应的证书CertECU（包含公钥pkECU。证书由可信认证机构（CA）颁发，所有 ECU 均存储 CA 公钥，用于验证其他 ECU 证书的有效性。证书中还包含 ECU 被授权提供、停止、请求或订阅的服务信息。为简化分析，我们假设所有（可信）证书均预先配置在各 ECU 中，且证书的哈希值被用作 ECU 的唯一标识IDECU。此外，也可将完整证书包含在 SOME/IP 消息中，ECU 仅存储可信根 CA 证书以验证收到的证书。证书可在生产过程中预先部署，并通过固件更新进行更新，本文暂不讨论证书的安全更新方式。

服务提供消息由发送方的私有密钥签名，并包含一个临时 - 静态（ephemeral-static）2 Diffie-Hellman（DH）密钥交换过程，用于建立对称会话密钥。该会话密钥随后通过附加消息认证码（MAC），保护后续 SOME/IP 消息的完整性。此外，若 ECU 之间实现松散时间同步，时间戳可确保消息的新鲜性；否则，可使用计数器实现该功能。

图 5 展示了 SESO-RC 在请求 / 响应通信中的应用流程：服务器 S 存储证书CertS（包含公钥pkS和服务器被授权提供及停止的服务列表）、对应的私有密钥skS以及所有客户端的公钥；客户端存储证书CertC（包含公钥pkC和客户端被授权请求的服务列表）、对应的私有密钥skC以及所有服务器的证书（含相应公钥）。

服务器广播服务提供消息 OS，其中包含服务 ID、实例 ID（用 “...” 表示）、标识IDS、新鲜值f1、DH 公钥pkSDH-S（供后续所有客户端生成共享对称密钥使用）等常规载荷，且该消息由服务器的私有密钥skS签名。需要请求服务的客户端首先验证签名的有效性和f1的新鲜性；验证通过后，客户端生成临时 DH 密钥对，并将公钥部分pkEDH-C、依赖于f1的新鲜值f2以及IDC包含在服务请求消息 Req 中，且该消息由客户端的私有密钥skC签名。此时，客户端和服务器可通过各自的私有 DH 密钥和收到的公钥计算共享对称密钥kSC。其他客户端同样使用服务器的pkSDH-S，但会生成各自的临时 DH 密钥对，确保每个连接使用独立的对称密钥。最后，服务器发送响应消息 Res，其中包含请求的服务数据、IDS和新鲜值f3。由于客户端和服务器此时已拥有共享对称密钥kSC，该消息及后续所有消息均通过 MAC 进行保护。

图 5、SESO-RC 在请求 / 响应通信中的应用

图 6 展示了 SESO-RC 在发布 / 订阅通信中的应用流程：由于服务器后续需向所有订阅该服务的客户端Ci（i为客户端编号）广播事件，因此需要一个组密钥。服务提供消息 OS 和订阅事件组消息 SE 的前两步流程与请求 / 响应场景类似。所有客户端Ci均已与服务器建立独立的对称密钥kSCi；服务器生成组密钥kgroup，并使用每个客户端的kSCi对其进行单独加密，通过订阅事件组确认消息 SEA 分发该组密钥。为防止重放攻击，加密过程中包含一个新鲜值；同时，使用kSCi计算 MAC 并附加在消息中，以确保完整性。需注意，此处为简化分析，kSCi既用于加密也用于计算 MAC，但实际应用中应基于kSCi派生不同的密钥，分别用于加密和 MAC 计算。

图 6、SESO-RC 在发布 / 订阅通信中的应用

7.2 基于授权服务器的安全 SOME/IP 服务发现与会话建立（SESO-AS）

该方案（SESO-AS）为每个 ECU 分配唯一标识IDECU和对称密钥kECU。同样，我们假设这些信息预先配置在 ECU 和授权服务器（AS）中。授权服务器还存储每个 ECU 被授权提供、停止、请求或订阅的服务信息。与 SESO-RC 类似，SESO-AS 也需通过某种机制确保消息新鲜性（所有 ECU 与授权服务器实现松散时间同步，或使用计数器）。

图 7、SESO-AS 在服务提供中的应用

图 7 展示了 SESO-AS 在服务提供过程中的应用流程：服务器向授权服务器发送服务提供消息 OS，其中包含常规载荷（用 “...” 表示）、IDS、新鲜值f0、加密的会话密钥kse以及 MAC。授权服务器验证 MAC 的有效性、f0的新鲜性以及服务器是否被授权提供该服务；验证通过后，授权服务器从kse派生出服务器与所有被授权使用（请求或订阅）该服务的客户端Ci之间的共享对称密钥kSCi，并使用每个客户端Ci的kCi对相应的kSCi进行单独加密。随后，授权服务器广播服务提供消息 OS（包含常规载荷和新的新鲜值f1，并为每个合法客户端Ci在消息中附加单独的容器Ei。例如，E1包含IDC1、用kC1加密的对称密钥y EnckC1 (kSC1 ))以及 MAC MACkC1 (OS, E1).。客户端C1验证 MAC 的有效性，解密得到k{SC1，并使用该密钥通过 MAC 保护后续消息。

7.3 安全性分析与验证

我们使用 Tamarin 定理证明器验证所提保护机制在 SOME/IP 服务发现过程中的密钥交换安全性，对应的 Tamarin 模型详见附录 A.2 和 A.3。与 SOME/IP 分析不同，此处我们不假设使用底层安全协议，而是允许攻击者完全控制网络；同时，用随机数抽象表示新鲜值fn。

7.3.1 SESO-RC 的安全性验证

针对 SESO-RC，我们验证会话密钥的强认证属性和前向保密性，具体定义如下两个安全属性（参见第 4.2 节）：

定义 7.1（会话密钥的注入一致性）：对于诚实的服务器 S 和诚实的客户端 C，当且仅当 S 看似与 C 建立会话时，C 此前已看似与 S 建立会话，且 C 和 S 就会话的所有参数（尤其是会话密钥）达成一致；此外，S 建立的每个会话均对应 C 建立的唯一会话。

若不存在同时被授权提供和使用某一服务的 ECU，注入一致性属性不仅隐含存活属性（参见第 5 章），还能防范重放攻击和中间人攻击。

定义 7.2（会话密钥的前向保密性）：对于诚实的服务器 S、诚实的客户端 C，以及双方均认为是彼此共享的会话密钥 k，即便攻击者后续攻陷 S 或 C 的私有密钥，也无法获取 k。

7.3.2 SESO-AS 的安全性验证

在对 SESO-AS 进行形式化验证时，我们假设授权由授权服务器（AS）执行，即授权服务器仅允许被授权的服务器 / 客户端之间针对特定服务进行密钥交换，因此无需在模型中单独体现授权过程。我们需要验证客户端与服务器之间共享密钥kSCn的注入一致性属性，以及会话密钥kse和kSCn的保密性。与 SESO-RC 不同，由于 SESO-AS 中传输的是加密后的会话密钥，其会话密钥不具备完美前向保密性。上述两种属性均可通过 Tamarin 验证。

定义 7.3（共享密钥的注入一致性）：对于诚实的服务器 S、诚实的客户端 C 和诚实的授权服务器 AS，当且仅当 C 看似从 S 接收一条 OfferService 消息时，S 此前已发送过一条 OfferService 消息，且 C 接收的共享对称密钥kSC是从会话密钥kse正确派生而来；此外，C 接收的每个事件均对应 S 发送的唯一事件。

定义 7.4（共享密钥的保密性）：对于诚实的服务器 S、诚实的授权服务器 AS，以及 S 生成的每个会话密钥kse，攻击者无法获取kse。

此外，对于诚实的服务器 S、诚实的客户端 C 和诚实的授权服务器 AS，当且仅当 C 接收一条看似与 S 共享对称密钥kSC的 OfferService 消息时，攻击者无法获取kSC。

7.4 性能评估

本章将介绍 SESO-RC 和 SESO-AS 的实现过程，评估其性能开销，并与 “安全 SOME/IP” 方案进行对比（由于文献未保护服务发现过程，故未纳入对比）。首先讨论消息尺寸增加带来的通信开销；然后通过实现所有方案并测量额外延迟，分析计算开销；最后总结三种方案的性能评估结果。

7.4.1 消息开销

SESO-RC 为每条消息增加 4 字节的新鲜值 f；服务器的 OfferService () 消息包含椭圆曲线 Diffie-Hellman（ECDH）密钥交换（采用 X25519 算法）的公钥（32 字节）和证书的 SHA-256 哈希值（32 字节）；消息的 Ed25519 椭圆曲线签名（64 字节）。图 8 展示了服务提供消息的完整格式。客户端的 Request () 消息和 SubscribeEventgroup () 消息格式相同。客户端和服务器后续发送的所有消息仅需附加 32 字节的 HMAC-SHA-512/256（使用 SHA-512 哈希函数并截断为 256 位的 HMAC）和 4 字节的新鲜值。

图 8、SESO-RC 服务提供消息格式

SESO-AS 为 OfferService () 消息增加 4 字节的新鲜值 f 和一组针对每个潜在客户端的加密密钥。为提升性能，加密和认证采用带关联数据的认证加密（AEAD）结构（ChaCha20-Poly1305 算法）。密钥组中的每个条目包含 1 字节的客户端标识IDCi、32 字节的客户端加密密钥kSCi以及 16 字节的 AEAD 认证标签（该标签通过关联数据包含 SOME/IP OfferService 消息）。新鲜值用作 ChaCha20-Poly1305 算法的输入随机数，用于加密密钥kSCi。图 9 展示了完整的消息格式。后续所有消息均需附加 32 字节的 HMAC-SHA-512/256 和 4 字节的新鲜值。

图 9、SESO-AS 服务提供消息格式

两种方案中常规 SOME/IP 消息的额外开销均为 36 字节，但密钥交换握手的开销因请求服务的客户端数量而异。表 3 对比了不同方案在不同客户端数量下的开销，其中 “消息数（msg）” 表示额外消息的数量，“字节数（bytes）” 表示所有必要消息的额外字节总数。

表 3、加密密钥交换的开销对比

SESO-AS 的消息开销包括：发送给授权服务器的服务提供消息增加 53 字节；向网络中所有客户端广播的额外 OfferService 消息增加（4 + 49c）字节（c 为合法客户端数量）。

SESO-RC 的密钥交换无需额外消息，因为服务提供消息直接广播给客户端；服务提供消息和第一条请求消息的额外开销均为 132 字节；每个额外请求服务的客户端需再增加 132 字节的开销。

“安全 SOME/IP” 方案要求每个客户端与服务器之间执行单播握手。为公平对比，我们在实现中用 Ed25519 椭圆曲线签名替换了 RSA 签名。握手过程中，客户端消息包含 36 字节的证书哈希和新鲜值；服务器消息包含 144 字节（含非对称加密并签名的组密钥）。每个额外客户端均需发送这两条消息。

从消息数量来看，SESO-RC 的额外消息数量最少；“安全 SOME/IP” 方案因无法广播服务发现消息，额外消息数量最多。因此，当使用某一服务的客户端数量超过 3 个时，“安全 SOME/IP” 方案的消息尺寸开销最大，而 SESO-AS 的开销最小。

7.4.2 CPU 开销

为评估安全扩展方案引入的 CPU 开销，我们在两块 ARMv6 开发板（ARM1176JZF-S 处理器，主频 700MHz）上实现了 SESO-RC、SESO-AS 和 “安全 SOME/IP” 方案，开发板通过 100Mbps 交换机连接，并使用 libsodium作为加密库。

我们通过 Linux 内核的 perf_events 工具统计额外的 CPU 指令数，以此评估加密扩展带来的延迟。测量结果不包含网络传输时间和 SOME/IP 消息解析时间。对于 SESO-RC 和 “安全 SOME/IP” 方案，我们分别评估客户端和服务器端的开销；对于 SESO-AS，还需额外评估授权服务器端的开销。针对三种方案，我们在不同客户端数量下各进行 1000 次测量，计算算术平均值和平均绝对偏差（MAD）以确定测量误差，结果如图 10 所示。

图10、密码学的附加CPU指令

SESO-AS 客户端和服务器的开销极低，无论客户端数量多少，指令数分别仅为 7032（MAD：13.1）和 9182（MAD：225.2）；授权服务器在为 16 个客户端加密广播消息时，最多需 153937 条指令（MAD：3615.6）。不出所料，SESO-AS 的性能优于 SESO-RC——SESO-RC 服务器和客户端分别需 4134880 条（MAD：22059.0）和 4134550 条（MAD：21707.0）额外指令。对比而言，“安全 SOME/IP” 方案客户端的性能更优（2939572 条指令，MAD：15371.1）。与不验证客户端的 “安全 SOME/IP” 方案相比，SESO-RC 服务器因需验证每个客户端的签名，CPU 占用率极高。随着客户端数量增加，SESO-RC 和 “安全 SOME/IP” 方案的 CPU 占用率均显著上升，而 SESO-AS 的 CPU 占用率仅略有增加。此外，由于 “安全 SOME/IP” 方案的服务提供采用单播通信，握手过程还需考虑额外延迟。在已建立的系统中，可使用此前交换的对称密钥验证客户端的新密钥请求，这将显著提升服务器性能。

7.4.3 性能评估总结

在延迟和消息开销方面，SESO-AS 的性能优于其他两种方案，但它也为安全和可靠性带来了单点故障风险；此外，在电子 / 电气（E/E）系统中引入新设备的复杂度更高，因为需更新授权服务器的权限列表，并提前交换密钥。

SESO-RC 通过证书解决了上述问题 —— 证书易于分发，且分布式授权可轻松融入 SOME/IP 协议；而 SESO-AS 需对协议进行小幅修改，使所有服务发现消息发送至授权服务器。两种方案均支持 SOME/IP 的广播服务发现功能，而 “安全 SOME/IP” 方案不支持该功能。

若 ECU 具备足够的处理能力，SESO-RC 是最优选择，因为它不存在单点故障风险，具备前向保密性，且通过证书可便捷、安全地分发密钥和权限。对于低性能设备，可通过硬件加密加速器提升性能，以支持非对称加密技术，但这会增加额外成本；或者，也可选择 SESO-AS 方案，但需重点保护授权服务器，因为它对整个网络的安全至关重要。

三种方案均能防范本文提出的中间人攻击；此外，SESO-RC 和 SESO-AS 还能在客户端与服务器之间建立独立的安全通道，并为订阅提供安全的广播通道。

我们使用 Tamarin 定理证明器对 SOME/IP 进行形式化分析，发现即便结合链路层安全机制，SOME/IP 仍存在三种中间人攻击风险：针对服务提供的模仿攻击和解关联攻击，可使攻击者在请求 / 响应通信中获取中间人位置；第三种攻击结合前两种攻击，可在发布 / 订阅通信中实施中间人攻击。我们通过实现与评估验证了这些攻击对两种实际 SOME/IP 库的有效性：在使用 vsomeip 的请求 / 响应通信中，解关联攻击的效果最佳，几乎所有消息均被劫持到中间人路径；在使用 vsomeip 的发布 / 订阅通信中，结合模仿攻击可劫持超过 2/3 的消息，结合经小幅调整的解关联攻击可劫持客户端接收的所有消息（但会丢失部分服务器事件消息）；在使用 CANoe 的场景中，两种攻击在请求 / 响应和发布 / 订阅通信中均能成功（尽管在发布 / 订阅场景下，正常服务器仍会向客户端发送消息）。

为防范这些攻击，我们提出并分析了 SESO-RC 和 SESO-AS 两种安全扩展方案。Tamarin 分析验证了方案的安全性，实际实现验证了方案的可行性。SESO-RC 适用于 ECU 具备足够非对称加密处理能力的场景，与相关工作不同，它仍支持服务发现的广播通信；若 ECU 的资源受限，SESO-AS 是可行选择（仅采用高效对称加密技术），但需额外部署授权服务器。