2021年08月24日 | 如何将硬件安全模块功能直接集成到车辆的安全概念中？

网络安全与功能安全的智能联合

在带有嵌入式硬件安全模块的 CPU 上运行的安全堆栈如今被认为是汽车网络安全的核心。 因此，它们也是车辆功能安全的关键先决条件。 在最坏的情况下，针对网络攻击的安全保护不足的车辆系统最终可能会导致危及生命的情况。 ESCRYPT 解释了为什么最好将硬件安全模块及其安全功能直接集成到车辆的安全概念中。

基于硬件安全模块 （HSM） 的微控制器和微处理器是当今许多汽车 ECU 的最先进技术。带有硬件安全模块的芯片现在被广泛使用，特别是在车辆的众多安全关键部件中，例如安全气囊、电池管理系统、转向系统和制动系统。因此，HSM 固件是功能安全的车辆系统的核心组件。

作为单独的硬件组件连接到主机控制器，HSM 包括自己的处理器、加密功能以及用于硬件安全固件和安全数据的专用存储器。HSM 固件为硬件添加了额外的安全功能，将这些功能捆绑到复杂的安全协议中，以支持专用的 OEM。即使在多核环境中，底层抢占式实时操作系统也能确保优化的、优先级驱动的资源利用率。所有功能都通过 API 接口提供给主机应用程序，从而确保 HSM 堆栈可以轻松集成到引导加载程序或任何 Autosar 堆栈中——使用“复杂驱动程序”或通过 Autosar 加密驱动程序，随附HSM 固件，如图 1。HSM 核心和软件构成了车辆系统的信任锚。硬件安全模块成为系统可用于检查真实性和完整性的一种基准，例如验证车载网络内的软件更新或消息（安全车载通信，SecOC）。

HSM 的功能安全

虽然当今大多数汽车微控制器和微处理器都配备了此类硬件安全模块，但实际上这些 HSM 中为功能安全而设计的很少。尽管硬件设计在很大程度上是在质量管理流程的基础上进行的，但这很少是涵盖可能的系统故障的符合 ISO-26262 的流程 ［1］。即使在过程符合 ISO-26262 的情况下，HSM 中也没有针对偶发性故障实施单独的保护，例如以硬件冗余或附加检查器功能的形式。这似乎令人惊讶，但考虑到通常没有直接分配给 HSM 本身的安全目标，这是完全有道理的。

由于上述硬件情况，HSM 固件的通用功能安全方法不是有用的解决方案。相反，需要深入考虑个别用例。HSM 包含在许多与安全相关的 ECU 中，在应用范围内用于各种功能，包括防止操纵、初始化、软件更新、诊断、车载通信和许多其他功能。因此，需要在 HSM 中进行特定于案例的实现。

安全与干扰共存

HSM 的典型用途是在集成环境中，它与执行安全相关功能的软件解决方案共存，分配的安全目标高达 ASIL D。因此，根据ISO 26262实现无干扰非常重要。这里通常的方法是使用芯片上可用的硬件功能来保护主机驱动程序和来自那些执行安全关键功能的软件模块的共享资源，例如通过使用专用保护机制或内存保护单元 （MPU） 。

然而，这种影响深远的基于硬件的划分对系统来说不一定有用，因为在相互保护的两个不同域之间交换数据和切换任务将不可避免地降低性能，潜在地导致的瓶颈会与其他运行时的要求产生冲突。更重要的是，这种硬件机制甚至可能不适用于为优化整体系统成本而选择的低成本设备。

HSM 固件作为上下文之外的安全元素

合格的 HSM 固件提供了针对此问题的优雅解决方案，该固件包括根据 ISO 26262 中指定的 ASIL 要求开发的主机驱动程序。这将允许 HSM 轻松集成到车辆 ECU 中，无需分区或内存保护，因此不会影响性能，如图 2。

基于 HSM 本身不会在硬件方面执行任何安全相关功能的假设，并考虑到上下文中固件最终将被多方面且未知地使用，它被设计为上下文之外的安全元素（ SEooC） ［1］。与此同时，必须在系统层面采取措施确保固件安全集成，换句话说，以可靠的方式防止硬件安全模块与其安全相关功能的主机内核之间的干扰。理想情况下，应为 HSM 固件提供专门的安全手册，其中包含关于如何在集成 SEooC 时确保不受干扰的说明。

使用安全的CMAC降低风险

一般来说，需要进行彻底的安全分析，以识别系统中的威胁和漏洞，并设计适当的对策。通过将网络安全方面纳入功能安全评估，可以从功能安全的角度进行知情风险评估，并据此确定安全完整性水平（SIL），如图3。但是，上述无干扰共存可能不会，对于某些系统设计和特定功能，即网络安全机制中的故障产生安全关键的影响［2］。例如，如果ECU之间交换的车载通信消息和信号与安全相关，则会出现这种情况。如果此类信息已损坏但仍被转发，则可能导致具有严重后果的危险情况，例如错误的制动信号或错误的转向角。

因此，Autosar为交换安全相关数据指定了端到端（E2E）保护。E2E概念在运行期间检测并处理通信网络中硬件和软件端的故障。因此，该概念适用于ASIL D之前的安全兼容通信。然而，与此同时，还有一些新的、更智能的系统设计实现方法，它们补充了E2E方法，同时设法避免其造成的开销。其中一种新颖的补充方法是安全CMAC，它使用基于密码的消息认证码（CMAC）保护安全关键消息。

满足ASIL D的基于HSM的安全机制

事实上，车内网络中的每条消息通常都包含一个CMAC，该CMAC被路由到硬件安全模块以验证消息的真实性。然而，同样的是这种MAC身份验证也可以用作检测损坏消息的功能安全措施。然而，HSM中的单点故障，例如随机HSM硬件故障，可能导致违反ASIL D规定的ECU安全目标，即避免转发非真实消息的要求。

因此，对于HSM，有必要定义一个额外的安全要求，即不验证任何虚假MAC是否正确；这适用于所有安全相关信息，无论有多少。根据使用情况，安全相关消息的数量将从每个驱动循环的单个消息和软件更新到100%的消息不等。另一方面，如果对所有消息（包括非安全相关消息）实施基于HSM的此类安全机制，这只会导致不必要的开销。因此，特定于用例的实施概念再次需要智能HSM固件，该固件提供了多个选项，用于在需要时集成基于CMAC的车辆系统功能安全。

可能的安全机制之一是基于应用程序启动的错误MAC自检。系统集成商必须确保执行和评估测试本身以及进入安全状态所需的时间满足要求的故障处理时间间隔（FHTI），即故障检测时间间隔（FDTI）和故障反应时间间隔（FRTI）的总和。此解决方案最多可用于ASIL B。另一种安全机制基于循环冗余校验（CRC），并应用于每个与安全相关的MAC验证。集成到HSM固件的性能优化批量CMAC接口中，可最大限度地减少因附加CRC计算和比较功能而导致的目标与时间的权衡，尤其是在设备硬件支持CRC的情况下。此解决方案最多可用于ASIL D。

关键系统功能安全的工具化

智能的成本和性能优化安全概念可以将功能安全目标委托给硬件安全模块。与其采取一般方法，不如对照整个系统的安全目标检查每个单独的用例，以得出硬件安全模块的特定功能安全要求。这方面的基本先决条件是具有相应功能安全包的适当复杂的HSM固件，该软件包可以涵盖ASIL D之前的用例，具体取决于每个用例中的目标和上下文。但是，这必须始终符合以下条件：HSM中定义的安全措施与主机侧的适当功能安全措施相伴随。

最新一代设备中使用的硬件已经具有增强的安全机制和性能。尽管如此，对提供更高性能的成本优化系统设计的需求仍然存在。在这方面，一个开创性的解决方案似乎是将网络安全机制工具化通过使用智能HSM固件实现硬件安全模块的安全性，以确保关键车内系统的功能安全。