联网车辆在其漫长的生命周期中遭受网络攻击的威胁日益严重。因此，及时的空中下载（OTA）更新流程正成为一种必要的缓解机制，其安全性也成为一项关键任务。在本文中，我们提出了一种新颖的联网车辆安全 OTA 更新分发机制，该机制能够应对最新汽车安全法规和标准中的威胁与要求。我们的安全概念专门适配可信平台模块 2.0（TPM）的功能，将其作为车辆远程信息处理单元的硬件信任锚，并展示了其在安全保障和功能方面相较于相关研究的优势与独特性。在我们的概念中，TPM 充当可信更新分发点，将后端的非对称加密安全转换为车内对称加密；同时作为更新授权点，负责协调更新安装（例如，根据车辆状态进行协调）。这些概念完全在 TPM 的隔离环境中执行，这使得 TPM 成为远程信息处理单元上经过最小化加固的可信计算基。该解决方案不依赖启动时完整性机制，因此甚至能够抵御高级运行时和物理硬件网络攻击。我们通过在汽车评估平台上的原型实现对该解决方案进行了评估。

OTA软件更新是一种有效的缓解策略，能够及时应对针对已投入使用的联网车辆的新型网络威胁，并避免高昂的召回成本。然而，OTA 更新过程本身具有高度的安全关键性，因为它需要外部访问车内网络组件以安装更新，甚至可能给系统引入新的漏洞。

OTA 软件更新的重要性日益凸显，这体现在最新的汽车标准和法规中，例如关于网络安全和软件更新工程的 ISO 21434 和 ISO 24089 标准，以及联合国欧洲经济委员会（UNECE）的 155 和 156 号法规。这些法规将使网络安全，特别是安全的软件更新系统，成为 2024 年新车辆审批的强制性要求。

贡献与概述

为应对汽车领域这些最新发展带来的新的严格安全要求，我们设计并实现了一种新颖的安全 OTA 更新系统。该系统通过将资源密集型的后端非对称加密转换为适用于资源受限车辆网络的轻量级对称加密，确保更新包的分发安全，并根据车辆的更新就绪状态授权更新安装。我们强大的系统安全保障基于可信平台模块 2.0（TPM 2.0）—— 一种物理隔离且经过特殊加固的硬件信任锚（HTA），将其部署在车辆的远程信息处理控制单元（TCU）中。TCU 连接车辆与外部世界，因此攻击面较大，需要特别加强安全保护。TPM 2.0 构建了额外的安全屏障，作为系统的主要安全提供者，它能够：（1）减少资源受限的车内电子控制单元（ECU）的安全开销；（2）通过将关键加密密钥简化为一个非对称更新签名密钥，降低后端的攻击风险。通过减少后端和资源受限 ECU 的复杂且易错的安全开销，整体安全性得到进一步提升。我们的系统安全策略专门适配 TPM 2.0 的功能，因此可以在其隔离环境中完全执行。这将维护整体安全策略的系统部分 —— 可信计算基（TCB）—— 缩减至仅 TPM 2.0。TCB 越简单、越坚固，整个系统就越安全。由于在我们的方案中，TCB 完全缩减为 TPM 2.0，我们的解决方案不依赖于诸如测量启动或安全启动之类的启动时完整性验证措施。因此，凭借 TPM 2.0 的安全特性，该方案甚至能够抵御软件的逻辑运行时攻击（例如权限提升攻击）以及物理侧信道或（半）侵入性篡改攻击（例如微探针攻击）。

汽车安全 OTA 更新已得到广泛研究，至少加密转换功能并非全新内容。然而，通过在第 6 节与各类相关研究进行比较，我们发现目前尚无类似的 OTA 更新分发和安装授权概念能够在提供同等强大安全保障的同时，满足我们提出的所有要求并具备相应功能，即便有些研究也将 TPM 2.0 用作车辆中的信任锚。

具体而言，我们的核心安全策略通过两个设计的安全构建块（SBB）来执行。TPM 2.0 通过以下方式实现这些 SBB：（1）确保并适配资源受限车辆网络的更新传输（SBB1）；（2）充当更新安装的授权点（SBB2）。

这两个 SBB 的结合通过降低后端和资源受限的目标 ECU 的复杂性和安全要求，最小化了整体攻击面。特别是在 SBB1 中，车载更新代理充当 “加密代理”，将资源消耗较大但易于处理、适用于后端通信的非对称加密转换为适用于车内通信且通常已在使用的轻量级对称加密。由于密钥更新在我们加固的 TCB 中进行，后端无需存储或知晓任何安全敏感的车辆对称密钥，进一步减小了攻击面。此外，在 SBB2 中，车载更新代理处理安全和安全关键的更新过程，因此资源受限 ECU 的安全开销可保持最小。这包括在授权更新安装之前执行某些约束检查，例如更新的有效性、真实性和完整性的正确性、是否适用于正确的目标 ECU、防止降级攻击的时效性，以及强制的车辆更新就绪状态等。

选择 TPM 2.0 作为车辆中的 HTA 来加固 TCB 是合理的设计决策，因为可信平台模块（TPM）已开始在首批车辆中使用，并且最新标准也推荐将其作为车辆网络的硬件安全机制。

我们证明了我们的概念可以完全映射到 TPM 2.0 的高级功能。我们设计的协议符合 TPM 广为人知且经过深入分析的加密方法和算法构建块，从而为组件交互获得强大的安全保障。我们的 SBB 的安全关键操作可以在 TPM 2.0 的隔离环境中完全处理。

据我们所知，并通过对相关工作的分析，目前没有类似的 OTA 更新分发和安装授权概念能够在提供同等强大安全保障的同时，满足我们提出的所有要求并具备相应功能。这些保障通过使系统适配 TPM 2.0 的高级功能来实现，而这些功能在我们分析的相关工作中均未被利用，因为其中一些关键功能是我们在本研究中首次实现的。我们的贡献如下：

・我们设计的更新系统基于广泛的需求分析和定义的攻击者模型，满足了由此得出的需求。它具有最小化的 TCB，还包含一些新颖概念，例如将车载更新代理作为车辆中的主要安全提供者，充当更新授权点和 “加密代理”，以减少后端系统和资源受限的车内 ECU 的攻击面和复杂性。

・我们的系统设计适配汽车架构的要求。为证明解决方案的可行性，我们展示了它的开销和干扰极小，制造商可以轻松部署。

・我们仔细设计系统以符合 TPM 2.0 规范，从而能够充分利用 TPM 2.0 作为系统中的信任锚并加固 TCB。这需要深入了解 TPM 2.0 规范，我们甚至贡献了必要的实现增强功能，使我们的工作独具特色。我们开发了详细协议，展示了如何利用 TPM 2.0 作为安全提供者和加固的 TCB。

・我们对解决方案进行了安全性评估，讨论了安全需求的满足情况，并实现了概念验证原型，以评估所提出系统在汽车环境中的可行性。我们已将开发的 TPM2 软件栈（TSS2）库扩展反馈给开源 Linux TPM2 & TSS2 软件社区。

・我们展示了我们的解决方案在安全保障和功能方面相较于相关工作的优势。

本文其余部分结构如下：第 2 节介绍 TPM 2.0 和汽车领域的一些背景知识。第 3 节详细描述系统设计过程，包括系统和攻击者模型以及需求分析。第 4 节基于特定协议更详细地解释系统。第 5 节介绍原型实现，并对系统进行安全性和可行性评估。第 6 节将我们的解决方案与安全更新过程相关的工作进行比较。第 7 节总结全文。附录提供了关于评估平台、JSON 编码的示例策略和系统需求分析的一些补充细节。

本章简要介绍可信平台模块 2.0（TPM 2.0）和汽车领域的一些背景知识。

2.1 可信平台模块 2.0

可信计算组（TCG）规范的修订版 2（TPM 2.0）是一种专用安全协处理器。它提供防篡改的隔离环境，用于存储和处理安全敏感数据，抵御软件（逻辑）和侧信道或（半）侵入性篡改（物理）攻击。它拥有各种用于对称和非对称密钥以及哈希生成的加密引擎，由硬件随机数生成器提供支持。其非易失性安全存储可用于在启动周期中持久保存任意数据或 TPM 特定数据结构，例如单调计数器、位掩码或测量值。安全敏感数据，如非对称私钥或对称密钥，绝不会以未加密的形式离开 TPM。它们要么存储在内部，要么由主 CPU 加密后存储在磁盘上。

可以使用各种授权机制限制对密钥操作和数据对象的访问：基于密码的授权和基于会话的授权。后者可用于即使在不安全的连接上也能远程授权密钥使用。一种特殊的基于会话的授权是策略授权，也称为增强授权（EA）。通过 EA，可以基于 TPM 策略限制对密钥的访问。TPM 策略在 TPM 内部处理，由各种 TPM 策略命令连接而成，每个策略命令执行不同的限制，例如关于存储在其非易失性存储器中的 TPM 值（TPM2_PolicyNV），或在挑战 - 响应方案中要求远程方的签名（TPM2_PolicySigned）。

我们充分利用 EA 功能，并设计自己的策略，使 TPM 的功能适应我们的系统设计。这使我们能够在所有系统组件之间建立在 TPM 内终止的安全端到端通道。此外，我们实现了 TPM 规范中尚未完善的密钥派生功能，以便能够派生特定于更新的授权密钥，从而实现我们的安全构建块（SBB）—— 利用 TPM 为资源受限的车辆网络重新加密非对称加密的更新包（SBB1）和更新安装授权（SBB2）。

2.2 汽车领域

现代汽车的电气 / 电子（E/E）架构包含多达一百个相互连接的计算单元，即所谓的电子控制单元（ECU）。ECU 和各种连接网络在计算能力、内存和存储大小以及可用带宽方面都具有异构特性。从拓扑结构来看，这些 ECU 可能根据不同的设计原则进行组织。所有设计的一个共同特征是具有互连子网的分层集群。E/E 架构已从基于中央网关的设计演变为现代的基于域的架构设计。文献讨论了这种现代基于域的 E/E 架构的通用实例。我们的系统设计基于该参考架构的增强版本。

更新通常由更新供应商准备，该供应商可以是汽车供应商或原始设备制造商（OEM）。在 OTA 更新的情况下，更新通过 OEM 或供应商后端直接通过蜂窝网络分发到车辆。车辆中的相应接口是远程信息处理控制单元（TCU），通常处理与后端系统的所有外部连接。非 OTA 更新通常发送到维修店，维修店通过车载诊断（OBD）连接进行更新刷写。在资源受限的子网中，通常使用唯一设备秘密（UDS）协议在车辆内传输更新。由于车辆网络的（主要）稀疏能力，更新过程依赖轻量级对称加密，后端和相应的 ECU 都需要安全存储相应的加密密钥。特别是后端需要存储所有车辆的所有 ECU 的密钥，这使得密钥管理成为一项复杂且易错的任务，很容易导致安全漏洞。这一点尤为关键，因为后端包含所有车辆的所有 ECU 的密钥，因此成为网络攻击的重要目标。

本节描述我们的系统设计，包括高层概念描述、系统需求和攻击者模型。

3.1 系统模型和高层概念

我们解决方案的总体优势在于，我们设计的系统将两个核心安全策略 ——（1）条件重加密和（2）安装授权 —— 完全在可信平台模块（TPM）的隔离环境中处理。因此，我们将可信计算基（TCB）加强为仅包含（防篡改的）TPM，从而使我们的解决方案能够抵御高级物理和运行时攻击。第 6 节将展示，与相关工作相比，这是我们解决方案的独特之处。

对于我们的系统模型，我们分析了当前讨论和预期的未来汽车架构，例如文献 [4,28,29] 中描述的架构，提取核心特征并开发了如图 1 所示的系统模型。它展示了具有电子控制单元（ECU）的车辆网络以及车辆环境中的外部更新分发网络。

我们在连接车辆与环境的远程信息处理控制单元（TCU）中配备 TPM 作为车辆信任锚（参见第 2.2 节）。TPM 和 TCU 共同构成车载更新代理。我们将车辆环境中的整个更新分发网络统称为更新供应商（US）。US 可以是汽车制造商或供应商，负责创建更新并将其分发给车辆 TCU。TCU 将更新转发给目标 ECU（ECUU），最终由目标 ECU 安装更新。此外，我们定义了所谓的条件 ECU（ECUC），它们也可能具有 ECUU 的角色，因此自身也可能被更新，但还提供信息以确保在车辆内任何 ECU 安装更新之前满足某些前提条件。

我们将 TPM 设计为车辆中的主要安全提供者，因此通常资源受限的 ECU（包括 ECUC）的可信组件的安全功能可以保持轻量级。例如，它们只需要处理对称加密，并依赖 TPM：（1）处理更复杂的非对称加密，包括证书（链）管理；（2）执行更高级的安全功能，如降级保护、撤销和 / 或安装前条件，TPM 将基于某些 ECUC 的状态应用这些功能。

我们的更新安全概念分为两个连续但独立的安全构建块（SBB），完全在 TPM 的隔离环境中处理：
（1）SBB1：认证更新分发；（2）SBB2：协调更新授权。第 4 节详细描述了这两个 SBB，下面仅简要概述其预期的安全优势。

在 SBB1 中，TPM 负责将更新包从车辆环境中的 US 安全传输到目标 ECU（ECUU）。在此过程中，TPM 充当 “加密代理”，将通常在车辆环境中部署的非对称加密转换为通常在受限的车内网络中使用的对称加密。如图 1 所示：（1）US 将经过非对称签名的更新包发送给车载更新代理；（2）只有当 TPM 成功验证该签名后，才使用密钥派生函数（KDF）派生基于哈希的消息认证码（HMAC）密钥，其输入是与 ECU 的共享密钥和更新包的哈希，然后创建相应的 HMAC；（3）TCU 将生成的 HMAC 和更新包发送给 ECU，ECU 现在可以使用通过相同 KDF 和输入派生的 HMAC 密钥进行对称验证。

图 1：高层概念：安全车载更新代理用作 “加密代理”（SBB1）和更新授权协调器（SBB2）

在 SBB2 中，TPM 在通过 SBB1 安全分发更新后协调更新安装。它在特定条件下授权更新安装，例如防止降级攻击或确保车辆处于安全状态。这些条件通过挑战 - 响应方案从条件 ECU（ECUC）获取。如图 1 所示：（4）ECU 向 TPM 请求更新安装授权；（5）相应的 TPM 响应密钥由 TPM 策略保护，该策略要求与（一个或多个）ECUS 进行挑战 - 响应方案；（6）只有当 ECUC 通过成功响应批准其条件时，TPM 响应密钥才会解锁；（7）TPM 才能响应 ECU 的更新安装授权请求。因此，SBB2 通过加密方式确保只有满足所有条件才能安装更新。

SBB 的主要优势在于：（1）后端不需要存储或知晓任何安全敏感的车辆对称密钥，只有其私有的更新签名密钥是安全关键的；（2）对称加密可用于能力稀疏的车内网络；（3）TPM 处理安全和安全关键的更新过程，因此资源受限的 ECU 的安全开销可以保持最小。这里仅简要概述这些优势，第 5 节将对其进行更详细的评估。

第 4 节包含更多关于如何将 SBB 概念映射到 TPM 的细节，下面简要概述该概念。

对于这两个 SBB，TPM 与车辆中的每个 ECU 安全存储一个共同的基础密钥（KECU 派生）。KECU 派生用于派生特定于 SBB 和特定于更新的应用密钥（K 重加密 HMAC，K 安装 HMAC）。KDF 的输入是当前更新的哈希、KECU 派生和 SBB 标识符（SID）（SBB1/2 的 SID1/2）。成功派生取决于我们设计的 TPM 策略的成功处理：重加密策略（RKP）和安装授权策略（IAP）（参见第 4.1 节）。

在 SBB1 的情况下，每次 US 发送更新（FWECU）时，RKP 强制只有在 TPM 成功验证非对称认证器 AuthECU 非对称（数字签名）后，才能派生 K 重加密 HMAC。然后使用 K 重加密 HMAC 创建对称认证器 AuthECU 对称（HMAC）。

在 SBB2 的情况下，在已通过 SBB1 安全分发的更新（参见 SBB1）将要安装时，IAP 强制只有满足我们的系统要求（例如，车辆处于更新就绪状态或用户确认），才能派生更新安装授权密钥 HIMAC。第 3.3 节和第 4 节描述了如何定义车辆更新就绪状态以及我们在概念中如何实现这一点。

3.2 攻击者模型

在我们的攻击者模型中，我们定义了三种能力递增的攻击者类型：（1）网络攻击者（A1）、（2）劫持攻击者（A2）和（3）运行时攻击者（A3）。

A1 基于经典的 Dolev-Yao 攻击者，可以干扰所有通信通道，并可能窃听、拦截、注入、重放和 / 或修改所有传输的数据。A2 和 A3 基于网络物理 Dolev-Yao 攻击者，它扩展了经典的 Dolev-Yao 攻击者模型，可以通过物理访问直接破坏系统组件。对于 A2，攻击者可以劫持系统组件并执行权限提升攻击，例如规避软件强制的安全策略（如强制或自主访问控制机制），或物理篡改系统（闪存）内存。A3 是我们模型中能力最强的攻击者，还可以在运行时篡改易失性内存。然而，我们的任何攻击者类型都无法破坏 ECU 和后端中的可信组件以及车载更新代理中的 TPM。此外，我们的模型不包括拒绝服务（DOS）攻击，因为它们对所有攻击者可以控制通信通道的通信系统都是威胁。它们可以通过弹性机制更好地解决，然后可以纳入我们的概念中。

任何攻击者的总体目标都是篡改传输的更新数据，使目标 ECU 刷写恶意或错误的固件版本。例如，攻击者可能充当中间人（MitM），并可能破坏通过无线接口在更新供应商和 TCU 之间传输的更新数据，或者破坏车内网络中的更新数据。凭借 A2 和 A3 的高级能力，攻击者还可能访问或破坏 TCU 或车辆网络中其他 ECU 的易失性和非易失性（NV）内存区域，例如随机存取存储器和闪存，以窃听或篡改加密密钥或注入自己的数据。该模型还涵盖了 UNECE 在其 155 号法规中详细说明的威胁。它们提供了有关滥用或破坏空中（OTA）和本地 / 物理软件更新程序的详细信息。下一章得出的要求针对我们攻击者模型中的这些威胁。

3.3 系统需求

表 1 显示了我们的更新系统的要求，这些要求源于我们的攻击者和系统模型，并与相关的汽车标准和法规保持一致。特别是，我们将它们与 UNECE 法规 UN155 和 UN156、ISO 21434 网络安全工程标准和 Uptane 部署最佳实践中详细说明的威胁（T）和要求（R）保持一致。

表 1：系统需求

本章详细介绍我们的系统规范并描述详细协议。

4.1 策略设计

我们利用 TPM 增强授权（EA）机制，使 TPM 的功能适应我们的系统设计并执行我们的整体安全策略。简要总结第 2.1 节，EA 允许基于 TPM 策略限制对密钥的访问。TPM 策略由各种 TPM 策略命令连接而成，每个策略命令执行不同的限制。TPM 策略不包含安全敏感信息，可以在 TPM 内完全执行。

我们的整体系统安全策略依赖于更新应用密钥的条件性和授权性派生。为此，我们使用初始授权策略创建派生密钥，该策略授予对任何由 US 的签名密钥 Kiss 签名的策略的密钥访问权限。我们设计了两个更新应用策略：（1）重加密策略（RKP）和（2）安装授权策略（IAP），以满足这一要求。通过设计，它们在 TPM 的隔离环境中完全执行我们实际安全策略的限制。更新应用策略如图 2.b）和图 3.b）中的相应协议下方所示。我们在此简要描述它们如何帮助执行我们的安全概念，并将在以下章节中详细说明它们的相应用法。

图2：a) 安全构建块（SBB）1：认证更新分发和b) 认证密钥更新策略（RKP）

两个更新应用策略都包含一个 TPM2_PolicyTemplate 命令，用于将密钥派生限制为策略中提供的确切模板。实际 KDF 的输入是更新包哈希（HashFWECU）、SID 和秘密派生密钥 KECU 派生。因此，派生的密钥特定于每个更新（HashFWECU）、SBB（SID）和 ECU（KECU 派生）。

RKP 在更新分发期间用于将非对称数字更新签名（AuthECU 非对称）重加密为适合资源受限车内网络的轻量级对称 HMAC（AuthECU 对称）。它确保只有在 AuthECU 非对称验证成功后，才能派生必要的重加密 HMAC 密钥（K 重加密 HMAC）。如图 2.b）所示，RKP 包含一个 TPM2_PolicyTemplate 和一个 TPM2_PolicyNV 命令。TPM2_PolicyNV 用于仅当相应的 NV 索引包含预期值时才允许密钥派生。该值表示 TPM 审计会话中成功签名验证的 HMAC。

IAP 用于在更新成功传输到目标 ECU（ECUU）后授权更新的实际安装。成功处理后，它允许派生用于响应更新安装请求挑战的更新安装密钥 HIMAC。IAP 对密钥派生执行预期的安全策略。如图 3.b）所示，IAP 包含一个TPM2_PolicyTemplate 和多个 TPM2_PolicySigned 命令。每个 TPM2_PolicySigned 要求来自不同条件 ECU（ECUC）的挑战 - 响应认证，从而将密钥派生绑定到各种 ECUC 报告的更新就绪状态。例如，特定的 ECU 可以是防盗控制器，只有在防盗器激活且车辆处于更新就绪状态以进行更新安装时，才会响应挑战。TPM2_PolicySigned 的数量与用于证明更新就绪状态的 ECU 数量相关。我们的需求分析表明，当前的汽车法规需要三个条件（参见第 3.3 节，SR02UN156）。

图3：a) 安全构建块（SBB）2：协同更新授权和b) 经过认证的安装授权策略（IAP）

4.2 配置协议

配置通常在安全环境中进行，要么在 ECU 生产期间，要么在工厂装配期间。

在此步骤中，随机创建的公共基础密钥（KECU 派生）被安全部署在 TCU 和 ECU 的可信子系统中（参见图 1），以防止未授权的读取和修改。在 TCU 上，这将是 TPM。在 ECU 上，这可以是典型的汽车硬件安全模块（HSM），例如符合安全硬件扩展（SHE）规范，或者对于更简单的 ECU，例如 ARM TrustZone（TZ）或轻量级设备标识符组合引擎（DICE）。这些假设似乎是合理的，因为例如，文献的作者表明 HSM 和可信执行环境（TEE）如 TZ 在汽车领域是可行的，而文献的作者展示了如何将 DICE 和 TPM 安全联锁以建立轻量级车辆认证机制。

在 TPM 上，创建一个派生父密钥（KTPM 父派生），该密钥安全地包装（加密）KECU 派生作为敏感参数。KTPM 父派生创建时带有授权策略，该策略仅在成功处理由 US 的签名密钥 Kiss 签名的 TPM 策略时才允许密钥访问。根据 TPM 规范，KTPM 父派生的敏感部分（KECU 派生）永远不能离开 TPM，只能加载到这个特定的 TPM。KTPM 父派生的授权使用稍后将仅通过密钥句柄（HKTPM 父派生）进行。

4.3 更新协议

如概念章节中所述，我们将实际的更新协议设计为两阶段协议。每个阶段由专用的安全构建块（SBB）表示。它们是（1）认证更新分发和（2）协调更新授权。SBB1 用于将更新从 US 通过 TPM 安全分发到 ECU，其中 TPM 执行更新的重加密，从而充当将 US 的非对称签名转换为 ECU 可以验证的对称 HMAC 的 “加密代理”。SBB2 用于通过执行车辆中的某些条件（例如回滚保护或安全车辆状态）来授权实际的更新安装。接下来的两节详细介绍这两个 SBB。

4.3.1 安全构建块（SBB）1：认证更新分发

认证更新分发的构建块如图 2 所示。该构建块的目标是从 US 通过 TPM 到 ECU 的认证端到端更新分发。TPM 充当加密代理，执行认证器的重加密，将车辆环境中使用的非对称加密转换为车内网络中可行的轻量级对称加密。整个重加密过程完全在 TPM 的隔离环境中完成。

具体而言，US 首先创建更新包 FWEU、使用 KUS 签名的相应签名 AuthECU 非对称，并将随机盐值（SecureAuditSessionSalt）加密为 Encsalt，该盐值稍后用于在 US 和 TPM 之间建立共享秘密会话认证密钥（KSessianHIMAC）。KHMAC 稍后用于可靠地报告已建立的 TPM 会话中所有已执行命令的输入和输出，因此该会话类似于审计会话。US 将 FWECC 和 Encsalt 发送到 TCU，TCU 反过来已经将 FWECU 转发到 ECUU，并开始与 TPM 的审计会话。在会话建立期间，TPM 和 TCU 随机数（NTPM，NT）被发送回 US，以便 US 也可以计算 KSessioeHMLAC 和预期的会话 HMAC（Authsym）。

US 创建重加密策略 RKP（参见图 2.b），该策略允许只有在成功验证后才能派生。这是通过将的使用与 RKP 绑定到表示所有已执行命令的输入和输出的预期会话 HMAC 来实现的。US 将 RKP 发送回 TCU。同时，TCU 在审计会话中执行 TPM2_VerifySignature 的签名验证。之后，TCU 检索会话 HMAC 并将其写入 TPM 的 NV 内存。

为了创建的 HMAC，需要通过在 TPM 内处理 RKP 来授权使用 e 进行密钥派生。RKP 通过 TPM2_PolicyNV 要求其包含的必须与存储在 TPM 的 NV 内存中的相同。TPM 中正确的计算取决于签名验证的成功。此外，由于引入了随机数，它对于每个会话都是唯一的，并且由于秘密，攻击者无法计算。因此，如果策略检查成功，则签名已成功验证，然后使用派生密钥的句柄创建对称认证器。它与一起发送到。最后，将通过使用和重新计算来验证。

4.3.2 安全构建块（SBB）2：协调更新授权

协调更新授权的构建块如图 3 所示。该构建块的目标是确保：（1）将要安装的映像是正确的（R07）、未修改的（R02）和最新的（R05）固件；（2）车辆处于更新就绪状态以进行更新（R04），例如车辆仍有足够的电量完成更新。

具体而言，派生特定于更新的密钥 KHMAC，其中 KDF 的输入是更新包哈希（HashFWECU）、SID2 和秘密派生密钥 KECU 派生。此外，创建一个 TPM 策略，该策略定义只有在满足以下限制时，才能在 TPM 中派生密钥：（1）TPM2_PolicyTemplate 用于将密钥派生限制为确切的 KHMAC。（2）TPM2_PolicyNV 用于仅当表示软件状态的相应 NV 索引处于正确状态以防止降级攻击时才授权密钥派生；（3）TPM2_PolicySigned 用于仅当车辆处于更新就绪状态时才授权密钥派生。最后一个策略命令可以在策略中出现多次，其中每个命令对应于不同的 ECU（例如电机控制器、电池控制器和主机单元）。IAP 可以在常规更新分发中传输，例如如 SBB1（第 4.3.1 节）中所述，然后存储在 TCU 上。

在根据更新分发接收并验证更新包后，ECU 从 KDF 派生更新安装授权密钥 HIMAC。之后，ECU 通过 TCU 与 TPM 启动挑战 - 响应认证方案。

由于 TPM 内的密钥派生绑定到密钥派生策略 IAP，因此需要成功处理 IAP 才能回答挑战。这意味着根据特定策略，需要通过挑战车辆内的一个或多个条件 ECU（ECUC）来验证车辆状态。成功处理 IAP 后，按照 TPM2_PolicyTemplate 的规定派生 KHMAC，TPM 返回其授权的密钥句柄 HKInstallHMAC。使用此 HKInstaHMAC 和挑战，计算 HMAC 作为响应。响应被发送回 ECU，然后 ECU 通过重新计算 HMAC 来验证响应。如果 HMAC 验证成功，ECU 将安装更新。

本章详细介绍了我们用于更新概念原型实现的硬件、软件和加密原语。此外，本章包含安全性评估（讨论我们安全需求的满足情况）和可行性评估（阐述解决方案在车辆环境中的适用性）。

5.1 原型实现

为了原型化我们的更新概念，我们增强了现有的汽车评估平台，该平台已经具有汽车以太网主干网，并添加了（1）我们的更新目标和条件 ECU（ECUU/ECUC）以及（2）我们设计的符合系统模型的车载更新代理（参见第 3 节）。车载更新代理和 ECU 通过汽车以太网连接。与后端 US 的通信通过 Wi-Fi 进行。附录 A 显示了最终平台。

5.1.1 原型硬件和软件

我们现在简要描述用于实现原型的硬件和软件以及加密原语和方案。

硬件：我们在树莓派上实例化车载更新代理和 ECU，因为它们的功能类似于相应的汽车对应物，例如大众汽车的模块化信息娱乐平台（MIB），该平台结合了主机单元和 TCU。我们通过串行外设接口（SPI）将作为铱星附加板一部分的 TPM 连接到树莓派的引脚_header。

软件：我们使用开源 Linux TPM2 & TSS2 软件仓库的 TPM2 软件栈实现和基于命令行界面（CLI）的 TPM2 工具与 TPM 通信，并将缺失的软件增强建议（主要关于密钥派生和 JSON 策略处理）反馈给该项目。在后端，我们使用链接到高级 TSS 2.0 功能 API（FAPI）库的 TPM2 工具，根据 JSON 数据类型和策略语言规范创建必要的 TPM2 策略，并使用 OpenSSL 为创建的更新包和策略创建签名。对于车内车载更新代理，我们将基于 C 的程序直接链接到针对嵌入式设备的 TSS 2.0 增强系统 API（ESAPI）。

加密原语：通过我们的设计概念，车载更新代理（特别是其 TPM）将系统分为适合车辆环境的非对称世界和适合车内网络的对称世界（参见图 1）。对于非对称世界，我们实现了基于 RSA 和 ECC 的方案，用于后续的性能评估。因此，用于签名更新包和策略的签名使用要么是带有 P-256 曲线和 SHA-256 作为哈希算法的 ECDSA，要么是带有 2048 位密钥长度和 SHA-256 作为哈希算法的 RSASSA。对于对称世界，使用 256 位 HMAC 密钥。对于密钥派生，我们使用 NIST SP800-108 的计数器模式，其中 HMAC 作为伪随机函数。

5.2 安全性评估

我们系统的核心安全概念依赖于车辆中的 TPM 作为信任锚，该信任锚安全地分发更新，并在某些条件（如安全车辆状态或更新版本号）下授权更新安装，以防止降级攻击。我们将两个安全构建块（SBB）SBB1 和 SBB2 专门用于这两个主要安全功能。第 4 节更详细地解释了它们。所有安全敏感的车辆密钥仅存储在相应 ECU 的密钥存储和 TPM 的隔离环境中，其使用受到我们设计的授权策略的保护。这种设计将 TCB 最小化为仅加固的 TPM（防止软件的逻辑运行时攻击和物理侧信道或（半）侵入性篡改攻击 [41]）、特定更新 ECU 的密钥存储以及更新供应商（US）后端的安全环境。在设计协议时，我们利用 TPM 支持的众所周知且经过深入分析的加密构建块，从而在交互实体之间获得强大的安全保障。整体安全概念通过满足我们的系统需求来保证，现在将对其进行讨论。R10 将在第 5.3 节中讨论。

R01：安全更新过程：与更新过程相关的所有安全敏感操作都在 US、TPM 和目标 ECU 内的定义可信组件中安全处理，以防止对更新系统本身的攻击。通过我们的设计，US 上存储的安全敏感密钥被最小化（参见 R03），唯一的安全关键密钥是更新签名密钥和签名创建。在这个有限的范围内，在没有任何外部连接的物理隔离环境（气隙）中处理后端签名操作是可行的，以防止任何远程攻击。通过使系统符合 TPM 功能，我们可以最小化和加固车载更新代理的 TCB，以便所有更新过程和数据都可以在其隔离环境中完全处理。因此，我们将 TPM 设计为车辆中的信任锚，并利用它作为车辆的主要安全提供者。资源受限的 ECU 的安全性可以保持最低，只需要安全的密钥存储和 HMAC 支持。

**R02：经过认证和完整性保护的软件更新。我们专门用 SBB1 来满足这一要求。更新分发的真实性和完整性通过从更新供应商到 TPM 的互联网连接传输的非对称签名方案以及从 TPM 到目标 ECU 的车内网络对称 HMAC 方案来保证。TPM 负责将非对称方案转换为对称方案。转换过程由独特的策略保护，该策略仅在更新签名验证成功后才对更新包进行对称重加密。签名和策略验证步骤均在 TPM 的隔离环境中完全处理。

R03：安全密钥管理。与 R01 一样，安全敏感密钥也在我们的可信组件中处理。在后端，只有更新签名密钥是安全敏感的，我们建议使用气隙来减轻远程攻击。所有车辆特定的对称密钥都在 TPM 的隔离环境中受到保护并专门使用。对于 ECU，我们假设密钥存储由 HSM 保护，或者至少对于能力较弱的 ECU，由 DICE 保护。

R04：条件更新。这一要求通过 SBB2 解决。目标 ECU 通过挑战 - 响应方案向 TPM 请求更新安装授权。只有当 TPM 正确响应挑战时，ECU 才会执行更新。相应的密钥授权策略（见图 3）将 TPM 密钥的使用绑定到特定的更新状态计数器（防止降级攻击）和从车辆中各个 ECU 安全获取的更新安全车辆状态。对这些 ECU 的信任源于它们的可信组件，例如使用 ARM TZ 或 DICE 实例化的组件。只有当这些条件验证成功后，TPM 才会授予密钥使用权限，ECU 的挑战才能成功应答。相应的更新授权密钥由目标 ECU 和 TPM 之间的共享基础密钥派生而来，并且是特定于更新和车辆的，因此可能的泄露不会影响其他更新。

R05：防止未授权回滚。SBB2 中的更新授权策略（见图 3）减轻了回滚和重放攻击。相应的策略将 TPM 内的密钥派生绑定到随每次更新递增的特定于更新的计数器值。因此，旧更新会被丢弃，因为它们绑定到较低的计数器值。

R06：离线签名密钥。我们设计的系统中，后端唯一的安全敏感密钥是更新签名密钥，该密钥可以在完全离线的环境中使用，例如受气隙保护的安全环境。后端中使用的其余密钥都是公钥。这种设计将后端的攻击面降至最低。

R07：正确的更新。SBB2 确保安装正确的更新。更新固件的哈希和 ECU 特定的基础密钥用作 KDF 的输入，从而派生特定于更新和 ECU 的更新密钥，确保为目标 ECU 安装正确的更新。

R08：半离线能力。在我们的概念中，我们将更新分发和安装步骤分为两部分。虽然安全非关键的更新分发（SBB1）需要在线连接以从后端传输更新包，但安全关键的更新安装过程（SBB2）完全离线进行，同时考虑更新安全的车辆状态，并排除在线连接作为单点故障。

R09：ECU 外安全执行。我们通过将车载更新代理（特别是其 TPM）设计为系统的主要安全提供者，解决了车内网络能力有限的问题。因此，实际 ECU 的安全开销降至最低。SBB1 和 SBB2 都通过以下方式为此做出贡献：（1）将任何资源密集型的非对称方案转换为轻量级的对称方案；（2）在更新前处理更新授权，例如回滚保护或确保安全的车辆状态。

5.3 汽车可行性评估

我们设计的 OTA 更新系统适合异构的汽车领域，并通过 R10 定义了一个专门的要求来评估解决方案的可行性。在前一节中，我们重点关注其安全优势，并表明由此产生的强大安全保障是当前任何相关工作都无法实现的。本节重点关注该解决方案在汽车领域的整体可行性。

首先，我们从针对汽车行业的攻击者和系统模型中推导出系统要求，并使它们与相关汽车标准和法规以及针对汽车领域的相关工作的威胁和要求保持一致。第 5.2 节评估了已定义要求的满足情况。此外，该系统还兼容 OTA 以及通过 OBD-II 接口在维修店进行的本地更新程序。

其次，我们分析了异构的汽车环境，一方面在后端系统中拥有成熟的服务器基础设施，另一方面在车内网络中资源非常有限。因此，我们将车载更新代理设计为 “加密代理”，将易于管理但资源密集的非对称加密（最适合后端）转换为轻量级的对称加密（最适合车内网络）。我们将所有对称密钥存储在车载更新代理的 TPM 隔离环境中，这样后端只需要处理非关键的公钥和一个离线更新签名密钥，该密钥受到保护以抵御所有远程攻击，例如通过气隙。

第三，我们将系统设计为以 TPM 作为主要的车内安全提供者。ECU 与 TPM 建立信任关系，并仅验证其授权。这种设计在保持最高安全保障的同时，将资源受限的 ECU 的安全开销降至最低。

表2：美国、TCU和ECUU/ECUC之间传输的密钥更新和更新授权的消息大小（ECC/RSA)

表3：密钥更新（SBB1）和更新授权（SBB2）的执行时间（单位：毫秒）。报告了1000次执行所得的平均值（及标准差）

第四，我们在增强的汽车评估平台中实现了我们的系统，并在传输大小（表 2）和计算（表 3）方面都实现了合理的低开销。如表 2 所示，大部分数据在后端和车载更新代理之间的车外通信中交换。在资源受限的内部网络中传输的消息开销保持最小。正如我们的 “加密代理” 设计概念所预期的那样，表 2 还显示非对称加密仅用于与后端的外部通信，而内部通信仅限于对称加密。表 3 详细列出了使用 RSA 或 ECC 基于方案进行签名验证时 SBB1 和 SBB2 的执行时间。它还显示了对称 HMAC 操作的时间，以比较非对称和对称执行时间。执行时间按 TCU 分层聚类，以显示实际 TPM 处理的执行时间。SBB1 的整体处理时间为 890.359 毫秒 / 735.666 毫秒（RSA/ECC），SBB2 为 1157.578 毫秒 / 860.218 毫秒（RSA/ECC）。非对称算法仅用于验证更新（1.1.1.）和策略（1.1.3./2.1.4.）签名。TCU 上的所有其他操作要么是对称的（1.1.4./5.，&2.1.5/6.），要么不使用任何加密。此外，表 3 报告了网络传输（1.2.，2.2.，2.4.）和 ECU 处理（1.3.，2.3.，2.5.）时间，包括 ECUU 和 ECUC。虽然 SBB1 在消息大小和计算开销方面是恒定的，但 SBB2 的开销根据为车辆状态查询的额外 ECU（ECUC）的数量而略有不同。我们对相关标准和相关工作的需求分析表明，需要三个 ECUC 来报告更新就绪的车辆状态（参见第 3.3 节，R04）。我们在第 4.3 节中讨论了它们。

对于外部通信，当查询一个 ECUC 时，传输开销从 2215/2727 字节（RSA/ECC）增加到查询三个 ECUC 时的 3591/4103 字节（RSA/ECC）。随着查询的 ECUC 数量增加，计算开销在两个 ECUC（2.a）时为 1171.004 毫秒 / 878.562 毫秒（RSA/ECC），在三个 ECUC（2.b）时为 1187.213 毫秒 / 992.106 毫秒（RSA/ECC），考虑到更新可能需要数小时才能完成，即使在三个 ECUC 的最坏情况下，这也是相当低的。由于我们的解决方案符合开放的 TPM 规范，因此可以轻松集成具有可能性能改进的下一代 TPM。

汽车安全 OTA 软件更新在科学领域得到了广泛研究。最近的一项调查根据以下方面对它们进行了分类：（1）对称密钥加密，（2）哈希函数，（3）非对称密钥加密，（4）区块链，（5）RSA 和隐写术，（6）安全更新框架，以及（7）硬件信任锚（HTA）。

图4：1次OTA更新生命周期中TCB与相关工作的对比

表4：与相关工作的比较

在图 4 和表 4 中，我们将它们与我们的工作进行了比较，并参考了我们的攻击者模型（参见第 3.2 节）。图 4 详细说明了与已建立的 TCB 相关的不同保护保证。我们在 OTA 更新过程的典型程序中分析 TCB：（1）配置，（2）（更新）分发，以及（3）安装授权。所有不使用 HTA 的工作都专注于保护通信通道。它们的 TCB 包括所有软件，因此该系统无法抵御我们的物理（A2）和运行时攻击者（A3）。对于所有不使用 HTA 的工作，TCB 包括所有软件，因此该系统无法抵御我们的物理（A2）和运行时攻击者（A3）。研究使用 TPM，并在配置期间防御所有攻击者。然而，在分发期间，仍然依赖软件进行重加密，因此容易受到 A2 和 A3 的攻击，而 [8] 依赖测量启动，仍然容易受到 A3 的攻击。研究使用 HTA，但没有详细说明如何使用它们。因此，安全保证尚不清楚。只有开发了重加密概念，将后端非对称加密转换为车内对称加密。然而，如前所述，他们依赖纯软件机制进行重加密。分析的相关工作均未涉及安装授权。

在本文中，我们提出并原型化实现了一种新颖的联网车辆安全 OTA 软件更新概念，该概念使用可信平台模块 2.0（TPM 2.0）作为车辆中的信任锚，并在原型实现中评估了其可行性。我们进行了广泛的需求分析，以推导出我们的系统安全要求，并使它们与相关标准、法规以及汽车领域中关于安全 OTA 更新的其他相关工作保持一致。我们设计的系统满足我们定义的要求，并且通过将车载更新代理的 TCB 最小化为仅包含 TPM 2.0 来加固它。我们将我们的解决方案与各种相关工作进行了比较，结果表明，即使有些工作也将 TPM 用作车辆中的 HTA，但目前没有类似的 OTA 更新分发概念能够在提供相当强的安全保证的同时，满足我们提出的所有要求并具备相应功能。

我们通过将系统设计为完全符合 TPM 2.0 的高级功能和强大的安全特性来实现这些强大的安全保证。我们将 TPM 2.0 设计为车辆中的主要安全提供者，它（1）通过将非对称方案转换为资源受限的车内网络中最可行的轻量级对称方案，将更新包从后端安全传输到目标 ECU；（2）通过执行某些条件（例如更新就绪的车辆状态）充当更新安装授权点。

该系统设计为所有安全和安全关键的更新过程以及加密密钥都由 TPM 2.0 完全处理。我们设计的协议利用 TPM 2.0 中易于理解且经过深入分析的加密构建块，在交互实体之间实现强大的安全保证。我们还将相关的实现细节反馈给了 TPM 2.0 开源社区。据我们所知，目前没有类似的 OTA 更新分发概念能够在提供相当强的安全保证的同时，满足我们提出的所有要求并具备相应功能。