满足AUTOSAR基础软件要求的硬件安全模块（HSM）加密运算

随着软件日益复杂，并且车载系统和传感器数量稳步增加，车内系统的通讯成几何增长，必须加强密码保护。这种保护可以通过经典的实时汽车开放系统架构（AUTOSAR）来实现。即便在资源稀缺的情况下，安装合适固件的硬件安全模块（HSM）也是一种永不过时的技术，它可以用来验证您的系统密码。

多年来，不论是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固件的体系结构。

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倍的加速。

在这里插入图片描述