汽车诊断系统信息安全TARA分析及测试评价研究

作 者 | 刘煜

出 品 | 汽车电子与软件

前 言

随着我国车辆的智能化、信息化发展，信息安全的理念在汽车研发生产中的地位越来越重要，为解决目前行业诊断系统中零部件诊断信息安全开发缺少参考依据的现状，满足R155/ISO 21434法规要求，本文开展诊断功能组信息安全TARA分析及测试评价研究。此方法论从功能清单及网络安全相关性确认、诊断功能组TARA分析、网络安全概念设计开展汽车诊断系统信息安全研究，并设计汽车诊断系统测试评价标准和问题等级，通过对黄板车某域控制器进行诊断信息安全测试，测试结果可识别此控制器对于诊断系统信息安全的满足程度。研究结果显示，此方法论可以识别诊断功能组的潜在信息安全风险点，基于风险点进行安全目标设计，并可设计网络安全需求用以指导零部件的诊断信息安全开发。

01

汽车诊断系统TARA分析拓扑设计

1.1 VTA车型整体方案介绍

OEM厂在VTA认证前需通过CSMS体系认证，表征OEM厂具备信息安全开发的管理流程体系，第二阶段为满足车型研发阶段R155/ISO 21434法规适应性，需通过VTA车型认证。VTA认证整体方案设计如图1所示。

• 整车概念阶段，梳理功能场景清单；

• 系统设计阶段，包括各功能组的威胁及风险分析、安全目标和安全需求设计

• 零部件设计阶段，提出安全控制要求

• 零部件开发阶段，开发零部件的网络安全开发

• 零部件试验阶段，对零部件开展零部件安全测试

• 系统试验阶段，对整车各功能组开展系统安全测试

• 整车试验阶段，对整车开展整车安全测试

图1 VTA车型整体方案设计图

1.2 汽车诊断系统TARA分析拓扑图设计

本文主要基于VTA认证中对整车诊断功能组进行威胁及风险分析，进行网络安全及网络需求分析，指导零部件诊断功能信息安全开发及测试验证，其汽车诊断系统TARA分析拓扑如图2所示。其中：

• 功能组功能清单及网络安全相关性识别确认是诊断功能组TARA分析阶段的前提，用以确认功能组的功能以及是否与网络安全相关。

• 诊断功能组TARA报告分析是本文讨论的重点，包括诊断功能组网络拓扑设计、确定安全资产类别及安全资产属性、危害场景识别、危害程度评估、威胁分析、风险评估及处置、定义安全目标。

• 网络安全设计是根据诊断功能组TARA报告分析的结果，结合安全目标及攻击树进行标准索引、分析威胁及缓解措施、定义网络安全需求。

至此，诊断功能组的网络安全概念设计完成，可用于指导零部件进行诊断功能的信息安全开发。

图2 汽车诊断系统TARA分析拓扑图

02

模型设计

2.1 功能清单及网络安全相关性确认

诊断功能组TARA分析之前需进行功能组功能清单及网络安全相关性确认。依据功能模块按等级进行三级功能划分，定义诊断功能组下属的子功能集，结合整车TARA分析数据流中关于诊断功能组的数据流图确定数据流走向，并根据网络安全相关性识别判断确定是否需要进行TARA分析，进入第二阶段诊断功能组TARA分析阶段。

此阶段识别出诊断功能组的功能类可分为诊断、标定、本地烧写，且依据网络安全相关性识别，均与网络安全相关。

2.2 诊断功能组TARA分析

诊断功能组TARA分析为本文讨论的主要阶段，此阶段主要完成诊断功能组TARA报告的出具，包括诊断功能组网络拓扑设计、诊断功能系统安全资产和属性设计、危害场景识别、危害程度评估、威胁分析、风险评估及处置、定义安全目标。

2.2.1 诊断功能组网络拓扑设计

本步骤依据车型网络拓扑图进行诊断功能相关的数据流图的设计，重点突出车型相关核心零部件（此处指与安全和动力相关的控制器）与诊断仪或者其他诊断设备进行诊断数据交换的途径（即OBD-II接口），其次也可以在诊断数据流图中体现其他可能具有攻击性的外部接口（如Bluetooth，WIFI，Cellular，RF，USB等）。

根据法规要求，现代汽车需安装OBD-II接口来进行汽车排放信息的采集，主机厂也会通过该接口进行诊断、标定以及本地刷写等操作。因其是唯一直连汽车整车网络的接口，故多数诊断相关信息安全威胁都与OBD-II接口有着密切的联系。故可以得出在整车层面诊断功能组相关网络安全功能分为诊断、标定与本地刷写。

通过上述分析，可得出车型的诊断数据流图以及相关网络安全功能，接下来进行网络安全相关性的判断，如图3所示，其中：

• 是否基于电子电器？主要判断该功能的实现是否需要电子电器（ECU）的参与，如果与电子电器（ECU）无关则可以直接得出该功能与网络安全无关。

• 是否与车辆的安全操作相关？主要判断该功能相关零部件是否有安全相关，如运动控制模块和具有汽车安全完整性（ASIL）等级的零部件。

• 实现的功能是否需要收集和处理用户相关的数据？主要判断是否与隐私相关。

• 事项是否基于联网部件实现的车辆功能？主要判断是否与网络相关，此处特指汽车总线，如CAN、MOST、Flexray以及汽车以太网等总线。

图3 网络安全相关性判断

2.2.2 诊断功能系统安全资产和属性设计

本步骤整理诊断功能相关的零部件并将其作为安全资产，并对该安全资产进行安全资产类别与安全资产属性的分析。

2.2.2.1 安全资产类别

通过车型架构分析，可以将安全资产类别分为以下几部分：

• 身份与配置信息：整车或者零部件的标识或者配置信息。

• 固件及应用：零部件的固件以及第三方应用程序。

• 数据：指在车辆行驶中，产生、收集和记录的信息；

• 通信信息：指在车辆网络中传输的信息。

将诊断功能相关的零部件进行安全资产的分析，并对各零部件的资产类别进一步细分和归类，例如身份与配置信息可以细分为身份信息和配置信息，车辆VIN号为整车的身份信息会存储在零部件中，VIN号属于身份信息，依据上述分析完成后得出得到网络安全资产属性表。

诊断功能组依据上述四类资产划分，具体分为：

• 身份与配置信息主要包括VIN、诊断ID、软件版本相关信息。

• 固件与应用包括固件和标定数据

• 数据包括诊断记录日志及各控制器的DTC

• 通信信息包括诊断服务命令、系统状态信息

2.2.2.2 安全资产属性

基于ISO-21434和SAE-J3061，安全资产的网络安全属性有如下主要类别：

• 机密性（Confidentiality）：信息不被泄漏给非授权的用户、实体或进程，或被其利用的特性；

• 完整性（Integrity）：信息未经授权不能进行更改的特性，即信息在存储或传输过程中保持不被偶然或蓄意地删除、修改、伪造、乱序、重放、插入等破坏和丢失的特性；

• 可用性（Availability）：信息可被授权实体访问并按需求使用的特性。

对安全资产类别进行分析，得出资产具备何种安全属性，最后由安全资产类别和安全属性得出网络安全资产分布表，用于下列危害场景的识别。

2.2.3 危害场景识别

危害场景的描述需至少包含以下三个要素：功能相关零部件、安全资产和后果。其中后果指安全资产的安全属性受损后导致的最严重的结果，此时无需考虑已有的缓解措施。对所有的安全资产属性的危害场景分析完成后，进行危害场景的评估。

2.2.4 危害程度评估

本步骤进行危害程度的评估使用SFOP模型。通过SFOP模型从Safety安全、Financial财产、Operational使用和Privacy隐私四个维度对危害场景的危害程度进行评估，各影响因素评分依据如表1至表4所示：

危害程度评级由上数4个影响因素评分的总和累加得出，总分为5个等级：

Critical（score>=1000）；

High（100<=score<1000）；

Medium（20<=score<100）；

Low（10<=score<20）；

No impact（score<10）。

这里以一条资产类型进行举例说明，以身份配置信息下的VIN的完整性进行SFOP模型分析，安全维度为微不足道的，财产维度是中等的，使用维度是，隐私维度是微不足道的、SFOP模型综合得分为10分，危害程度评级为Low。

2.2.5 威胁分析

2.2.5.1 威胁分析模型

依据车辆诊断功能架构及其车辆电子电气架构，相关网络安全威胁划分为5层：

• Level 1: 基础攻击（攻击界面），根据系统架构和部件架构，基于网络安全攻击知识和经验搭建构成。

• Level 2: 部件内器件层攻击，根据部件所存在的攻击界面，由基础攻击构成。

• Level 3: 部件层攻击，根据部件设计架构，由部件内器件层攻击构成。

• Level 4: 网络层攻击，根据系统网络拓扑由基础攻击中关于系统相关外部通信攻击构成。

• Level 5: 目标资产攻击，根据系统架构图由网络层攻击和部件层攻击构成。

2.2.5.2 攻击路径分析流程

首先依据前面所识别出的危害场景进行攻击路径的分析，得出从网络层和部件层中存在的攻击路径。实际场景中会存在一些对危害场景的攻击路径不涉及整个零部件，如通过传感器和诊断工具等，这些攻击路径将从部件内器件层直接到系统级攻击，而不会再经过部件层攻击。然后网络层直接到基础攻击，而部件层攻击需要经过部件内器件层攻击再到基础攻击。攻击路径的分析可参照ISO 21434中与威胁相关的漏洞和攻击方式。攻击路径分析可参考CVSS漏洞评估模型，从攻击向量、攻击复杂度、攻击权限、攻击交互进行综合评估，其Feasibility Rating为上述四维度的最终得分，Attack Feasibility等级为该攻击路径的最终的漏洞评估等级。

以身份配置信息下的VIN的完整性举例，通过对控制器1，控制器2，控制器3或车内通信的攻击，篡改VIN码，导致读取VIN码错误，诊断内容出错，此攻击路径经CVSS模型分析，其Feasibility Rating得分为1.44，Attack Feasibility等级为Low。

2.2.6 风险评估及处置

依据诊断功场景分析基于SFOP模型的打分，结合威胁分析基于CVSS模型的打分结果，依据表5进行综合判断诊断能组风险评估及处置。

QM为质量管理，不需要额外的网络安全措施，依据公司现有质量管理体系管理即可。Risk Rate等级依据表6进行风险评估及处置。

以身份配置信息下的VIN的完整性举例，危害程度评级为low、Attack Feasibility等级为Low，最终TARA分析Risk Rate等级为Low，即接受风险。其他资产可参考此列进行分析。

2.2.7 定义安全目标

依据诊断功能组网络安全风险等级,定义诊断功能的网络安全目标.安全目标的设定需考虑从诊断功能组资产的安全资产类别和安全属性类别出发进行。

2.3 网络安全概念设计

结合威胁分析和风险评估及处置，开始诊断功能组网络安全概念设计。此部分需根据TARA报告中Risk Rate等级为Medium及以上的部分进行设计，针对每条安全资产属性下的风险评估，画出每条用例对应的攻击树，结合R155法规中的威胁及缓解措施，列出每条攻击路径下的缓解措施，结合汽车诊断理论综合汇总得出最终的网络安全需求。

03

车型理论验证

依据某车型，开展该车型的诊断功能组信息安全TARA分析研究。

3.1 功能清单及网络安全相关性确认

依据该车型的诊断功能，识别出诊断功能组功能清单，如图4所示。

图4 诊断功能组功能清单

3.2 诊断功能组TARA分析

基于该车型的诊断功能系统信息，梳理该车型诊断功能组网络拓扑结构，根据身份与配置信息、固件及应用、数据、通信信息此4类安全资产，以及机密性、完整性、可用性3类安全属性，进行诊断功能组安全资产及属性划分，部分资产结果如图5所示。

图5 诊断功能组安全资产及安全属性

根据该车型的诊断功能，部分资产对应的危害场景如图6所示。

图6 诊断功能组危害场景及评分

车辆诊断功能安全资产威胁分析部分如图7所示。

图7 诊断功能组威胁分析

依据车辆诊断功能组的威胁分析和危害评估，出具诊断功能组风险评估及处置结果，部分结果如图8所示。

图8 诊断功能组风险评估及处置结果

依据诊断功能组风险评估及处置结果，定义诊断功能组的网络安全目标，部分结果如图9所示。

图9 诊断功能组网络安全目标

3.3 网络安全概念设计

依据安全目标，此部分需根据TARA报告中风险标识为Medium及以上的部分进行设计，针对每条安全资产属性下的风险评估，部分结果如表7所示。每项需求描述针对网络安全目标提出的具体网络安全方案，可指导零部件从硬件、软件维度开展信息安全诊断开发。

04

汽车诊断系统测试验证

4.1 诊断系统测试标准制定

依据诊断系统网络安全需求和ISO-14229对诊断服务的要求，规划诊断系统信息安全技术，并基于企标设计诊断系统信息安全测试用例，其一级目录及二级目录如图10至图11所示。

图10 诊断系统信息安全测试用例一级目录

图11 诊断系统信息安全测试用例二级目录

4.2 汽车诊断系统信息安全测试验证

依据诊断系统网络安全需求及测试标准，在台架对某控制器开展诊断系统信息安全测试，诊断各服务测试通过情况如图12所示。测试结果表明此域控制器的测试通过项36项，失败项11项，通过率为76.6%，测试结果如图13所示。

图12 各服务测试通过情况界面

图13 诊断系统信息安全测试通过率界面

05结 论

本文设计了汽车诊断系统的信息安全开发的TARA分析流程，并结合具体车型开展诊断功能组TARA分析及安全概念设计。研究结果显示，此分析流程可以识别诊断功能组的潜在信息安全风险点，基于风险点进行安全目标设计，并可设计网络安全需求用以指导零部件的诊断信息安全开发，为信息安全相关领域提供了一种信息安全分析思路，为相关研究人员的信息安全研究提供参考依据。

参考文献：

[1] 赵开放. 汽车CAN网络信息安全研究[D]. 华中科技大学, 2019.

[2] 于赫. 网联汽车信息安全问题及CAN总线异常检测技术研究[D]. 2016.

[3] 张铁欣. 基于汽车网关平台功能的网络拓扑设计与安全研究[J]. 汽车电器, 2017(9):22-25.

[4] 吴尚则. 基于车载CAN总线网络的身份认证方法研究[D].吉林大学,2018.

[5] 叶卫明,常贺. 基于智能网联汽车的通信和信息安全研究[J]. 电信工程技术与标准化, 2022.35(1):88-92.

欢迎加入智能交通技术群！扫码进入。

扫描加入免费的「智慧城市之智慧交通」知识星球可了解更多行业资讯和资料。

联系方式：微信号18515441838