硬件安全模块如何启用AUTOSAR

How hardware security modules enable AUTOSAR

越来越复杂的软件和车内连接需要越来越多的加密保护。这种保护也必须由经典的实时AUTOSAR系统来实现。硬件安全模块（HSM）具有合适的固件，即使在资源不足的情况下，也能保证系统的加密。

汽车电子控制单元（ecu）的连通度多年来一直在提高，控制单元之间相互连接，也与外界相连。然而，随着越来越复杂的软件面临新的需求，对通信的需求也在不断增加。从安全角度来看，这意味着从孤立的单一系统到高度连接的节点的转变。因此，安全和防范外部威胁的重要性日益增加。除其外，这种保护可以通过增加强加密技术的使用来实现，乍一看，这在经典的实时系统中并不容易。过去，只有在特殊操作模式下，如维修车间的ECU软件更新，才需要加密。

现在，即使在常规运行时，也必须有效地可用：例如，验证通信伙伴和通信内容并防止截获。适当的实现必须允许实时需求。乍一看，这与密码方法的计算时间要求相矛盾。硬件安全模块（HSM）用于解决此问题。允许在单独的处理器上计算密码。然而，需要一个优化的实现来充分发挥潜力。

Automotive real time

对车内实时性的要求通常来自于所谓的效应链。分析了在处理从传感器输入脉冲到相关执行器期望输出脉冲的过程中，涉及的硬件或软件组件以及顺序。整个链条的最长可接受运行时间可由传感器和执行器的物理条件得出。然后可以将其分解为单个组件的允许最大运行时间。根据使用情况，范围从10µs到100 ms。如果超过了允许的最大运行时间，这可能会降低便利性并导致噪音等。对于需要实时功能的安全相关功能，这甚至可能导致生命和肢体受伤的风险。

为了满足和实现软件的实时性要求，AUTOSAR操作系统将相关软件功能划分为子步骤，即所谓的任务。任务由外部事件激活，即标记为可运行，然后根据优先级进行处理。对于大多数应用，使用带有循环激活表的计时器来激活任务，因为相关的控制功能将持续处理新的信号生成。这将导致默认的时间响应，该响应在几十毫秒的周期内重复。需要几个步骤来确保满足实时性要求。一方面，在实施信号处理步骤时，适当的措施当然必须确保能够提供所需的时间响应。另一方面，ECU中与时间相关的任务激活必须能够实现时间要求。为此，必须分析所有任务的运行时行为，以找到适当的优先级排序和保证时间的按时间顺序的激活顺序。

AUTOSAR basic software

AUTOSAR基本软件

ECU的功能不再仅仅涉及信号处理。处理通信和管理的基本软件是这些功能的重要组成部分。这个基本软件也必须划分为任务，根据其运行时需求进行分析，并在整个系统中加以考虑。简言之，有两种不同的功能集：一部分基本软件，例如用于传输信号值，是实现实时信号处理所必需的。这一部分必须给予适当的高度优先考虑。另一部分的实时性要求明显较低：该部分必须在后台定期运行；但是，可能会被具有更高实时性要求的函数暂时抢占。因此，一种常见的实现模式是将这些非关键功能转移到低优先级的后台任务。在这种情况下，问题是各职能之间的优先次序：一般来说，有多个后台活动，其中任何一个都不能在较长时间内失败。这种优先级排序的解决方案是循环调度，其中每个低优先级函数计算一个短时间，然后是下一个函数。在AUTOSAR术语中，涉及的每个模块都提供了一个所谓的“MainFunction”，运行时间有限。在后台任务中，这些函数按顺序调用。

Security

安全

这种经典的“背景函数”的一个例子是密码算法。自4.0版以来，AUTOSAR包含了加密基础软件的规范—在以后的版本中，对相应的规范进行了修订和微调。在这种情况下，所谓的加密服务管理器（CSM）为应用程序提供加密服务：

Figure 1  Security modules in an AUTOSAR 4.3 system

图1 AUTOSAR 4.3系统中的安全模块

例如，被安全板载通信（SecOC）使用，以加密方式验证所传输数据包中的信号值。顾名思义，CSM管理加密服务。实际实现位于特定于制造商的加密库中。为了支持集成到具有实时需求的AUTOSAR系统中，CSM异步地处理请求：最初，只被保存，然后在CSM MainFunction的调用中逐个处理。为此，CSM MainFunction将调用所有底层加密原语的mainformations，每个原语随后都要计算几个步骤。

典型密码原语的计算时间比信号处理函数的计算时间高出一个数量级。这在划分MainFunction调用时带来了一个两难的问题：允许计算的确切范围是多少？过多的计算步骤会使整个系统的实时性受到质疑，从而使加密变得毫无用处。太少的步骤会延迟计算较长的加密操作，以至于利益受到限制。

此外，还必须考虑另一个影响：特定的主函数负责管理其内部计算状态，以便允许逐步执行计算。就其本身而言，这种状态管理意味着开销。单个调用实际计算的次数越少，开销就越大。

软件供应商应该找到解决这个问题的标准解决方案。在经典的场景中，例如，运行时的加密用于通过对称加密方法对较小的数据块进行身份验证。一种解决方案可能是为每个MainFunction调用计算一个对称块。然而，当使用更复杂的方法时，很难找到合理的折衷方案。

示例包括验证/加密大量数据或生成非对称签名。例如，假设100µs的每毫秒计算一次是可以接受的，这是一个非常乐观的假设，在大多数实时场景中很难维持。

与纯计算时间相比，这样的除法意味着在得到结果之前的时间增加了10倍。对于纯计算时间已经造成困难的密码函数，这种划分大大限制了其实际应用。

Hardware security modules

硬件安全模块

显然，加密方法在实时性和开销方面的矛盾要求不能仅靠软件来解决。因此，一个明显的解决方案是使用专门的硬件，可以计算适当的算法-或其中的大部分-与主处理器并行。然后AUTOSAR CSM和相关的加密库只将请求传递给这个硬件，并且在main函数中，周期性地检查结果是否可用。这些硬件协处理器中的第一个已经在过去十年被制造商软件计划（HIS）指定为“安全硬件扩展”。关于密码算法，本规范仍然限于AES-128在不同模式下的实现。因此，最近的发展往往是由于硬件的大量发展或不太理想，所以才有可能出现更多的纯硬件。

其结果是向所谓的硬件安全模块（HSM）发展。HSMs是独立的微控制器，通过防火墙连接到主机系统的总线上。HSM通常有自己的受保护RAM，一个用于程序代码和数据的专用闪存区，以及自己的外围设备，如定时器、某些密码算法的硬件加速器或真随机数发生器。能够访问主机的完整硬件。这允许在运行时实现系统或主机监视的安全、经过身份验证的启动。专用数据闪存可用于存储机密，使主机系统无法访问这些机密。这意味着主机可以请求由HSM执行的加密操作，而不需要密钥离开HMS。然而，在这方面，HSM的特殊优点是可以自由编程。作为一个独立的微控制器，HSM能够运行针对当前用例优化的任何程序代码。这使得能够实现比简单协处理器多得多的安全需求。

Implementation of HSM firmware

HSM固件的实现

简单地在HSM上实现成熟的AUTOSAR标准软件并使用标准AUTOSAR方法将其连接到环境中，这似乎很诱人。这将允许重用熟悉的AUTOSAR实现模式。然而，事实并非如此：具有实时信号处理的典型AUTOSAR系统和关注安全性的HSM的用例有很大不同。显然，如果HSM的固件能够更自由地实现这一目的，那么可以更自由地实现这一目的。此外，目前的HSM硬件只有有限的资源可用，这也是在HSM上使用AUTOSAR软件困难的另一个因素。