CN114286318A - 一种基于一机一密的ota升级包传输方法 - Google Patents

Abstract

本发明提供了一种基于一机一密的OTA升级包传输方法，所述传输方法包括：云端服务器使用第一密钥对升级包加密；所述云端服务器将用第二密钥对所述第一密钥加密成形成的第三密钥发送给车载网关，所述车载网关用所述第二密钥对所述第三密钥解密获得所述第一密钥；所述车载网关用所述第一密钥对接收的所述升级包解密得到明文的升级包；其中，所述第二密钥是针对每辆车分配的唯一密钥。本发明通过云端服务器和车载网关之间传输第二密钥和第一密钥，而非第一密钥，从而大大降低了裸传第一密钥的风险。因此本发明某种意义上实现“一机一密”，作为信息安全的第三道屏障。

Description

一种基于一机一密的OTA升级包传输方法

技术领域

本发明主要涉及数据安全领域，尤其涉及一种基于一机一 密的OTA升级包传输方法。

背景技术

当传统汽车需要进行车内控制器(Electronic Control Unit，简称ECU)软件升级时，用户需要将汽车开到售后店由专 业人员使用专业工具进行升级，随着汽车智能化网联化的发展， 汽车内代码数量越来越多，代码复杂度越来越高，尤其是面向 服务的电子电器架构(Service Oriented Architecture，简称 SOA)成为行业共识后，汽车的整个生命周期内软件升级的频率 越来越高，因此空中下载技术(Over-the-Air Technology，以 下简称OTA)远程升级技术快速被各大整车厂商所接受，为汽车 用户提供了极大的便利性，也为汽车厂商的业务拓展提供了丰 富的想象空间。OTA技术通常是由每辆汽车充当一个客户端，通 过WIFI或者移动网络连接到汽车制造商的云端服务器，经过预 定的私有协议进行通信交互，完成任务的同步，配置文件的解 析，升级包的下载校验，以及车内控制器ECU的更新等步骤， 相较于传统的升级方式，OTA技术要求汽车需要对外开放通信的 端口，因此OTA技术在带来便利性的同时也增加了被攻击的风 险，如果OTA的信息安全有漏洞，数百万辆汽车被攻击者控制， 不仅危害个人的生命财产安全，也会造成整个社会的动荡。

无论采用哪种OTA技术方案，总会有一些关键信息需要在 网关(Gateway)和云端进行传输，比如客户端每间隔一定的时 间周期向云端查询是否有最新软件版本发布，如果有软件需要 更新，网关需要从云端下载配置文件，配置文件中包含需要被 更新控制器ECU的软件包的版本，密钥，证书，签名等敏感信 息。通常这些关键信息都是基于https(http+tls)协议进行传 输，https协议被广泛应用于互联网行业，用于建立安全的通信 链路，可以完成身份的双向认证和信息的加密传输，是信息安 全的第一道屏障。对升级包和配置文件进行完整性，机密性， 合法性校验是信息安全的第二道屏障。几乎所有的现行OTA技 术在信息安全的设计和实现都会止于此。

在第二道屏障中，为了保证升级包的机密性，一般采用高 级加密标准(AdvancedEncryption Standard，简称AES)对称 加密算法对升级包加密，当零部件供应商发布控制器(ECU)的 软件包并上传至整车厂的云端服务器时，云端服务器会动态生 成对称密钥，使用此密钥加密升级包，并在OTA升级过程中将 此对称密钥传输至相应的控制器进行解密，考虑到云端服务器 的开发和管理，当有大量安装此控制器(ECU)的汽车需要更新 软件时，几乎无法做到一机一密，这里的一机一密含义是：针 对软件包，每辆车使用不同的对称密钥，加上此密钥在第二道 屏障里通常是明文传输，如果第一道屏障被攻破，第二道屏障 的机密性将无法得到保证。

发明内容

应当理解，本公开以上的一般性描述和以下的详细描述都是 示例性和说明性的，并且旨在为本公开提供进一步的解释。

本发明要解决的技术问题是提供

为解决上述技术问题，本发明提供了一种基于一机一密的 OTA升级包传输方法，其特征在于，所述传输方法包括：

步骤S1，云端服务器使用第一密钥对升级包加密；

步骤S2，所述云端服务器将用第二密钥对所述第一密钥加 密成形成的第三密钥发送给车载网关，所述车载网关用所述第 二密钥对所述第三密钥解密获得所述第一密钥；

步骤S3，所述车载网关用所述第一密钥对接收的所述升级 包解密得到明文的升级包；

其中，所述第二密钥是针对每辆车分配的唯一密钥。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述第二密钥的形成包括：

在OTA发生时，由云端服务器生成随机数的所述第二密钥， 并发送给所述车载网关。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述第二密钥的形成包括：

由所述车载网关自动生成，并同步到所述云端服务器，待 OTA时由所述云端服务器下发。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述步骤S2和步骤S3之间进 一步包括：

所述车载网关获得所述升级包后，检测是否满足所述升级包 的下载条件？如果满足，进入正常下载，如果不满足，等待满 足所述下载条件。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述下载条件包括车载端电池 电压和转速。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述步骤S1中的所述升级包由 供应商提供。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述步骤S2和步骤S3之间进 一步包括：

所述云端服务器比较并判断所述供应商和所述车载网关获 得的软件版本，需要升级时，下发升级任务并发送所述第二密 钥给所述车载网关，不需要升级时，则断开安全链路连接。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述步骤S3之后进一步包括：

步骤S4，所述车载网关校验所述升级包的完整性和合法性， 如果验证成功进行更新，如果验证不成功，将下载失败信息上 报所述云端服务器。

比较好的是，本发明进一步提供了一种基于一机一密的OTA 升级包传输方法，其特征在于，所述步骤S4之后进一步包括：

步骤S5，所述车载网关接收更新的报文实现文件的传输与 更新，并将最新的版本号上报所述云端服务器。

与现有技术相比，本发明提出的一种加强版的信息安全解 决方案，在某种意义上实现“一机一密”，作为信息安全的第 三道屏障。

附图说明

现在将详细参考附图描述本公开的实施例。现在将详细参考 本公开的优选实施例，其示例在附图中示出。在任何可能的情 况下，在所有附图中将使用相同的标记来表示相同或相似的部 分。此外，尽管本公开中所使用的术语是从公知公用的术语中 选择的，但是本公开说明书中所提及的一些术语可能是申请人 按他或她的判断来选择的，其详细含义在本文的描述的相关部 分中说明。此外，要求不仅仅通过所使用的实际术语，而是还 要通过每个术语所蕴含的意义来理解本公开。

下面，参照附图，对于熟悉本技术领域的人员而言，从对 本发明的详细描述中，本发明的上述和其他目的、特征和优点 将显而易见。

图1是实现本发明的升级包传输的系统框图；

图2是本发明的流程示意图。

附图标记

11――云端服务器

12――车载网关

100――升级系统

200――供应商

具体实施方式

为了更清楚地说明本申请的实施例的技术方案，下面将对 实施例描述中所需要使用的附图作简单的介绍。显而易见地， 下面描述中的附图仅仅是本申请的一些示例或实施例，对于本 领域的普通技术人员来讲，在不付出创造性劳动的前提下，还 可以根据这些附图将本申请应用于其他类似情景。除非从语言 环境中显而易见或另做说明，图中相同标号代表相同结构或操 作。

如本申请和权利要求书中所示，除非上下文明确提示例外 情形，“一”、“一个”、“一种”和/或“该”等词并非特指 单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成 一个排它性的罗列，方法或者设备也可能包含其他的步骤或元 素。

除非另外具体说明，否则在这些实施例中阐述的部件和步 骤的相对布置、数字表达式和数值不限制本申请的范围。同时， 应当明白，为了便于描述，附图中所示出的各个部分的尺寸并 不是按照实际的比例关系绘制的。对于相关领域普通技术人员 已知的技术、方法和设备可能不作详细讨论，但在适当情况下， 所述技术、方法和设备应当被视为授权说明书的一部分。在这 里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示 例性的，而不是作为限制。因此，示例性实施例的其它示例可 以具有不同的值。应注意到：相似的标号和字母在下面的附图 中表示类似项，因此，一旦某一项在一个附图中被定义，则在 随后的附图中不需要对其进行进一步讨论。

在本申请的描述中，需要理解的是，方位词如“前、后、 上、下、左、右”、“横向、竖向、垂直、水平”和“顶、底” 等所指示的方位或位置关系通常是基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，在未作相反说明 的情况下，这些方位词并不指示和暗示所指的装置或元件必须 具有特定的方位或者以特定的方位构造和操作，因此不能理解 为对本申请保护范围的限制；方位词“内、外”是指相对于各 部件本身的轮廓的内外。

为了便于描述，在这里可以使用空间相对术语，如“在…… 之上”、“在……上方”、“在……上表面”、“上面的”等， 用来描述如在图中所示的一个器件或特征与其他器件或特征的 空间位置关系。应当理解的是，空间相对术语旨在包含除了器 件在图中所描述的方位之外的在使用或操作中的不同方位。例 如，如果附图中的器件被倒置，则描述为“在其他器件或构造 上方”或“在其他器件或构造之上”的器件之后将被定位为“在 其他器件或构造下方”或“在其他器件或构造之下”。因而， 示例性术语“在……上方”可以包括“在……上方”和“在…… 下方”两种方位。该器件也可以其他不同方式定位(旋转90度 或处于其他方位)，并且对这里所使用的空间相对描述作出相应 解释。

此外，需要说明的是，使用“第一”、“第二”等词语来 限定零部件，仅仅是为了便于对相应零部件进行区别，如没有 另行声明，上述词语并没有特殊含义，因此不能理解为对本申 请保护范围的限制。此外，尽管本申请中所使用的术语是从公 知公用的术语中选择的，但是本申请说明书中所提及的一些术 语可能是申请人按他或她的判断来选择的，其详细含义在本文 的描述的相关部分中说明。此外，要求不仅仅通过所使用的实 际术语，而是还要通过每个术语所蕴含的意义来理解本申请。

本申请中使用了流程图用来说明根据本申请的实施例的系 统所执行的操作。应当理解的是，前面或下面操作不一定按照 顺序来精确地执行。相反，可以按照倒序或同时处理各种步骤。 同时，或将其他操作添加到这些过程中，或从这些过程移除某 一步或数步操作。

图1是本发明的组成系统框图。

实现本发明OTA升级包传输的系统100包括云端服务器11 和车载网关12，升级包由供应商200提供。

具体的流程请参见图2所示，下面给予详细的说明：

步骤S11，零部件供应商发布控制器(ECU)的软件包上传 至整车厂的云端服务器11；

步骤S12，云端服务器11使用key1对升级包进行对称加密；

步骤S13，以一定周期，车载网关12与云端服务器11进行 通信，车端网关12将先进驾驶辅助系统(简称ADAS)的软件版 本，以及车辆的VIN和SN号上报给云端服务器11，向云端服务 器11请求安全通信；

其中，VIN码又称车辆识别码，即车辆身份证。由十七个字 母或数字组成，VIN码第一位为车辆产地，L为中国，其它都是 进口车；4-8位是车辆的描述，包括车重、发动机、变速箱等； 第9位用于校验；第10位代表车辆生产年份；第11位是工厂 代码，代表车辆组装工厂；剩下的6位(12-17位)是产品的序 列号车辆的VIN号；

其中，SN号是序列号，每辆车出厂时都配有自己唯一的SN 码。

步骤S14，云端服务器11根据步骤S11和S13分别从供应 商和车载网关获得的软件版本进行比较，判断是否不一致需要 升级，如果需要升级，云端服务器11才下发升级任务，如果一 致不需要升级，则进入步骤S15，如果有升级任务，转入步骤 S17；

步骤S15，断开安全链路连接，并计时；

步骤S16，判断计时是否到设定周期，如果不到，转入S15， 如果达到设定周期，转入步骤S14，继续考察是否需要升级；

步骤S17，云端服务器通过私有协议与车载网关进行信息交 互，同时生成随机数key2发送至车载网关，车载网关接收到key2 后将其保存在可信执行环境中；

在该步骤中，key2的产生有多种方案，比较典型的包括：

方案一：在OTA时候发生时，由云端服务器11生成随机数 key2，然后发送给网关12；

方案二：由车载网关12自动生成，可以是产线上本地服务 器与车辆的VIN和SN号绑定生成该key2，并由本地服务器同步 到云端服务器11，到OTA时由云端服务器11下发下来；

该key2为每辆车分配的唯一对称密钥key2，对称密钥key2 需要和车辆的VIN和SN号绑定，绑定关系需要同步至云端服务 器11，至此，云端服务器11和车端网关12在车辆生产阶段就 已经共享了密钥key2。步骤S18，云端服务器11使用key2对 key1进行对称加密生成key3，并将key3通过私有协议发送至 车载网关12；

步骤S19，车载网关12判断以上信息是否有误？

在步骤S12中云端服务器11对升级包用key1加密，然后再 用key2加密key1得到key3，车载网关12用key2对key3解密 得到key1，如果能解密获得key1，表明正确获取到传输的OTA 软件升级包，转入步骤S20；

如果车载网关12解不出来key1，则表明有误，下载失败， 转入步骤S25；

步骤S20，在获取到传输的OTA软件升级包后，车载网关12 进一步检测下载该升级包的条件是否满足？如果满足转入S21， 不满足，转入S22；

这里的车载端下载条件包括：车载端电池电压，转速等。

S21，如果条件满足，表明车载端已经做好下载准备，则按 照步骤S17中信息交互获得的指定地址，下载升级包；

S22，如果条件不满足，需要进一步等待车载端做好下载准 备，此时通过计时并判断累积时间是否达到设定周期，即周期 性检测下载条件是否满足，如果满足，转入步骤S21，如果此时 仍不满足，则断开安全连接，等待固定周期后转入步骤S13；

S23，车载网关下载完升级包后，使用步骤S19中获得的key1 对升级包进行解密得到明文的升级包，解密成功则说明升级包 的机密性正确，如果解密不成功，转到步骤S25，提示失败；

S24，车载网关12使用哈希文件校验升级包的完整性，完整 性校验成功后，再使用证书链和签名验证升级包的合法性，验 证成功则转至步骤S26；

S25，如果验证失败，则下载失败，上报至云端服务器，提 示失败的具体原因，断开通信链路；

S26，车载网关12作为统一诊断服务(Unified Diagnostic Services，简称UDS)UDS Client解析升级脚本，被更新的节 点ADAS作为UDS Server接收更新的报文实现文件的传输与更 新，更新成功后，需要将最新的版本号上报云端并通知更新成 功，更新失败则上报失败的原因。

从上面详细的流程步骤描述可以了解到，本发明实现一机一 密的方式是，用每个车随机不同的key2对升级包加密的key1 再进行加解密成key3之后再进行传输，然后解密后取回key1， 即通过云端服务器11和车载网关12之间传输key2和key3，而 非key1，从而大大降低了裸传key1的风险。

上文已对基本概念做了描述，显然，对于本领域技术人员 来说，上述发明披露仅仅作为示例，而并不构成对本申请的限 定。虽然此处并没有明确说明，本领域技术人员可能会对本申 请进行各种修改、改进和修正。该类修改、改进和修正在本申 请中被建议，所以该类修改、改进、修正仍属于本申请示范实 施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如 “一个实施例”、“一实施例”、和/或“一些实施例”意指与 本申请至少一个实施例相关的某一特征、结构或特点。因此， 应强调并注意的是，本说明书中在不同位置两次或多次提及的 “一实施例”或“一个实施例”或“一替代性实施例”并不一 定是指同一实施例。此外，本申请的一个或多个实施例中的某 些特征、结构或特点可以进行适当的组合。

本申请的一些方面可以完全由硬件执行、可以完全由软件 (包括固件、常驻软件、微码等)执行、也可以由硬件和软件 组合执行。以上硬件或软件均可被称为“数据块”、“模块”、 “引擎”、“单元”、“组件”或“系统”。处理器可以是一 个或多个专用集成电路(ASIC)、数字信号处理器(DSP)、数 字信号处理器件(DAPD)、可编程逻辑器件(PLD)、现场可编 程门阵列(FPGA)、处理器、控制器、微控制器、微处理器或 者其组合。此外，本申请的各方面可能表现为位于一个或多个 计算机可读介质中的计算机产品，该产品包括计算机可读程序 编码。例如，计算机可读介质可包括，但不限于，磁性存储设 备(例如，硬盘、软盘、磁带……)、光盘(例如，压缩盘CD、 数字多功能盘DVD……)、智能卡以及闪存设备(例如，卡、棒、 键驱动器……)。

计算机可读介质可能包含一个内含有计算机程序编码的传 播数据信号，例如在基带上或作为载波的一部分。该传播信号 可能有多种表现形式，包括电磁形式、光形式等等、或合适的 组合形式。计算机可读介质可以是除计算机可读存储介质之外 的任何计算机可读介质，该介质可以通过连接至一个指令执行 系统、装置或设备以实现通讯、传播或传输供使用的程序。位 于计算机可读介质上的程序编码可以通过任何合适的介质进行 传播，包括无线电、电缆、光纤电缆、射频信号、或类似介质、 或任何上述介质的组合。

上文已对基本概念做了描述，显然，对于本领域技术人员 来说，上述发明披露仅仅作为示例，而并不构成对本申请的限 定。虽然此处并没有明确说明，本领域技术人员可能会对本申 请进行各种修改、改进和修正。该类修改、改进和修正在本申 请中被建议，所以该类修改、改进、修正仍属于本申请示范实 施例的精神和范围。

同时，本申请使用了特定词语来描述本申请的实施例。如 “一个实施例”、“一实施例”、和/或“一些实施例”意指与 本申请至少一个实施例相关的某一特征、结构或特点。因此， 应强调并注意的是，本说明书中在不同位置两次或多次提及的 “一实施例”或“一个实施例”或“一替代性实施例”并不一 定是指同一实施例。此外，本申请的一个或多个实施例中的某 些特征、结构或特点可以进行适当的组合。

同理，应当注意的是，为了简化本申请披露的表述，从而 帮助对一个或多个发明实施例的理解，前文对本申请实施例的 描述中，有时会将多种特征归并至一个实施例、附图或对其的 描述中。但是，这种披露方法并不意味着本申请对象所需要的 特征比权利要求中提及的特征多。实际上，实施例的特征要少 于上述披露的单个实施例的全部特征。

一些实施例中使用了描述成分、属性数量的数字，应当理 解的是，此类用于实施例描述的数字，在一些示例中使用了修 饰词“大约”、“近似”或“大体上”来修饰。除非另外说明， “大约”、“近似”或“大体上”表明所述数字允许有±20％的 变化。相应地，在一些实施例中，说明书和权利要求中使用的 数值参数均为近似值，该近似值根据个别实施例所需特点可以 发生改变。在一些实施例中，数值参数应考虑规定的有效数位 并采用一般位数保留的方法。尽管本申请一些实施例中用于确 认其范围广度的数值域和参数为近似值，在具体实施例中，此 类数值的设定在可行范围内尽可能精确。

虽然本申请已参照当前的具体实施例来描述，但是本技术 领域中的普通技术人员应当认识到，以上的实施例仅是用来说 明本申请，在没有脱离本申请精神的情况下还可作出各种等效 的变化或替换，因此，只要在本申请的实质精神范围内对上述 实施例的变化、变型都将落在本申请的权利要求书的范围内。

Claims (9)

1.一种基于一机一密的OTA升级包传输方法，其特征在于，所述传输方法包括：

步骤S1，云端服务器使用第一密钥对升级包加密；

步骤S2，所述云端服务器将用第二密钥对所述第一密钥加密成形成的第三密钥发送给车载网关，所述车载网关用所述第二密钥对所述第三密钥解密获得所述第一密钥；

步骤S3，所述车载网关用所述第一密钥对接收的所述升级包解密得到明文的升级包；

其中，所述第二密钥是针对每辆车分配的唯一密钥。

2.根据权利要求1所述的基于一机一密的OTA升级包传输方法，其特征在于，所述第二密钥的形成包括：

在OTA发生时，由云端服务器生成随机数的所述第二密钥，并发送给所述车载网关。

3.根据权利要求1所述的基于一机一密的OTA升级包传输方法，其特征在于，所述第二密钥的形成包括：

由所述车载网关自动生成，并同步到所述云端服务器，待OTA时由所述云端服务器下发。

4.根据权利要求2或3所述的基于一机一密的OTA升级包传输方法，其特征在于，所述步骤S2和步骤S3之间进一步包括：

所述车载网关获得所述升级包后，检测是否满足所述升级包的下载条件？如果满足，进入正常下载，如果不满足，等待满足所述下载条件。

5.根据权利要求4所述的基于一机一密的OTA升级包传输方法，其特征在于，

所述下载条件包括车载端电池电压和转速。

6.根据权利要求5所述的基于一机一密的OTA升级包传输方法，其特征在于，

所述步骤S1中的所述升级包由供应商提供。

7.根据权利要求6所述的基于一机一密的OTA升级包传输方法，其特征在于，所述步骤S2和步骤S3之间进一步包括：

所述云端服务器比较并判断所述供应商和所述车载网关获得的软件版本，需要升级时，下发升级任务并发送所述第二密钥给所述车载网关，不需要升级时，则断开安全链路连接。

8.根据权利要求7所述的基于一机一密的OTA升级包传输方法，其特征在于，所述步骤S3之后进一步包括：

步骤S4，所述车载网关校验所述升级包的完整性和合法性，如果验证成功进行更新，如果验证不成功，将下载失败信息上报所述云端服务器。

9.根据权利要求8所述的基于一机一密的OTA升级包传输方法，其特征在于，所述步骤S4之后进一步包括：

步骤S5，所述车载网关接收更新的报文实现文件的传输与更新，并将最新的版本号上报所述云端服务器。

Images