JürgenDobaj，DamjanEkert，JakubStolfa，SvatoplukStolfa，GeorgMacher，RichardMessnarz2024-07-08
摘要
网络安全已成为汽车行业的一个关键挑战。在现阶段，ISO/SAE21434描述的框架不足以导出供应商级别安全汽车网络嵌入式系统设计的具体方法。本文介绍了一个案例研究，其中包含设计安全系统的可操作步骤，并系统地提出了可追溯的网络安全需求，以弥补这一差距。该案例研究与ISO/SAE21434标准相一致，可为将网络安全工程集成到公司特定流程和实践规范中提供基础。
01.简介
车辆正在从孤立的、主要是电子机械系统变为带轮子的互联计算机。这一趋势是由汽车行业希望提供创新的移动服务以及向部分和完全自动化车辆的进一步发展所驱动。这些目标很可能只有通过合作和自动化车辆才能实现。然而，为了实现安全、自动化和互动的车辆，需要进一步改进网络安全。
最近的评估和披露表明，在当前车辆中几乎所有连接元素都存在多个漏洞，以下例子可以说明这一点：如今，汽车制造商充当本地互联网注册机构(LIR)并维护IP地址、证书和证书管理系统集群，以确保车队中的车辆能安全远程访问外部基础设施和服务。为此，现代车辆使用基于Linux的网关服务器来实现对外部服务的远程访问。每辆车的网关服务器在生产线末端(EOL)生产过程中都配置有单独的密钥材料和证书。除了网关服务器，车辆还提供各种其他协议来访问车载功能，例如车载诊断(OBD)接口和服务、WLAN、蓝牙和专用Vehicle2X通信协议。这些连接功能扩大了现代车辆的攻击面，使它们容易受到外部攻击。
图1：针对联网车辆的多层远程网络安全攻击示例
图1展示了一次成功对市场上出售的车辆上进行的的远程网络安全攻击。在这种多层攻击中，通过利用远程接口中的漏洞来获得车辆车载功能的访问权限，最终导致不必要的车辆转向。所描述的攻击包括以下步骤：
1）信息泄露：在第一步中，攻击者使用相同型号的车型进行攻击准备。通过OBD接口嗅探车辆总线消息，攻击者可以了解总线通信的细节（即消息目录的部分内容）。此外，还可以识别车辆制造商使用的IP地址集群。为了进行后续攻击，通过嗅探目标车辆与车主智能手机之间的通信，可以获得受攻击车辆的具体IP地址。
2）权限提升：在下一步中，利用Linux网关防火墙的已知漏洞来获取root权限，从而使攻击者能够访问车辆的内部网络。在此阶段，可以使用网关从远程设备向车辆内部网络发送恶意命令，并在网关上部署恶意软件。
3）仿冒攻击：在最后一步中，通过执行先前部署在网关上的脚本对车辆进行攻击。该脚本向车辆内部网络发送包含恶意但适当组装的转向控制命令和车速信息的消息。消息结构在第一步攻击中被识别，并且现在用于所谓的仿冒攻击，以模拟其他总线参与者的行为/消息。在具体示例中，模拟的车速信息（即车辆以低于5km/h的速度行驶）欺骗了转向控制单元（SCU）接受来自停车辅助控制单元（PACU）的转向命令，即使在高速行驶的情况下。最后，使攻击者能够远程操控车辆。
1.1问题陈述
如今，只有少数网关服务器开发公司与原始设备制造商（OEM）密切合作，共同设计车辆的电气/电子（E/E）架构和车队安全服务架构（SSA）。因此，大多数汽车开发仍然与交付电子控制的网络嵌入式车辆功能有关，这些功能实现了例如车辆转向、加速和制动等。
这些功能需要以安全的方式集成到SSA和E/E架构中，以缓解新出现的安全威胁。因此，网络安全正成为汽车工业成功的基石，与可靠性和安全性并列。这一事实反映在最近的网络安全法规中，这些法规要求在将车型引入市场时提供网络安全证明（即联合国欧洲经济委员会（UNECE）批准，特别是UNECEWP.29/R155和UNECEWP.29/R.156）。
在这方面，汽车行业已经利用其他行业的经验，在发展和实施安全连接车辆方面取得了进展。然而，该行业仍面临几个特定的挑战。因此，迫切需要制定行业标准，以解决网络安全工程的问题，保护现代互联车辆和移动基础设施免受网络攻击。
虽然这些标准没有提供关于网络安全开发和实施的细节，但它们提供了一个提供一般指导的框架。而道路车辆网络安全工程标准ISO/SAE21434是在认识到网络安全过程活动的大部分缺乏成熟的最新技术的基础上制定的。因此，标准中只能给出一个框架。这个框架未来需要补充完善，以提供具体指导，建立一个安全的开发过程。
1.2目的
本文旨在提出与汽车领域标准和适用于电子控制网络车辆功能安全设计的法规相一致的可操作步骤和方法。这些步骤应补充这些标准，并为工程师提供有关开发安全车辆功能的实用指导。本工作的重点是工程方面，包括风险驱动的系统设计和系统性的引出需求，以解决汽车开发工作流程不同阶段识别出的网络安全风险。涉及的工作流程步骤包括系统和架构设计阶段、硬件/软件设计阶段以及硬件/软件详细设计阶段，如图2所示。案例研究旨在展示如何应用安全驱动的分析方法来创建必要的证据（即工作产品），以引出由坚实的基于证据的和标准一致的论证支持的网络安全需求。
图2：网络安全开发工作流程和支持工作产品
1.3案例研究
该案例研究聚焦于负责控制车辆转向的转向控制单元(SCU)的开发。在图3中，SCU被突出显示，该图例说明了典型汽车一级供应商项目的范围，该项目针对特定车辆功能的开发。从安全角度来看，SCU应被设计为安全地集成到给定的E/E架构中。
图3：典型供应商集成到安全服务架构(SSA)中
将不同的网络域进行清晰划分，为防御网络攻击提供了额外的防护层。这也允许使用已经建立的汽车开发流程和工具，来工程化安全关键的电子控制车辆功能。然而，在汽车领域内，尚无确立的最佳实践指南或安全工程流程与安全系统设计。因此，汽车供应商必须调整其开发生命周期，以将网络安全工程方面集成到其流程环境中。
在本工作的剩余部分，将描述提出的安全驱动工程步骤和方法，以进行此类适应。这些步骤和方法符合ISO/SAE21434标准。该标准要求的主要规范活动包括项目定义以及威胁分析和风险评估（TARA）。
图4：转向控制单元（SCU）的项目定义
案例研究的示例基于两个并联运行的三相电机，每个电机都安装在转向架上。两个主/从处理单元用于控制三相电机，这两个单元都根据ASILD（汽车安全完整性级别）的约束进行开发。这些处理单元连接到车辆总线，用于与其他ECU交换信息。给定项目定义中的网络安全关键系统资产标记为Axx，并被分组。呈现的系统架构旨在满足现代高度自动化车辆的安全和故障运行要求。
02.系统级网络安全工程
2.1TARA准备
简而言之，在进行TARA之前，首先应使用（半）结构化方法（a）至（d）来识别系统资产。下面解释这些方法的结果。
图5显示了通过网络安全项定义、关键功能分析和技术栈分析识别的资产摘录。得出的系统级资产清单包括，例如接口、固件、配置数据、加密密钥材料、功能块、传感器和执行器等。资产分析是后续TARA的主要输入。
图5：资产清单摘录
图6：转向控制系统0级威胁模型
表1：STRIDE威胁及其受影响的安全属性
2.2TARA执行
图7显示了资产描述的摘录、适用于资产的STRIDE威胁以及特定威胁场景的描述。对于每项资产，可能适用多种STRIDE威胁。合理的威胁场景应从系统级威胁模型中得出，并针对每个适用的威胁进行描述。
在图7所示的特定示例中，ADAS域控制器通过车辆总线传输的转向角请求描述了要分析的资产。该资产在图6中建模为数据流元素，是资产组A01的一部分。根据STRIDE方法，以下三种威胁适用于数据流（即要分析的资产）：篡改、信息泄露和拒绝服务(TID)。图7描述了两种威胁场景，一种用于篡改威胁，另一种用于信息泄露威胁。一般来说，威胁场景描述不应包含预期攻击的（技术）细节。相反，威胁场景应是对预期威胁的高级描述，应使用创建的威胁模型检查其合理性。
图7：威胁场景描述
图8：影响分析的潜在损害场景描述
图9：损坏场景影响级别的分类
图10：潜在损害场景与威胁场景的链接
除了影响等级外，还应估计成功攻击的可能性，这由威胁级别（TL）评级表示。该评级基于以下四个参数的估计：(a)攻击者所需的专业知识，(b)攻击者对目标系统的知识，(c)给定的发动攻击的机会窗口，以及(d)发起攻击所需的设备和工具。系统级威胁模型应作为支持工具，用于估计和证明威胁等级分类。
图11：威胁级别评级的分类以及由此产生的安全级别
03.网络安全需求获取和可追溯性
图12举例说明了链接/可追溯性模型。该模型显示了系统分析期间创建的工作产品与从分析结果（即工作产品）衍生的需求之间的追溯链接。绿色圆圈中的数字表示网络安全工程工作流程步骤。红线表示步骤之间的链接和可追溯性标识符。前四个步骤在第2节中进行说明。其余步骤将在下面进行说明。在此之前，给出了需求提出工作流程步骤的总结：
1）应使用头脑风暴和系统建模来识别资产，如第2.1节所述。
3）网络安全目标应源自TARA（即步骤1和2），如第2.2节所述。
4）应从网络安全目标和客户的需求规范中衍生客户网络安全需求，如第3节所述。
5）网络安全客户需求应细化/转化为（技术）网络安全系统需求。
6）应识别影响系统网络安全的硬件/软件功能（例如，从总线发送/接收数据、加密算法）。这些功能随后被称为安全关键功能（SCF）。
7）每个功能的目的是处理信息/数据。假设SCF处理的信息/数据影响系统网络安全，例如加密材料、配置数据和总线消息。在这种情况下，该信息/数据应被视为安全关键数据/信息(SCD)并链接到正在处理SCD的SCF。
9）应将网络安全目标分配给SCF和SCD元素。通过将分配的网络安全目标，与由TARA过程中识别的网络安全目标确定的SUD网络安全属性进行比较，可以用于识别系统及其设计中的弱点。识别的弱点应推动系统设计的改进和硬件/软件需求的提出。
11）攻击模式描述了已知网络安全攻击中使用的策略和技术。这些攻击模式可用于支持适当设计模式和缓解技术的衍生，以防止已知攻击。
12）网络安全设计模式和攻击模式，可用于基于针对SUD及其实施的缓解技术的已知攻击和漏洞的系统性安全测试衍生。
图12：链接/可追溯性模型，包括网络安全需求和网络安全分析的工作产品
在给出的示例中，ADAS转向角请求被归类为高风险资产。定义高级安全目标SecG_01来应对这一风险。接下来，安全目标被分解为两个客户需求及其对应的系统需求Sys_01和Sys_02。按照工作流程步骤7至10，接下来应识别SCF和SCD元素。SCF和SCD元素旨在支持系统分析和需求获取过程。因此，这些元素不一定是描述特定机制实现的需求。相反，这些元素也可以是高级概念、功能、技术和信息，可用于构建设计决策的结构化论证。基于此类论证，应开发（详细的）硬件/软件设计，并得出相应的需求，即步骤9和10。这些步骤将在以下段落中更明确地解释。
表2指出从车辆总线读取消息被识别为安全关键功能SCF_01。为了满足Sys_01，必须以安全的方式认证关键车辆总线消息，这导致定义了软件需求SW_Req_01，即应使用标准AUTOSAR接口进行消息认证。此外，还定义了硬件需求一和二，以确保在硬件级别上适当支持加密算法（例如，安全消息认证算法）的实现。
采用类似的方法来衍生出实施系统需求Sys_02的硬件/软件需求，该需求规定车辆总线消息应安全地记录，以确保不可否认性（即SCF_02）。为此，每个车辆总线消息（即SCD_01）被嵌入到日志条目中（即SCD_02），应写入内存中的先进先出（FIFO）队列（即SW_Req_02）。这个FIFO队列只应在每次系统关闭时存储到安全闪存中，以防止由于频繁使用而导致闪存的损坏（即SW_Req_03）。为了确保即使在恶劣条件下（例如断电），FIFO队列的内容也被写入闪存，硬件安全模块（HSM）应提供加速写入闪存的硬件支持（即HW_Req_03）。
为了识别设计弱点（即步骤9），首先应识别当前系统设计提供的网络安全属性，并将其分配给SCF和SCD元素。建议使用系统和威胁模型来识别这些属性。其次，网络安全目标（即所需的系统网络安全属性）应分配给SCF和SCD要素。比较分配的所需和提供的属性，以识别系统设计中的差距/弱点。
综上所述，通过选择合适的安全设计模式和缓解机制，可以提高SUD的安全性。此外，这些模式可以支持以结构化和可追溯的方式引导合适的的硬件/软件安全需求和安全测试场景的提出（参见图12）。
表3：适用于各个系统级别的安全设计模式和安全控制示例
04.硬件和软件网络安全前景
上一节讨论了系统网络安全系统和需求工程的流程，其中包括衍生适当的网络安全控制措施以满足特定的网络安全目标。本节简要讨论如何将网络安全控制（例如表3中提供的控制措施）整合到通常用于汽车嵌入式系统的典型AUTOSAR的基础系统栈中。
图13显示了这样的系统堆栈，它被结构化为多个层次。底层由用于代码执行、数据存储和连接的硬件元件组成。硬件安全模块（HSM）也位于此层。HSM提供硬件支持用于安全地存储和访问私钥材料，这对于充分实现各种高级安全控制至关重要。此外，HSM还可能提供硬件加速的加密算法，即使需要对毫秒和亚毫秒范围内安全保护循环通信，也能满足汽车网络系统的严格实时要求。
图13：基于AUTOSAR的分层硬件/软件堆栈
与其他硬件组件一样，HSM可以通过位于微控制器抽象层(MCAL)的驱动程序集成到软件堆栈中。在图13中，该驱动程序表示为虚拟HSM(vHSM)。假设没有专用的硬件HSM，HSM功能可以通过软件模拟。因此，vHSM可以将服务请求转发到位于复杂驱动程序层的基于软件的HSM实现。值得注意的是，基于软件的HSM方法不如使用专用HSM安全。
应用程序（例如app1）可以通过运行时环境(RTE)层访问HSM的专用加密服务，RTE指定了与加密服务管理器（CSM）的接口。RTE将应用程序的服务请求转发到位于AUTOSAR核心操作系统(OS)层的系统服务和CSM。除了通过RTE直接访问HSM之外，还可以配置位于AUTOSAROS层的通信服务，以管理HSM服务的使用，以建立安全的车载通信(SecOC)会话。在这种情况下，SecOC服务被配置为检查和确保特定消息的真实性，使基于HSM的安全机制对应用层透明。
除了HSM之外，还利用几个其他组件和安全控制来确保系统安全。例如，实施安全启动过程应确保整个软件系统的完整性，包括系统固件和持久数据。为此目的，在EoL生产过程中可以建立所谓的信任锚（另请参见第1节），例如通过将主引导程序的公钥哈希(PKH)存储在微控制器的OTP熔丝内。每次系统启动时，微控制器首先使用PKH来验证引导加载程序的完整性。只有在可以验证引导加载程序的完整性（即引导程序未被篡改）时，引导过程才会继续。在随后的启动阶段，可以通过检查固件和数据的签名的有效性来验证它们，例如使用EoL生产过程中存储在HSM内的密钥材料。
05.结论
目前，将网络安全集成到汽车行业的开发流程中仍处于早期阶段，尚无普遍接受的最新技术。ISO/SAE21434标准是朝这个方向迈出的重要一步。然而，在现阶段，ISO/SAE21434仅提供了关于如何设计此类开发流程的粗略指导。因此，本文旨在提供可操作的步骤和方法，帮助工程师将安全系统设计技术和系统性网络安全需求提出方法集成到他们已建立的开发流程中。本工作使用案例研究来演示在电动助力转向系统示例中应用所提出的步骤和方法。所呈现的案例研究和工作流程是根据实际专家知识和前期研究结果结合汽车系统工程领域的需求而衍生出来的。我们未来的工作包括在更多项目中验证和完善所呈现的方法，并将结果和见解反馈给不同的标准化工作组中。此外，我们旨在开发一个通用的安全驱动开发生命周期模型，用于当前和未来汽车电子系统和架构的开发。