如何选择汽车ECU的加密方法

摘要

随着车辆与外部组件连接性的增强，需要采取安全措施来防止未授权访问。可以通过使用加密方法来保护车辆。此时就会产生一个问题，考虑到汽车的边界条件，哪种方法是最佳解决方案。因此，本文提出了一个概念，通过将加密库集成到汽车控制单元中并确定加密方法的性能，为汽车领域加密方法的选择提供帮助。通过这种方式，可以推断出哪些安全措施适合保护车辆中的信息技术系统。

1、引言

随着联网程度的提高，汽车的可靠性和抗攻击性变得越来越重要，特别是考虑到电子组件的不断增加。这源于诸如车对 X（Car-2-X）或蓝牙等技术的引入，因此车辆联网的复杂性以及与外部组件的通信程度都有所提高。车辆的控制单元以前只能通过总线系统在内部相互通信，现在有机会与外部世界建立连接。由于存在未授权访问车辆的可能性，且这可能导致财产和人员伤害，因此内部通信以及与外部的通信都必须受到保护。可以通过使用加密方法来防止未授权访问，这些方法在信息技术领域已经使用多年。由于车辆的总线系统和控制单元在存储和性能方面与传统信息技术系统不同，加密方法不能不加修改地应用于车辆网络。必须考虑由不同存储和性能特性导致的限制。因此，问题在于如何在车辆联网的条件下评估加密方法的适用性。我们提出了一个框架概念，使用户能够将加密库嵌入到控制单元中，以便在控制单元上执行加密方法。此外，该框架还记录所执行方法的存储和运行时间特性。这样可以在实际条件下评估该方法的性能和适用性。这有助于从可用于保护信息技术系统的措施中选择最合适的措施。

问题：目前没有用于评估加密方法在汽车领域嵌入式系统上的性能和适用性的概念。

解决方案：我们提出了一个概念，该概念能够将加密库快速集成到控制单元中，以便随后能够执行加密协议。

贡献：本文提出了一个可以将加密库集成到汽车控制单元中的概念。此外，我们还提供了一个工具，通过该工具以框架的形式实现所提出的概念。通过这种方式，可以进行基准测试，在控制单元上执行和检查可选的加密算法。在执行过程中，将记录协议所需的工作内存、闪存大小以及计算时间，以便评估其存储和性能特性。

2、概念

此处提出的概念旨在能够将加密库快速集成到控制单元中，并评估加密算法的性能和适用性。与其他基准测试解决方案相比，我们的解决方案的不同之处在于，它特别考虑了汽车领域及其特殊性，例如通过总线系统进行数据传输。我们概念的示意图如图 1 所示。

图1：框架的概念结构。PC应用程序与控制器上的框架应用程序通信。这反过来又攻击了加密网络钓鱼库。其中包含的程序以及控制器的硬件驱动程序

关于本文中阐述的框架，需要注意的是，一方面存在包含不同方法和实现的各种加密库。另一方面，控制单元在性能、制造商、外围接口等方面存在差异。该框架以应用程序的形式将这两个方面结合起来。它通过通用接口访问所使用的加密库或其中包含的方法，并在控制单元上执行这些方法。此外，该应用程序通过接口（硬件抽象层）访问所使用控制单元的驱动程序，以利用硬件功能。下面将详细解释框架的各个组件。

2.1 加密库

加密库是已知加密方法及其实现的集合。该库被集成到控制单元中，以便框架的用户能够从库中选择一种加密方法并在控制单元上执行。由于库在包含的方法和实现方式上可能有所不同，框架提供了一个接口，作为框架应用程序和库之间的接口。这样，在需要时可以更换库，而无需调整框架的应用程序。

2.2 控制单元

控制单元作为执行框架的平台。由于控制单元在制造商、性能、存储资源、外围设备连接等方面存在差异，框架在这里也提供了一个接口，作为框架应用程序和控制单元的硬件驱动程序之间的接口。这样，可以更换控制单元，而无需在框架应用程序中进行调整。由于该接口直接访问硬件驱动程序，因此在接口内实现了所使用总线系统的通信协议。

2.3 电脑应用程序

电脑应用程序有两个任务：提供用于设置控制单元配置的界面，以及展示性能评估结果。在设置配置时，由框架用户选择加密协议。此外，还在此处指定协议的特定参数、要传输的数据和其他相关数据。该配置由电脑应用程序发送到控制单元的框架应用程序，在那里执行加密协议。性能测量的结果以及在执行过程中生成的加密数据被发送回电脑应用程序，在那里向用户显示。

2.4 控制单元应用程序

控制单元应用程序是框架的主要组件，其任务范围可分为三个部分：

（a）加密库的集成（框架应用程序↔加密库）

（b）基准测试（框架应用程序↔控制单元）

（c）与电脑应用程序的通信（框架应用程序↔电脑应用程序）

（1）加密库的集成：将库集成到框架中的一个挑战是应用程序接口和库接口之间的差异，这些差异是由不同的实现、方法等导致的。因此，应用程序的接口被实现为具有通用参数的通用接口，以确保不同库的接口之间具有尽可能高的兼容性。因此，分析了对称和非对称加密方法以及数字签名和哈希函数，以确定在通用接口中使用的必要加密参数。对称方法的特点是所有通信伙伴都拥有相同的秘密信息（秘密密钥）。除了密钥之外，还需要要加密的明文以及由此产生的密文作为其他参数。此外，一些方法需要所谓的 Nonce（一次性数字）来生成密文。非对称方法使用密钥对（私钥和公钥）。数字签名需要用于签名或消息认证码（MAC）的参数。此外，使用哈希函数需要哈希值的参数。

通用接口总共需要以下参数：

· 加密协议

· 加密方法

· 明文

· 密文

· 秘密密钥（对称方法）

· 秘密密钥（非对称方法）

· 公钥

· 消息认证码

· 哈希值

· 一次性数字

（2）加密协议的基准测试：基准测试包括测量在控制单元上执行加密协议时所需的闪存、随机存取存储器（RAM）和运行时间。这使得可以在实际条件下比较各个算法的性能。在编译框架软件期间测量所需的随机存取存储器和闪存。运行时间在加密协议执行期间测量。框架通过使用硬件接口提供了测量框架。在该接口内，控制单元的内部外设（例如计数器 / 定时器）用于记录协议的运行时间。

（3）与电脑应用程序的通信：与电脑应用程序的通信用于在电脑和控制单元之间交换数据。控制单元执行加密协议需要框架用户设置并发送给控制单元的配置。协议执行过程中生成的参数（密钥、认证数据等）以及测量的性能值由控制单元发送到电脑应用程序，在那里向用户显示。

3、实现

为了能够进行评估，上述概念被实现为一个针对特定应用场景的框架，下面将对其进行说明。

（1）加密库的集成：在实现该概念时，使用了两个开源库，以便能够在不同实现之间进行比较。一个是 libsodium 库（The Sodium Crypto Library），另一个是 mbed TLS 库。其中，libsodium 是 NaCl 库（Networking and Cryptographic Library）的衍生版本，该库由 Bernstein 等人年提出，而 mbed TLS 由 ARM Limited 公司提供。这两个库都包含了常见加密方法的实现。假设库中的方法已正确实现和测试。为了涵盖尽可能广泛的加密方法，实现了以下加密协议作为应用场景：

a) 非对称密钥交换以计算秘密密钥。

b) 使用秘密密钥进行明文的对称加密 / 解密，以确保机密性。

c) 生成消息认证码（MACs），以确保消息的真实性和完整性。

该协议所使用的加密方法如下表 1 所示。

表 1：所选协议的加密方法

为了配置该协议，所有方法的密钥长度都设置为 256 位，明文长度设置为 64 位，消息认证码长度设置为 128 位，因为这些大小与所选方法兼容。在此需要提及的是，本文未考虑秘密密钥的安全管理，因为该框架仅用于评估方法的性能，而密钥管理对此没有影响。

（2）基准测试和（3）与电脑应用程序的通信：为了执行加密协议，搭建了一个测试平台，在两个控制单元之间实现了 CAN 总线通信，如图 2 所示。两个控制单元都是带有 ARM-Cortex-R4F 处理器的开发板，该处理器专为汽车应用设计。两个开发板都通过其 USB 接口连接到运行电脑应用程序的电脑上。

图2：框架的通信原理

在电脑应用程序中，选择上述加密协议。所选协议、相关参数以及明文数据通过 USB 连接发送到电子控制单元 1（ECU 1）。电子控制单元 1 与电子控制单元 2 执行非对称密钥交换，以计算共同的秘密密钥。此秘密密钥随后用于对传输的明文数据（要发送的消息）进行对称加密和生成消息认证码。加密后的明文与相应的消息认证码通过 CAN 总线发送到电子控制单元 2，在那里验证消息认证码并解密加密的消息。在执行加密协议的同时，利用控制单元的内部外设（定时器）测量计算时间。协议完成后，测量值与加密数据一起通过 USB 接口发送到电脑应用程序，并向用户显示。

4、评估

为了评估该框架，首先将 libsodium 库和用于比较的 mbed TLS 库集成到框架中，将框架软件加载到控制单元上并执行加密协议。

4.1 性能评估结果

在查看结果时，特别关注了这些方法的计算时间。请参见表 2，其中说明了两个库的加密协议的平均计算时间。所示数值是这些方法的纯计算时间，未考虑通过 CAN 传输的延迟时间。

表 2：运行时间测量结果

在查看加密 / 解密以及消息认证码生成和验证的计算时间时，可以发现尽管使用了不同的方法，两个库所需的计算时间相似。libsodium 使用 ChaCha20 和 Poly1305 算法，平均计算时间为 3.798 毫秒，而 mbed TLS 使用 AES 和 HMAC 方法，平均计算时间为 3.930 毫秒。然而，在执行椭圆曲线迪菲 - 赫尔曼密钥交换时，发现了显著的运行时间差异。libsodium 的该方法平均计算时间为 93.590 毫秒，而 mbed TLS 的计算时间为 1567.550 毫秒，是前者的 16.75 倍。初步研究发现，mbed TLS 在实现椭圆曲线迪菲 - 赫尔曼密钥交换时执行了许多类型转换，而 libsodium 在实现中使用了统一的变量类型。这是造成运行时间巨大差异的一个初步迹象。此处框架的价值显而易见，因为如果不进行比较，在时间关键型功能中使用 mbed TLS 会导致控制单元上显著的性能劣势，这与车辆网络中的高效和可靠运行背道而驰。需要提及的是，计算时间只是可能的决策标准之一。然而，该框架提供了一个辅助工具，用于选择方法或库，通过该工具可以在考虑控制单元性能的情况下评估不同的配置。

4.2 库的可替换性

通过将表 1 中提到的两种方法的 libsodium 和 mbed TLS 库集成到加密协议的执行中，评估了加密库的可替换性。在框架应用程序的通用接口中调用各个方法的功能。在此过程中，将概念部分中提出的通用接口参数传递给加密库的接口。需要指出的是，通用接口并不追求完整性。如果库或方法的接口需要通用接口中不包含的其他参数，可以在接口函数内部本地定义这些参数。参数数据类型的可能转换也在此处进行。通过在更换库时在通用接口内部本地进行这些调整，从而使框架应用程序不受调整的影响，保证了库的可替换性。

5、结论与展望

通过此处提出的框架，可以从多种用于实现保护目标的安全措施（加密方法）中选择合适的措施。可以在考虑车辆网络内硬件限制的情况下应用这些措施，以确保车辆的可靠和安全运行。我们建议在早期开发阶段使用该框架。一方面，这样做的好处是通过选择合适的加密库，可以避免可能的硬件调整。此外，结果还可以影响未来的开发。需要指出的是，本文提出的解决方案目前仅涵盖有限的应用范围。因此，未来工作的目标是实现更多的加密协议，以涵盖不同的应用场景。此外，扩展性能评估也是重点。可以研究加密方法在嵌入式系统中的适用性还取决于哪些其他参数。例如，可以研究带有集成硬件安全模块（HSM）的控制单元对算法性能的影响。总体而言，通过这些方法，该框架可以在功能上得到扩展，基于多次性能评估的结果，确定保护车辆的最佳解决方案。