高效安全的汽车无线更新框架

一种高效且安全的汽车无线软件更新框架

摘要

未来车辆将无线连接到周边车辆、道路基础设施和互联网，从而成为物联网的有机组成部分。未来的智能车辆将集成新的舒适功能、安全功能以及多种新型车辆专用服务。这些功能包括一种快速、安全且可靠的车辆诊断和重新配置方式，以及在其集成的电子控制单元上安装新软件的方法。此类无线软件更新对汽车原始设备制造商和客户均有益处，可通过空中下载方式安全地启用新功能并修复软件缺陷。安全可靠的无线软件更新过程在现代车辆的整个生命周期中都具有重要价值，不仅可在车辆开发和装配线制造过程中使用，也可用于服务中心的车辆维护。此外，未来车辆将支持远程下载最新软件到电子控制单元。

为了支持整个车辆生命周期内的这一过程，需要一个通用框架。本文提出了一种能够实现安全高效无线汽车软件更新的通用框架SecUp。SecUp利用IEEE 802.11s作为无线通信介质，以可靠且快速的方式连接车辆和诊断设备。此外，SecUp支持并行和部分软件更新等有益的无线软件更新功能，以提高效率，并包含先进的安全机制，防止滥用和攻击。

索引术语

汽车系统, 通用框架, IEEE 802.11s, SecUp, 安全概念, 无线软件更新

I. 引言

MODERN 车辆包含越来越多的电子控制单元（ECU），以集成新服务。这些服务需要在车辆的集成ECU上实现复杂且通常是分布式的软件（SW）实现，从而增加了软件的复杂性。此外，车载系统日益增强的连接性和分布式特性可能会在汽车软件（SW）实现及相关功能中引入越来越多的缺陷。

修复此类软件缺陷以及升级ECU软件以实现新功能，需要允许高效汽车软件更新的新概念。这些概念支持现代车辆的开发和维护。在整个现代车辆的生命周期中，高效且安全的软件更新都将带来益处，并将显著减少车辆维护所需的时间。

本文提出了一种通用框架SecUp，可实现无线软件更新和诊断。与现有方案不同，仅关注无线远程更新的系统（如[1],[2],[3],[4], SecUp）支持现代车辆的整个生命周期，考虑来自不同应用场景（即车辆开发、装配和服务中心维护）的需求。在所有这些场景中，在专用区域（例如服务中心或装配线）本地执行的无线软件更新必须快速、高效且安全。为了实现高效且快速的无线软件更新，SecUp除了提供基本的汽车无线软件更新功能外，还支持并行软件更新（在同一时间将相同的软件二进制文件安装到不同的车辆和电子控制单元上）和部分软件更新（仅安装软件中发生变化的部分）等有益特性。

此外，SecUp采用基于强身份验证和加密机制的全面安全概念，以确保安全的无线软件更新。该安全概念还保证了传输数据和整个车辆的完整性。因此，SecUp能够保护诊断设备、传输的数据、车辆以及OEM主干网络免受未授权访问。

本文的关键贡献是提出了SecUp，一种通用框架，可实现高效且安全的无线软件更新，适用于不同的汽车应用场景，即：（i）车辆开发中的软件更新，（ii）装配线上的软件更新，以及（iii）服务中心维护期间的软件更新。SecUp不仅支持基本的无线软件更新，还通过支持并行和部分软件更新来提升效率。此外，SecUp基于一种新颖的安全概念构建。

本文结构如下。在第二节回顾相关工作后，第三节描述了SecUp及其架构。此外，还列出了所采用的IEEE 802.11s网络的优势，证明其适用于执行高效且可靠的无线软件更新。第四节重点说明了在所考虑的应用场景中涉及的设备和用户的角色。第五节概述了进行的安全分析以及由此得出的安全概念。第六节介绍了核心节点的开发原型，并描述了用于评估SecUp的不同汽车电子控制单元，同时介绍了所开发的支持并行或部分软件更新的功能。为了评估SecUp，首先在第七节分析了SecUp的安全概念及其对系统性能的影响；其次，在第八节描述了对SecUp的评估并给出了相应的结果。最后，第九节给出了结论。

二、相关工作

与传统（即有线）软件更新相比，汽车空中下载技术（OTA）更新的优势列于[1]中，并提出了这些更新的高层架构。然而，该文未包含对无线介质、所需安全机制或其他技术细节的描述。[5]的作者基于国际标准描述了电子控制单元的软件更新过程。但是，该项工作完全没有涉及此类更新的无线方法。

之前一些作者的研究（如[2],[3],[4],[6],[7],[8]）仅关注车辆远程软件更新及其相应的安全问题，但既未考虑在本地执行更新的其他场景（例如在服务中心内），也未支持诸如并行软件更新等高级软件更新机制。Idrees等人提出了一个支持空中下载技术更新的系统[2]。该系统利用硬件安全模块（HSM）在无线接口和车辆的所有电子控制单元上实现数据加密、密钥管理以及确保数据完整性。因此，每个电子控制单元都需要配备一个HSM，这将导致显著的额外成本。此外，作者并未提供有关无线链路具体类型或特性的任何信息。[9]的作者也建议在电子控制单元和车辆网关上使用安全硬件模块以保护空中下载技术更新。他们重点研究了如何将这些模块集成到电子控制单元中，并评估了由此带来的资源开销。该论文还包含了一个空中下载技术更新架构的高层描述，但未提供具体的实现细节或评估结果。Nilsson等人[3],[4]提出了一种通过互联网连接将车辆与门户服务器相连以实现汽车空中下载技术更新的系统。他们列出了关于空中下载技术更新的重要安全方面，特别是数据完整性和数据机密性，但既未描述所使用的无线网络，也未说明网络中的数据流。在[7]中提出了一种通过发送软件的多个副本来确保数据完整性的安全无线软件更新架构。然而，该方案仅适用于一辆车辆与原始设备制造商（OEM）服务器之间的点对点链路，并依赖于大量先决条件（例如通过发送多个副本来确保空中下载技术更新的数据完整性）。[8]的作者也建议将软件二进制文件向车辆发送两次以保障更新过程的安全性，但未提供关于实际软件更新框架或其他技术细节的详细描述。

尽管之前的研究提出了不同的系统，以实现远程空中下载技术更新并解决相应的安全方面问题，但所列出的解决方案仅针对单播链路（即原始设备制造商与特定车辆之间的点对点连接），因此无法实现并行或部分软件更新等功能。与此不同的是，SecUp 可同时在多辆车辆上安装最新软件，并提供高效的软件更新机制（即并行或部分软件更新）。

截至2017年，特斯拉是唯一提供汽车空中下载技术更新解决方案的汽车制造商。通过无线网络（基于3G/4G或Wi-Fi网络将车辆连接到互联网）来传输最新软件从原始设备制造商的服务器到特斯拉车辆[10]。然而，这种原始设备制造商与车辆之间的点对点连接无法用于在不同车辆以及多个电子控制单元上并行同时安装软件。

[2],[3],[4],[7]的作者主要关注汽车软件更新的不同安全性方面，并列出了一些相关的安全威胁，即：数据机密性、数据完整性、密钥交换与管理以及车辆完整性与认证。与以往的研究不同，本文提出的并在第V-B节中阐述的安全概念同时涵盖了所有这些方面。

A. IEEE 802.11s网状网络及其安全特性

所提出的用于无线软件更新的框架利用IEEE 802.11s网络将车辆与诊断硬件互连。目前，这是唯一使用11s作为无线软件更新媒介的解决方案，但该协议也已应用于其他汽车应用中：文献[11]和[12]的作者将 IEEE 802.11s用作车对车和车对基础设施通信（V2X）网络的骨干网络，以互连V2X实体和路侧单元。在[13]中，比较了多种无线通信协议，如IEEE 802.11（Wi-Fi）、蓝牙低功耗（BLE）、IEEE 802.15.4（ZigBee）和 IEEE 802.11s，以找出最适合汽车环境中无线软件更新的协议。在此过程中，作者重点关注吞吐量、可扩展性以及可扩展性等方面，表明IEEE 802.11s是唯一能够满足所有考察方面的协议，并指出了其他协议的弱点（例如，BLE和ZigBee提供的吞吐量不足）。尽管作者揭示了 IEEE 802.11s在无线汽车软件更新中的适用性，但该论文并未包含任何能够实现此类更新的框架描述。利用IEEE 802.11s网络进行无线汽车软件更新的优势列于第三节-B。

一些主要关注IEEE 802.11s安全性的贡献提出了不同的扩展和改进。然而，这些方面尚未针对汽车应用进行讨论。Tan等人[14]描述了对IEEE 802.11s网络的内部攻击和外部攻击，并列出了相关的安全性要求。作者指出，IEEE 802.11s中使用的对等实体同时认证(SAE)[15]能够缓解外部攻击。然而，SAE无法防止一系列内部攻击，因此需要额外的安全特性。

在[16]中，使用GPS定位来缓解针对IEEE 802.11s的各种潜在攻击。文中提出的称为PASER的系统在[17],中与其他用于安全IEEE 802.11s网络的方法进行了比较，作者表明，这些方法在时间和功耗效率方面存在不足。然而，如[16]和[17],中所提出的使用GPS的方法，在装配线或服务中心内并不适用，因此SecUp无法利用PASER。

[14],[18],[19],[16],[17]中提出的方案允许创建安全的IEEE 802.11s网络，然而，这些方案均无法同时满足无线软件更新的效率要求以及抗可能的攻击。第五节中提出的定义的安全概念通过在网络层和应用层使用安全机制，满足了这两个方面的要求。特别是，所提出的安全概念基于结构化安全分析，在[20]中已对此进行了详细描述。本文还展示了如何利用该分析来设计符合SAE J3016[21],这一汽车领域安全标准的汽车应用。

第三节. 框架与架构

本节描述了SecUp.A的架构，系统概述在第三节-A中给出，所使用的无线网络在第三节-B中讨论。

A. 系统架构与核心节点

安全高效的无线软件更新将独立于应用场景，需要一个可靠且快速的无线网络。此外，每辆车辆都需要一个可靠的智能网关接口，以可靠且安全的方式将车辆与无线网络连接。该接口是SecUp中最关键的组件，称为无线车辆接口（WVI）。WVI将车载通信基础设施（即CAN等汽车总线系统）以及车辆的电子控制单元与无线网络，并进一步与互联网相互联接。

WVI可以实现为完全集成设备（即智能总线网关或专用ECU），也可以实现为插件式解决方案。后者可通过车辆的OBD接口临时连接到车辆，主要应用于服务中心场景，在这些场景中，WVI的插件特性以及标准化车载通信协议的使用确保了向后兼容性和独立于原始设备制造商。

在未来车辆中，WVI将成为车载通信系统的一部分，从而实现需要访问车辆生成或存储数据的新服务和功能。

所谓的诊断测试仪（DT）可以在无线软件更新框架中被视为新软件版本的来源。它可以通过骨干链路连接到原始设备制造商（OEM），以获取最新的可用软件以及车辆的相关信息，例如车辆配置（如电子控制单元的类型和ID）或所需的授权密钥。根据具体场景和其他一般条件，DT可以是专用设备（例如服务中心中的工具），但更可能是运行在笔记本电脑、个人计算机或服务器上的软件应用。此外，DT通常支持多种诊断功能。在典型的OTA更新场景中，DT应用程序运行在汽车制造商的服务器上，并在WVI与DT之间建立安全互联网连接（例如VPN隧道）。

在SecUp中，连接到无线软件更新系统的手持设备由服务中心的机械师或车辆开发阶段的工程师使用，用于：i）执行无线诊断，ii）监控车辆不同总线系统上交换的消息，以及iii）触发、监控和验证软件更新过程。

B. 无线IEEE 802.11s网络

为了互连第三节-A中描述的所有相关节点，SecUp利用了IEEE 802.11s网络。根据[13],，该协议最适合无线汽车软件更新，并在吞吐量、可扩展性以及可扩展性等不同重要方面优于其他无线标准，如蓝牙低功耗或ZigBee。

IEEE 802.11s基于网状网络拓扑，其中每个节点将直接与其传输范围内的其他节点通信，或通过中间的其他节点转发数据包至目标目的地。IEEE 802.11s的网状特性允许数据包在网络中传输时选择不同的路径。这种隐式冗余提高了IEEE 802.11s网络的可靠性。类似地，可以通过在网络边缘添加中继节点（例如其他车辆或设备）来增加网络的传输范围。

IEEE 802.11s的多跳能力是一项关键优势，可显著提高此类网状网络的可靠性和可用性，从而使得IEEE 802.11s网络也可在恶劣的无线环境中使用。

如图1所示并在第IV-B节中进一步描述的现代服务中心是一个典型恶劣环境的例子，因为无线链路可能受到车辆或其他（金属）物体的屏蔽影响，从而降低数据传输/收集的可靠性。然而，IEEE 802.11s网络能够提供稳定的通信：如果车辆与DT之间的直接链路太弱而无法交换数据包，则位于中间的其他车辆或IEEE 802.11s中继节点将转发数据包至目标车辆或DT。

IEEE 802.11s 标准在网状网络中包含组播数据流。这种组播可用于将数据包从一个节点发送到网络中的多个其他节点。因此，SecUp 可能会利用此类第二层组播，同时在多辆车辆上传输并安装新软件版本（即执行并行软件更新）。尽管 IEEE 802.11s 标准定义了组播数据流，但当前在所开发框架中使用的 open11s 实现 [24] 尚不支持第二层的组播，因此组播在高层实现。

IV. 支持整个车辆生命周期

本节首先列出了考虑的无线软件更新场景。随后，在第IV-B节中给出了服务中心内无线软件更新的示意图。

A. 无线软件更新场景

SecUp能够满足以下场景中无线软件更新的要求：i) 车辆开发期间，ii) 装配线中，iii) 服务中心内。下文将重点说明各场景的具体需求，并提供有关相关用户、可用基础设施以及安全性的信息。

1) 车辆开发 ：在车辆开发阶段，工程师需要多次更新测试车辆中一个或多个电子控制单元的软件，以分析、比较和评估新开发的功能。因此，开发工程师需要一个灵活且高效的系统，支持无线软件更新以及车辆诊断。车辆开发活动主要在受限区域内进行，由工程师（即专家用户）执行。在此场景下，无线解决方案具有多项优势，能够实现快速、灵活的软件更新，同时支持使用平板电脑或智能手机等手持设备。

2) 车辆装配 ：此步骤在高度自动化和安全的环境中进行，许多操作由机器和机器人完成。在车辆离开装配线之前，必须在其所有集成ECU上安装最新软件。因此，必须对大量车辆的软件进行更新——理想情况下并行更新，以在所有ECU上安装最新软件。由于车辆数量众多且自动化程度高，软件更新系统的可扩展性、可靠性和效率至关重要。

3) 车辆维护 ：在服务中心，机械师将对多辆车辆进行诊断、维修和保养。因此，机械师会连接车辆以运行诊断功能，检查车辆及其电子控制单元是否发送了诊断故障码（DTC），并执行必要的维修。在此过程中，机械师还会检查车辆的一个或多个电子控制单元是否有新软件可用，并进行安装。同时进行的无线软件更新将非常有益，特别是在需要大规模车辆召回（例如由于严重软件缺陷）的情况下：机械师可以并行连接多辆车辆，并同时安装新软件。

此外，无线解决方案在服务中心也非常有利，因为机械师无需使用笨重的诊断设备（例如装在坚固金属外壳中的个人计算机和电池），而可以使用轻量级手持设备来执行无线诊断和软件更新。

4) 远程软件更新 ：主要适用于配备集成式WVI的未来车辆，该WVI可实现为总线网关或专用ECU，支持通过3G/4G或Wi-Fi实现无线连接。当前版本的SecUp主要关注在本地环境中执行的软件更新，但所开发的软件更新机制也可在车辆连接到用户无线网络时使用。

特定场景特性总结如下：在装配线或车辆开发阶段进行的软件更新由专家用户在安全受限区域中执行。在这些使用场景中，安全性是一个重要问题（例如工业间谍），但其关键程度不如OTA场景，因为在OTA场景中，更新由非专业用户在用户家中或公共场合执行，且可能使用受感染设备或不安全网络。特别是服务中心和装配线场景需要一种高效且快速的方法来安装软件更新。在车辆开发过程中，由于在此阶段需要执行大量功能测试、系统评估和诊断，因此特别需要通过轻松扩展无线网络的传输范围来实现高度灵活性。

B. 服务中心的无线软件更新

本节通过图1所示的典型服务中心场景，描述了在车辆的电子控制单元上安装最新软件所需的步骤。在此示例中，机械师使用手持设备进行无线诊断并执行无线软件更新来维护车辆。类似的流程和方案也适用于其他更新场景。

本节的主要目标是解释基本软件更新流程，而不涉及相关安全机制的细节，这些内容将在第V-B节中进行描述。

1) 将车辆连接到软件更新系统 ：维修技师首先通过OBD接口将WVI连接到车辆（即，如果车辆没有集成式WVI）。WVI加入IEEE 802.11s网络，并在接收到周期性广播的、宣告DT存在的信标后，与DT建立连接。手持设备采用相同的原理来连接DT（即，在接收到DT信标后），以及连接到WVI（即，通过发送信标）。需要注意的是，在进行更新时，软件直接从DT传输到WVI，出于安全性的考虑，不会存储在手持设备上。

2) 收集车辆信息 ：在诊断工具（DT）、手持设备和WVI之间的连接建立后，诊断工具（DT）通过获取车辆识别号（VIN）来开始收集车辆信息。利用获取的VIN，诊断工具（DT）可以查询其本地数据库或访问原始设备制造商（OEM）服务器，以获取车辆特定信息，包括车辆型号和变体、集成ECU（包括ECU-ID）和CAN-ID，以及可用软件版本。这些信息通常汇总在所谓的开放式诊断数据交换（ODX）[25]文件中。

3) 执行无线软件更新 ：如果车辆有新软件可用，软件二进制文件将首先从诊断工具完整传输到WVI。随后，WVI将验证接收到的软件二进制文件，并利用统一诊断服务（UDS）协议[26]开始在电子控制单元上安装该二进制文件。除了这种基础软件更新机制外，SecUp还支持部分软件下载，即仅发送当前软件版本与新软件版本之间的差异部分至电子控制单元。此功能可显著缩短软件更新的持续时间，但需要电子控制单元支持（另见第VI-D节）。为了并行对多辆车辆执行软件更新，技师将首先在诊断工具上为特定软件更新注册车辆，当所有车辆均准备好接收更新时，系统将自动启动更新。并行软件更新可再次显著缩短无线软件更新的持续时间，从而通过同时处理多辆车辆来降低成本。

V. 安全性和信任

安全性是无线软件更新的一个关键方面，因为攻击者可能会破坏相关的设备和协议以泄露敏感数据和钥匙。根据应用场景的不同，必须考虑不同的攻击向量，因此需要不同级别的安全性。

SecUp的安全概念基于以系统为中心的设计，采用可度量的安全性方法，如[27]中所述。所使用的设计方法 DEWI安全度量基于结构化的系统分解，而非传统的先分析攻击向量再实施相应缓解措施的方法。

这种以系统为中心的设计包含以下关键步骤：i）安全分析框架，从而得到安全的系统配置；ii）从安全的系统配置中提取安全需求；iii）基于这些需求和应用场景特点定义安全概念；以及 iv）使用STRIDE威胁模型对所定义的安全概念进行评估[28]。[20]提供了更详细的信息，并强调该方法可与新的SAE安全标准SAE-J3061[21]保持一致。

接下来将列出最重要的已揭示安全威胁，随后在第 V-B节中更详细地描述安全概念。该描述还展示了 SecUp的安全概念如何缓解这些威胁。更多详细信息见于 [29]。

A. 安全威胁和攻击向量

允许无线汽车软件更新的系统是多种攻击的有利目标。

接下来，我们将收集并描述关键的外部和内部威胁，并在后续步骤中说明SecUp所采用的安全机制能够有效防止这些威胁。

外部攻击者可能会窃听无线信道，以获取传输的授权密钥和最新软件本身，或篡改传输的数据，在车辆的电子控制单元上安装恶意软件（威胁T1）。

除了上述外部攻击（例如，由无法访问无线网络的黑客实施的攻击）之外，还存在由内部人员实施的一系列内部威胁，例如服务中心中的恶意技工或其他欺诈性使用无线网络的用户。这些内部威胁包括盗窃设备（如WVI），以执行未经授权的软件更新（例如，调校；T2）、提取存储在设备上的密钥（T3），或伪装WVI或诊断工具的身份（威胁T4），以获取密钥、软件或车辆访问权限。

为了缓解所有（上述）威胁，软件更新框架（如 SecUp）必须：i) 采用强身份验证方案，在相关设备之间建立信任；ii) 使用强加密以及消息认证码（MAC）来保护传输数据的机密性和完整性；iii) 在专用内存或硬件安全模块（HSM）中安全地存储敏感数据和密钥。

B. 安全概念

本节介绍的安全概念基于利用DEWI安全指标进行的系统分析结果。所形成的安全概念依赖于网络和应用层上的安全机制。

在网络层，wpasupplicant（一种适用于不同类型的无线网络的通用安全框架）被用于保护IEEE 802.11s网状网络。该wpa supplicant是当前open11s实现的一部分，可通过使用SAE [15]以轻量级方式保障网络安全。SAE专为基于802.11s的支持多跳的网状网络而设计，已完全集成到最新的wpa supplicant版本中，并能够有效缓解多种外部攻击 [14]。然而，SAE无法针对内部攻击提供适当的缓解措施，此类攻击中，攻击者利用已连接到无线网络的节点（例如受感染设备或服务中心中的恶意用户等，如威胁 T2-T4）发起攻击。因此，在应用层采用了额外的安全特性，以防止内部攻击，从而应对四个重要的安全方面，即车辆完整性与认证、数据完整性、数据机密性、密钥管理与交换。

为确保车辆的完整性，尤其是在配备WVI的情况下，必须采用强身份验证机制，以防止未授权用户访问车载总线系统。此外，更为重要的是避免攻击者通过攻破一辆车辆并提取共享的（即对称的）认证密钥，从而危及整个车队的安全。所开发的概念基于唯一的非对称密钥对 ，该密钥对包含私钥和公钥，应用于WVIs、手持设备以及诊断工具，以确保所有节点之间的唯一性认证。

在经典的公钥基础设施（PKI）中，公钥通过互联网等方式交换，并用于加密数据或验证数字签名。为了使用户能够检查某个公钥是否真正属于某一实体，经典的 PKI系统采用第三方——证书颁发机构（CA）。因此，每个节点都需要互联网连接以与证书颁发机构通信。

在SecUp中，选择了一种不同的方法：为了使系统保持本地化（即只有诊断工具连接到互联网和/或OEM主干网络），设计了一种无需CA的安全概念。然而，这种概念要求公钥最初进行交换并安全存储。该配对步骤由授权用户（例如服务中心负责人）在受控环境（例如靠近诊断工具）中通过专用介质或机制（例如SecUp支持近场通信和一次性密码的使用）完成。配对只需进行一次：首先，在每个设备上创建一个master key pair并安全地存储在专用内存或可信平台模块（TPM）中。其次，公钥被交换并安全存储。在初始配对步骤之后，主密钥可用于处理相关节点之间的认证，并用于签名和加密单播数据包。

由于WVI安全地存储了DT的公钥（反之亦然），因此可以使用基于RSA的数字签名（2048位密钥长度RSA签名和SHA-256哈希）对相关方进行认证。在认证步骤中（例如每日执行一次），双方协商生成一个基于 AES-GCM的对称会话密钥，用于确保数据传输的机密性和完整性。请注意，在SecUp中，i) 数据包使用会话密钥进行保护，而不是使用主密钥，因为对称密钥的使用更加高效；ii) 使用时间戳和随机数来保护交换的消息，从而防范重放攻击等常见攻击，类似于TLS和其他常见的安全消息传输协议。

为实现并行软件更新，需要安全的组播数据流，而这就需要使用对称密钥来验证和加密数据。从诊断工具发送到多个车辆的数据必须使用共享密钥进行签名和加密。该共享session key由诊断工具创建，然后通过使用诊断工具的私有主密钥签名的单播数据包 individually 分发给所有无线车辆接口。由此，组播数据包使用session key进行加密和签名，以确保交换数据的机密性和完整性。

通过利用主密钥对和（共享的）对称会话密钥，可以解决与车辆本身以及数据交换层面（单播和组播）相关的安全性方面的认证、机密性和完整性问题。为了防止攻击者提取所使用的钥匙（例如通过窃取WVI），这些钥匙必须安全地存储在设备上并始终保密。因此，SecUp中使用的钥匙存储在专用安全存储器或可信平台模块（TPM）中。

C. 安全概念在用例中的应用

第IV-B节中概述的服务中心场景将再次用于说明如何通过应用已定义的安全概念来确保无线软件更新的安全性（参见图2）：

1) 用户认证 ：机械师使用NFC智能卡和PIN码对系统进行认证。不同的用户配置文件用于授权不同模式：普通维修技术人员只能使用SecUp进行无线诊断。特权用户则可以额外执行无线软件更新。

2) 连接WVI ：在将WVI连接到车辆后，WVI上电并使用共享网络密钥连接到IEEE 802.11s网络。

3) WVI与诊断工具之间的认证 ：使用WVI和诊断工具的主密钥相互进行认证。

4) 并行软件更新 ：首先，诊断工具创建一个会话密钥，并将其分发给所有相关的无线车辆接口（单播）。其次，诊断工具通过使用会话密钥对每个数据包进行签名和加密，将分段的软件二进制文件发送给无线车辆接口（组播）。

5) 数据验证 ：为确保数据完整性，诊断工具首先计算软件二进制文件的哈希值。然后，诊断工具使用主密钥对该哈希值进行签名和加密，并发送将其单播至相关的WVI。因此，这些WVI在将接收到的软件二进制文件安装到相关电子控制单元之前，会使用传输的哈希值进行验证。请注意，在诊断工具的本地数据库中存储新的软件二进制文件之前，诊断工具会验证新软件的真实性（即软件确实来自原始设备制造商）。然而，此安全软件分发过程（参见[30]）不在本文讨论范围内。在当前概念中，由于诊断工具已经验证过，WVI不再重复验证其真实性。

D. 安全概念的形式化评估

所定义的安全概念首先使用微软STRIDE威胁模型 [28] 进行了正式评估。STRIDE是一种以攻击为中心的方法，可用于通过识别多种潜在安全威胁并将其归为六类来分析系统的安全性：S伪装（Spoofing）、T篡改（Tampering）、R抵赖（Repudiation）、I信息泄露（Information disclosure）、D拒绝服务（Denial of service）以及 E权限提升（Elevation of privilege）。应用STRIDE时，需对系统的每个部分进行分析，并确定每个组件或流程的所有潜在威胁。基于这些威胁，可在后续步骤中定义适当的缓解措施。SecUp的安全概念评估采用了类似方法：首先列出潜在的STRIDE威胁，并根据其发生的可能性和严重性进行优先级排序；其次，将这些威胁（理论上）应用于该安全概念及其安全特性，以证明存在适当的缓解措施来避免所有这些威胁。[29] 中更详细地描述了评估过程，并展示了形式化分析的结果。

由于空间限制，无法进行全面的威胁分析以及针对这些已识别威胁的系统评估。然而，在下文中，将使用第 V-A节中描述的威胁T1-T4来展示SecUp的安全特性。威胁T1涉及交换数据的机密性和完整性。在SecUp中，交换的数据通过以下方式得到保护：i) 网络层上的SAE，用于保护IEEE 802.11s网络并缓解外部攻击；ii) 应用层上的安全特性，包括逐包加密和完整性检查，以及通过将软件二进制文件的哈希值（由DT加密并签名）发送给 WVI，对传输的软件二进制文件进行最终验证。

威胁T2和T3涉及设备盗窃（例如，服务中心中的插件式 WVI或手持设备）。SecUp允许在专用区域（如服务中心）内进行无线软件更新：在诊断工具与新WVI完成初始配对步骤后，所使用的设备将形成一个可信网络，且仅当WVI连接到可信诊断工具时才允许进行软件更新。因此，被盗的 WVI无法用于执行未经授权的软件更新（威胁T2），因为WVI不会允许攻击者在未连接到可信诊断工具的情况下执行更新。攻击者可能在第二步尝试伪造可信诊断工具的身份（威胁T4），但由于采用了基于数字签名的认证步骤，该尝试也将失败。攻击者还可能使用被盗设备读取或替换设备上存储的钥匙，但同样会失败，因为SecUp利用可信平台模块（TPM）安全地存储钥匙和其他敏感数据。

六、已实现的原型和演示系统

本节描述了无线软件更新系统核心节点的已实现硬件和软件原型，并介绍了所使用的演示电子控制单元。

A. 开发的WVI原型

所开发的WVI原型由一块BeagleBone Black (BBB)板和一块自主设计的印刷电路板（PCB）组成。该 PCB可通过指定的插针接口安装在BBB上，并集成了所需的硬件接口（即CAN和OBD）以及相应的收发器，以实现WVI与车辆的互联。该PCB还负责WVI的电池管理：当车辆点火关闭且车辆的OBD接口未提供电源时，电池将作为WVI的电源。WVI的软件实现主要采用Java语言，并通过Java本地接口（JNI）与WVI原型的硬件相关部分进行交互。

所开发的安全概念的一个关键方面是在相关设备（即 WVI、手持设备和诊断工具）之间使用强身份验证机制。相应的认证密钥必须保密，以确保系统的可信性。尤其是插件式WVI尤为关键，因为攻击者可能窃取此类设备并尝试提取其中的密钥。为避免这种情况，可在WVI上使用可信平台模块（TPM）来安全地存储密钥和其他敏感信息。尽管目前 TPM仅用于存储RSA密钥以及处理WVI与诊断工具之间的认证，但它也为SecUp未来版本中使用证书提供了可能性。

1) 可信平台模块集成

所使用的恩智浦（NXP）可信平台模块通过集成电路间（I2C）总线连接到WVI。BBB上现有的I2C库并未完全支持TPM与WVI之间进行数据交换所需的I2C协议。因此，在BBB上使用普通I/O引脚实现了一个额外的I2C总线，以满足TPM对I2C通信协议的要求。然而，这种方法的缺点是TPM与BBB之间的通信速度较慢：约为7 kBaud。

在第七节-A中，通过首先比较集成式可信平台模块与基于软件的密码学库Java Bouncy Castle（JBC）的性能，其次使用示波器分析可信平台模块执行不同密码操作时的时序行为，来评估WVI与可信平台模块之间慢速总线连接的影响。

B. 诊断工具和手持设备的原型及实现

诊断工具（DT）的实现采用Java开发，并在运行 Win7的双核笔记本电脑以及运行Debian Linux的BBB 上进行了测试（系统评估由作为诊断工具（DT）运行的 BBB完成）。最新的诊断工具（DT）实现支持多种模式，如ECU编程、CAN总线监控和OBD诊断。

使用Nexus 7安卓平板作为手持设备。它可以同时连接到WVI和DT，从而使手持设备能够监控车辆的总线系统、执行OBD请求以及触发软件更新。

C. 用于基本框架评估的沃尔沃FlexECU

沃尔沃FlexECU是一种主要用于测试新应用程序的原型 ECU。该ECU提供多个连接器（即CAN接口、电源供应和使能引脚），并封装在坚固金属外壳内。该ECU的引导加载程序包含UDS协议栈，因此支持符合UDS的软件更新过程。当 ECU已在运行其应用软件时，必须触发复位才能访问引导加载程序。

该电子控制单元用于对软件更新框架进行基本评估（第八节）。使用了两个略有不同的软件版本进行测试，其中一个周期性地发送CAN-ID为1001的CAN帧，另一个发送 CAN-ID为2001的CAN帧，以测试所开发的框架并进行一些基本性能分析。由于CAN-ID不同，可以方便地验证新软件版本是否已正确安装到电子控制单元上。

D. 英飞凌AURIX作为高级ECU演示器

沃尔沃ECU不适合测试差值或部分无线软件更新等高级功能，因为无法对FlexECU硬件或在电子控制单元上运行的软件进行适配或扩展。因此，开发了基于英飞凌AURIX的第二个演示用电子控制单元。采用AURIX带来了多项优势，并提供了更大的自由度来开发高级软件更新功能，因为可以修改默认的引导加载程序，甚至可以开发新的AURIX引导加载程序。

1) AURIX平台描述

所开发的演示器ECU由集成在 AURIX应用套件TC277 TFT中的英飞凌AURIX多核ECU组成。它是一种高性能ECU，符合支持最高汽车安全等级 ASIL-D的安全要求[31]。该AURIX ECU基于运行频率高达 300兆赫兹的32位标量TriCore CPU，可在完整的汽车温度范围内工作{‐ 40,+170}◦C。它配备最多4MB闪存和472 KB RAM内存，并配有高速CAN收发器、安全处理器和看门狗，以及每个核心专用的紧密耦合内存区域。

2) 针对AURIX的通过CAN刷写机制

该机制是无线软件更新的基础，因为它涵盖了通过CAN总线将新软件从 WVI传输到AURIX ECU以及在ECU上安装该软件的过程。AURIX默认不提供此类机制。因此，开发了一种扩展的 AURIX引导加载程序，以实现可靠的通过CAN刷写机制。

后者主要由三个核心组件构成：i）CAN驱动程序负责处理通过CAN的数据传输，ii）闪存驱动程序 用于对闪存内存进行编程和擦除，以及iii）控制器协调编程序列。

CAN驱动程序本身已在AURIX基础软件中实现，只需配置以支持总线的正确比特率（例如1Mbit/s）。闪存驱动程序负责对电子控制单元的数据和程序闪存内存进行编程和擦除，主要包含两个功能：扇区擦除和页面编程。该闪存驱动程序能够擦除一个或多个连续的扇区，并可写入单个页面，或使用突发编程模式写入多个连续的闪存内存页面。控制器组件是根据UDS开发的标准，并且每次调用AURIX引导加载程序时（例如，在硬件或软件复位后）都会启动。它初始化CAN驱动程序并检查编程请求。如果没有收到此类请求，则启动电子控制单元的应用软件，或者在没有应用软件的情况下重新启动。否则，如果发现编程请求，控制器将处理数据传输以及新应用软件的安装。

新应用软件可以通过以下步骤安装到AURIX上：首先，向电子控制单元发送包含软件起始地址的编程请求。其次，执行基于典型种子与密钥机制的授权步骤，然后在电子控制单元上启动符合UDS的编程会话。第三步，使用相应的UDS命令将软件逐块传输到电子控制单元。电子控制单元接收每个块，将其存储在临时缓冲区中，最后利用闪存驱动程序将其写入闪存内存。在将所有块传输到电子控制单元后，通过计算新软件块的CRC来验证新软件版本。最后，电子控制单元重启并启动新的应用程序。

3) 部分软件更新

根据第七节-C以及表I所示结果，通过CAN总线将软件二进制文件传输到电子控制单元是执行无线软件更新时最耗时的步骤。加快此步骤将显著缩短软件更新的持续时间。

实现这一点的一种方法是利用部分软件更新。部分软件更新的基本思想是仅更新与当前安装的软件版本相比发生更改的软件部分。在仅进行简单参数值更改的情况下，可能带来的好处高达近100%：正常的软件更新无论新旧二进制文件多么相似（即只有一两个参数发生变化），还是新版本包含大量新功能因而体积大得多，都需要将整个新二进制文件下载到电子控制单元；而部分软件更新则只会下载二进制文件中已更改的部分（即一个或多个内存块）。

在闪存架构中，可用内存被划分为不同的扇区，有时甚至具有不同的大小。要修改一个扇区，闪存驱动程序必须先擦除整个闪存扇区，然后才能填入新内容。因此，无法仅更新存储在特定扇区中的单个参数值，而必须重写整个内存区域。这一事实导致了部分软件更新的两种不同方法：

增量下载 ：仅将软件部分的相关（即已更改）部分发送到电子控制单元。在电子控制单元上，受影响的部分被复制到RAM内存中，闪存驱动程序擦除闪存部分，然后使用接收到的增量字节修改RAM中的该部分内容，最后将修改后的部分数据重新写入闪存内存。这种方法一方面最小化了需要传输到电子控制单元的数据量，但另一方面显著增加了电子控制单元层面的复杂性。

部分软件更新 ：不只传输增量字节，而是将整个段传输到电子控制单元。尽管这样会限制部分软件更新的优势，因为需要向电子控制单元发送更多数据，但实现起来非常简单。

要决定是使用增量下载还是采用部分软件更新，需考虑分区大小、比特率等不同因素。对于AURIX电子控制单元，选择了部分软件更新方法，因其闪存内存被划分为不同大小的扇区（见图3），并且软件开发人员可以利用链接器文件来影响软件二进制文件的特定部分在闪存内存中的存储位置。在开发新的AURIX软件时，应将二进制文件划分为不同的扇区，并相应地映射到电子控制单元的闪存内存中，如图3所示：在车辆生命周期内最可能保持不变的区域（例如基本电子控制单元功能），以及可能发生变更的区域（例如包含参数或可选功能的块）。后者将位于闪存内存的一个或多个小分区中（通常为几千字节）。

七、安全概念评估

本节评估了所采用的安全机制对系统性能的影响。

A. 评估集成可信平台模块的性能

在SecUp中，可信平台模块（TPM）被集成到WVI中，以安全地存储密钥和敏感数据。所使用的TPM能够存储钥匙并执行密码操作，例如RSA加密/解密或RSA/AES密钥生成。该TPM还可用于对称数据加密和签名。因此，所定义的安全概念所需的所有密码操作均由TPM支持。然而，这些操作也可以由所使用的Java软件库JBC来执行。

在首次评估步骤中，比较了可信平台模块（TPM）和JBC的性能。因此，WVI与诊断工具（DT）之间的认证步骤分别使用TPM和JBC各执行20次，从而测量这些操作的持续时间。包含不同RSA操作（即数据加密/解密和签名）的认证步骤可由可信平台模块（TPM）、JBC库执行，或采用结合两者的混合解决方案来完成。

收集到的结果表明，JBC 的性能优于 TPM：使用 TPM 时的最小/最大/平均持续时间为 (6328/6588/6415.5ms)，而 JBC 为 (575/701/635.8 ms)。然而，TPM 最重要的优势在于其能够安全地存储敏感数据和钥匙。因此，最终的概念采用了混合解决方案（3525/3690/3577.9ms），即将快速的 JBC 库与 TPM 的安全存储相结合。由于 JBC 与 TPM（一种专门用于执行密码操作的硬件芯片）之间的性能差异起初并不明显，因此进行了额外的评估以查明此问题。

如第六节 VI-A1 中所述，连接可信平台模块（TPM）与 WVI的I2C总线是通过BBB的I/O引脚实现的，因此该总线速度较慢（7 kBaud）。为了评估慢速总线连接对可信平台模块（TPM）整体性能的影响，执行了多次RSA操作（使用 2048位密钥进行RSA加密/解密，208字节数据），同时使用示波器分析TPM的时序行为。测量结果清楚地表明，I2C总线对整体性能有显著影响，因为在TPM与WVI之间进行数据交换所需的时间在RSA解密中约占操作总时长的 45%，在RSA加密中甚至高达87%。测量结果显示，采用更快速的I2C总线或使用其他类型的总线（如串行外设接口(SPI)）将有助于显著减少总时长。在当前设置中，可信平台模块（TPM）仅应用于存储钥匙和执行认证，而不用于AES对称加密（即采用混合解决方案）。

B. 安全机制对网络层的影响

在本节中，通过评估SAE对往返时间(RTT)和IEEE 802.11s内核模块代码大小的影响，分析了SAE对系统性能的影响。

第一个评估步骤是评估RTT——即从节点A向节点B发送请求包所需的时间，加上从节点B返回响应包到节点A所需的时间。在本实验中使用了五个IEEE 802.11s节点。通过在网络中定义静态路径，强制形成不同长度的多跳路由（从直接连接到最多四跳的多跳路由）。对于每种不同路径长度以及SAE开启或关闭的情况，均从节点A向节点B发送10000条消息。为了测量RTT，最多使用五块BBB开发板（BBB0至BBB4），从BBB0向BBB4发送UDP数据包并返回，中间使用零到三块开发板（BBB1、BBB2和BBB3）来转发数据。在BBB0和BBB4上，使用UDP服务器‐客户端应用程序：i) 发送请求（BBB0），ii) 接收该请求并发送响应（BBB4），iii) 接收该响应（BBB0）。采用改进版的IEEE 802.11s来检测交换的UDP测试数据包。在BBB0和BBB4上，将接收和发送的时间戳添加到测试数据包中。这些数据包在测试期间被收集于BBB0，并在后续评估中用于计算网络层RTT（通过去除应用层所花费的时间；仅对BBB0和BBB4有效，因为BBB1至BBB3的数据包转发仅在网络层进行）。

，以及差值(中位数)= median(SAE)‐median(None)(b)。)

在第二次评估步骤中，使用标准3.19版Linux内核的 MAC80211内核模块（默认包含SAE）的源代码，分析了 SAE对MAC80211内核模块代码大小的影响：首先编译包含SAE的模块，然后移除所有与SAE相关的源代码移除后，重新编译（并测试）了生成的模块。评估结果表明，SAE 对 IEEE 802.11s 内核模块代码大小的影响约为代码行数（LOC）的 5%（无 SAE 时为 58545 LOC，有 SAE 时为 61354 LOC），内存大小影响为 3%（无 SAE 时为 774 KB，有 SAE 时为 801 KB）。

C. 安全机制对软件更新持续时间的影响

为了保护SecUp的安全，采用了网络层和应用层上的不同安全机制。这些机制对所开发系统的整体性能产生影响。通过使用沃尔沃FlexECU进行真实无线软件更新的延迟测量，以评估这种影响。以下列出了使用所开发框架成功执行无线软件更新所需的所有步骤：i) WVI发现和连接建立，ii) WVI与DT之间的认证过程，iii) 软件更新初始化（主要针对ECU），iv) 使用种子与密钥程序在ECU上进行授权，v) 从DT到WVI的无线数据传输，vi) 通过 CAN将数据下载到ECU，以及vii) 在ECU上验证已下载的软件。

每个步骤都会增加无线软件更新的总时长，且每步的延迟因所采用的安全机制而异。在本实验中，使用了 FlexECU以及相应的二进制文件，包括应用软件（ 378KB）和二级引导加载程序（67KB）。在应用层，采用了基于Java Bouncy Castle (JBC) 实现的安全机制。

表I中所示的评估结果表明：i）通过CAN进行的数据传输占软件更新持续时间的大部分（启用所有安全机制时为75%，禁用时高达87%）；ii）所采用的安全特性使执行无线软件更新所需的总时间增加了20%。尽管这一持续时间增加相当显著，但必须予以接受，因为所有安全机制都是确保安全系统执行所必需的。

第八节 框架评估

本节介绍了对SecUp及其无线软件更新机制的评估。所进行的评估是首次针对提供高级软件更新机制并支持在不同环境下安全高效地进行软件更新的无线软件更新框架的分析（本地）场景，例如装配线或服务中心。因此，目前没有合适的基准可用于比较所获得的结果。在[32]中已经提出了一个基本的系统评估：使用开发的车辆和ECU模型（ VEM）进行基础实验、系统评估和通信测试。此外，还利用VEM评估了在出现错误（例如发送意外帧）和通信问题（例如CAN帧丢失、延迟或重复）时所开发系统的响应行为。该评估还包括对无线网络的分析，其中诊断工具（DT）连接到真实车辆，并使用开发的WVI原型执行无线诊断。通过这些评估结果，验证了IEEE 802.11s作为无线软件更新传输介质的适用性。

A. 使用沃尔沃FlexECU进行无线软件更新分析

首先使用沃尔沃卡车提供的Flex‐ECU（如第六节-C所述）并连接到WVI，对软件更新过程进行了分析。该电子控制单元分两个步骤进行编程：首先，将二级引导加载程序（SBL）传输到电子控制单元，并通过特定的UDS命令在电子控制单元上启动；其次，将应用二进制文件发送到电子控制单元并安装。SecUp既支持使用SBL和应用二进制文件的方式，也支持直接安装应用二进制文件而不使用SBL的方法。

在表 II 中，将无线数据传输的持续时间（SBL 和应用软件从诊断工具传输到 WVI）与通过 CAN 将 SBL 和应用软件安装到电子控制单元所需的时间进行了比较。使用沃尔沃ECU测得的软件更新持续时间也被用作评估 AURIX 及其所实现的软件更新功能的基准。结果表明，无线数据传输（包括数据传输、完整性检查等）比通过 CAN 传输二进制文件快 12 倍，这与表 I 中所示的结果一致。因此，WVI 在从诊断工具接收到二进制文件后自主控制向电子控制单元的数据传输是合理的（即无需与诊断工具保持永久无线连接）。随后，当软件成功安装到电子控制单元或发生任何问题时，WVI 会通知诊断工具。

B. 使用AURIX ECU进行无线软件更新分析

在第VI-D节中描述的AURIX ECU被用于进一步评估 SecUp及其功能。因此，SecUp的核心节点、诊断工具（DT）和WVI的软件实现均在BBB开发板上运行。这些 BBB开发板通过USB连接到测量PC，以控制测量并收集结果。每次测量任务（即每种模式一次）执行20次无线软件更新，并对每个单独步骤的持续时间进行测量，具体步骤如第七节-C所述。这些步骤随后被分为四组：i)连接相关，包括DT发现以及DT与WVI之间的认证；ii)ECU相关，涵盖软件更新的初始化以及WVI与电子控制单元之间的相应授权步骤；iii)上传，即无线数据传输；iv)下载，通过CAN进行的数据传输以及软件在电子控制单元。该设置允许比较不同更新机制下软件更新的总时长，并进一步分析每个步骤所增加的延迟。

为了比较沃尔沃FlexECU和AURIX ECU的软件更新持续时间，使用AURIX推荐的软件开发工具Hightec Studio创建了适用于AURIX的软件二进制文件。生成的.hex文件（即二进制文件）被设计为与沃尔沃FlexECU的二级引导加载程序（SBL）加上应用软件的大小相同（即 67 KB + 378 KB= 445 KB）。尽管.hex文件包含了无线软件更新所需的所有信息，但该文件格式不适合直接分析部分软件更新，因此开发了一个解析器，将.hex文件转换为所谓的.phex（已解析的十六进制）文件格式。在.phex文件中，每一行代表软件二进制文件的一个块，因此可以通过比较不同软件版本的行来检查是否可以进行部分软件更新。这种文件格式的另一个优点是.phex文件比对应的.hex文件更小：用于评估的二进制文件最初以 445 KB的.hex文件存储，可转换为约316 KB的.phex文件。

1) 沃尔沃FlexECU和AURIX ECU比较

在初步评估阶段，对比了使用FlexECU和AURIX进行软件更新的更新时长。表III中显示的结果表明，AURIX的更新速度比 FlexECU快两倍以上。原因如下：i) 在ECU层面的初始化过程（即启动编程会话并处理授权）由于AURIX具备更高的CPU性能，比FlexECU快十倍；ii) 无线数据传输速度快约30%，因为.phex文件比SBL加上应用软件的总和小29%；iii) 在CAN上的数据传输（两个ECU均使用 500 Kbits/s的CAN总线）以及二进制文件的存储在 AURIX上接近快三倍，因为沃尔沃ECU必须先存储并启动SBL，然后再加载、存储并启动应用软件。

2) 部分软件更新评估

本实验展示了部分软件更新相较于传统软件更新的优势。通常由于需要修复漏洞或更新/调整电子控制单元的参数字段，而必须进行软件更新。在这种情况下，大部分软件保持不变，仅需更改少量字节。

为了说明这一点，开发了两个不同的AURIX软件应用版本。两个版本的.hex文件大小均为445 KB，并总共使用了一个1024字节的参数字段。该参数字段存储在 AURIX ECU的专用内存区域中（参见图3），也是这两个软件版本之间的唯一区别。在使用部分软件更新时，只需将包含参数字段的内存区域（1 KB）传输到电子控制单元，而无需传输整个二进制文件。

在表III中显示了对软件更新持续时间的影响：与使用 AURIX ECU的正常更新相比，部分软件更新速度快约六倍（即持续时间减少了83%）。这主要是因为需要从诊断工具无线传输到WVI的数据量减少（速度提升98%），以及通过 CAN从WVI传输到ECU的数据量也大幅减少（速度快约二十倍）。然而，部分软件更新的优势在很大程度上取决于内存架构以及两个软件版本之间的差异。

3) 并行软件更新评估

在最后的评估步骤中，分析了并行软件更新。这些更新在某些情况下非常有益（参见第四节描述的场景），例如需要在多辆车辆中集成的电子控制单元上安装相同软件版本时。这对于装配线以及服务中心在发生大规模车辆召回（例如由于软件缺陷）时尤为重要，因为可以同时对所有车辆执行更新。

在进行的实验中，两个无线车辆接口原型各自连接到一个AURIX ECU，并通过无线方式连接到同一个诊断工具。软件更新没有按顺序执行，而是同时在两个电子控制单元上安装了软件二进制文件。

表III中显示的评估结果表明，并行更新时长比正常的无线软件更新增加了约25%。这是由于必需步骤无法完全并行化所致。然而，并行软件更新仍然比顺序执行正常软件更新（即连续两次执行软件更新）快得多（在本例中快75%）。

IX. 结论

本文提出了一种可实现安全且高效的无线软件更新的通用框架SecUp。SecUp的设计与实现旨在满足多个应用场景的需求：车辆开发、车辆装配线、车辆维护以及空中下载技术更新。SecUp包含高效的无线软件更新功能，例如并行软件更新（可同时更新多辆车辆的软件）和部分软件更新（仅传输并安装软件二进制文件中发生变化的部分）到电子控制单元。本文还描述了所采用的IEEE 802.11s网络的特性，并阐述了SecUp所使用的跨层安全概念。对开发的软件更新机制进行比较，显示出利用高级更新功能的优势。