内容提要：本文描述了现代车辆中的典型验证和确认方法，以及如何导出和开发此类测试用例。

摘要

新一代汽车拥有多个连接到中央网关的ECU（电子控制单元），需要通过网络安全集成测试才能满足汽车的认证要求。汽车通常有一个Linux网关服务器（少部分有额外的域服务器）和大量的ECU，这些ECU和实时控制执行器（ESP、EPS、ABS等——通常是多核嵌入式控制器）通过汽车专用总线 (CAN-FD) 连接到域控制器或网关服务器。行业规范（SAE J3061、ISO 21434）要求进行网络安全相关的验证和确认。汽车制造商使用一个网络测试套件来验证，该套件可以运行2000多个测试用例，必须通过认证。这些规范会影响汽车通信基础设施的测试方式，以及ECU/汽车上路发布之前应该检查哪些网络安全攻击模式。本文描述了现代车辆中的典型验证和确认方法，以及如何导出和开发此类测试用例。

1.介绍

2021年2月，VDA（德国汽车协会）AK 13发布了用于网络安全评估模型的Automotive SPICE（图1）。用于网络安全认证评估（2022年7月起汽车制造商必须进行）。

图1：ASPICE网络安全评估模型流程

该模型包括新流程

•MAN.7网络安全风险管理（管理、执行和跟踪TARA–网络安全威胁分析和风险分析，并得出网络安全目标）

•SEC.1网络安全要求获取（源自TARA的要求）

•SEC.2网络安全实施（针对风险和威胁设计对策，并实现网络安全目标）

•SEC.3风险处理验证（根据网络安全要求进行验证）

•SEC.4风险处理确认（针对网络安全目标的确认）

并扩展了2个现有流程

•ACQ.2供应商请求和选择（包括招标中的网络安全）

•ACQ.4供应商监控（监控网络安全目标工作产品、要求的实现情况）

本文讨论了如何在SEC.3和SEC.4流程中实施车辆架构中的网络安全测试概念。

2.网络安全测试相关工作产品

在SOQRATES工作组中，一组领先的汽车供应商、大学和培训机构以及欧盟汽车蓝图项目DRIVES制定了预期典型工作产品的概念。图2显示了04至06清单中的典型工作产品。

图2：用于网络安全测试的网络安全相关工作产品04–06

SEC.3风险处理验证：SW单元验证（参见上图2）

04 MISRA和CERT

•网络安全编码规则MISRA C:2012 2016年修正案1和ISO/IEC TS 17961:2013 C-Secure

04 MITRE指导

•网络安全模式（攻击列表和建议的操作）

•04 OWASP

•开放Web应用程序安全项目(owasp.org)，其中介绍了在基于Web的安全环境中进行编程的好坏做法

04代码检查

•审核清单已扩展至包括网络安全相关方面。通常，编码规则会自动检查。然而，网络安全相关的软件部分需要标记，需要独立于正常代码（不受干扰），应用扩展的网络安全相关检查表和规则集。

SEC.3风险处理验证：软件集成/系统集成/网络测试（参见上图2）

05 NTS网络测试套件

•这是一个测试套件，通过总线（LIN、CAN、CAN-FD、以太网）连接到ECU（电子控制单元），并具有用于编写测试用例的可编程接口（例如重放攻击）。自动执行测试并报告网络安全覆盖范围。

•已经拥有先进网络安全架构的高级客户通常需要使用特定的测试套件，并在ECU上运行给定的客户诊断测试。

05网络测试用例类型

•测试用例类型通常由网络安全目标和诊断章节构成

•例如，验证测试

o例如，安全诊断和刷写测试

o例如，测试安全启动

o例如，重放攻击测试

o例如，测试UDS（统一诊断服务）诊断功能并尝试通过未经身份验证的诊断协议功能访问安全部分（通常UDS $27）

o例如，拒绝服务攻击

o例如，报文丢失、在不正确的时间范围内频繁出现等情况下的行为。

05 测试的攻击类型

•必须涵盖所有攻击类型（通常检查MITRE目录并选择适用于正在开发的产品的部分）。

02 典型OEM测试合作

•先进汽车制造商如大众、戴姆勒、宝马等对测试工具和测试程序设置提出了要求：戴姆勒股份公司的NTS网络测试套件、宝马的FAT工具套件、带有CAPL编程测试用例的CANoe以及大众汽车的HIL平台（HIL–硬件在环）等。

SEC.4风险处理确认：软件和系统测试（参见上图2）

06 网络安全测试台

•生产中的汽车在生产线末端测试时会收到IP地址以及配置的所有证书和密钥。在测试台中对这些关键更新进行了测试。

•06 渗透测试/测试团队合作

•渗透测试由外部网络安全测试团队完成。该团队不会收到所有内部设计，但会收到有关ECU的网络安全目标和技术数据。

06 整车集成测试

•车辆集成现在需要测试：例如，测试驱动向车辆设置中刷写新钥匙。

• 06 网络安全用例/验证报告

•网络安全经理生成的报告证明100%的网络安全相关要求已测试并通过。

3.验证的网络安全要求

网络安全规范要求执行TARA（威胁分析和风险分析）。ISO 21434规范中描述了TARA属性，TARA提供影响级别、威胁级别和防护级别（风险表的影响和威胁级别）。此外，如果防护级别有安全评级，TARA中的每一行都包括网络安全目标（见图4 TARA的示例摘录）。

在执行TARA之前，会绘制网络安全相关项分析或威胁模型，包括显示系统、所有关键接口和关键数据，并对可能受到攻击的资产进行分组。

请参阅图3中的示例，该示例描述了6相电动机EPS系统。其中一个关键的接口是：可能导致车辆意外转向的转向角度请求。

图4显示了相关TARA的示例线路和所选属性，其中ADAS转向角请求作为关键信号被评为中等威胁级别，并且因为（不可见）影响级别至关重要（因为突然转向几乎总是会导致事故），安全级别为高。

图4中指定的安全目标是“防止由于未经授权的指令而导致不必要的转向，并确保在800毫秒的时间内完成指令的安全记录。

然后，网络安全目标被分解为系统要求（授权和验证指令）、网络安全关键软件功能和网络安全关键软件数据要求。对于关键功能要求，引用了相关的关键数据，定义了该功能处于活动状态的软件状态（白名单），并指定了安全目标（见图5）。

图3：网络安全相关项分析–关键资产和接口

图4：网络安全目标– TARA的结果

图5：网络安全关键功能要求

对于每个网络安全目标，都需要制定相应的对策并进行测试。

图6：网络安全目标/所需属性

继续转向MAC的示例，该MAC将仅用于接受经过身份验证和授权的报文：

MAC（报文验证代码）应提供以下安全属性/目标：

-新鲜度（第二目标）

-身份验证（第二目标）

-信息/有效负载：转向角请求

-诚信（第二目标）

我们可以分配给软件级别分析的算法细节：

-新鲜度：每条报文中添加一个新的随机数

-身份验证：通过共享密钥

-信息/有效负载：转向角请求

-完整性：通过HASH加CRC进行安全纠错

-CAN报文= [h1|转向角请求|CRC]

-p1=[共享密钥|随机数增加|转向角要求]

-h1=HASH[共享密钥|HASH[p1]]

4.集成测试验证策略——网络测试套件方法

图7展示了应用的典型通用测试框架，通常在戴姆勒项目中使用的特定测试环境。

图7：网络测试套件的典型设置

PCAN是研究团队和小公司可以负担得起的工具，您可以在其中使用C/C++甚至Visual Basic编写测试用例。还有一整套功能可以导入DBC文件、嗅探总线以及更改、调整和重放报文。

在车辆中，CAN总线基于J1939规范，其中报文格式已标准化（见图9）。研究旨在创建基于以太网的更安全协议。

CAN FD的结构类似于CAN，并允许灵活的数据(FD)速率。为了向CAN添加网络安全（一开始并非如此），将创建一个网络安全相关报文包，其中包含报文和网络安全相关报文部分，以验证、授权、检查命令/报文（参见图8图10）。

重要的是不要将安全性与支持15位、17位或21位CRC的内置CRC校验和算法（参见图8）混淆。此CRC用于报文的E2E（端到端）验证，该报文一般不会被更改。

添加的SecOC捆绑包是针对攻击者的保护部分（参见图8中的h1）。

图8：网络安全的CAN FD结构和扩展

对于车辆的设计（车辆包含许多通过总线连接的ECU电子控制单元），CAN报文目录根据nom (J1939)指定并由ECU导入。为网络安全而开发的ECU软件通常具有由Autosar>=4.3支持的标准服务架构（见图10），该架构提供管理安全通信（SecOC组件）的服务，连接到硬件安全模块（vHSM和HSM），并允许使用加密、解密、签名、身份验证、散列算法等的功能程序。解密的数据可通过RTE（运行时环境）获得。

图9：没有安全包的报文结构

图9和图10显示了RTE中的典型结果，您可以在其中读取请求的电机扭矩，也可以通过标志读取身份验证是否正常。

图10：集成报文和安全部分的报文包

在测试汽车时，使用集成测试设备（图7和图8），该设备允许更改、重放报文，并观察结果并通过协议读取来自RTE的值。

5.验证测试用例设计

汽车中的测试用例需要链接到相应的需求。在汽车领域，这种对测试用例和测试结果的要求的可追溯性是必须的，以证明在认证车辆时功能是完整的。有不同的规范检查这种可追溯性，例如Automotive SPICE和ASPICE网络安全扩展、功能安全，以及用于证明网络安全案例覆盖范围的ISO 21434等网络安全规范。还要进行评估以检查覆盖范围，以及开发过程是否合规。

由于设置的工具由带有脚本的测试框架支持，因此测试用例通常在数据库中设计，链接到需求和脚本，写入测试结果日志，这些日志可以导入回数据库以提供测试状态。

在SOQRATES中讨论了描述此类测试用例的最佳实践属性，在下面的图11中，您可以找到使用如下属性的示例规范：

•文本案例ID

•相关软件安全要求

•测试用例标题

•测试用例描述/测试步骤

•前提条件、预期结果

•使用的测试用例设计方法

•测试级别

•测试（工具）环境

•网络安全测试级别

•网络安全测试方法/验证标准/测试用例设计模式

图11：网络安全测试用例示例

6.确认的测试用例方法

虽然网络安全验证为测试团队提供了包含许多网络安全相关功能和数据要求的白盒视角，但确认是基于黑盒视角。测试人员知道功能、技术描述和网络安全目标，但他们不知道，例如:渗透测试细节。这用于模拟来自外部的真实攻击者。

此外，进行渗透测试的攻击者团队有一个结构化的测试策略，称为“基于MITRE派生的攻击模式创建对手模拟计划”（图12）。

使用测试规范，工具框架中的编辑器和脚本可以实现：例如：使用错误的报文计数器重新发送报文（这会在重放攻击中发生）。

图12：网络安全攻击流分析

为了准备此类计划，MITRE还要求进行渗透测试的攻击者团队还有一个结构化测试策略，称为“基于MITRE派生的攻击模式创建对手模拟计划”（图12）。

在Mitre.org中，您可以选择攻击导航器功能，为您创建新的层模型，然后开始规划。这可能会产生图13中描述的策略。

图13：使用MITRE Attack Navigator进行网络安全攻击流分析

MITRE基于ICT行业中观察到的攻击模式集合，因此车辆测试人员需要将提议的ICT策略调整为基于车辆的策略。这会产生如图14所示的攻击策略。

这种渗透测试结构化方法，基于源自MITRE的知识并适配汽车泛目标假设。

图14：攻击策略表示例

然后根据这些攻击流/场景对渗透测试用例进行分组。

7.结论

现代汽车有一个带有IP地址的网关服务器，并连接到网络，服务器/网关可能会受到攻击。汽车未来将扩展到电子城市、电子环境，构建互联社会。

ISO 21434等网络安全规范和UNECE法律中的汽车法律法规要求涵盖网络安全规范和要求，并通过网络安全验证和确认来证明这一点。

用于网络安全的ASPICE于2021年2月发布，其中包含用于网络安全验证和网络安全确认的流程。

本文描述了网络安全车辆中的测试策略是如何实施的，以及如何将其应用到车辆架构网络安全上。

会议更多信息及洽谈，详询“牛小喀”微信：NewCarRen

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！