本文由武智、刘天宇、贾先锋共同创作
摘要
随着汽车工业向智能化、网络化、电气化方向的快速发展，车载电子设备（ECU）整车系统逐渐增多，整车和 ECU 从物理模式升级到软件升级（OTA）更新迭代。目前，黑客攻击事件频发，OTA 作为智能网络汽车的重要功能，该功能也成为黑客的关键攻击对象。攻击者通过劫持、篡改、替换等攻击方法对智能网联汽车进行攻击 OTA 升级链接发起攻击。基于当前智能网联汽车的文章 OTA 通过设计安全性，升级架构进行安全分析 OTA 升级方案，提升整车 OTA 安全升级。
近年来，随着智能网络汽车的发展，越来越多的主机制造商集成了汽车产品 OTA 升级功能，通过 OTA 实现系统升级、应用更新、漏洞修复和功能开放。目前，主机厂 OTA 系统主要通过自主研发或自主研发 OTA 在整车系统中实现供应商集成的方式 OTA 升级功能。
整车 OTA 系统主要分为云、车、通信三部分。
云的主要功能包括：OEM 车型/车辆/云对接ECU 版本信息管理、软件管理升级、差分包管理、大版本管理和策略创建ECU 相关升级配置、升级模式配置、战略测试、审批、发布等。车辆的主要功能包括：升级条件判断、软件包下载、升级包验证、升级包解密、安全刷、升级状态报告等。
通信端主要负责 OTA 升级过程中进行报文传输及升级包下载等。
图 1 OTA 升级系统架构图
现阶段国内 OEM 已集成量产车型 OTA 升级功能，实施安全战略保障 OTA 安全升级。目前常见 OTA 升级验证模式分为两种：
（1）基于 HASH 算法完整性验证：云使用 HASH 算法如 MD5、SHA-1 等待计算升级文件 HASH 值，车端 UC-Mstaer 使用相同算法计算升级文件HASH 值，通过比较 HASH 值，升级文件完整性验证，完成 OTA 升级校验。但攻击者通常可以篡改 HASH 篡改验证逻辑以绕过验证方法。
图 2 完整性校验
该校验方法安全性低，攻击方法成熟，不建议 OEM 制造商使用验证方法来实现验证 OTA 升级校验。
(2)基于签名算法的签名验证:使用 PKI 系统生成公共和私钥，云使用私钥加密升级包数据验证等与数据内容相关的变量，完成数据的合法签名，UC-Master 云公钥用于解收到的数字签名保障 OTA 升级安全性。
通过这种验证方法 UC-Master 检查升级包可以保证升级包的合法性和完整性，但在实际升级过程中，升级包通常包装多个ECU 升级包，UC-Master 升级包全包验证完成后， 解包升级包。通过网关或域控制器传输到目标 ECU，对目标 ECU 升级刷写。通常目标ECU 升级包不会进行二次验证。随着攻击者攻击手段的不断升级，攻击者可以在那里 UC-Master 升级包完成验证解包后，更换/篡改目标 ECU 升级包，达到恶意升级的目的。
上述两种升级方法都有一定的安全威胁。虽然基于签名算法的验证确保了升级包的合法性和完整性，但在升级过程中不能对目标进行检查 ECU 升级包进行二次验证，仍存在一定的安全隐患，影响整车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）二次验证，验证成功后升级刷写安装。
图 3 车端 OTA 升级流程
在整车 OTA 升级，根据不同 ECU 软硬件架构。车端使用数字签名或消息认证码 UC-Master 和 UA 二次验证升级包可以充分保证整车OTA 安全可靠性升级。
在整车 OTA 信息安全在升级中 OTA 升级至关重要。随着攻击者攻击技术的不断提高，OEM 除了保证 OTA 需要对高效可靠的升级进行升级 OTA 不断优化升级安全。
本文通过分析不同 ECU 结合不同的算法特性，提出软硬件架构的安全性 OTA 升级方案有效改进 OTA 安全升级。