智能网联汽车OTA升级安全设计

2022年9月17日12:02:33评论50 views字数 3789阅读12分37秒阅读模式

摘要

随着汽车行业快速向智能化、网联化、电动化的方向发展，车载电子器件（ECU）在整车系统中逐渐增多，整车和 ECU 已经实现从物理方式到软件升级（OTA）的更新迭代。当前针对汽车的黑客攻击事件频发，OTA 功能作为智能网联汽车的重要功能，也成为黑客的重点攻击对象。攻击者通过劫持、篡改、替换等攻击方法对智能网联汽车 OTA 升级链接发起攻击。文章基于当前智能网联汽车 OTA 升级架构进行安全分析，通过设计安全的 OTA 升级方案，提升整车 OTA 升级的安全性。

前言

近年来，随着智能网联汽车的发展，越来越多的主机厂在汽车产品上集成了 OTA 升级功能，通过 OTA 实现系统升级、应用更新、漏洞修复及功能开通等等。目前主机厂 OTA 系统主要通过自主研发或由 OTA 供应商集成的方式在整车系统上实现 OTA 升级功能。

1 OTA系统架构

整车 OTA 系统主要分为云端、车端、通讯端三部分。

云端主要功能包括：OEM 云对接、车型/车辆/ECU 版本信息管理、升级软件管理，差分包管理、大版本管理及策略创建、ECU 关联升级配置、升级模式配置、策略测试、审批、发布等。车端主要功能包括：升级条件判断、软件包下载、升级包验签、升级包解密、安全刷写、升级状态上报等。

通讯端主要负责在 OTA 升级过程中进行报文传输及升级包下载等。

智能网联汽车OTA升级安全设计

图 1 OTA 升级系统架构图

2 现阶段OTA升级中信息安全威胁

现阶段国内 OEM 已在量产车型上集成 OTA 升级功能，并通过实施安全策略保障 OTA 升级的安全性。目前常见的 OTA 升级校验模式分为两种：

（1）基于 HASH 算法的完整性校验：云端使用 HASH 算法如 MD5、SHA-1 等计算升级文件 HASH 值，车端 UC-Mstaer 使用相同算法计算升级文件HASH 值，通过对比 HASH 值，实现升级文件完整性校验，完成 OTA 升级校验。但攻击者通常可通过篡改 HASH 值、篡改校验逻辑从而绕过该校验方式。

智能网联汽车OTA升级安全设计

图 2 完整性校验

该种校验方式安全性较低且针对该方式的攻击方法较为成熟，不建议 OEM 厂商使用该校验方式实现 OTA 升级校验。

（2）基于签名算法的签名校验：通过使用 PKI 系统生成公私钥，云端使用私钥对升级包数据校验和或其他与数据内容有关的变量进行加密处理，完成对数据的合法“签名”，UC-Master 则利用云端的公钥来解读收到的“数字签名”，并将解读结果用于对数据完整性的检验，确认签名的合法性。保障 OTA 升级安全性。

该种校验方式通过 UC-Master 对升级包进行验签，可以保证升级包整包的合法性和完整性，但在实际升级过程中，一个升级包整包通常打包有多个ECU 升级包，UC-Master 在完成升级包整包校验后，通过对升级包进行解包。通过网关或域控制器透传至目标 ECU，对目标 ECU 进行升级刷写。通常目标ECU 不会对升级包进行二次校验。随着现在攻击者攻击手段不断升级，攻击者可在 UC-Master 对升级包整包完成校验解包后，替换/篡改目标 ECU 升级包，达到恶意升级的目的。

以上两种方法升级均存在一定安全威胁，虽然基于签名算法的校验保证了升级包整包的合法性和完整性，但在升级过程中无法对目标 ECU 升级包进行二次验证，导致仍存在一定安全隐患，影响整车OTA 升级的安全性。

3 安全的OTA升级设计

针对上文讨论，整车 OTA 升级安全性仍存在一定安全威胁。本文将基于数字签名和消息认证码设计一种安全的 OTA 升级方法，提高整车 OTA 升级安全性。

3.1 数字签名

当前部分主机厂 OTA 升级系统通过调用 PKI 系统对升级包进行基于数字签名的合法性校验。数字签名通过使用发送方的私钥对原始数据进行签名，只有用发送方公钥才能通过签名验证。

因此，私钥加密得到的密文实际上就是数字签名，要验证这个签名是否正确，只能用私钥持有者的公钥进行解密验证。使用数字签名的目的是为了确认某个信息确实是由某个发送方发送的，任何人都不可能伪造消息，并且，发送方也不能抵赖。OTA 通过使用数字签名可实现防止伪造、防止抵赖、检测篡改、验证数据的完整性等，保证 OTA 升级过程中软件包的合法性。

常见的数字签名算法有：MD5withRSA／SHA1 withRSA／ SHA256withRSA／ SHA1withDSA／ SHA 256withDSA／SHA512withDSA／ECDSA 等。

基于数字签名的校验流程：云端平台在升级任务下发前，通过签名算法（私钥）对软件升级包进行签名。车端 OTA-Master 通过调用 PKI 系统（公钥） SDK 对升级包进行校验。

但基于数字签名的 OTA 升级校验对车端 UC- Matser 环境要求较高，需通过集成 PKI-SDK 或内置密钥的形式进行。对零部件自身性能及安全性要求较高，通常 UC-Master 搭载在非实时操作系统的智能 ECU 中，如 T-BOX、IVI、CGW 中。主机厂还可在 UC-Master 的智能 ECU 中集成 HSM（硬件安全模块）或 SE 芯片，保障 OTA 升级安全、高效。

3.2 消息认证码

基于分组密码的消息认证码（CMAC）是基于AES 算法，工作模式分为 ECB、CBC、CFB、OFB 四种，其中 CBC 和 ECB 这两种模式比较常用。当取AES 作为 MAC 加密的分组密码时，一般采用 CBC 模式，所以通常称为基于 AES 的 CBC-MAC，只需要一个块密码密钥，并且在加密数量方面进行了高度优化。从分组密码密钥 K1 中派生出两个掩码密钥K2 和 K3。如果最后一个块完成，掩码密钥 K2 将在最后一次加密之前添加；否则，添加掩码密钥 K3。但由于分组密码算法特性，加解密运算时间相对哈希算法运算耗时较长。

基于哈希的消息认证码（ HMAC）是 Keyed- Hashing for Message Authentication 的缩写。HMAC 的 MAC 算法是 HASH 算法，首先它是基于信息摘要算法的。目前主要集合了 MD 和 SHA 两大系列消息摘要算法。其中 MD 系列的算法有 HmacMD2、HmacMD4、HmacMD5 三种算法；SHA 系列的算法有 HmacSHA1 、 HmacSHA224 、 HmacSHA256 、HmacSHA384、HmacSHA512 五种算法。HMAC 算法除了需要信息摘要算法外，还需要一个密钥。HMAC 的密钥可以是任何长度，如果密钥的长度超过了摘要算法信息分组的长度，则首先使用摘要算法计算密钥的摘要作为新的密钥。一般不建议使用太短的密钥，因为密钥的长度与安全强度是相关的。通常选取密钥长度不小于所选用摘要算法输出的信息摘要的长度。

3.3 整车 OTA 安全设计

由于车端 UC-Master 只能对 OTA 升级整包进行校验，车端 UC-Master 完成校验后将升级包整包进行解包，通过网关透传到目标 ECU 进行刷写。但当前传统EEA 架构中只有少数ECU 搭载非实时操作系统，如：T-BOX、IVI、CGW 等。绝大多数 ECU 不具备多线程多任务处理能力且不支持集成第三方SDK，如：VCU、BCM、BMS 等。导致在这类非智能 ECU 上实现基于签名算法的升级校验较为困难。虽然开发者可以通过软件方式实现数字签名算法，

但由于该类 ECU 通常性能较差，软件实现可能导致软件升级签名验证耗时较长，影响软件升级效率。整车的 OTA 升级需在保证安全的前提下，降低对整车及 ECU 性能影响。提高升级效率。

针对当前整车 EE 架构，在 OTA 升级过程中OEM 厂商在车端 UC-Master 中集成 PKI-SDK，实现基于数字签名的升级校验。在云端下发升级任务后，车端 DM 下载软件升级包。UC-Master 对升级包进行签名校验，校验完成后对升级包进行解包分发，通过网关透传到目标 ECU。ECU 根据自身软硬件架构，被升级 ECU-UA 对收到的升级包，使用数字签名或哈希消息认证码（HMAC）进行二次校验，校验成功后进行升级刷写安装。

智能网联汽车OTA升级安全设计