使用基于属性的加密方案提升OTA远程升级的安全性

本文旨在证明，在汽车场景中，通过使用一种名为 “基于属性的加密”（ABE）的加密方案，可以提升空中下载（OTA）更新功能的安全性，该方案能够为空中软件 / 固件更新提供机密性保障。我们通过研究表明，ABE 在计算时间和存储方面的开销相较于 OTA 过程中产生的其他开销而言可忽略不计，从而证明 ABE 能够无缝集成到现有的 OTA 更新解决方案中，同时也证实了可以以极低的成本增强安全性。为了支撑这一观点，我们展示了在赛灵思（Xilinx）ZCU102 评估板上实施所提出的 ABE OTA 技术的实验结果。该评估板是一款面向汽车领域的软硬件（HW/SW）平台，配备了 Zynq UltraScale + 多核片上系统（MPSoC）芯片，其计算能力可代表真实汽车电子控制单元（ECU）的水平。

在过去的几十年里，汽车行业发生了翻天覆地的变革。车辆对电子元件的依赖程度日益加深，借助电子元件为消费者提供全新功能。如今，每辆车配备的电子控制单元（ECU）数量远超 80 个，软件维护已成为一个亟待解决的重要问题。在行业内，据估算，每 1000 行代码中的漏洞数量在 0.5 到 25 个之间波动。认为市场上的车辆不存在任何漏洞是不切实际的，而假定这些漏洞均不会引发安全隐患则更为荒谬。新的攻击手段和漏洞利用方式层出不穷，要完全防范所有威胁几乎是不可能的。不过，在大多数情况下，针对新发现的漏洞，我们能够找到解决方案，并通过软件或固件更新来修复漏洞。

为车辆的软件或固件进行更新的一种安全方式是将车辆送至最近的授权维修店，但显然这种方式应尽量避免，因为它不仅会给消费者带来极大不便，还会增加汽车原始设备制造商（OEM）的额外成本。这一严峻问题也引起了欧洲处理器计划（EPI）项目委员会及其合作伙伴（如宝马和 Elektrobit）的高度关注。

空中下载（OTA）更新是解决这一问题的方案之一，用户可以像操作智能手机或家用电脑那样自行完成更新操作。其核心原理是：每辆车内都配备一个特殊的 ECU，即网关，它负责将外部网络与车辆内部所有的 ECU 连接起来。例如，网关可为车内乘客提供信息娱乐服务，而在本文所述场景中，它能与制造商建立互联网连接，以便下载更新文件。

目前已有多种先进的解决方案实现了 OTA 软件更新功能，这些方案均着重保障更新的真实性和完整性，而机密性则被视为可选的安全特性。然而，这就导致更新文件的知识产权（IP）无法得到有效保护。因为如果更新文件在传输到车辆的过程中未经过任何加密处理，竞争对手便可轻易截获并分析其中的内容。这种情况在以下场景中尤为不利：更新文件包含应对新型攻击的创新性防护措施，或是为车辆新增了特色功能。

另一个问题在于，即便通过建立安全通道（如传输层安全协议 TLS）来实现更新文件的机密传输，但当更新文件处于 “静态存储” 状态时，其机密性便无法得到保障。“静态存储” 指的是数据未在互联网中传输，例如存储在云服务器中的数据就处于静态存储状态。这意味着，若制造商借助安全通道保障更新文件的机密性，就无法使用第三方不可信服务器来存储和分发更新文件，因为当更新文件上传到这类服务器时，它将处于未加密状态。此外，即便制造商使用自家的可信云服务器向每辆车传输更新文件，一旦更新文件到达车辆的网关，仍有可能被篡改网关的人员轻易截获。

造成这种风险的原因在于，网关是唯一直接连接互联网的 ECU，因此相较于其他所有 ECU，它更容易遭受网络攻击，也更易被篡改。事实上，在《AUTOSAR 更新与配置管理规范》文档中也明确指出，宜设置一个独立于网关的专用 ECU，专门负责管理车辆的软件更新。

解决 “静态数据” 安全问题的一种方法是对更新文件进行非对称加密（如采用 RSA 算法），使得只有上述专用 ECU（甚至网关都不具备此权限）能够对其进行解密。但这种方法的成本较高，因为制造商需要为每一辆待更新的车辆分别对更新文件进行加密处理。

基于属性的加密（ABE）大幅降低了多接收端端到端加密的成本，同时解决了更新文件静态存储的安全问题，使得为更新文件提供机密性保障变得经济且高效。借助 ABE 技术，即便攻击者成功篡改了车辆的网关，更新文件依然处于加密状态，并且通过专用 ECU 所持有的长期密钥进行签名，从而使攻击者的篡改行为失去意义。攻击者若想分析更新文件副本，唯一的途径就是篡改专用 ECU 或需要进行更新的目标 ECU。

汽车行业已意识到此类风险，并针对这些问题制定了一系列安全策略，例如多层安全架构。该架构根据相关应用的安全需求，将车辆内部架构划分为不同的安全级别，涵盖从低安全级别（如信息娱乐系统）到高安全级别（如自动驾驶车辆的制动系统）的各个领域。除其他作用外，该策略确保了不直接连接互联网的 ECU 难以被篡改。

尽管近年来已有众多高质量的研究成果证实了 ABE 在各类设备上的可行性，但据作者所知，目前尚无文献针对 ABE 在真实汽车嵌入式硬件平台上的影响展开测试。本文的研究目标就是证明，总体而言，ABE 方案能够在与车辆实际搭载的 ECU 性能相近的平台上良好运行。为此，我们选用了 Bethencourt 等人提出的密文策略基于属性的加密（CP-ABE），因为此前有关 ABE 可行性的研究均采用了该方案。通过证明该方案对 OTA 过程的影响微乎其微，我们进而表明 ABE 能够在这类设备上实现出色的性能表现。

本文的贡献主要包括以下三个方面：（1）提出一种适用于软件 / 固件 OTA 安全更新的 ABE 技术，该技术可无缝集成到现有的先进解决方案中；（2）证实 ABE 不仅符合现代汽车的车内网络架构，还与真实汽车 ECU 的计算能力相匹配；（3）在真实的汽车兼容平台（即赛灵思 ZCU102 评估板）上对 ABE 的性能进行实验评估。

本文其余部分的结构安排如下：第 2 节介绍相关背景知识并综述相关研究成果；第 3 节阐述性能评估的实验设置；第 4 节展示并分析实验结果；最后，第 5 节对全文进行总结。

2.1 基于属性的加密

基于属性的加密（ABE）是一种将访问控制机制嵌入加密数据的加密技术。在 ABE 中，数据和可解密实体均通过 “属性” 来描述，并且通过基于这些属性定义的布尔公式（即策略）来管控对数据的访问权限。

在 ABE 机制中，加密方（以下简称 “数据生产者”）使用一个公开且唯一的加密密钥；而任何解密方（以下简称 “数据消费者”）则使用各自专属的私有解密密钥。ABE 主要包含两种范式：密文策略基于属性的加密（CP-ABE）和密钥策略基于属性的加密（KP-ABE）。

在 CP-ABE 中，每个数据消费者都持有一个属性集合，该集合被嵌入到其解密密钥中；每一份数据都对应一个访问策略，该策略被嵌入到密文中。访问策略可被视为一棵树状结构，其中内部节点代表逻辑运算符 “与”（AND）和 / 或 “或”（OR），叶子节点则代表具体的属性。所有 CP-ABE 方案均包含四个核心算法：

· 初始化算法（Setup）：生成主密钥和加密密钥；

· 密钥生成算法（KeyGen）：以主密钥和描述解密密钥持有者的属性集合作为输入，生成解密密钥；

· 加密算法（Encrypt）：以加密密钥、明文消息以及描述待加密数据的访问策略作为输入，生成密文；

· 解密算法（Decrypt）：以解密密钥和密文作为输入，当且仅当解密密钥中的属性集合满足密文中的访问策略时，才能解密得到明文消息。

KP-ABE 与 CP-ABE 采用相同的算法框架，但两者在属性集合和访问策略的应用方式上存在差异。在 KP-ABE 中，密钥生成算法（KeyGen）的输入是访问策略而非属性集合，而加密算法（Encrypt）的输入则是属性集合而非访问策略。

ABE 具备抗合谋特性，即两个数据消费者无法通过合并各自的密钥来访问单独任何一方都无权访问的数据。此外，ABE 的一大显著优势在于，数据生产者只需对信息进行一次加密，就能通过数学方式为其施加访问控制机制，确保只有拥有足够访问权限的解密密钥才能对其进行解密。

这意味着，如果数据生产者采用 RSA 算法向 n 个数据消费者发送一个文件，就需要对该文件进行 n 次加密；而若采用 ABE 算法，只需对文件进行一次加密即可。因此，汽车企业可以利用 ABE 对更新文件进行加密并签名，然后将其上传至第三方云存储服务器，由这些服务器安全地将更新文件分发给所有目标车辆，确保接收的更新文件具备真实性、完整性和机密性。即便第三方云存储服务器不可信，采用 ABE 也是一种安全的设计选择。

在本次性能评估中，我们选用了 Bethencourt 等人提出的 CP-ABE 方案。我们认为，对于原始设备制造商（OEM）而言，CP-ABE 是更优的选择，因为与 KP-ABE 方案相比，CP-ABE 能让数据生产者（即 OEM）拥有更强的控制权。

2.2 空中下载（OTA）框架

空中下载（OTA）更新解决方案是未来汽车 ECU 软件和固件更新的发展方向。对用户而言，无需将车辆送至最近的授权维修店进行更新，极大地提升了便利性，同时也提高了用户实际安装更新的意愿。此外，有数据显示，汽车 OTA 更新可将保修成本降低一半。

目前已有一些先进的解决方案实现了 OTA 固件 / 软件更新的端到端加密，例如 vConnect。该方案通过在服务器与车辆网关之间建立加密会话来构建安全通道。但这种方式存在安全隐患：当更新镜像文件下载完成后，它会在网关内处于 “静态存储” 状态。由于网关是唯一直接连接互联网的 ECU，因此它是最容易受到攻击的 ECU。

相比之下，如果企业采用本文提出的 ABE OTA 软件更新技术，网关只需将下载到的加密且已签名的镜像文件转发给更新与配置管理器（UCM）即可。根据《AUTOSAR 自适应平台规范》文档，UCM 也可运行在一个独立于网关的专用 ECU 上，从而能更好地抵御外部攻击。

2016 年，Karthik 等人发布了 Uptane 框架，该框架专为地面车辆的软件和固件 OTA 更新安全而设计。Uptane 允许用户选择使用对称加密、非对称加密或数字信封技术对软件镜像（即软件更新文件）进行加密。本文设计了一个集成 ABE 的简易框架，用于评估 ABE 对 OTA 软件更新的影响。由于 ABE 本质上属于非对称加密方案，因此本文的研究将证明，ABE 能够集成到真实复杂的框架中，是保障知识产权（IP）机密性的可行方案。

2018 年，Asokan 等人提出了 ASSURED 框架，这是一种基于 Uptane的 OTA 固件更新框架。他们在研究中声称，ASSURED 框架实现了以下五个目标：

1. 端到端认证与完整性：更新文件必须经过制造商签名，并由设备进行验证；

2. 控制器的更新授权：只有经过授权的设备才能安装更新；

3. 更新安装的证明：设备必须能提供更新已安装的证明；

4. 设备上代码与密钥的保护：更新文件的存储以及关键代码的隔离执行必须在安全存储区域内进行；

5. 最小化设备负担。

然而，ASSURED 框架并未将窃听通信以获取更新代码，或从被篡改的网关中窃取更新代码的外部实体视为潜在攻击者。与之不同的是，本文的研究除了实现 ASSURED 框架所达成的目标外，还考虑了此类攻击者，并通过基于属性的加密（ABE）技术为更新文件提供保护，抵御这类攻击。

2020 年，Ghosal 等人提出了 STRIDE 方案，这是一种适用于自动驾驶车辆的 OTA 软件更新方案。在该方案中，作者采用 Bethencourt 等人提出的 CP-ABE 方案来保障软件更新文件的机密性，并通过 OMNeT++仿真工具进行了全面的性能评估。但与本文不同的是，他们并未在真实的汽车平台上测试引入 ABE 后的性能表现，而本文则在赛灵思 ZCU102 评估板上开展了相关测试，从而能更真实地评估 ABE 的性能。此外，他们的研究未对密钥撤销机制的性能进行评估，而在实际应用场景中，密钥撤销机制至关重要，不能被忽略。

Halder 等人近期发表了一篇关于联网车辆安全 OTA 软件更新的综述文章。在该综述中，更新文件的机密性被视为一项强制性要求，作者探讨并分析了多种相关方案，涵盖仅基于对称密钥、哈希函数、区块链、RSA 与隐写术结合、硬件安全模块（HSM）以及安全更新框架等技术的 OTA 更新方案。然而，该综述并未提及明确基于属性的加密（ABE）的解决方案。

2.3 测试平台与汽车硬件背景

基于属性的加密（ABE）技术最初由 Sahai 和 Waters 于 2005 年提出。此后，众多研究人员提出了各自的 ABE 方案，并在各类平台上对这些方案进行了评估。此外，已有大量文献探讨了多种 ABE 方案（包括 KP-ABE 和 CP-ABE）在智能手机、物联网设备等资源受限设备上的可行性。但据作者所知，目前尚无文献针对 ABE 方案在真实汽车嵌入式硬件平台上的影响展开测试。

传统物联网设备（如智能手机、传感器、树莓派等）与汽车嵌入式平台的主要区别在于硬件配置。正如读者将在本节末尾了解到的，汽车嵌入式平台具备多核处理器、实时处理器等硬件组件，而这些组件在普通物联网设备中通常是不存在的。因此，本节将阐述真实汽车平台的车载网络架构和计算能力，以便将所提出的 ABE 技术集成到具有代表性的汽车场景中。同时，本文还将介绍新兴的车辆架构设计，说明为何在讨论 ABE 在汽车领域的性能时，不能直接参考以往的研究成果。

车载网络正经历从传统的基于域的电子架构向区域架构的转型。基于域的架构包含多个简单且相互独立的 ECU 和网络，将继续用于普通汽车子系统（如制动或转向控制系统）。而对于高性能任务（如用于障碍物检测、导航和轨迹规划的传感器融合），则需要少量的超级计算机来支撑。

除了传统的本地互联网络（LIN）和控制器局域网（CAN）外，在新兴的汽车平台中，无线车联网（V2X）通信通过车载版本的无线局域网（如 802.11p 技术）和蜂窝网络（如 C-V2X）来实现。这种多样化的连接方式将大幅增加软件 OTA 分布式分发的可能性，但同时也带来了安全隐患，使车辆更容易受到外部网络威胁的攻击。

汽车企业已意识到这一严重威胁，并尝试将所有连接功能集中到一个名为 “网关” 的 ECU 上。然而，对于 OTA 软件 / 固件更新这类关键应用，根据相关规范，建议设置一个独立于网关的专用 ECU，即更新与配置管理器（UCM）。该 ECU 存储 OTA 软件 / 固件更新所需的加密参数，例如用于签名验证的公钥和用于解密的私钥。

实际上，车辆内部推荐的 OTA 更新流程如下：

1. 网关下载经过签名和加密的更新文件，并将其转发给 UCM；

2. UCM 验证更新文件的签名；

3. UCM 对更新文件进行解密；

4. UCM 将解密后的更新文件转发给需要更新的 ECU。

这种新型汽车网络架构的一个关键特征是配备了性能更强大的 ECU。与普通 ECU（通常采用低成本微控制器）不同，高性能汽车 ECU 处理器通常具备以下特点：

1. 具备以太网物理层和交换机接口；

2. 搭载应用处理器（如采用 AArch64 64 位指令集的 Cortex-A 系列处理器）；

3. 配备硬件安全引擎（HSE），用于安全启动和加速安全服务。

特别值得注意的是，对于上述第三点，根据车载安全硬件的实际标准 ——EVITA 项目的规定，UCM 应属于 “安全级别 IV” 的 ECU。在车内互联方面，S32G 芯片支持以太网、CAN 等多种网络协议。这些特性使得 UCM 能够轻松执行多种加密操作，并且能够与所有需要 OTA 软件 / 固件更新支持的普通 ECU 进行连接。

需要明确的是，这类高性能 ECU 并非未来的研发方向，而是已经投入实际应用。将多核 Cortex-A 处理器集成到汽车平台的理念也被超级计算机平台所采用，例如瑞萨（Renesas）H3 异构片上系统（SoC）。该芯片集成了四个 Cortex-A72 核心、四个 Cortex-A53 核心，并由一个双核锁步 Cortex-R7 实时微控制器和丰富的网络接口进行管理。

为此，欧洲处理器计划（EPI）正在研发一款高性能异构处理器，该处理器集成了多个采用 AArch 64 位架构且支持可扩展向量扩展（SVE）的 ARM 核心，以及用于嵌入式现场可编程门阵列（FPGA）、大规模并行处理器阵列（MPPA）和基于 RISC-V 的模板与神经流加速器（STX）的协处理器模块。

为了评估 ABE 作为附加功能的易集成性，本文在一个真实的汽车兼容评估板上进行了性能评估。为此，我们选择了赛灵思（Xilinx）的 ZCU102 评估板，该板是一款多功能原型平台，既能代表高性能汽车 ECU 处理器，也可作为异构超级计算机的简化版本。

ZCU102 评估板搭载了 Zynq UltraScale + 多核片上系统（MPSoC）芯片，该芯片包含四个带 ARM Neon™技术的 ARM Cortex®-A53 核心、两个 Cortex-R5F 实时处理器核心以及一个 Mali™-400 MP2 图形处理器。此外，ZCU102 的 FPGA 资源支持进一步集成加速器，同时还提供了丰富的连接接口。

在软件开发方面，ZCU102 支持类 Linux 操作系统（PetaLinux）以及集成设计环境（VITIS），便于同时开发硬件和软件部分。需要说明的是，赛灵思 Zynq UltraScale+ MPSoC 平台不仅是一款快速原型开发工具，还可作为产品级解决方案使用。最近，大陆集团（Continental）已采用该平台用于其四维（4D）汽车雷达系统。

为了评估引入 ABE 对车辆性能的影响，我们设计了以下实验。在实验中，我们选用 Bethencourt 等人提出的 CP-ABE 方案作为 ABE 方案。默认情况下，CP-ABE 加密采用数字信封技术，即 CP-ABE 密文用于保护一个对称密钥，该对称密钥再对实际的明文消息进行对称加密。在本文中，所提及的 CP-ABE 加密和 CP-ABE 解密均默认采用数字信封技术，其中对称加密算法选用高级加密标准（AES）。

本实验场景包含多个车辆、一个制造商和一个 “诚实但好奇” 的云服务器。制造商持有 CP-ABE 主密钥、CP-ABE 加密密钥、一对 RSA 密钥，并知晓每辆车的 RSA 公钥，同时负责生成系统所需的所有加密密钥。

根据《AUTOSAR 规范文档》的规定，我们假设每辆车都配备一个专门用于 OTA 更新的 ECU，即更新与配置管理器（UCM）。该 ECU 不直接连接互联网，但与网关以及所有支持 OTA 更新功能的 ECU 相连。每辆车持有以下三种密钥 / 参数：

1. 一个 CP-ABE 解密密钥，该密钥包含车辆的组件信息和特性描述；

2. 一对 RSA 密钥；

3. 制造商的 RSA 公钥。

这些与车辆相关的加密密钥由原始设备制造商（OEM）在车辆生产过程中安装到实现 UCM 功能的 ECU 中。

制造商的主要操作流程如下：生成软件更新文件，使用 CP-ABE 对其进行加密，结合版本号使用 RSA 算法对加密后的文件进行签名，然后将经过签名和加密的更新文件存储到云服务器中。云服务器会将经过签名和加密的更新文件发送给所有请求更新的车辆。

车辆接收更新文件的流程如下：网关接收到软件更新文件后，将其转发给 UCM；UCM 首先验证制造商的签名，然后对 CP-ABE 密文进行解密；最后，UCM 将解密后的更新文件转发给需要更新的 ECU，待用户确认后，该 ECU 完成更新安装。图 1 展示了该用例场景及各实体间的交互过程。

此外，当一个或多个解密密钥存在泄露风险时，制造商需为未受影响的车辆提供新的密钥。具体操作流程为：制造商为每辆未受影响的车辆生成新的 CP-ABE 解密密钥，使用该车辆的 RSA 公钥对新的解密密钥进行加密，再用自身的 RSA 私钥对加密后的密钥进行签名，随后将经过加密和签名的解密密钥（以下简称 “密钥更新文件”）存储到云服务器中。如果某辆车有新的解密密钥可供使用，那么当该车请求软件更新时，云服务器会同时将密钥更新文件发送给该车。在这种情况下，UCM 首先验证密钥更新文件的签名，然后通过 RSA 解密获取新的 CP-ABE 解密密钥；最后，UCM 验证软件更新文件的签名，并使用新的 CP-ABE 解密密钥对其进行解密。图 2 展示了这一交互过程。

读者可能会认为这种密钥撤销机制的效率较低，但本文所设计的是一种最坏情况的场景：如果这种简单机制对测试平台的性能影响较小，那么更先进、更高效的撤销机制必然能得到更好的支持。

图 1、采用密文策略基于属性的加密（CP-ABE）的固件空中下载更新用例场景

图 2、密钥泄露情况下的 CP-ABE 解密密钥分发流程

3.1 攻击者模型

结合图 2（本文所研究的最复杂场景），我们对攻击者模型进行定义，明确攻击者的能力、动机、目标以及攻击方式。

我们假设原始设备制造商（OEM）、更新与配置管理器（UCM）以及车辆的所有 ECU（网关除外）都是可信的，而云服务器和网关则被视为不可信实体。我们认为这一假设具有合理性，因为车辆中的网关是唯一直接连接互联网的 ECU，相较于其他 ECU，它面临更多的外部攻击风险。

下面我们将分析两类潜在威胁：被动攻击者和主动攻击者。

被动攻击者

被动攻击者能够拦截互联网中传输的所有消息，包括原始设备制造商（OEM）与云服务器之间、云服务器与车辆之间传输的消息。被动攻击者的目标有两个：

1. 截获并解密 ABE 密文，获取更新文件；

2. 截获并解密 RSA 密文，获取 ABE 解密密钥。

然而，这两个目标均无法实现，因为要达成这些目标，攻击者必须分别破解文献和提出的加密方案，而这些方案在当前技术水平下具有较高的安全性。

主动攻击者

主动攻击者能够获取并 / 或控制云服务器和 / 或网关。他们可能利用近年来发现的众多漏洞来实施攻击。例如，主动攻击者可在网关（或云服务器）中植入间谍软件，从而获取该网关（或云服务器）处理的所有信息。

主动攻击者的目标包括：

1. 强迫车辆安装恶意软件更新；

2. 解密 ABE 密文；

3. 从车辆中获取解密密钥和 RSA 私钥。

要实现目标（1），攻击者必须伪造原始设备制造商（OEM）对软件更新文件的有效签名，这意味着需要破解 RSA 签名方案，而这在目前是难以实现的。

攻击者可通过控制云服务器或网关来尝试实现目标（2），但由于云服务器和网关均不持有任何解密密钥，因此该目标同样无法达成。

若攻击者以某种方式获取了某辆车的 CP-ABE 解密密钥和 RSA 私钥，从而实现目标（3），那么他们就能解密所有该 ABE 密钥有权访问的密文，并且能够获取并解密为该车生成的密钥更新文件。不过，这种攻击仅在原始设备制造商（OEM）未对该密钥执行撤销操作前有效。一旦 OEM 执行撤销操作，会将对应的 RSA 公钥从其公钥数据库中移除，并停止为该受影响车辆生成密钥更新文件。

需要说明的是，原始设备制造商（OEM）如何发现攻击行为并进而执行密钥撤销操作，这一过程超出了本文的研究范围。

本节简要说明我们如何构建实验场景，并介绍所使用的软硬件环境。

4.1 实验设置

我们设计了一个客户端 - 服务器应用程序，用于模拟云服务器与车辆之间的交互过程。该应用程序采用 C 语言编写，并使用了 OpenSSL、libswabe、CP-ABE 工具包、GMP（ GNU 多精度算术库）以及基于配对的密码学（PBC）库。

实验的核心目标是测量从车辆发起更新请求到完成更新安装所耗费的时间，最终证明 CP-ABE 在提供关键安全特性的同时，对性能的影响微乎其微。

我们设计了三种不同的实验场景，分别如下：

1. 无 CP-ABE 场景：当车辆请求更新时，云服务器将更新文件（明文形式）及其对应的版本信息发送给车辆，且这些数据均经过原始设备制造商（OEM）签名。该场景作为评估 CP-ABE 性能的基准参考。

2. 仅 CP-ABE 加密场景：云服务器存储经过 CP-ABE 加密的软件更新文件及其版本信息，且这些数据均经过 OEM 签名。该场景的交互过程如图 1 所示。

3. CP-ABE 加密 + 密钥更新场景：该场景与场景 2 的交互过程基本一致，但云服务器会不定期地向车辆发送新的 CP-ABE 解密密钥（交互过程如图 2 所示）。

在场景 2 和场景 3 中，我们采用单一策略对软件更新文件进行加密，并设置了两个不同的属性集合，分别代表两辆能够满足该加密策略的车辆（车辆 1 和车辆 2）。图 3 展示了所采用的加密策略和属性集合。

加密策略的具体含义为：“车辆若要访问该更新数据，必须满足以下两个条件之一：（1）具备 ECU_MODEL_2247 属性；（2）同时具备 CAR_MODEL_21 属性和 ECU_MODEL_2248 属性”。

两个车辆的属性集合具体如下：

· 车辆 1 的属性集合包含四个属性，分别是：“CAR_MODEL_23、ECU_MODEL_2247、ECU_MODEL_2256、ECU_MODEL_2268”；

· 车辆 2 的属性集合包含三个属性，分别是：“CAR_MODEL_21、ECU_MODEL_2246、ECU_MODEL_2248”。

车辆 1 能够对密文进行解密，是因为它具备 ECU_MODEL_2247 属性；车辆 2 能够对密文进行解密，是因为它同时具备 CAR_MODEL_21 属性和 ECU_MODEL_2248 属性。

图 3、实验所用的加密策略和两个车辆的属性集合

实验中，客户端（用于模拟车辆）运行在赛灵思（Xilinx）ZCU102 评估板上。如前所述，该评估板搭载了 Zynq UltraScale + 多核片上系统（MPSoC）芯片，配备四个带 ARM Neon™技术的 ARM Cortex®-A53 核心、两个 Cortex-R5F 实时处理器核心、一个 Mali™-400 MP2 图形处理器，此外还拥有四个 SLFP + 以太网接口、六个 16.3 Gb/s GTH 收发器、64 个用户自定义差分 I/O 信号、600 个系统逻辑单元、32 Mb 内存以及 2500 个 DSP 切片。

对于每种实验场景，我们在 ZCU102 评估板上进行了 5000 次迭代测试，并计算了 95% 置信区间的结果。在椭圆曲线密码学（ECC）操作中，我们使用了 PBC 库的 A 型内部参数，其中群阶为 160 位，元素大小为 512 位，嵌入度 k=2，对应的安全级别为 80 位。

在确定密钥撤销频率时，我们参考了特斯拉（Tesla）车辆的更新频率数据。根据其官方网站信息，2020 年 1 月至 2020 年 11 月期间，特斯拉共发布了 122 次更新，平均每月发布超过 11 次更新。基于此，我们设置了四种不同的密钥撤销频率（大致涵盖从每周到每月的范围），分别为：每 2 次更新执行一次撤销、每 3 次更新执行一次撤销、每 6 次更新执行一次撤销以及每 12 次更新执行一次撤销。

4.2 实验结果

图 4 展示了实验结果。场景 1（无 CP-ABE）的评估结果显示，下载更新文件和验证 RSA 签名总共耗时约 256 毫秒。

在场景 2（仅 CP-ABE 加密）中，引入 CP-ABE 解密后，从车辆发起更新请求到开始安装更新所耗费的时间增加了 200-230 毫秒。耗时增加的原因主要包括两方面：一是执行 CP-ABE 解密操作所需的时间，二是下载 CP-ABE 密文额外数据的时间。

从图 4 中可以看出，车辆 2 的平均耗时比车辆 1 多约 24 毫秒。这是因为在解密 CP-ABE 密文时，车辆 2 需要使用 2 个属性（即 CAR_MODEL_21 和 ECU_MODEL_2248）来满足加密策略，而车辆 1 只需使用 1 个属性（即 ECU_MODEL_2247）即可满足加密策略。

在场景 3（CP-ABE 加密 + 密钥更新）中，当撤销频率设置为每 6 次更新执行一次（相当于每 15 天执行一次撤销）时，额外获取新解密密钥的平均耗时为 90-105 毫秒。此外，图 5 显示，在多种不同的撤销频率下，CP-ABE 解密和密钥更新对总耗时的影响均较小。即使在最高的撤销频率下（每 2 次更新执行一次，相当于每 5 天执行一次），完成更新文件下载、密钥更新以及解密的总耗时也仅不到 675-710 毫秒。当撤销频率降低到每 12 次更新执行一次（大致相当于每月执行一次）时，整个过程的耗时仅为 518-535 毫秒。

图 4、从发起更新请求到开始安装更新前的耗时（场景 3 的撤销频率为每 6 次更新一次）

从场景 2 和场景 3 与场景 1 的耗时对比来看，CP-ABE 似乎对 OTA 软件更新过程的耗时产生了不可忽视的影响。但当我们将这些耗时与实际的软件安装时间进行对比时，会发现 CP-ABE 所增加的耗时其实是可以忽略不计的。

为此，我们还调研了汽车场景中软件更新文件的大小。研究发现，以特斯拉 “Model 3” 车型为例，其软件更新文件的大小通常约为 100 MB。为了模拟软件安装过程，我们在 ZCU102 评估板上安装了不同大小的安装包，并测量了对应的安装时间。具体而言，我们测试了大小约为 6.9 KiB、2.7 MiB 和 5.9 MiB 的程序，安装时间如图 6 所示。

我们未测试更大尺寸的软件安装包，主要原因有两点：一是难以找到大小约为 100 MB 的合适测试程序；二是即便使用这些较小尺寸的安装包，其安装时间也已远大于解密和下载更新文件所需的时间。

图 6 显示，大小约为 6.9 KiB、2.7 MiB 和 5.9 MiB 的软件安装包，其平均安装时间分别为 2100 毫秒、12388 毫秒和 22148 毫秒。

图 6、不同大小软件的安装时间对比

图 7 展示了三种场景下，从车辆发起更新请求到完成更新安装的总耗时。由于软件安装时间远大于其他过程的耗时，为了清晰展示 CP-ABE 对总耗时的影响，我们采用了对数坐标。实际上，当考虑软件安装时间时，三种场景的总耗时几乎没有差异。

具体而言，对于大小为 5.9 MiB 的软件更新文件，其平均安装时间为 22148 毫秒，95% 置信区间为 ±247 毫秒。这意味着软件安装时间比三种场景中之前计算的其他过程耗时高出两个数量级。因此，我们可以得出结论：即便考虑到实验中所使用的软件镜像文件大小远小于实际部署的更新文件大小，CP-ABE 对 OTA 软件更新总耗时的影响仍然是可以忽略不计的。

图 7、从发起更新请求到完成软件安装的总耗时对比（软件大小为 5.9 MiB，场景 3 的撤销频率为每 6 次更新一次）

此外，我们还评估了 CP-ABE 对消息大小的影响。图 8 展示了云服务器发送给车辆的更新消息中各组成部分的大小。该更新消息主要包含三个部分：

1. 经过对称加密的软件更新文件（大小为 5.9 MiB）；

2. 包含对称密钥的 CP-ABE 密文；

3. 原始设备制造商（OEM）的 RSA 签名。

与 RSA 签名相比，CP-ABE 密文的大小是其三倍多。但与软件更新文件本身的大小相比，CP-ABE 密文所增加的额外数据量几乎可以忽略不计。正因如此，为了在同一图表中同时展示两者的大小，我们不得不采用对数坐标。

图 8、云服务器发送给车辆的更新消息中各字段的大小

考虑到 OTA 软件更新并非时间敏感型任务，且无论何种情况，软件安装过程都是耗时最长的环节，我们认为在实际应用中采用 CP-ABE 技术将极大地提升车辆的安全性。

本文的研究表明，在汽车场景中，基于属性的加密（ABE）技术能够提升空中下载（OTA）更新功能的安全性。具体而言，ABE 不仅能为空中软件 / 固件更新提供机密性保障，还能保护静态存储状态下的更新文件。这一安全特性是现有先进解决方案所缺失的。此外，本文还测试了一种简单的密钥撤销机制，而这也是现有系统中未实现的功能。

本文通过实验证实，ABE 能够无缝集成到现有的 OTA 更新解决方案中，并且更广泛地说，ABE 在架构和文档方面均符合汽车行业标准。同时，与 OTA 软件更新涉及的其他任务（如软件安装）相比，ABE 在计算时间和存储方面所带来的额外开销是可以忽略不计的。这些结果表明，我们能够以极低的成本增强 OTA 软件更新的安全性。

由于比萨大学是 H2020 研究计划下欧洲处理器计划（EPI）项目的官方合作伙伴，我们计划与宝马（BMW）、Elektrobit 等其他合作伙伴开展合作，将本文提出的研究成果集成到他们现有的系统中。具体而言，我们计划对 OTA CP-ABE 技术进行适配，使其符合 AUTOSAR 自适应平台的规范要求。