确保道路车辆ECU安全可靠运行的新型远程验证方案

随着道路车辆连通性和复杂性的不断提升，安全性对车辆安全产生了重大影响。事实上，研究人员已证实，车辆缺乏安全性可能导致危害甚至危及生命的情况。在现有的车辆安全解决方案中，软件攻击这一威胁尚未得到充分解决。在软件攻击中，攻击者会破坏电子控制单元（ECU）的软件。远程验证是防御软件攻击的一种很有前景的技术，因为它能够检测出已被破坏的设备。本文提出了一种新颖的验证方案，该方案可确保电子控制单元的软件完整性，进而保障车辆安全。在我们提出的方案中，一个可信的主电子控制单元会对所有安全关键型电子控制单元的完整性进行验证，一旦检测到不可信且因此不安全的状态，便会拒绝启动发动机。由于现代车辆是高度异构的系统集合，我们提出了两种不同的验证技术，既能对简单的电子控制单元（如基本传感器或执行器）进行验证，也能对先进且更复杂的电子控制单元（如传感器融合系统）进行验证。我们在一个包含控制器局域网（CAN）和以太网的示例性汽车网络上实现了该验证方案，并表明我们的解决方案给乘客带来的额外开销微乎其微，几乎无法察觉。

在过去几十年里，车辆已从单纯的机械装置转变为复杂系统，其中包含数十个相互连接的嵌入式计算机，这些计算机被称为电子控制单元（ECU）。如今，电子控制单元可通过多种通信协议和接口进行访问，其中一些接口甚至是无线的，例如蓝牙、无线网络（WiFi）和长期演进技术（LTE）。这种发展极大地增加了车辆的攻击面，使得传统的车辆安全保障技术（如冗余、可靠性和确定性）不再够用。事实上，近期的攻击事件和安全性评估表明，电子控制单元可能会被操控以执行恶意操作，进而引发危及生命的事故。因此，只有建立起适当水平的安全性，才能保证现代车辆的安全。

为了保障车辆安全，科研人员在身份验证协议的研究和标准化方面投入了大量精力。这些协议可防范网络攻击，在网络攻击中，攻击者会试图在汽车网络中伪造或篡改信息。尽管身份验证协议对安全性至关重要，但它们无法防范所有类型的攻击。特别是，它们无法防御软件攻击。在软件攻击中，攻击者会破坏电子控制单元的软件以执行恶意操作。例如，制动执行器的固件可能会被篡改，导致无法正常制动。身份验证协议无法阻止此类攻击。远程验证是防御软件攻击的一项关键技术，它通常通过验证者和至少一个验证者之间的质询 - 响应协议来实现。通过执行该协议，验证者能够判断验证者是否处于可信的软件状态。

已有研究认识到远程验证在保护车辆免受软件攻击方面的潜力，但现有解决方案的适用性有限，因为它们要么要求电子控制单元配备可信平台模块（TPM），要么要求采用 SANCUS 研究架构。目前，电子控制单元尚未配备可信平台模块，且 SANCUS 在商业上也无法获取。此外，现有研究要么不关注安全性，要么缺乏对验证方案的实现和评估。

研究成果

在这项研究中，我们提出了一种新颖的解决方案，以确保道路车辆中电子控制单元的安全可靠运行。简而言之，我们的研究成果如下：

1. 汽车验证方案：我们提出了首个旨在确保道路车辆安全的验证方案。在该方案中，每当乘客解锁车辆并打开车门时，一个可信的主电子控制单元会对车辆中所有安全关键型电子控制单元的软件完整性进行验证。只有在所有安全关键型电子控制单元都成功通过验证后，主电子控制单元才会允许发动机启动。

2. 适用于商用电子控制单元：为应对道路车辆中电子控制单元的异构特性，我们的方案包含两种验证技术。第一种技术适用于系统架构简单、功能较为基础的电子控制单元，如基本传感器和执行器；第二种技术则针对配备 ARM 应用处理器、适用于执行更复杂任务（如传感器融合）的先进电子控制单元。我们验证，这两种技术都适用于广泛部署在道路车辆中的各类现有商用电子控制单元，因此，我们的方案仅需极低的部署成本。

3. 评估：我们在商用设备上实现了该方案，并将这些设备连接到汽车控制器局域网和以太网中。在我们搭建的实验环境中进行的测量表明，验证 100 个电子控制单元所需的时间不到 1.4 秒。需要注意的是，普通车辆总共包含 70-100 个电子控制单元，因此安全关键型电子控制单元的数量预计会少于 100 个。根据我们的测量结果，乘客不会察觉到车辆启动时间有任何额外延迟。

文章结构

第二部分概述相关工作；第三部分描述我们的系统模型；第四部分介绍我们的验证方案；第五部分展示我们的实现过程和评估结果；第六部分总结全文。

2.1 远程验证

远程验证是一种允许第三方（验证者）确保远程设备（验证者）完整性的技术。在验证过程中，验证者向验证者发出质询，并接收一个能表明验证者是否处于可信系统状态的响应。基于硬件的验证技术依赖于验证者设备中内置的安全硬件，如可信平台模块（TPM）、ARM 信任区（TrustZone）或英特尔软件保护扩展（Intel SGX）。对于低端嵌入式设备而言，此类硬件过于复杂且成本高昂。因此，近期的技术致力于实现只需最少安全硬件的验证方案。相比之下，基于软件的验证技术不依赖硬件，因此适用于未配备安全硬件的传统设备。然而，基于软件的验证技术依赖一些在实际中难以实现的严格假设，例如协议的优化实现与执行、精确的时间测量，以及攻击者在验证过程中处于被动状态等。

2.2 车辆中电子控制单元的验证

Oguma等人提出了一种验证方案，该方案允许一个专用的主电子控制单元验证车辆内其他电子控制单元的完整性。为确保验证过程的安全性，主电子控制单元和所有普通电子控制单元都配备了可信平台模块 1.2（TPM 1.2）。但在嵌入式系统中部署可信平台模块被认为过于复杂且成本较高，因此，所提出的验证方案在实际车辆中的适用性有限，因为实际车辆中的电子控制单元大多（即便不是全部）都属于嵌入式系统。我们注意到，可信平台模块 2.0 汽车精简版（TPM 2.0 Automotive Thin Profile）最近已发布。但由于这些新型可信平台模块同样是需要集成到电子控制单元中的独立微控制器，它们会像可信平台模块 1.2一样，增加电子控制单元的尺寸、复杂性和成本。此外，这些新型可信平台模块自 2018 年 10 月才开始商业化供应，目前尚未部署在现有的商用电子控制单元中。

VulCAN是一种消息验证、软件隔离和验证方案，能够在不可信的车辆网络中动态验证电子控制单元的完整性。然而，VulCAN 的前提假设是所有可验证的电子控制单元都配备了 SANCUS，而 SANCUS 是一种目前尚未商业化的研究型安全架构。此外，VulCAN 的验证概念尚未经过实现和评估，其实用性尚未得到证实。

2.3 商用嵌入式设备的验证

近期的研究表明，只要商用低端嵌入式设备提供只读引导代码和简单的内存保护机制，就可以对其进行验证。但是，这些研究都没有调查电子控制单元中是否存在所需的硬件安全特性，而且所提出的解决方案也没有在汽车网络中进行实现和评估，因此，它们在汽车领域的实用性尚不清楚。

其他研究则针对功能更强大、且额外配备了 ARM 信任区（TrustZone）技术的商用嵌入式设备开展远程验证研究。fTPM和 Komodo分别展示了如何利用信任区（TrustZone）通过软件实现可信平台模块（TPM）和英特尔软件保护扩展（Intel SGX）。谢泼德等人提出了一种协议，该协议基于对在信任区（TrustZone）中运行的应用程序的相互验证，在设备之间建立安全通道。尽管如此，fTPM和 Komodo仅为验证方案的实现迈出了第一步，因为它们缺乏测量和验证完整性的机制；而仅能对在信任区（TrustZone）中运行的单个程序进行验证。

3.1 系统模型

如图 1 所示，我们所考虑的车辆由多个相互连接的电子控制单元组成。主电子控制单元（Master ECU）具有特殊作用，它会使用我们提出的验证方案来验证车辆中其他电子控制单元的软件完整性。在汽油动力车辆中，主电子控制单元直接与点火开关相连；在全电动车辆中，它则与电源相连。如果至少有一个安全关键型电子控制单元的软件无法通过验证，主电子控制单元就会拒绝启动车辆。我们假设主电子控制单元是可信的，而车辆内的所有其他电子控制单元则可能会像下文所述的那样，被攻击者破坏。

图1、我们在电动汽车中的系统架构示意图

为了能被主电子控制单元验证，电子控制单元必须具备某些特定的安全硬件特性，这些特性将在第 4.2 节中阐述。我们主要关注两类电子控制单元：第一类是执行基本传感和 / 或执行器任务的简单电子控制单元，例如感知制动踏板状态或执行实际制动操作的电子控制单元。这类简单电子控制单元通常是低端到中端设备，存储容量仅为几兆字节（MB），中央处理器（CPU）的运行频率最高仅为几百兆赫兹（MHz）。第二类是功能更先进的电子控制单元，它们属于中端到高端嵌入式设备，运行功能完备的操作系统（OS），并包含各类应用程序。先进电子控制单元用于执行更复杂的任务，例如高级驾驶辅助系统（ADAS）中的传感器融合或目标检测。尽管我们的解决方案适用于对车辆中的所有电子控制单元进行验证，但从安全性角度来看，并非所有电子控制单元都需要进行验证。例如，假设车辆内所有通信都经过验证，那么车窗升降器对安全的影响与制动系统相比就微乎其微了。

3.2 攻击者模型

我们假设存在一个攻击者 Adv，该攻击者能够完全控制通信媒介（遵循多莱夫 - 姚模型，Dolev-Yao model）。因此，攻击者 Adv 可以窃听、修改、删除或插入网络中所有电子控制单元之间的任何消息。我们进一步假设，除了可信的主电子控制单元之外，攻击者 Adv 能够破坏所有其他电子控制单元的软件。对于已被破坏的电子控制单元，攻击者 Adv 能够完全控制其执行状态，并且可以读取所有可读取的存储内容，写入所有可写入的存储区域。但是，我们假设攻击者 Adv 无法绕过电子控制单元提供的硬件保护，因此，攻击者 Adv 无法篡改存储在硬件保护内存中或在其中执行的数据或代码。此外，我们不考虑针对单个电子控制单元的拒绝服务（DoS）攻击，因为对于能够完全控制网络的攻击者而言，这类攻击是无法防范的。如果攻击者 Adv 无法为软件已被破坏的电子控制单元伪造有效的系统状态，我们就认为我们的验证方案是安全的。

在本节中，我们首先阐述验证方案的基本工作原理（第 4.1 节），然后详细说明其在简单电子控制单元和先进电子控制单元上的技术实现细节（第 4.2 节）。

4.1 方案概述

我们提出的验证方案以主电子控制单元为核心。每当车辆被解锁并打开车门时，主电子控制单元就会通过执行我们提出的验证协议，对预先设定的一组安全关键型电子控制单元的软件完整性进行验证。安全关键型电子控制单元的集合由制造商在车辆出厂时确定，但之后可以根据需要进行修改，例如在需要更换电子控制单元的情况下。制造商为每个安全关键型电子控制单元配置两个不同的随机数（nonce），即NB和 N、一个唯一标识符（ID）以及一个只有该电子控制单元和主电子控制单元知晓的唯一验证密钥（AK）。此外，主电子控制单元和所有安全关键型电子控制单元都配备了协议代码和数据，具体细节将在第 4.2 节中详细说明。该协议的流程如图 2 所示，具体步骤如下：

图2、主ECU对简单和高级ECU的验证。受安全硬件保护的代码和数据以灰色显示

验证过程分为三个步骤，这些步骤会在车辆解锁并打开车门时依次执行：

步骤（1）：所有安全关键型电子控制单元启动，并对自身的软件完整性进行测量。为此，电子控制单元会计算其已安装软件的哈希值，并将该哈希值存储在完整性测量变量（IM）中。之后，每个电子控制单元会生成一个所谓的响应密钥（RK）。电子控制单元通过使用验证密钥（AK）对随机数NB和测量值（IM）计算基于哈希的消息验证码（HMAC）来生成响应密钥（RK）。在步骤（2）中，响应密钥（RK）将用于响应主电子控制单元的验证质询。如果某个电子控制单元处于软件被破坏的状态，其完整性测量变量（IM）就会与该电子控制单元已知的正常完整性测量值不同，从而导致响应密钥（RK）与该电子控制单元预期的响应密钥不匹配。在步骤（3）中，主电子控制单元在验证验证响应时，最终会检测到这种不匹配的情况。

为了确保验证过程的安全性，至关重要的一点是，攻击者 Adv 无法获取电子控制单元的验证密钥（AK），也无法篡改完整性测量变量（IM）和响应密钥（RK）的计算过程。确保这一点的具体细节因电子控制单元的类型而异，将在下面的小节（第 4.2 节）中详细阐述。

步骤（2）：主电子控制单元生成一个随机数（N），并将该随机数广播给所有安全关键型电子控制单元。这个随机数（N）起到质询的作用，可防止攻击者 Adv 利用已记录的验证响应实施重放攻击。

电子控制单元接收到随机数（N）后，会用随机数（N）覆盖之前的随机数NB。由于响应密钥（RK）依赖于随机数NB，这使得每次验证过程中响应密钥（RK）都会发生变化。正如后面将要讨论的，这一机制使我们的方案能够应对所谓的运行时攻击。在运行时攻击中，攻击者 Adv 会在电子控制单元通过验证之后破坏其软件。之后，电子控制单元会生成验证响应，该响应包含两部分内容：（i）电子控制单元的标识符（ID）；（ii）使用步骤（1）中生成的响应密钥（RK）对随机数（N）和标识符（ID）计算得到的基于哈希的消息验证码（σ）。最后，电子控制单元会将验证响应（即标识符 ID 和基于哈希的消息验证码 σ）发送给主电子控制单元。

步骤（3）：主电子控制单元接收所有响应，并按以下方式进行验证。对于每个安全关键型电子控制单元，主电子控制单元都存储有已知的正常完整性测量值IM'以及保密的验证密钥AK'。根据接收到的响应中包含的标识符（ID），主电子控制单元会检索出相应电子控制单元的已知正常完整性测量值IM'和验证密钥AK'。主电子控制单元使用验证密钥AK'、已知正常完整性测量值IM'以及之前的随机数NB，计算出预期的响应密钥RK'。接着，主电子控制单元使用计算得到的预期响应密钥RK'对随机数（N）和标识符（ID）生成基于哈希的消息验证码，并将其与验证响应中的基于哈希的消息验证码（σ）进行比较。如果两者的值匹配，就认为该电子控制单元的验证响应有效。

只有当所有安全关键型电子控制单元都返回了有效的响应时，主电子控制单元才会认为车辆处于安全状态。只有在这种情况下，主电子控制单元才会解除对点火开关和 / 或电源的锁定，允许车辆启动发动机。因此，已被破坏的电子控制单元只能阻止车辆启动，而无法危害车辆的安全。

4.2 技术细节

4.2.1 安全需求

为了实现安全的验证过程，攻击者 Adv 必须满足以下两个条件：（i）无法获取验证密钥（AK）；（ii）无法篡改软件完整性测量值（IM）和响应密钥（RK）的计算过程。如果这两个条件都能得到满足，攻击者 Adv 就无法计算出响应密钥（RK）。此外，响应密钥（RK）将能够反映电子控制单元的软件完整性状况。这意味着，只有当相应的电子控制单元处于可信的软件状态时，响应密钥（RK）才会与主电子控制单元用于验证验证响应的预期响应密钥RK'相匹配。由于攻击者 Adv 只有通过违反上述两个条件中的任意一个才能绕过我们的验证方案，因此，所有用于确保这两个条件得到满足的硬件和软件都构成了我们的可信计算基（TCB）。

更具体地说，我们的可信计算基（TCB）软件包含在步骤（1）中执行的所有代码，在该步骤中，会对验证密钥（AK）进行访问，并计算完整性测量值（IM）和响应密钥（RK）。与基于硬件的验证方案类似，我们要求可信计算基（TCB）软件得到安全硬件的支持，该安全硬件必须具备以下特性：

1. 安全存储：验证密钥（AK）必须只能由可信计算基（TCB）代码访问。

2. 不可篡改性：可信计算基（TCB）的代码和数据必须存储在受写保护的内存区域中。

3. 不可中断性：一旦可信计算基（TCB）代码开始执行，其执行过程就不能被其他代码中断。

在接下来的内容中，我们将分别讨论在简单电子控制单元和先进电子控制单元上如何实现这些特性以及可信计算基（TCB）代码。

4.2.2 在简单电子控制单元上的实现

简单电子控制单元配备有引导加载程序（bootloader），该引导加载程序存储在只读存储器（ROM）中，并且包含可信计算基（TCB）代码。在执行引导加载程序的过程中，可信计算基（TCB）代码首先会对电子控制单元中存储固件的预定义内存区域进行哈希计算，从而得到完整性测量值（IM）。为了提高灵活性，可以从一个证书中读取需要测量的内存区域，具体方式如文献所述。接下来，可信计算基（TCB）代码会访问验证密钥（AK），并生成响应密钥（RK）。生成响应密钥（RK）后，可信计算基（TCB）代码会确保验证密钥（AK）处于隐藏状态，这可能包括从内存中清除中间机密信息，并禁止软件进一步访问验证密钥（AK）。最后，引导加载程序会执行经过测量的固件。

将可信计算基（TCB）代码存储在受写保护的引导加载程序中，可确保其不可篡改性，并且在电子控制单元启动时能立即执行。通过暂时禁用所有中断，引导加载程序代码还能确保在可信计算基（TCB）代码执行完毕之前，其自身的执行过程不会被中断。因此，任何恶意代码都只能在步骤（1）之后才能执行。安全存储的实现方式取决于电子控制单元各自的硬件。已有研究展示了基于简单内存保护单元（MPU）、模拟内存保护单元（MPU）、静态随机存取存储器物理不可克隆函数（SRAM PUF）或可隐藏的电可擦可编程只读存储器（EEPROM）的具体实现方案。在第 5.1 节中，我们将描述在一个示例性设备上如何实现所有这些特性。

在实际应用中，许多简单电子控制单元都具备所需的安全硬件特性，因为它们所基于的微控制器已被证实具有这些特性。此外，多年来，所有主要制造商都提供符合 HIS-SHE 和 / 或 EVITA标准的电子控制单元。这两项标准为道路车辆中的安全硬件提供了通用规范，它们规定电子控制单元必须提供硬件支持，以实现不可篡改且不可中断的代码，从而实现安全引导功能，进而满足上述第（2）条和第（3）条特性要求。基于第（2）条和第（3）条特性要求，近期的研究表明，可以通过模拟的方式实现安全存储，从而满足第（1）条特性要求。因此，所有符合 HIS-SHE 和 EVITA 标准的电子控制单元也必然满足我们提出的安全硬件要求。需要注意的是，实际应用中的电子控制单元通常会配备真正的内存保护单元（MPU），我们更倾向于使用真正的内存保护单元（MPU），而非模拟的内存保护单元。

4.2.3 在先进电子控制单元上的实现

先进电子控制单元采用与简单电子控制单元相同的措施来实现必要的特性。因此，它们也会将引导代码和引导数据存储在只读存储器（ROM）中。然而，为了实现更丰富的功能，我们要求先进电子控制单元还需具备 ARM 信任区（TrustZone）技术，该技术提供了一个具有特权的第二执行环境，称为安全世界（secure world）。安全世界通过硬件与普通世界（normal world）隔离开来，普通世界中运行着标准操作系统和各类应用程序。自 2010 年推出 ARM Cortex-A15 处理器以来，所有 ARM 应用处理器（Cortex-A 系列）都具备信任区（TrustZone）技术。此外，新型 ARMv8-M 架构将信任区（TrustZone）技术引入到微控制器中，即 Cortex-M23/M33/M35P 处理器。此外，我们要求验证密钥（AK）的安全存储只能从安全世界进行访问，这是基于信任区（TrustZone）的安全服务的一项常见要求。为实现安全存储，制造商提供了多种解决方案，例如硬件熔丝（hardware fuses）、支持信任区（TrustZone）的内存控制器以及 / 或者输入输出内存管理单元（IOMMU）。

之所以需要额外的安全硬件特性，是因为先进电子控制单元的软件复杂度较高，必须采用与简单电子控制单元不同的验证技术。如今，功能完备的操作系统包含数千个不断变化的文件。对于先进电子控制单元而言，像对简单电子控制单元那样预先确定需要测量哪些内存区域以检测恶意软件，几乎是一项不可能完成的任务。因此，我们提出了一种更灵活的技术，即在加载时、执行前，根据需要对任何可执行代码进行测量。利用先进电子控制单元额外的安全特性，我们提出的技术能够确保测量代码的完整性，防止可能存在的恶意软件篡改已完成的测量结果。

更具体地说，先进电子控制单元配备的引导加载程序会对两个软件系统进行安全引导：（i）在普通世界中运行的基于 Linux 的操作系统；（ii）在信任区（TrustZone）安全世界中运行的名为 OP-TEE的软件。安全引导技术能够确保相关软件来自可信方（如制造商），而非攻击者。为此，会对软件进行测量，并将测量结果与存储在证书中的参考测量结果进行比较。如果实际测量结果与参考测量结果不匹配，或者证书的签名验证失败，那么该软件将不会被执行。

在先进电子控制单元上运行的所有（汽车）应用程序都由基于 Linux 的操作系统进行管理，该操作系统配备了启用的完整性测量架构（IMA）。完整性测量架构（IMA）是近期 Linux 内核的一部分，能够在二进制文件（包括库文件和配置文件）执行前对其进行测量。每次测量结果都会存储在完整性测量架构（IMA）的测量列表中，其中包含文件名、文件路径以及对文件计算得到的哈希值等信息。

第二个经过安全引导的软件是 OP-TEE，它负责管理在信任区（TrustZone）安全世界中运行的所有应用程序。具体而言，在先进电子控制单元的安全世界中部署了一个特殊的可信应用程序（TA）。该可信应用程序（TA）提供了一个应用程序编程接口（API），使完整性测量架构（IMA）能够将已完成的测量结果传递给可信应用程序（TA）。传递过来的测量结果会被连接起来，形成完整性测量值（IM），并存储在安全世界中加以保护。此外，可信应用程序（TA）还提供了第二个应用程序编程接口（API），用于计算响应密钥（RK）。为此，可信应用程序（TA）会接收一个随机数NB，并使用验证密钥（AK）对随机数NB和连接后的测量值（IM）计算出一个基于哈希的消息验证码（HMAC），作为响应密钥（RK）返回。需要注意的是，响应密钥（RK）的计算也可以在步骤（2）中根据需要进行。这是可行的，因为计算过程在安全世界中进行，能够防止在普通世界中运行的潜在恶意软件篡改计算过程。

4.2.4 运行时攻击

我们认识到，攻击者 Adv 还可能实施运行时攻击。在运行时攻击中，攻击者 Adv 会在电子控制单元完成测量之后破坏其软件。此类攻击可能会破坏我们方案的安全性，并且是所有加载时验证协议（例如，广泛部署的可信平台模块（TPM）也会受到影响）的一个已知局限性。尽管如此，引导随机数NB能够防止任何持续性攻击，因为它会使每次验证过程中的响应密钥（RK）都发生变化。因此，攻击者 Adv 在运行时攻击中植入的恶意软件会在电子控制单元下次重启时被检测出来。

在本节中，我们将首先描述我们的实现环境（第 5.1 节），然后展示并评估我们的测量结果（第 5.2 节）。

5.1 实现过程

我们将示例性的简单电子控制单元和先进电子控制单元连接到控制器局域网（CAN）总线和以太网中。对于简单电子控制单元，我们选用了 5 块 Olimex ESP32-EVB 开发板，这些开发板配备了 4 兆字节（MB）的闪存、一个 240 兆赫兹（MHz）的双核 32 位微处理器、100 兆比特（MBit）以太网接口以及一个控制器局域网（CAN）通信模块。为了实现第 4.2 节中提到的安全特性，我们使用 “一次性闪存”（one-time flash）选项对每块 ESP32-EVB 开发板的引导加载程序进行锁定，使其无法被修改。此外，我们部署的引导加载程序会对内存保护单元（MPU）进行配置，仅允许引导加载程序代码访问验证密钥（AK）。对于先进电子控制单元和主电子控制单元，我们采用了 6 块树莓派 3B+（Raspberry Pi 3 Model B+）开发板，这些开发板配备了 1 千兆字节（GB）的内存、一个 1.4 吉赫兹（GHz）的四核 ARM Cortex-A53 处理器以及千兆以太网接口。此外，我们为每块树莓派 3B + 开发板扩展了一个 SK Pang PiCAN2 模块，以支持控制器局域网（CAN）通信。遗憾的是，由于树莓派 3B + 开发板对信任区（TrustZone）安全世界内存的保护不足，并且缺乏安全存储功能，我们无法在其上实现第 4.2 节中提到的所有必要安全特性。

我们也认识到，我们所选的硬件缺少一些典型汽车硬件所具备的安全特性，例如锁步模式（lockstep mode）、纠错码内存（ECC memory）以及较宽的工作温度范围。然而，实现支持信任区（TrustZone）的内存控制器、安全存储以及汽车安全特性所带来的运行时额外开销微乎其微，因此，对我们的性能测量结果几乎没有影响。

5.2 运行时测量

5.2.1 单设备测量

我们对验证单个设备所需的运行时额外开销进行了研究。表 1 列出了我们在 ESP32-EVB 开发板和树莓派 3B + 开发板上，针对验证方案主要组成部分所测得的平均运行时间。如表所示，这两种设备的主要额外开销都来自安全引导过程，安全引导确保了引导代码的不可篡改性和不可中断性（见第 4.2 节）。ESP32-EVB 开发板的安全引导过程耗时 587 毫秒（ms），树莓派 3B + 开发板的安全引导过程耗时 508 毫秒（ms），这比其他操作所需的时间长得多，因为安全引导过程涉及多个计算密集型的签名验证操作。需要注意的是，在其他设备上，实现安全硬件特性（见第 4.2 节）可能并不需要安全引导过程。

表 1、ESP32-EVB 开发板和树莓派3B +开发板的平均测量数据

加密操作也会带来额外开销，我们使用 mbed TLS 库来实现这些加密操作。在验证过程中，两种设备都会对所有要执行的软件计算 SHA-256 哈希值。ESP32-EVB 开发板会对一个 512 千字节（KB）的固件二进制文件进行哈希计算，耗时 127 毫秒（ms）；而树莓派 3B + 开发板则会对 29 个文件进行测量，这些文件的总大小为 2.5 兆字节（MB），耗时 326 毫秒（ms）。此外，两种设备都会计算两个基于哈希的消息验证码（HMAC），ESP32-EVB 开发板的耗时为 0.24 毫秒（ms），树莓派 3B + 开发板的耗时为 0.41 毫秒（ms）。树莓派 3B + 开发板需要更长的时间，因为它要对 29 个软件完整性测量结果计算基于哈希的消息验证码（HMAC），而不是对单个测量结果进行计算。此外，作为主电子控制单元的树莓派 3B + 开发板，重新计算基于哈希的消息验证码（HMAC）并验证 ESP32-EVB 开发板的验证响应需要 0.18 毫秒（ms），验证其他树莓派 3B + 开发板的响应则需要 0.44 毫秒（ms）。

此外，网络通信也会产生额外开销，因为在验证过程中需要传输一个 16 字节（Byte）的质询消息和一个 33 字节（Byte）的响应消息。有趣的是，ESP32-EVB 开发板和树莓派 3B + 开发板上网络接口的性能存在较大差异。在 ESP32-EVB 开发板上，控制器局域网（CAN）的速度比以太网快，传输质询消息和响应消息仅需 1.19 毫秒（ms）。相比之下，在树莓派 3B + 开发板上，控制器局域网（CAN）的速度远慢于以太网，传输这两种消息需要 5.95 毫秒（ms）。

总体而言，对单个设备进行验证所需的运行时额外开销取决于设备类型和网络接口。其范围从至少 715 毫秒（ms）（ESP32-EVB 开发板通过控制器局域网（CAN）连接）到最多 844 毫秒（ms）（树莓派 3B + 开发板通过控制器局域网（CAN）连接）不等。

5.2.2 多设备测量

图 3 展示了通过控制器局域网（CAN）和以太网对不同数量的电子控制单元进行验证所需的运行时额外开销。如图所示，ESP32-EVB 开发板通过控制器局域网（CAN）连接时的验证速度最快，而树莓派 3B + 开发板通过控制器局域网（CAN）连接时的验证速度最慢。与验证单个设备的额外开销相比，随着网络中设备数量的增加，对多个设备进行验证的运行时间仅略有增加。这表明我们提出的验证方案具有良好的可扩展性。事实上，我们对大型网络的预测显示，即使在最坏情况下（即网络中仅包含通过控制器局域网（CAN）连接的树莓派 3B + 设备），对多达 100 个设备进行验证所需的时间也不到 1.4 秒。由于普通乘客进入车辆并启动发动机所需的时间通常超过 1.4 秒，因此，我们的方案不会给乘客带来可察觉的延迟。此外，道路车辆中安全关键型电子控制单元的数量通常少于 100 个。

图3、验证多个ECU的运行时开销

在这项研究中，我们提出了一种新颖的汽车验证方案。在该方案中，每当车辆被解锁并打开车门时，一个可信的主电子控制单元会对车辆中所有安全关键型电子控制单元的软件完整性进行验证。只有在主电子控制单元确认所有安全关键型电子控制单元都处于可信软件状态后，才会允许车辆发动机启动。通过这种方式，可以防止已被破坏的电子控制单元危害车辆安全。为了应对电子控制单元的异构特性，我们提出了两种不同的验证技术：第一种技术针对简单的传感器和执行器电子控制单元，第二种技术则针对更复杂的电子控制单元（例如用于传感器融合的电子控制单元）。由于这两种技术都适用于多种现有的商用电子控制单元，因此，我们的解决方案仅需极低的部署成本。我们在一个采用控制器局域网（CAN）和以太网的汽车网络中对该方案进行了评估，结果表明，验证 100 个电子控制单元的总时间额外开销不到 1.4 秒。因此，我们的方案不会给乘客带来可察觉的延迟。