多年来，不论是ECU之间的连接，还是ECU与外部的连接，汽车电子控制单元（ECU）的连接程度是在不断加深的。然而，随着软件日益复杂，新的需求也随之而生，对通信的要求也越来越高。从安全角度来看，这意味着从单个孤立系统到高度连接节点的变化。因此，抵御外部威胁的安全防护变得越来越重要。除此之外，这种保护可以通过加强密码使用来实现。乍看之下，在经典的实时系统中实现密码保护并非易事。密码学曾经只在特殊操作模式下才需要，例如修配车间的ECU软件更新。

现在，必须确保加密在常规运行时同样有效：例如，对通信伙伴和通信内容进行身份验证并防止拦截。想要适当的实施，必须允许实时需求。这与密码方法的计算时间要求看似相矛盾。硬件安全模块（HSM）可以解决这个问题。它们允许在单独的处理器上计算密码，如果可行，可用硬件加速。然而，我们需要一个优化的实现来发挥其全部的潜力。

汽车实时性

对车辆实时性的要求通常是由所谓的连锁效应造成的。在处理从传感器到相关执行器期望输出脉冲的输入脉冲时，分析涉及到的硬件或软件组件，以及排列顺序。从传感器和执行器的物理状态中得出整个链的最长可接受运行时间。然后，将其分解成单个组件的最长允许运行时间。根据用例不同，从10微秒到100毫秒不等。如果超出了最长允许运行时间，可能会降低便利性，导致噪音。对于需要实时性的安全相关功能来说，这甚至可能伤害生命和肢体。

为了满足对软件的实时需求，并实现需求，AUTOSAR操作系统将相关的软件功能划分为子步骤，即所谓的任务。通过外部事件触发任务，比如加注可运行标记，然后基于优先级进行处理。大多数应用程序会使用具有循环触发表的定时器来触发任务，因为相关的控制功能会连续处理新的生成信号。这样会产生一个默认的时间响应，几十毫秒一次循环。为确保满足实时要求，必须实施下列步骤。一方面，在处理信号时，必须采取适当措施，确保能够提供所需的时间响应。另一方面，必须确保ECU中与时间相关的触发任务能够满足时间要求。为此，必须分析所有任务在运行时期的行为，找到适当的优先级及触发命令时序，确保时效性。

AUTOSAR基础软件

ECU功能涉及的不仅是信号处理。处理通信和管理的基本软件也是ECU的重要组成部分。同样，基础软件必须分成不同任务，根据运行需求进行分析，并将其放进整个系统中加以考虑。简而言之，有两种不同的功能集：例如，基本软件中用于通信信号值的一部分，对于处理实时信号十分必要，必须高度重视。而另一部分的实时需求明显较低：必须在后台定期运行；然而，它可能被具有较强实时要求的功能短暂抢占。因此，常见模式是将这些非关键功能转移到低优先级后台任务中。此文的问题在于如何划分功能的优先级：通常，存在多个后台活动，所以在较长时期不必确定哪个不合格。解决优先级排序的方法是循环调度，对每个低优先级功能计时小段时间，后面紧接着下个功能。AUTOSAR术语中，涉及的每个模块都提供了一个运行时间有限的所谓的“主功能”。在后台任务中，这些功能将按顺序调用。

信息安全

“后台功能”中一个典型的例子是密码算法。4.0发布之后，AUTOSAR包含加密基础软件的规范——版本修改和微调的规范。在这种情况下，所谓的密码服务管理器（CSM）为应用程序提供加密服务：

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

例如，安全车载通信系统(SecOC)使用CSM对传输数据包中信号值进行加密验证。顾名思义，CSM管理密码服务。通过制造商专用密码库实现。为了集成到具有实时需求的AUTOSAR系统中，CSM异步处理请求：最初，CSM 主功能调用只保存请求，然后逐个处理请求。为此，CSM主功能就其本身而言，调用所有底层加密原语的主功能，然后每个对加密原语进行几步计算。

典型的加密计算时间超过了信号处理函数计算时间的数量级。调用主函数时，就出现了一个两难问题：允许的计算能力是多少？计算步骤过多，密码系统会失效，整个系统的实时性会成为问题。而步骤太少，加密操作的计算则会延迟，导致受益有限。

此外，还必须考虑另一个影响：特定的主函数用于管理内部计算状态，允许逐步执行计算。这种状态管理在某种程度上意味着开销。实际计算调用越少，开销越大。

应由软件供应商找到一个标准的解决方案。在典型场景中，例如，运行时的加密常用对称加密方法来验证较小的数据块。其中一种解决方案是为每个主函数调用计算一个对称块。然而，如果使用更为复杂的方法，很难找到明智的折衷方案。

示例包括对大量数据进行认证/加密或生成非对称签名。例如，假设每1毫秒计算100微妙可接受——这个假设十分乐观，因为在多数实时场景中保持这个状态并非易事。

与纯计算时间相比，这种划分意味着在结果可用之前时间增加了10倍。对于纯计算时间已经造成困难的密码函数而言，这种划分严重限制了实际应用。

硬件安全模块

显然，实时性能和加密方法开销的要求相互冲突，仅仅通过软件无法解决。因此，一个显而易见的解决方案是使用专门的硬件，这些硬件可以与主处理器并行计算适当算法或者其中大部分。然后，AUTOSAR CSM及相关的密码库仅负责将请求传递给该硬件，并在主功能中循环检查结果是否可用。过去十年里，在制造商的软件计划（HIS）里，这些硬件协处理器中的第一批被指定为“安全硬件扩展”。而在密码算法中规范仍限于在不同模式下实现AES-128。最近的发展显示，由于存在大量的可能情况，纯硬件协处理器常常是有限的，因此并不理想。

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

HSM固件实现

仅在HSM上建立良好的AUTOSAR标准软件，使用标准AUTOSAR方法将其与环境连接，似乎很不错。这样可以重用熟悉的AUTOSAR实现模式。然而，事实并非如此：具有实时信号处理功能的典型AUTOSAR系统，和关注安全性的HSM的用例大有不同。这清楚表明，如果HSM固件可以更自由地优化其目的，则可以实现更高的效率。此外，当前HSM硬件可用资源有限——另一个因素使得在HSM上使用AUTOSAR软件变得困难。

HSM用例通常是典型的客户机-服务器模型：主机将一个或多个请求发送到HSM，在HSM中处理这些请求，并在结果可用时立即发出通知。与传统的AUTOSAR系统不同，HSM上管理和后台任务的数量非常有限。因此，可以假定HSM大部分计算时间将专用于处理主机请求。

当在HSM上使用允许中断的操作系统时，可以相应优化任务映射和优先次序。这样的话，可以在低优先级任务中处理长时间运行的操作，中断较短的操作。如有需要，高优先级中循环任务允许处理管理任务。通过这种类型的映射，可以实现加密例程，在一个会话中执行特定任务。不再需要适当的例程允许中断。然而，操作系统使得日常操作透明化。不再需要相关的管理开销，这大大减少了代码规模和运行时间。此外，中断只有在实际需要时才会发生——如果只需处理单个操作，那么计算将不会中断。图2是HSM固件的体系结构。

电子束zentur HSM固件的建筑

算法布局的影响

事实上，与ECU硬件性能相比，HSM硬件性能有限，这可能是HSM软件优化的障碍之一。因此，理论上纯软件实现在HSM上需要的时间比主机更长。然而，在实践中，优化节省了时间。图3是tc397 ECDSA英飞凌测量（secp-256r1）上的主机系统，明显比HSM慢。虽然主机核心运行300MHz，HSM核心运行100MHz，主机上的软件算法比HSM的执行时间快了三倍。不幸的是，在一个真正的ECU中，主机CPU时间无法专门用于执行算法计算。事实上，使用AUTOSAR时间片和并发应用的用例可能只占主机CPU时间的10%，可用于算法计算。因此，100% CPU时间场景中的xyz ms，在结果可用之前，其操作将围绕实际ECU项目中的xyz * 10 ms。

有趣的是硬件加速器可以用来加速算法，所以软件部分只需设置输入数据并读出结果。计算是由硬件来完成，不需要任何CPU周期。图3显示了惊人的加速速度。具有8k输入数据的测量ECDSA secp-256r1仅需要9.6ms验证签名，而相应的HSM软件需要大约750ms，才能给出结果。这是一个78倍的加速。如果我们将硬件解决方案与具有10%CPU时间的主机CPU解决方案进行比较，结果在2.5秒之后是可用的，这意味着在硬件支持下，我们可以实现260倍的加速。

图3 ECDSA (secp-256r1)在主系统和HSM的运行时间

加密时间

因此，使用具有优化固件的HSM，也使实时ECUs成为永不过时的技术来验证密码。非对称加密方法也不再局限于特定的操作模式，而是可以在运行时以可接受的性能计算和使用。这开创了以前无法实现的密码用例。HSM的自由可编程性使得在选择所需方法及其实现方面能够进行特定于应用程序的优化。