技术领域

本申请涉及车载技术领域， 尤其涉及一种车载设备升级方法及相关设备。 背景技术

未来的每辆车都是车联网中的一个网络节点， 与电脑， 手机等联网设备没有本质的不 同。 据估计， 北美 60%到 70%车辆招回是由于固件 /软件的原因， 因此升级车载设备的固件 /软件是必不可少的环节。传统待升级车载设� �的固件 /软件是采用车辆招回的方式， 这种办 法的缺点是： 成本高、 周期长。

因此， 未来车载设备的升级应采用更灵活的远程升级 ， 空中下载技术 (Over-The-Air， OTA)的方式， 就像现在的电脑和手机升级一样通过远程来升 级。 对车载设备进行远程固件 /软件升级可带来很多好处。 例如， 便于关键的固件 /软件 bugs得以快速修复、 增加车辆安 全性、 便于车辆在整个生命周期内及时添加新功能或 特色等。 因此采用 OTA方式不需要车 辆招回就可进行固件 /软件升级， 可为车辆生产商或销售商节省大量成本， 同时也为车主带 来便利。

然而， 在智能车辆的远程升级过程中， 可能存在一些安全隐患。 例如， 升级文件被非 法窃取或者篡改， 智能车辆内部的安全处理密钥被非法窃取或篡 改等， 这些都有可能导致 车载设备升级的失败或异常， 最终导致用户的驾驶安全受到威胁。 因此， 如何保证车载设 备安全高效的进行固件 /软件升级成为亟待解决的问题。 发明内容

本发明实施例所要解决的技术问题在于， 提供一种车载设备升级方法及相关设备， 解 决了车载设备无法安全高效的进行固件 /软件升级的问题。

第一方面， 本发明实施例提供了一种车载设备升级方法， 应用于车载系统， 所述车载 系统包括智能车辆和通信设备， 所述智能车辆包括车载控制设备， 所述方法可包括：

所述车载控制设备接收通信设备发送的第一部 分密钥； 所述车载控制设备将所述第一 部分密钥与存储在所述车载控制设备上的第二 部分密钥还原得到第一密钥； 所述车载控制 设备利用所述第一密钥对第一升级文件进行安 全处理， 得到安全处理后的第一升级文件， 所述安全处理包括生成第一消息认证码 MAC,所述安全处理后的第一升级文件包括所述� � 一升级文件和所述第一 MAC。 本发明实施例， 通过在车载升级架构中， 加入与智能车辆匹 配的通信设备， 并作为智能车辆的安全密钥分散保管的载体， 使得智能车辆中的车载控制 设备在需要对升级文件进行安全处理时， 可以从通信设备处获得分散保管的密钥并进行 密 钥还原， 并利用还原后的密钥对升级文件进行安全处理 ， 以便于升级文件在车内的安全保 存和 /或安全传输，避免密钥单独存储在智能车辆� �通信设备上，被不法分子轻易截获篡改， 从而保证了智能车辆中升级文件的存储或传输 的安全性， 此外， 在智能车辆中的车载控制 设备和待升级车载设备之间进行升级文件的传 输时， 具体利用生成升级文件的 MAC， 并携 带在第一升级文件中发送给待升级车载设备的 方式， 从而保证升级文件在车内传输过程的 完整性， 且减少了车内安全校验的计算量， 提升升级效率。 在一种可能的实现方式中， 所述通信设备为与所述智能车辆之间建立了匹 配关系的终 端设备， 或者所述通信设备是为智能车辆提供特定服务 的服务器， 其中， 所述升级包包括 所述第一升级文件。 本发明实施例提供两种不同的安全升级架构， 当第一部分密钥来自于 终端设备 （如智能手机） 时， 智能车辆通过与终端设备之间的密钥分散存储 管理， 合作完 成车辆内部的安全存储或传输； 当第一部分密钥来自于服务器 （可选的， 密钥服务器或专 用服务器） 时， 那么智能车辆通过与服务器之间的密钥分散存 储管理， 合作完成车辆内部 的安全存储或传输。 避免密钥只存储在一个设备上， 被不法分子轻易截获篡改， 从而保证 了智能车辆中升级文件的存储或传输的安全性 。

在一种可能的实现方式中， 所述智能车辆还包括第一待升级车载设备； 所述方法还包 括：所述车载控制设备将所述安全处理后的第 一升级文件发送给所述第一待升级车载设备; 所述第一待升级车载设备利用存储在所述车载 控制设备上的第二密钥对所述安全处理后的 第一升级文件进行安全校验， 所述第二密钥为与所述第一密钥预先匹配的密 钥， 所述安全 校验为所述安全处理的逆操作； 若校验成功， 所述第一待升级车载设备根据校验成功的第 一升级文件进行升级。 本发明实施例， 车载控制设备将分散保管的密钥还原得到第一 密钥 后， 对升级文件进行安全处理， 以将该安全处理后的升级文件安全传输给对应 的待升级车 载设备进行安全升级。 保证了升级文件在智能车辆的车内传输即车载 控制设备与待升级车 载设备之间的传输过程中的安全性。

在一种可能的实现方式中， 所述安全处理还包括利用所述第一密钥对所述 第一升级文 件和第一 MAC进行加密； 所述安全处理后的第一升级文件包括经过所述 第一密钥加密后 的所述第一升级文件和所述第一 MAC。 本发明实施例， 通过在智能车辆中的车载控制设备 和待升级车载设备之间进行升级文件的传输时 ， 不仅利用生成升级文件的 MAC， 并携带在 第一升级文件中， 并且还进一步通过第一密钥对其进行加密， 再发送给待升级车载设备的 方式， 不仅保证升级文件在车内传输过程的完整性， 减少了车内安全校验的计算量， 提升 升级效率， 并且还进一步的保证了升级文件的私密性， 以避免被不法分子窃取。

在一种可能的实现方式中，所述车载控制设备 接收通信设备发送的第一部分密钥之前， 还包括： 所述车载控制设备确定所述第一密钥以及所述 第二密钥， 并将所述第二密钥发送 给所述第一待升级车载设备。 本发明实施例， 在智能车辆中的第一密钥分散保管之前， 车 载控制设备需要先确定车内使用的密钥对， 并发送给对应的待升级车载设备。 便于车载控 制设备将升级文件利用与待升级车载设备协商 好的第一密钥进行安全处理， 且待升级车载 设备利用协商好的匹配的第二密钥进行安全校 验， 以保证升级文件在车内的传输安全。

在一种可能的实现方式中，所述车载控制设备 接收通信设备发送的第一部分密钥之前， 还包括：所述车载控制设备将所述第一密钥拆 分为所述第一部分密钥和所述第二部分密钥， 并将所述第一部分密钥发送给所述通信设备。 本发明实施例， 在智能车辆中的第一密钥分 散保管之前， 车载控制设备与待升级车载设备协商好第一密 钥和第二密钥之后， 车载控制 设备将第一密钥进行拆分， 并将拆分的一部分发送至匹配的通信设备上进 行存储， 自身保 存另一部分， 以避免被一次性轻易的非法截获篡改。

在一种可能的实现方式中，所述车载控制设备 接收通信设备发送的第一部分密钥之前， 还包括： 所述车载控制设备获取升级包， 所述升级包包括所述第一升级文件； 所述车载控 制设备对所述升级包进行安全验证； 在验证通过的情况下， 所述车载控制设备向所述通信 设备请求所述第一部分密钥。 本发明实施例， 在车载控制设备获取分散保管的部分密钥之 前， 首先需要获取包含升级文件的升级包， 并且对该升级包进行安全验证， 验证通过后， 则启动将对应的将升级文件进行安全处理并传 输给对应的待升级车载设备的流程， 也才会 向通信设备请求用于对升级文件进行安全处理 的部分密钥。 避免在没有确定车载升级包是 否安全的情况下， 过早获取第一部分密钥， 以免被非法获取， 进一步提升了车载升级的安 全性。

在一种可能的实现方式中， 所述通信设备包括终端设备； 所述车载控制设备获取升级 包之前， 还包括： 所述车载控制设备向所述通信设备发送安全升 级请求， 所述安全升级请 求包括所述智能车辆的升级相关参数； 在所述升级相关参数满足预设升级条件的情况 下， 所述车载控制设备接收所述通信设备发送的第 一指示， 所述第一指示用于触发所述车载控 制设备从所述终端设备或升级服务器处获取所 述升级包。 本发明实施例， 在通信设备根据 智能车辆的车载控制设备反馈的升级相关参数 ， 判断出该智能车辆当前满足升级条件的情 况下， 才会指示或触发该智能车辆的车载控制设备进 行车载升级包的获取， 以提升车载升 级的成功率。 可以理解的是， 智能车辆可以是从服务器处获取， 也可以是通信设备上获取 已经下载好的升级包。

在一种可能的实现方式中， 所述方法还包括： 所述车载控制设备和所述通信设备相互 进行安全认证， 以建立安全合作通道； 所述车载控制设备接收通信设备发送的第一部 分密 钥， 包括： 所述车载控制设备通过所述安全通道接收通信 设备发送的第一部分密钥。 本发 明实施例， 车载控制设备和相匹配的通信设备之间建立安 全通道， 后续的车载控制设备和 通信设备之间的第一部分密钥请求、 安全认证请求等， 都可以通过该安全通道来传输， 以 进一步的保证车载控制设备和通信设备之间的 安全传输。

在一种可能的实现方式中， 所述方法还包括： 所述车载控制设备在所述第一待升级车 载设备升级成功后， 指示所述通信设备更新所述第一升级文件的回 滚文件； 和 /或所述车载 控制设备在所述第一待升级车载设备升级失败 后， 从所述通信设备获取所述第一升级文件 的回滚文件， 并发送给所述第一待升级车载设备进行回滚操 作。 本发明实施例， 通信设备 可以为智能车辆提供升级文件的回滚文件， 无论在待升级车载设备升级成功或者失败的情 况下， 通信设备都对当前的升级文件进行回滚操作， 以便于待升级车载设备后续升级时优 回滚文件可以参考。 第二方面， 本发明实施例提供了一种车载设备升级方法， 应用于车载系统， 所述车载 系统包括智能车辆和通信设备， 所述智能车辆包括车载控制设备， 所述方法包括：

通信设备向所述车载控制设备发送第一部分密 钥， 所述第一部分密钥用于所述车载控 制设备与存储在所述车载控制设备上的第二部 分密钥还原得到第一密钥， 所述第一密钥用 于所述车载控制设备对第一升级文件进行安全 处理， 得到安全处理后的第一升级文件， 所 述安全处理还包括利用所述第一密钥对所述第 一升级文件和第一 MAC进行加密； 所述安 全处理后的第一升级文件包括经过所述第一密 钥加密后的所述第一升级文件和所述第一 MAC。 本发明实施例， 通过在车载升级架构中， 加入与智能车辆匹配的通信设备， 并作为 智能车辆的安全密钥分散保管的载体， 使得智能车辆中的车载控制设备在需要对升级 文件 进行安全处理时， 可以从通信设备处获得分散保管的密钥并进行 密钥还原， 并利用还原后 的密钥对升级文件进行安全处理， 以便于升级文件在车内的安全保存和 /或安全传输， 避免 密钥单独存储在智能车辆或通信设备上， 被不法分子轻易截获篡改， 从而保证了智能车辆 中升级文件的存储或传输的安全性。

在一种可能的实现方式中， 所述车载控制设备将所述第一密钥拆分为所述 第一部分密 钥和所述第二部分密钥； 所述通信设备向所述车载控制设备发送第一部 分密钥之前， 还包 括： 所述通信设备接收所述车载控制设备发送的所 述第一部分密钥。 本发明实施例， 在智 能车辆中的第一密钥分散保管之前， 车载控制设备与待升级车载设备协商好第一密 钥和第 二密钥之后， 车载控制设备将第一密钥进行拆分， 并将拆分的一部分发送至匹配的通信设 备上进行存储， 自身保存另一部分， 以避免被一次性轻易的非法截获篡改。

在一种可能的实现方式中，所述通信设备向所 述车载控制设备发送第一部分密钥之前， 还包括： 所述通信设备接收所述车载控制设备发送的第 一部分密钥请求， 所述第一部分密 钥请求为所述车载控制设备对升级包进行安全 验证且在验证通过的情况下发送的， 所述升 级包包括所述第一升级文件。 本发明实施例， 在车载控制设备获取分散保管的部分密钥之 前， 首先需要获取包含升级文件的升级包， 并且对该升级包进行安全验证， 验证通过后， 则启动将对应的将升级文件进行安全处理并传 输给对应的待升级车载设备的流程， 也才会 向通信设备请求用于对升级文件进行安全处理 的部分密钥。 避免在没有确定车载升级包是 否安全的情况下， 过早获取第一部分密钥， 以免被非法获取， 进一步提升了车载升级的安 全性。

在一种可能的实现方式中， 所述通信设备包括终端设备； 所述通信设备接收所述车载 控制设备发送的第一部分密钥请求之前， 还包括： 所述通信设备接收所述车载控制设备发 送的安全升级请求， 所述安全升级请求包括所述智能车辆的升级相 关参数； 所述通信设备 判断所述升级相关参数是否满足预设升级条件 ； 若满足， 所述通信设备向所述车载控制设 备发送第一指示， 所述第一指示用于触发所述车载控制设备从所 述终端设备或升级服务器 处获取所述升级包。 本发明实施例， 在通信设备根据智能车辆的车载控制设备反馈 的升级 相关参数， 判断出该智能车辆当前满足升级条件的情况下 ， 才会指示或触发该智能车辆的 车载控制设备进行车载升级包的获取， 以提升车载升级的成功率。 可以理解的是， 智能车 辆可以是从服务器处获取， 也可以是通信设备上获取已经下载好的升级包 。

在一种可能的实现方式中， 所述方法还包括： 所述通信设备和所述车载控制设备相互 进行安全认证， 以建立安全合作通道； 所述通信设备向所述车载控制设备发送第一部 分密 钥， 包括： 所述通信设备通过所述安全通道向所述车载控 制设备发送第一部分密钥。 本发 明实施例， 车载控制设备和相匹配的通信设备之间建立安 全通道， 后续的车载控制设备和 通信设备之间的第一部分密钥请求、 安全认证请求等， 都可以通过该安全通道来传输， 以 进一步的保证车载控制设备和通信设备之间的 安全传输。

在一种可能的实现方式中，所述方法还包括： 在所述第一待升级车载设备升级成功后， 所述通信设备接收所述车载控制设备发送的更 新所述第一升级文件的回滚文件的指示； 和 / 或在所述第一待升级车载设备升级失败后， 所述通信设备向所述车载控制设备发送所述第 一升级文件的回滚文件， 以用于所述第一待升级车载设备进行回滚操作 。 本发明实施例， 通信设备可以为智能车辆提供升级文件的回滚 文件， 无论在待升级车载设备升级成功或者 失败的情况下， 通信设备都对当前的升级文件进行回滚操作， 以便于待升级车载设备后续 升级时优回滚文件可以参考。 第三方面， 本发明实施例提供了一种智能车辆， 应用于车载系统， 所述车载系统包括 智能车辆和通信设备， 所述智能车辆包括车载控制设备； 其中

所述车载控制设备， 用于接收通信设备发送的第一部分密钥， 并将所述第一部分密钥 与存储在所述车载控制设备上的第二部分密钥 还原得到第一密钥， 再利用所述第一密钥对 第一升级文件进行安全处理， 得到安全处理后的第一升级文件， 所述安全处理包括生成第 一消息认证码 MAC, 所述安全处理后的第一升级文件包括所述第一 升级文件和所述第一 MAC。

在一种可能的实现方式中， 所述智能车辆还包括第一待升级车载设备；

所述车载控制设备， 还用于将所述安全处理后的第一升级文件发送 给所述第一待升级 车载设备；

所述第一待升级车载设备， 用于利用存储在所述车载控制设备上的第二密 钥对所述安 全处理后的第一升级文件进行安全校验， 若校验成功， 则根据校验成功的第一升级文件进 行升级， 所述第二密钥为与所述第一密钥预先匹配的密 钥， 所述安全校验为所述安全处理 的逆操作。

在一种可能的实现方式中， 所述安全处理还包括利用所述第一密钥对所述 第一升级文 件和第一 MAC进行加密； 所述安全处理后的第一升级文件包括经过所述 第一密钥加密后 的所述第一升级文件和所述第一 MAC。

在一种可能的实现方式中， 所述车载控制设备， 还用于：

在接收通信设备发送的第一部分密钥之前， 确定所述第一密钥以及所述第二密钥， 并 将所述第二密钥发送给所述第一待升级车载设 备。

在一种可能的实现方式中， 所述车载控制设备， 还用于：

在接收通信设备发送的第一部分密钥之前， 将所述第一密钥拆分为所述第一部分密钥 和所述第二部分密钥， 并将所述第一部分密钥发送给所述通信设备。

在一种可能的实现方式中， 所述车载控制设备， 还用于：

在接收通信设备发送的第一部分密钥之前获取 升级包，并对所述升级包进行安全校验， 在验证通过的情况下， 向所述通信设备请求所述第一部分密钥， 所述升级包包括所述第一 升级文件。

在一种可能的实现方式中，所述通信设备包括 终端设备；所述车载控制设备，还用于： 在获取升级包之前向所述通信设备发送安全升 级请求， 并在所述智能车辆的升级相关 参数满足预设升级条件的情况下， 接收所述通信设备发送的第一指示， 所述第一指示用于 触发所述车载控制设备从所述终端设备或升级 服务器处获取所述升级包， 所述安全升级请 求包括所述智能车辆的升级相关参数。

在一种可能的实现方式中， 所述车载控制设备还用于： 和所述通信设备相互进行安全 认证， 以建立安全合作通道；

所述车载控制设备， 具体用于：

通过所述安全通道接收通信设备发送的第一部 分密钥。

在一种可能的实现方式中， 所述车载控制设备， 还用于：

在所述第一待升级车载设备升级成功后， 指示所述通信设备更新所述第一升级文件的 回滚文件; 和 /或

在所述第一待升级车载设备升级失败后， 从所述通信设备获取所述第一升级文件的回 滚文件， 并发送给所述第一待升级车载设备进行回滚操 作。 第四方面， 本发明实施例提供了一种通信设备， 应用于车载系统， 所述车载系统包括 智能车辆和通信设备， 所述智能车辆包括车载控制设备， 所述通信设备可包括：

第一发送单元， 用于向车载控制设备发送第一部分密钥， 所述第一部分密钥用于所述 车载控制设备与存储在所述车载控制设备上的 第二部分密钥还原得到第一密钥， 所述第一 密钥用于所述车载控制设备对第一升级文件进 行安全处理， 得到安全处理后的第一升级文 件， 所述安全处理包括生成第一消息认证码 MAC， 所述安全处理后的第一升级文件包括所 述第一升级文件和所述第一 MAC。

在一种可能的实现方式中， 所述车载控制设备将所述第一密钥拆分为所述 第一部分密 钥和所述第二部分密钥； 所述通信设备还包括：

第一接收单元， 用于在向所述车载控制设备发送第一部分密钥 之前， 接收所述车载控 制设备发送的所述第一部分密钥。

在一种可能的实现方式中， 所述通信设备还包括：

第二接收单元， 用于在向所述车载控制设备发送第一部分密钥 之前， 接收所述车载控 制设备发送的第一部分密钥请求， 所述第一部分密钥请求为所述车载控制设备对 升级包进 行安全验证且在验证通过的情况下发送的， 所述升级包包括所述第一升级文件。

在一种可能的实现方式中， 所述通信设备为终端设备； 所述通信设备还包括： 第三接收单元， 用于在接收所述车载控制设备发送的第一部分 密钥请求之前， 接收所 述车载控制设备发送的安全升级请求， 所述安全升级请求包括所述智能车辆的升级相 关参 数；

判断单元， 用于判断所述升级相关参数是否满足预设升级 条件；

第二发送单元， 用于若满足， 向所述车载控制设备发送第一指示， 所述第一指示用于 触发所述车载控制设备从所述终端设备或升级 服务器处获取所述升级包。

在一种可能的实现方式中， 所述通信设备还包括：

认证单元， 用于和所述车载控制设备相互进行安全认证， 以建立安全合作通道； 所述第一发送单元， 具体用于：

通过所述安全通道向所述车载控制设备发送第 一部分密钥。

在一种可能的实现方式中， 所述通信设备还包括：

第四接收单元， 用于在所述第一待升级车载设备升级成功后， 接收所述车载控制设备 发送的更新所述第一升级文件的回滚文件的指 示； 和 /或 第三发送单元， 用于在所述第一待升级车载设备升级失败后， 所述通信设备向所述车 载控制设备发送所述第一升级文件的回滚文件 ， 以用于所述第一待升级车载设备进行回滚 操作。 第五方面， 本发明实施例提供了一种车载系统， 所述车载系统包括通信设备和智能车 辆； 所述通信设备， 为上述第四方面中提供的任意一种所述的通信 设备； 所述智能车辆， 为上述第三方面中提供的任意一种所述的智能 车辆。

第六方面， 本申请提供一种车载设备升级装置， 该车载设备升级装置具有实现上述任 意一种车载设备升级方法实施例中方法的功能 。 该功能可以通过硬件实现， 也可以通过硬 件执行相应的软件实现。 该硬件或软件包括一个或多个与上述功能相对 应的模块。

第七方面， 本申请提供一种车载控制设备， 该车载控制设备中包括处理器， 处理器被 配置为支持该车载控制设备执行第一方面提供 的一种车载设备升级方法中相应的功能。 该 车载控制设备还可以包括存储器， 存储器用于与处理器耦合， 其保存该车载控制设备必要 的程序指令和数据。 该车载控制设备还可以包括通信接口， 用于该车载控制设备与其他设 备或通信网络通信。

第八方面， 本申请提供一种待升级车载设备， 该待升级车载设备中包括处理器， 处理 器被配置为支持第一待升级车载设备执行第一 方面提供的一种车载设备升级方法中相应的 功能。 该待升级车载设备还可以包括存储器， 存储器用于与处理器耦合， 其保存该待升级 车载设备必要的程序指令和数据。 该待升级车载设备还可以包括通信接口， 用于该待升级 车载设备与其他设备或通信网络通信。

第九方面， 本申请提供一种计算机存储介质， 用于储存为上述第三方面提供的智能车 辆所用的计算机软件指令， 其包含用于执行上述方面所设计的程序。

第十方面， 本申请提供一种计算机存储介质， 用于储存为上述第四方面提供的通信设 备所用的计算机软件指令， 其包含用于执行上述方面所设计的程序。

第十一方面， 本发明实施例提供了一种计算机程序， 该计算机程序包括指令， 当该计 算机程序被计算机执行时， 使得计算机可以执行上述第一方面中任意一项 的车载设备升级 方法中车载控制设备或第一待升级车载设备所 执行的流程。

第十二方面， 本发明实施例提供了一种计算机程序， 该计算机程序包括指令， 当该计 算机程序被计算机执行时， 使得计算机可以执行上述第二方面中任意一项 的车载设备升级 方法中通信设备所执行的流程。

第十三方面， 本申请提供了一种芯片系统， 该芯片系统包括处理器， 用于支持第一待 升级车载设备或车载控制设备实现上述第一方 面中所涉及的功能， 例如， 例如接收或处理 上述方法中所涉及的数据和 /或信息。 在一种可能的设计中， 所述芯片系统还包括存储器， 所述存储器， 用于保存第一待升级车载设备或车载控制设备 必要的程序指令和数据。 该芯 片系统， 可以由芯片构成， 也可以包含芯片和其他分立器件。 附图说明

图 1是本发明实施例提供的一种车载设备升级应� �场景的示意图； 图 2是本发明实施例提供的另一种车载设备升级� �用场景的示意图；

图 3是本发明实施例提供的又一种车载设备升级� �用场景的示意图；

图 4是本发明实施例提供的一种车载系统升级架� �示意图；

图 5是本发明实施例提供的一种 OTA Orchestrator的结构示意图；

图 6是本发明实施例提供的一种待升级车载设备� �结构示意图；

图 7是本发明实施例提供的一种终端设备的结构� �意图；

图 8是本发明实施例提供的另一种车载系统升级� �构图；

图 9是本发明实施例提供的一种车载设备升级方� �的流程示意图；

图 10是本发明实施例提供的另一种车载设备升级� ��法的流程示意图；

图 11是本发明实施例提供的一种智能车辆的结构� ��意图；

图 12是本发明实施例提供的一种通信设备的结构� ��意图；

图 13是本发明实施例提供的一种设备的结构示意� ��。 具体实施方式

下面将结合本发明实施例中的附图， 对本发明实施例进行描述。

本申请的说明书和权利要求书及所述附图中的 术语“第一”、 “第二”、 “第三”和“第四” 等是用于区别不同对象， 而不是用于描述特定顺序。 此外， 术语“包括”和“具有”以及它们 任何变形， 意图在于覆盖不排他的包含。 例如包含了一系列步骤或单元的过程、 方法、 系 统、 产品或设备没有限定于已列出的步骤或单元， 而是可选地还包括没有列出的步骤或单 元， 或可选地还包括对于这些过程、 方法、 产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着， 结合实施例描述的特定特征、 结构或特性可以包含在 本申请的至少一个实施例中。 在说明书中的各个位置出现该短语并不一定均 是指相同的实 施例， 也不是与其它实施例互斥的独立的或备选的实 施例。 本领域技术人员显式地和隐式 地理解的是， 本文所描述的实施例可以与其它实施例相结合 。

在本说明书中使用的术语“部件”、“模块” 、“系统”等用于表示计算机相关的实体、硬 件、 固件、 硬件和软件的组合、 软件、 或执行中的软件。 例如， 部件可以是但不限于， 在处理 器上运行的进程、 处理器、 对象、 可执行文件、 执行线程、 程序和 /或计算机。 通过图示， 在计算设备上运行的应用和计算设备都可以是 部件。 一个或多个部件可驻留在进程和 /或执 行线程中， 部件可位于一个计算机上和 /或分布在 2个或更多个计算机之间。 此外， 这些部 件可从在上面存储有各种数据结构的各种计算 机可读介质执行。 部件可例如根据具有一个 或多个数据分组 (例如来自与本地系统、 分布式系统和 /或网络间的另一部件交互的二个部 件的数据，例如通过信号与其它系统交互的互 联网)的信号通过本地和 /或远程进程来通信。 首先， 对本申请中的部分用语进行解释说明， 以便于本领域技术人员理解。

( 1 )、 空中下载技术 (Over the Air Technology, OTA) ，是通过移动通信的空中接口进 行远程固件或软件远程升级的技术。

(2)、 车载信息服务 (Telematics) 是远距离通信的电信 (Telecommunications) 与信息 科学 (Informatics) 的合成词， 按字面可定义为通过内置在汽车、 航空、 船舶、 火车等运输 工具上的计算机系统、 无线通信技术、 卫星导航装置、 交换文字、 语音等信息的互联网技 术而提供信息的服务系统。简单的说就通过无 线网络将车辆接入互联网，为车主提供驾驶、 生活所必需的各种信息。

(3)、 电子控制单元 (Electronic Control Unit, ECU) , 从用途上讲则是汽车专用微机 控制器。 它和普通的电脑一样，由微处理器 (CPU)、 存储器 (ROM、 RAM)、 输入 /输出接 口 (I/O)、 模数转换器 (A/D) 以及整形、 驱动等大规模集成电路组成。

(4)、 车辆控制单元 (Vehicle control unit， VCU)， 也可以称之为电动汽车整车控制器 VCU是电动汽车动力系统的总成控制器， 负责协调发动机、 驱动电机、 变速箱、 动力电池 等各部件的工作， 具有提高车辆的动力性能、 安全性能和经济性等作用。 是电动汽车整车 控制系统的核心部件， 是用来控制电动车电机的启动、 运行、 进退、 速度、 停止以及电动 车的其它电子器件的核心控制器件。 VCU作为纯电动汽车控制系统最核心的部件， 其承担 了数据交换、 安全管理、 驾驶员意图解释、 能量流管理的任务。 VCU采集电机控制系统信 号、 加速踏板信号、 制动踏板信号及其他部件信号， 根据驾驶员的驾驶意图综合分析并作 出响应判断后， 监控下层的各部件控制器的动作， 对汽车的正常行驶、 电池能量的制动回 馈、 网络管理、 故障诊断与处理、 车辆状态监控等功能起着关键作用。

(5)、 控制器局域网络 (Controller Area Network， CAN)总线， 是国际上应用最广泛的 现场总线之一。 其所具有的高可靠性和良好的错误检测能力受 到重视， 被广泛应用于汽车 计算机控制系统和环境温度恶劣、 电磁辐射强和振动大的工业环境。 CAN总线是一种应用 广泛的现场总线， 在工业测控和工业自动化等领域有很大的应用 前景。 CAN属于总线式串 行通信网络。 CAN 总线在数据通信方面具有可靠、 实时和灵活的优点。 为使设计透明和执 行灵活，遵循 ISO /OSI标准模型， CAN总线结构划分为两层物理层和数据链路层 (包括逻辑 链路控制子层 LLC和媒体访问控制子层 MAC)。

(6)、 消息验证码 (message authentication code, MAC) , MAC是通信实体双方使用 的一种验证机制， 是保证消息数据完整性的一种工具。 MAC类似于摘要算法， 但是它在计 算的时候还要采用一个密钥， 因此 MAC 是基于密钥和消息摘要所获得的一个值， 实际上 是对消息本身产生一个冗余的信息， 可用于数据源认证和完整性校验。

(7)、 密钥导出算法 (Key Derivation Function， KDF), 是加解密过程使用到的密钥派生 函数， 作用是从一个共享的秘密比特串口派生出密钥 数据， 在密钥协商过程中， 密钥派生 函数作用在密钥交换所获动向的秘密比特串上 ， 从中产生所需的会话密钥或进一步加密所 需的密钥数据。

( 8 )、 公钥密码 (非对称密码)， 公钥密码又称为非对称密码， 非对称密钥算法是指一 个加密算法的加密密钥和解密密钥是不一样的 ， 或者说不能由其中一个密钥推导出另一个 密钥。 拥有公钥密码的用户分别拥有加密密钥和解密 密钥， 通过加密密钥不能得到解密密 钥。 并且加密密钥是公开的。 公钥密码就是基于这一原理而设计的， 将辅助信息 (陷门信 息) 作为秘密密钥。 这类密码的安全强度取决于它所依据的问题的 计算复杂度。 现在常见 的公钥密码有 RSA公钥密码、 ElGamal公钥密码、 椭圆曲线密码。

(9)、 对称密码， 对称密钥加密又叫专用密钥加密， 即发送和接收数据的双方必使用 相同的密钥对明文进行加密和解密运算。 即加密密钥能够从解密密钥中推算出来， 反过来 也成立。 在大多数对称算法中， 加密解密密钥是相同的。 这些算法也叫秘密密钥算法或单 密钥算法， 它要求发送者和接收者在安全通信之前， 商定一个密钥。 对称算法的安全性依 赖于密钥， 泄漏密钥就意味着任何人都能对消息进行加密 解密。 只要通信需要保密， 密钥 就必须保密。

从上述对对称密钥算法和非对称密钥算法的描 述中可看出， 对称密钥加解密使用的同 一个密钥， 或者能从加密密钥很容易推出解密密钥； 对称密钥算法具有加密处理简单， 加 解密速度快， 密钥较短， 发展历史悠久等特点，非对称密钥算法具有加 解密速度慢的特点， 密钥尺寸大， 发展历史较短等特点。

( 10)、 传输层安全协议 (Transport Layer Security， TLS)， 用于两个应用程序之间提供 保密性和数据完整性。 该协议由两层组成： TLS记录协议 (TLS Record) 和 TLS握手协议

(TLS Handshake) _c 安全传输层协议 (TLS ) 用于在两个通信应用程序之间提供保密性和 数据完整性。

( 11 )、终端设备，可以为用户设备 (User Equipment， UE)、无线局域网 (Wireless Local Area Networks, WLAN)中的站点 (STAION， ST)、蜂窝电话、无线本地环路 (Wireless Local Loop, WLL) 站、 个人数字处理 (Personal Digital Assistant, PDA) 设备、 具有无线通信功 能的手持设备、 计算设备或连接到无线调制解调器的其它处理 设备、 可穿戴设备等。 为了便于理解本发明实施例， 以下示例性列举本申请中车载设备升级方法所 应用的场 景， 可以包括如下三个场景。

场景一， 通过通信设备对智能车辆进行一对一管理：

请参见图 1， 图 1是本发明实施例提供的一种车载设备升级应� �场景的示意图， 该应 用场景中包括通信设备 (图 1中以通信设备为终端设备如智能手机为例)、 智能车辆和升级 服务器或密钥服务器， 终端设备和智能车辆之间可以通过蓝牙、 NFC、 Wi-Fi和移动网络等 进行通信， 而升级服务器和终端设备或智能车辆之间则可 以通过 Wi-Fi和移动网络等进行 通信。 其中， 智能手机和智能车辆之间可以建立一对一的匹 配关系， 例如通过智能车辆的 车牌或唯一标识与终端设备的身份识别卡或者 合法账号进行匹配， 匹配完成后， 智能手机 和智能车辆之间便可以合作执行本申请中提供 的车载设备升级方法的流程。 从而实现用户 通过智能手机对驾驶的车辆进行升级管理， 保证车辆的升级安全。

场景二， 通过通信设备对智能车辆进行一对多管理：

请参见图 2， 图 2是本发明实施例提供的另一种车载设备升级� �用场景的示意图。 该 应用场景中包括通信设备 (图 2中以通信设备为终端设备如智能手机为例)， 多个智能车辆 和升级服务器或密钥服务器， 该应用场景中的通信方式可以参考图 1 中的通信方式， 在此 不再贅述。 其中， 智能手机和智能车辆之间可以建立一对多的匹 配关系， 例如一个用户可 以同时拥有并管理多个车辆， 也可以是一个用户对多个不同用户的车辆进行 管理。 比如 4S 店的员工， 通过专用的终端设备对店内的同一个型号的所 有车辆进行系统升级， 或者某个 用户通过自己的终端设备对附近的与其建立了 匹配关系的智能车辆进行升级包的提供或管 理等， 以实现一个设备同时管理多个智能车辆的应用 场景， 节省时间、 节省网络传输带宽 以及存储资源， 并且保证车辆的升级安全。 可以理解的是， 在一对多的管理中， 需要该终 端设备中预先存储有该多个车辆的相关信息， 或者是该多个车辆向终端设备证明其合法性 以及与该终端设备之间存在服务关系。

场景三， 通信设备为服务器， 通过服务器进行一对多管理：

请参见图 3， 图 3是本发明实施例提供的又一种车载设备升级� �用场景的示意图。 该 应用场景中包括智能车辆和服务器 （可选的， 可以为密钥服务器也可以为专用服务器， 并 且上述两种服务器可以与升级服务器在同一个 物理实体上），升级服务器和智能车辆之间则 可以通过 Wi-Fi和移动网络等进行通信。 其中升级服务器可以对多个合法注册的智能车 辆 进行升级管理， 且该升级服务器中除了可以完成关于升级包的 提供、 下载更新等相关服务 以外， 还作为本申请中的通信设备与智能车辆合作执 行本申请中提供的车载设备升级方法 的流程。 例如升级服务器上新增一个逻辑功能实体， 该逻辑功能实体用于存储相关密钥， 对车辆内部的升级文件的存储或传输进行安全 强化， 保证车辆的升级安全。 可选地， 当通 信设备为密钥服务器时， 本申请中关于判断智能车辆是否满足相关升级 条件、 指示智能车 辆下载升级包以及提供相关回滚文件的操作则 可以通过升级服务器来处理。

可以理解的是， 图 1、 图 2和图 3 中的应用场景的只是本发明实施例中的几种示 例性 的实施方式， 本发明实施例中的应用场景包括但不仅限于以 上应用场景。 结合上述应用场景， 下面先对本发明实施例所基于的其中一种系统 架构进行描述。 请 参见图 4， 图 4是本发明实施例提供的一种车载系统升级架� �示意图 （简称为架构一）， 本 申请提出的车载设备升级方法可以应用于该系 统架构。 该系统架构中包含了升级服务器、 智能车辆和通信设备（图 4中以通信设备为终端设备如智能手机为例）� �其中智能车辆包括车 载控制设备和一个或多个待升级车载设备， 例如 HMI（人机界面）、 BMS（电池管理系统）、 ECU1和 ECU2,而车载控制设备可以包括 Telematics单元和 OTA协调器（OTA Orchestrator） 单元， 用于管理和辅助多个待升级车载设备的升级过 程。 在上述系统架构下， 车载设备远 程升级可以包括以下基本过程：升级包发布， 升级包获取， 升级包车内传输， 升级与确认。 其中，

升级服务器， 可以用于从开发者处获取未经过加密的车载升 级包， 该车载升级包包括 本申请中的第一升级文件， 可用于第一待升级车载设备进行升级。

车载控制设备中的 Telematics， 负责对外通信， 在本申请中负责与升级服务器和密钥服 务器通信， 完成车载升级包的获取任务， 以及车载升级包的部分传输动作 （发送给 OTA Orchestrator）。

车载控制设备中的 OTA Orchestrator， 负责与车载内的待升级车载设备或负责与本申 请 中的通信设备 （图 4中以通信设备为终端设备为例） 进行通信， 其主要功能是管理和辅助 车载设备的升级过程。具体来说， OTA Orchestrator可以具有如下功能：密钥分发及管理 （包 括确定第一密钥和第二密钥， 以及拆分和还原第一密钥等）； 管理 0TA过程； 与通信设备 共同帮助其他较弱的待升级车载设备分担计算 量大的操作， 如验证升级包的完整性和真实 性， 及 Transcoding（转码）等； 与通信设备共同作为其他较弱的待升级车载设 备的备份点， 以便升级失败时回滚。 OTA Orchestrator是个逻辑实体， 物理上可以部署任何功能强大的单 元或模块上， 例如 Telematics、 Gateway、 VCU等，

OTA Orchestrator 的结构可以如图 5 所示， 图 5 是本发明实施例提供的一种 0TA Orchestrator的结构示意图。 其中， OTA Orchestrator可以包括处理器 CPU以及相关的易失 性存储器 RAM和非易时性存储器 ROM; 用于存放密钥的安全存储， 如与待升级车载设备 共享的静态密钥（本申请中的第一密钥和第二 密钥）等；用于存储 O T A管理程序的存储器， 该 OTA管理程序用于实现对升级过程的管理； 用于通过 CAN bus或其他车内网络与其他 车载设备通信的网络接口。 可以理解的是， 如果 OTA Orchestrator实现在 Telemantics上， 它还需有与外部网络通信的网络接口。即 OTA Orchestrator应有较强的计算能力和较多资源 辅助车载设备完成远程升级，并被其他车载设 备信任。从逻辑架构上划分， OTA Orchestrator 把该架构分为车外通信部分和车内通信部分。 车内部分的各设备无需进行公钥密码操作而 只需进行对称密码操作； 如涉及公钥密钥操作， 则代理给 OTA Orchestrator， 以减少车载内 待升级设备的计算量和计算复杂度。

待升级车载设备， 任意一个待升级车载设备 （包括本申请中的第一待升级车载设备） 的构成可以如图 6所示， 图 6是本发明实施例提供的一种待升级车载设备� �结构示意图。 待升级车载设备可以包括微型控制器（Micro controlller） , CAN控制器（CAN controller）和收 发器（Transceiver）。 其中， 待升级车载设备通过收发器 Transceiver与车内网络如 CAN bus 通信， CAN controller则用于实现 CAN协议， 微型控制器则用于实现待升级以及升级后的 相关的计算处理， 例如可以实现本申请中关于待升级车载设备所 执行的车载设备升级方法 流程。 结合上述结构示意图， 在本申请中， 待升级车载设备基于车内网络如 CAN bus， 通 过收发器（Transceiver）接收车载控制设备发送� ��第一升级文件， 并通过微型控制器（Micro Controlller）利用所述第一升级文件进行安全升� ��。 更具体的功能可以参照后续实施例中关 于待升级车载设备相关功能的描述。

通信设备， 本申请中的通信设备可以为终端设备或者升级 服务器， 用于从资源扩展、 安全强化以及升级控制等角度， 参与到智能车辆的安全升级过程中来。 例如， 通信设备利 用自身的存储能力协助储存中间档案（如各个 待升级车载设备软 /固件信息，当前版本、大小、 开发者等）， 备份文件（如待升级车载设备软 /固回滚版）与车机系统状况， 以完成储存扩展； 通信设备通过自身的计算能力进行 transcoding， 以实现计算扩展； 通信设备通过自身的联 网能力下载升级包， 分担传输开销， 以实现传输扩展； 通信设备在每次有升级任务时验证 OTA Orchestrator是否完整或是整车是否处于安全状态 以实现认证 （Attestation） ; 通信设备 通过密钥分散管理（secret sharing）方法由车载 OTA Orchestrator和通信设备分散保管密钥， 保证密钥的安全， 通信设备通过既有的安全模块做安全检测（例 如恶意软件检测 malware detection）, 以实现安全强化； 通信设备 （例如为终端设备时） 作为软 /固件升级的远程控制 console端（让用户选择是否升级、 升级时间、 单点或群组升级模式等）， 以实现用户远程控 制升级。

当通信设备为终端设备时， 该终端设备的构成可以参考图 7， 图 7是本发明实施例提 供的一种终端设备的结构示意图。该终端设备 可包括处理器 CPU以及相关的易失性存储器 RAM和非易时性存储器 ROM; 用于存储 0TA管理程序的存储器， 该 0TA管理程序用于 实现对升级过程的管理； 用于与其它设备 （包括智能车辆以及升级服务器等） 进行通信的 无线通信模块； 用于为用户提供车载升级交互控制界面的显示 及输入， 如音频输入输出模 块、 按键或触摸输入模块以及显示器等。 需要说明的是， 当通信设备为服务器且该服务器 和本申请中的升级服务器在同一个物理实体上 时， 则该升级服务器中可以包含一个实现上 述通信设备所实现的功能的逻辑功能实体， 因此， 关于通信设备具体的实际结构本申请不 作具体限定。 且当通信设备为终端设备时， 则可以对应图 1和图 2中的应用场景， 当通信 设备为服务器时， 则可以对应图 3中的应用场景。

可以理解的是， 图 1 中的通信系统架构只是本发明实施例中的一种 示例性的实施方式 本发明实施例中的通信系统架构包括但不仅限 于以上通信系统架构。 请参见图 8,图 8是本发明实施例提供的另一种车载系统升级� �构图（简称为架构二）， 与图 1提供的系统升级架构不同之处在于，该车载� �统升级架构还包括密钥服务器。其中， 升级服务器， 用于从开发者处获取经过开发者加密的车载升 级包。

密钥服务器， 用于在车载升级包被开发者加密的情况下， 该密钥服务器通过安全通道 从开发者处获取密钥并存储密钥， 并且最终将密钥提供给车载控制设备。 可以理解的是， 当本申请中的通信设备为服务器例如为专用服 务器时， 则该专用服务器可以为所述密钥服 务器， 即该密钥服务器不仅存储升级包相关的密钥， 也可以存储车内传输过程中的相关密 钥， 例如第一部分密钥等。

可以理解的是其它关于载控制设备和多个待升 级车载设备的具体功能， 请参照上述图 4对应的车载系统升级架构中的各个功能实体� �单元的描述， 在此不再贅述。

还以理解的是， 本申请中的车载系统升级架构还可以包括开发 者， 开发者在固件 /软件 发布的开发和测试升级程序后， 将车载升级包交付给升级服务器， 该交付的车载升级包需 要经过数字签名。 可选的， 在经过数字签名之前， 还可以对该车载升级包经过加密。 若不 经过加密， 则对应上述图 4中的系统架构， 若经过加密则对应上述图 8中的系统架构。 后 述会详细描述对应实施例。

需要说明的是， 图 4和图 8中的车载系统升级架构只是本发明实施例中� �两种示例性 的实施方式， 本发明实施例中的通信系统架构包括但不仅限 于以上系统架构。 下面结合上述应用场景、 系统架构和本申请中提供的车载设备升级方法 的实施例， 对 本申请中提出的技术问题进行具体分析和解决 。

请参见图 9， 图 9是本发明实施例提供的一种车载设备升级方� �的流程示意图， 该车 载设备升级方法应用于车载系统（包括上述架 构一和架构二）， 且适用于上述图 1至图 3中 的任意一种应用场景。 其中， 所述车载系统包括智能车辆和通信设备， 所述智能车辆包括 车载控制设备， 下面将结合附图 9从智能车辆和通信设备的交互侧进行描述， 该方法可以 包括以下步骤 S901 -步骤 S903。

步骤 S901 : 通信设备向所述车载控制设备发送第一部分密 钥； 车载控制设备接收所述 通信设备发送的第一部分密钥。

具体地， 该第一部分密钥是车载控制设备从通信设备 （终端设备或升级服务器） 上获 取的， 也即是车载控制设备上当前没有该第一部分密 钥。 当第一部分密钥来自于终端设备 （如智能手机） 时， 智能车辆通过与终端设备之间的密钥分散存储 管理， 合作完成车辆内 部的安全存储或传输； 当第一部分密钥来自于密钥服务器或专用服务 器， 那么智能车辆通 过与服务器之间的密钥分散存储管理， 合作完成车辆内部的安全存储或传输。 避免密钥只 存储在一个设备上， 被不法分子轻易截获篡改， 从而保证了智能车辆中升级文件的存储或 传输的安全性。 需要说明的是， 当通信设备是终端设备， 则该终端设备需要与智能车辆之 间建立匹配关系； 若为升级服务器， 则该服务器则是为智能车辆提供升级包 （包括所述第 一升级文件） 的升级服务器。

步骤 S901： 车载控制设备将所述第一部分密钥与存储在所 述车载控制设备上的第二部 分密钥还原得到第一密钥。

具体地， 车载控制设备在从通信设备处获得了第一部分 密钥之后， 与已经存储在车载 控制设备本地的第二部分密钥进行还原得到第 一密钥。 其中， 车载控制设备上存储的第二 部分密钥可以是初始存在于车载控制设备上的 ， 也可以是从其它设备 （如升级服务器或密 钥服务器等） 上获得之后存储在本地的， 本发明实施例对此不作具体限定。

步骤 S903 : 车载控制设备利用所述第一密钥对第一升级文 件进行安全处理， 得到安全 处理后的第一升级文件。

具体地， 车载控制设备得到还原的第一密钥之后， 则利用该第一密钥对第一升级文件 进行安全处理， 该安全处理可以包括生成第一消息认证码 MAC， 则对应的安全处理后的第 一升级文件包括所述第一升级文件和所述第一 MAC。 可选地， 所述第一密钥为对称密钥， 所述车载控制设备利用所述第一密钥生成所述 第一升级文件的第一消息认证码 MAC,得到 的安全处理后的第一升级文件则为 （第一升级文件 +第一 MAC）。 即在智能车辆中的车载控 制设备和待升级车载设备之间进行升级文件的 传输时， 具体利用对称密钥生成升级文件的 MAC, 并携带在第一升级文件中发送给待升级车载设 备， 从而保证升级文件在车内传输过 程的安全性， 并且还减少了车内安全校验的计算量 （因为对称密钥的计算量小）， 提升升级 效率。 可选地， 安全处理也可以为签名处理、 加密处理或其它安全处理等， 本发明实施例 对此不作具体限定。

在一种可能的实现方式中， 所述安全处理还包括利用所述第一密钥对所述 第一升级文 件和第一 MAC进行加密； 所述安全处理后的第一升级文件包括经过所述 第一密钥加密后 的所述第一升级文件和所述第一 MAC。即通过在智能车辆中的车载控制设备和待 升级车载 设备之间进行升级文件的传输时， 不仅利用生成升级文件的 MAC， 并携带在第一升级文件 中， 并且还进一步通过第一密钥对其进行加密， 再发送给待升级车载设备的方式， 不仅保 证升级文件在车内传输过程的完整性， 减少了车内安全校验的计算量， 提升升级效率， 并 且还进一步的保证了升级文件的私密性， 以避免被不法分子窃取。

本发明实施例， 通过在车载升级架构中， 加入与智能车辆匹配的通信设备， 并作为智 能车辆的安全密钥分散保管的载体， 使得智能车辆中的车载控制设备在需要对升级 文件进 行安全处理时， 可以从通信设备处获得分散保管的密钥并进行 密钥还原， 并利用还原后的 密钥对升级文件进行安全处理， 以便于升级文件在车内的安全保存和 /或安全传输， 避免密 钥单独存储在智能车辆或通信设备上， 被不法分子轻易截获篡改， 从而保证了智能车辆中 升级文件的存储或传输的安全性。 请参见图 10， 图 10是本发明实施例提供的另一种车载设备升级� ��法的流程示意图， 该车载设备升级方法应用于车载系统（包括上 述架构一和架构二）， 且适用于上述图 1至图 3 中的任意一种应用场景。 其中， 所述车载系统包括智能车辆和通信设备， 所述智能车辆 包括车载控制设备， 下面将结合附图 10从智能车辆和通信设备的交互侧进行描述， 该方法 可以包括以下步骤 S 1001-步骤 S 1012。

步骤 S1001： 车载控制设备确定第一密钥以及第二密钥， 并将所述第二密钥发送给所 述第一待升级车载设备。

具体地， 车载控制设备确定车内传输的共享密钥， 该共享密钥则为匹配的第一密钥和 第二密钥。 当共享密钥为对称密钥时， 则第一密钥和第二密钥相同， 当共享密钥为非对称 密钥时， 则第一密钥和第二密钥之间为密钥对。 车载控制设备在确定了车载内部的共享密 钥之后， 则将第二密钥发给第一待升级车载设备， 自己保留第一密钥， 便于在后续车载内 部安全传输中， 车载控制设备利用第一密钥进行安全处理， 第一待升级车载设备利用第二 密钥进行安全校验， 该安全校验为所述安全处理的逆操作。 本发明实施例， 在智能车辆中 的第一密钥分散保管之前， 车载控制设备需要先确定车内使用的密钥对， 并发送给对应的 待升级车载设备。 便于后续车载控制设备将升级文件利用与待升 级车载设备协商好的第一 密钥进行安全处理， 且待升级车载设备利用协商好的匹配的第二密 钥进行安全校验， 以保 证升级文件在车内的传输安全。

步骤 S1002： 车载控制设备将所述第一密钥拆分为第一部分 密钥和第二部分密钥， 并 将所述第一部分密钥发送给所述通信设备； 通信设备接收所述车载控制设备发送的所述第 一部分密钥。

具体地， 车载控制设备将第一密钥拆分为第一部分密钥 和第二部分密钥， 并将第一部 分密钥发送给通信设备， 该通信设备接收到第一部分密钥之后存储在本 地， 而车载控制设 备侧则可以将第一部分密钥进行刪除。 也即是避免在一个设备上同时存储有第一部分 密钥 和第二部分密钥， 避免被不发分子轻易窃取。 本发明实施例， 在智能车辆中的第一密钥分 散保管之前， 车载控制设备与待升级车载设备协商好第一密 钥和第二密钥之后， 车载控制 设备将第一密钥进行拆分， 并将拆分的一部分发送至匹配的通信设备上进 行存储， 自身保 存另一部分， 以避免被一次性轻易的非法截获篡改。

需要说明的是， 车载控制设备将第二密钥发送给第一待升级车 载设备和将第一密钥进 行拆分并将第一部分密钥发送给通信设备， 这两个流程之间没有严格的时间顺序， 本发明 实施例对此不作具体限定。

步骤 S1003： 车载控制设备向所述通信设备发送安全升级请 求， 所述安全升级请求包 括所述智能车辆的升级相关参数； 通信设备接收所述车载控制设备发送的所述安 全升级请 求。

具体地， 即车载设备在升级之前， 需要向通信设备发起安全升级的相关认证， 将智能 车辆当前的相关参数 （固件 /软件的相关参数） 发送给通信设备进行判断， 以避免在没有满 足升级条件的情况下盲目升级，浪费相关传输 资源和升级资源。例如，通信设备作为 verifier, 要求车载 OTA Orchestrator向其做 attestation（hardware/software based）或其他汇报机制， 以 确保车载 OTA Orchestrator的完整性或车机处于安全可升级状态 。 如果 attestation或检测失 败， 则报错终止升级。 同样的， 车载 OTA Orchestrator也可以检验通信设备是否处于安全可 升级状态。

步骤 S1004： 通信设备判断所述升级相关参数是否满足预设 升级条件。

具体地，通信设备可以按照一定的相关标准判 断升级相关参数是否满足相关升级条件。 步骤 S1005： 若满足， 通信设备向所述车载控制设备发送第一指示， 所述第一指示用 于触发所述车载控制设备从所述终端设备或升 级服务器处获取所述升级包； 车载控制设备 接收所述通信设备发送的第一指示。

具体地， 当通信设备判断出智能车辆满足升级条件时， 则向其发送第一指示， 该第一 指示用于指示车载控制设备可以开始进行升级 ， 即可以获取升级包。 该升级包可以是通信 设备上之前 （例如终端设备在检测到有升级包更新的情况 下， 或者终端设备当前有 Wi-Fi 的情况下等） 就已经下载好了， 则通信设备直接通过向该终端设备获取即可； 也可以是车 载控制设备直接去升级服务器处获取。 本发明实施例， 在通信设备根据智能车辆的车载控 制设备反馈的升级相关参数， 判断出该智能车辆当前满足升级条件的情况下 ， 才会指示或 触发该智能车辆的车载控制设备进行车载升级 包的获取， 以提升车载升级的成功率。 可以 理解的是， 智能车辆可以是从服务器处获取， 也可以是通信设备上获取已经下载好的升级 包， 此时通信设备可以为终端设备。

步骤 S1006 : 车载控制设备获取升级包， 所述升级包包括所述第一升级文件。

具体地， 升级包可以包括多个升级文件， 且每一个升级文件用于对至少一个待升级车 载设备进行升级，即车载系统内的待升级车载 设备可以对应一个或者多个升级文件。其中， 升级包至少包括第一待升级车载设备的第一升 级文件。

步骤 S1007： 车载控制设备对所述升级包进行安全验证。

具体地， 车载控制设备获得了升级包之后， 还需要对升级包进行安全验证。 安全验证 可以包括对签名进行验证， 对升级包进行解密等， 而相关密钥可以是升级服务器与智能车 辆之间预先就协商好的， 也可以是智能车辆从密钥服务器中获取的， 也即是说采用上述架 构一和架构二均可以进行相关密钥的获取。 本发明实施例， 在车载控制设备获取分散保管 的部分密钥之前， 首先需要获取包含升级文件的升级包， 并且对该升级包进行安全验证， 验证通过后， 则启动将对应的将升级文件进行安全处理并传 输给对应的待升级车载设备的 流程， 也才会向通信设备请求用于对升级文件进行安 全处理的部分密钥。 避免在没有确定 车载升级包是否安全的情况下， 过早获取第一部分密钥， 以免被非法获取， 进一步提升了 车载升级的安全性。

步骤 S1008： 在验证通过的情况下， 所述车载控制设备向所述通信设备请求所述第 一 部分密钥； 所述通信设备接收所述车载控制设备发送的第 一部分密钥请求。

具体地， 在验证了升级包的安全性之后， 则车载控制设备可以开始在车内将升级包中 的升级文件安全传输给对应的待升级车载控制 设备。 因为第一部分密钥和第二部分密钥在 同一个设备上同时存储的时间越长， 则被不法分子一次性轻易盗取或者是篡改的可 能性就 更大， 因此， 车载控制设备在与通信设备的安全请求认证以 及获取了升级包并认证了升级 包的安全性之后， 再向通信设备请求第一部分密钥。

步骤 S1009： 通信设备向所述车载控制设备发送第一部分密 钥； 所述车载控制设备接 收通信设备发送的第一部分密钥。 在一种可能的实现方式中， 通信设备向在发送第一部分密钥之前， 所述车载控制设备 和所述通信设备之间相互进行安全认证， 以建立安全合作通道； 所述车载控制设备接收通 信设备发送的第一部分密钥， 具体为： 所述车载控制设备通过所述安全通道接收通信 设备 发送的第一部分密钥。 即保证车载控制设备和通信设备之间发送及接 收数据是通过安全通 道进行的。 本发明实施例， 车载控制设备和相匹配的通信设备之间建立安 全通道， 后续的 车载控制设备和通信设备之间的第一部分密钥 请求、 安全认证请求等， 都可以通过该安全 通道来传输， 以进一步的保证车载控制设备和通信设备之间 的安全传输。

步骤 S1010： 车载控制设备将所述第一部分密钥与存储在所 述车载控制设备上的第二 部分密钥还原得到第一密钥。

步骤 S 1011： 车载控制设备利用所述第一密钥对第一升级文 件进行安全处理， 得到安 全处理后的第一升级文件。

步骤 S 1010至步骤 S 1011可参考上述图 9实施例中的步骤 S902至步骤 S903。

步骤 S 1012： 车载控制设备将所述安全处理后的第一升级文 件发送给第一待升级车载 设备。

具体地， 虽然车载控制设备和待升级车载设备都是在智 能车辆内部， 但是涉及到两个 设备之间的传输， 都有可能会在传输的过程中被拦截或被篡改， 因此采用本发明实施例的 上述安全处理和安全校验的过程， 可以保证车内传输过程的安全， 保证升级的安全。

步骤 S1013： 第一待升级车载设备利用存储在所述车载控制 设备上的第二密钥对所述 安全处理后的第一升级文件进行安全校验， 所述第二密钥为与所述第一密钥预先匹配的密 钥。

具体地， 第一待升级车载设备利用车载控制设备在共享 密钥阶段分享的第二密钥对安 全处理后的第一升级文件进行安全校验， 所述安全校验为所述安全处理的逆操作。

步骤 S1014： 若校验成功， 第一待升级车载设备根据校验成功的第一升级 文件进行升 级。

具体地， 若校验成功， 则说明接收到的第一升级文件是安全合法的， 因此则可以进行 安全升级。 本发明实施例， 车载控制设备将分散保管的密钥还原得到第一 密钥后， 对升级 文件进行安全处理， 以将该安全处理后的升级文件安全传输给对应 的待升级车载设备进行 安全升级， 保证了升级文件在智能车辆的车内传输即车载 控制设备与待升级车载设备之间 的传输过程中的安全性。

步骤 S1015： 车载控制设备在所述第一待升级车载设备升级 成功后， 指示所述通信设 备更新所述第一升级文件的回滚文件； 和 /或

具体地， 当待升级车载设备升级成功了， 可以反馈一个升级成功的反馈信息给车载控 制设备， 此时车载控制设备可以进一步地进行升级后系 统的兼容性检测， 检测成功后说明 此时已经升级成功， 并且与车载系统之间可以兼容。 所以可以指示通信设备更新当前升级 成功的回滚文件， 以便于下次需要重新获取该升级文件时有回滚 文件可以获取， 以通过通 信设备的存储能力对智能车辆进行存储扩展。

步骤 S1016： 车载控制设备在所述第一待升级车载设备升级 失败后， 从所述通信设备 获得所述第一升级文件的回滚文件， 并发送给所述第一待升级车载设备进行回滚操 作。 具体地， 当待升级车载设备升级失败了其中， 升级失败可以包括升级文件升级成功， 但未通过系统的兼容性测试， 则可以反馈一个升级失败的反馈信息给车载控 制设备， 此时 车载控制设备可以从通信设备处 （可以理解的是， 通信设备上需要保管有第一升级文件的 回滚文件） 获取回滚文件并发送给第一车载控制设备进行 回滚操作。 本发明实施例， 通信 设备可以为智能车辆提供升级文件的回滚文件 ， 无论在待升级车载设备升级成功或者失败 的情况下， 通信设备都可以对当前的升级文件进行回滚操 作， 以便于待升级车载设备后续 升级时有回滚文件可以参考。

本发明实施例， 除了保留了上述图 9对应的实施例的有益效果外， 进一步通过通信设 备和智能车辆之间的安全认证交互过程， 提升智能车辆的升级效率。 同时， 通信设备还可 以为待升级车载设备提供升级包下载及回滚服 务等， 分担了车载控制设备的传输压力和存 储压力， 并对整个升级过程进行了强化， 提供安全有效的升级服务。 上述详细阐述了本发明实施例的方法， 下面提供了本发明实施例的相关装置。

请参见图 11， 图 11是本发明实施例提供的一种智能车辆的结构� ��意图， 该智能车辆应 用于车载系统， 所述车载系统包括智能车辆和通信设备， 所述智能车辆 10包括车载控制设 备 101， 其中，

车载控制设备 101， 用于接收通信设备发送的第一部分密钥， 并将所述第一部分密钥 与存储在所述车载控制设备上的第二部分密钥 还原得到第一密钥， 再利用所述第一密钥对 第一升级文件进行安全处理， 得到安全处理后的第一升级文件， 所述安全处理包括生成第 一消息认证码 MAC, 所述安全处理后的第一升级文件包括所述第一 升级文件和所述第一 MAC。

在一种可能的实现方式中，所述智能车辆还包 括至少一个第一待升级车载设备 102（图 11中以多个为例）；

车载控制设备 101， 还用于将所述安全处理后的第一升级文件发送 给所述第一待升级 车载设备；

第一待升级车载设备 102， 用于利用存储在所述车载控制设备上的第二密 钥对所述安 全处理后的第一升级文件进行安全校验， 若校验成功， 则根据校验成功的第一升级文件进 行升级， 所述第二密钥为与所述第一密钥预先匹配的密 钥， 所述安全校验为所述安全处理 的逆操作。

在一种可能的实现方式中， 所述安全处理还包括利用所述第一密钥对所述 第一升级文 件和第一 MAC进行加密； 所述安全处理后的第一升级文件包括经过所述 第一密钥加密后 的所述第一升级文件和所述第一 MAC。

在一种可能的实现方式中， 车载控制设备 101， 还用于：

在接收通信设备发送的第一部分密钥之前， 确定所述第一密钥以及所述第二密钥， 并 将所述第二密钥发送给所述第一待升级车载设 备。

在一种可能的实现方式中， 车载控制设备 101， 还用于：

在接收通信设备发送的第一部分密钥之前， 将所述第一密钥拆分为所述第一部分密钥 和所述第二部分密钥， 并将所述第一部分密钥发送给所述通信设备。 在一种可能的实现方式中， 车载控制设备 101， 还用于：

在接收通信设备发送的第一部分密钥之前获取 升级包，并对所述升级包进行安全校验， 在验证通过的情况下， 向所述通信设备请求所述第一部分密钥， 所述升级包包括所述第一 升级文件。

在一种可能的实现方式中， 所述通信设备包括终端设备； 车载控制设备 101， 还用于： 在获取升级包之前向所述通信设备发送安全升 级请求， 并在所述智能车辆的升级相关 参数满足预设升级条件的情况下， 接收所述通信设备发送的第一指示， 所述第一指示用于 触发所述车载控制设备从所述终端设备或升级 服务器处获取所述升级包， 所述安全升级请 求包括所述智能车辆的升级相关参数。

在一种可能的实现方式中， 车载控制设备 101还用于： 和所述通信设备相互进行安全 认证， 以建立安全合作通道；

车载控制设备 101， 具体用于：

通过所述安全通道接收通信设备发送的第一部 分密钥。

在一种可能的实现方式中， 车载控制设备 101， 还用于：

在所述第一待升级车载设备升级成功后， 指示所述通信设备更新所述第一升级文件的 回滚文件; 和 /或

在所述第一待升级车载设备升级失败后， 从所述通信设备获取所述第一升级文件的回 滚文件， 并发送给所述第一待升级车载设备进行回滚操 作。

需要说明的是，本发明实施例中所描述的智能 车辆 10中的车载控制设备 101和第一待 升级车载设备 102可参见上述图 9和图 10中所述的方法实施例中的车载控制设备和第� ��待 升级车载设备相关描述， 此处不再贅述。

可以理解的是， 智能车辆 10还可以运用计算机、 现代传感、 信息融合、 通讯、 人工智 能及自动控制等技术， 集成智能驾驶系统、 生活服务系统、 安全防护系统、 位置服务系统 以及用车服务系统等功能， 本申请对此不作具体限定， 也不再贅述。 请参见图 12， 图 12是本发明实施例提供的一种通信设备的结构� ��意图， 该通信设备 20应用于车载系统， 所述车载系统包括智能车辆和通信设备， 所述智能车辆包括车载控制 设备， 通信设备 20各个单元的详细描述如下。

第一发送单元 201， 用于向车载控制设备发送第一部分密钥， 所述第一部分密钥用于 所述车载控制设备与存储在所述车载控制设备 上的第二部分密钥还原得到第一密钥， 所述 第一密钥用于所述车载控制设备对第一升级文 件进行安全处理， 得到安全处理后的第一升 级文件， 所述安全处理包括生成第一消息认证码 MAC， 所述安全处理后的第一升级文件包 括所述第一升级文件和所述第一 MAC。

在一种可能的实现方式中， 所述车载控制设备将所述第一密钥拆分为所述 第一部分密 钥和所述第二部分密钥； 通信设备 20还包括：

第一接收单元 202， 用于在向所述车载控制设备发送第一部分密钥 之前， 接收所述车 载控制设备发送的所述第一部分密钥。

在一种可能的实现方式中， 通信设备 20还包括： 第二接收单元 203， 用于在向所述车载控制设备发送第一部分密钥 之前， 接收所述车 载控制设备发送的第一部分密钥请求， 所述第一部分密钥请求为所述车载控制设备对 升级 包进行安全验证且在验证通过的情况下发送的 ， 所述升级包包括所述第一升级文件。

在一种可能的实现方式中， 所述通信设备为终端设备； 通信设备 20还包括： 第三接收单元 204， 用于在接收所述车载控制设备发送的第一部分 密钥请求之前， 接 收所述车载控制设备发送的安全升级请求， 所述安全升级请求包括所述智能车辆的升级相 关参数；

判断单元 205， 用于判断所述升级相关参数是否满足预设升级 条件；

第二发送单元 206， 用于若满足， 向所述车载控制设备发送第一指示， 所述第一指示 用于触发所述车载控制设备从所述终端设备或 升级服务器处获取所述升级包。

在一种可能的实现方式中， 通信设备 20还包括：

认证单元 207， 用于和所述车载控制设备相互进行安全认证， 以建立安全合作通道； 第一发送单元 201， 具体用于：

通过所述安全通道向所述车载控制设备发送第 一部分密钥。

在一种可能的实现方式中， 通信设备 20还包括：

第四接收单元 208， 用于在所述第一待升级车载设备升级成功后， 接收所述车载控制 设备发送的更新所述第一升级文件的回滚文件 的指示； 和 /或

第三发送单元 209， 用于在所述第一待升级车载设备升级失败后， 所述通信设备向所 述车载控制设备发送所述第一升级文件的回滚 文件， 以用于所述第一待升级车载设备进行 回滚操作。

需要说明的是， 本发明实施例中所描述的通信设备 20中各功能单元的功能可参见上述 图 9 -图 10所述的方法实施例中通信设备的相关描述， 此处不再贅述。 如图 13所示， 图 13是本发明实施例提供的一种设备的结构示意� ��。 智能车辆 10中的 车载控制设备 101和第一待升级车载设备 102， 以及通信设备 20, 均可以以图 13中的结构 来实现，该设备 30包括至少一个处理器 301，至少一个存储器 302、至少一个通信接口 303。 此外， 该设备还可以包括天线等通用部件， 在此不再详述。

处理器 301 可以是通用中央处理器 ( CPU )， 微处理器， 特定应用集成电路 ( application- specific integrated circuit, ASIC), 或一个或多个用于控制以上方案程序执行的 集成电路。

通信接口 303， 用于与其他设备或通信网络通信， 如升级服务器、 密钥服务器、 车载 内部的设备等。

存储器 302可以是只读存储器 (read-only memory, ROM) 或可存储静态信息和指令的 其他类型的静态存储设备， 随机存取存储器 (random access memory, RAM) 或者可存储信 息和指令的其他类型的动态存储设备， 也可以是电可擦可编程只读存储器 ( Electrically Erasable Programmable Read-Only Memory, EEPROM)、 只读光盘 (Compact Disc Read-Only Memory, CD-ROM) 或其他光盘存储、 光碟存储 (包括压缩光碟、 激光碟、 光碟、 数字通 用光碟、 蓝光光碟等)、 磁盘存储介质或者其他磁存储设备、 或者能够用于携带或存储具有 指令或数据结构形式的期望的程序代码并能够 由计算机存取的任何其他介质，但不限于此。 存储器可以是独立存在， 通过总线与处理器相连接。 存储器也可以和处理器集成在一起。

其中， 所述存储器 302用于存储执行以上方案的应用程序代码， 并由处理器 301来控 制执行。 所述处理器 301用于执行所述存储器 302中存储的应用程序代码。

图 13所示的设备为车载控制设备 101时，存储器 302存储的代码可执行以上图 9提供 的车载设备升级方法中车载控制设备的动作， 比如接收所述通信设备发送的第一部分密钥； 将所述第一部分密钥与存储在所述车载控制设 备上的第二部分密钥还原得到第一密钥； 利 用所述第一密钥对第一升级文件进行安全处理 ， 得到安全处理后的第一升级文件。

图 13所示的设备为第一待升级车载设备 102时，存储器 302存储的代码可执行以上图 10提供的车载设备升级方法中第一待升级车载� ��备的动作， 比如利用存储在所述车载控制 设备上的第二密钥对所述安全处理后的第一升 级文件进行安全校验， 所述第二密钥为与所 述第一密钥预先匹配的密钥， 所述安全校验为所述安全处理的逆操作； 若校验成功， 根据 校验成功的第一升级文件进行升级。

需要说明的是，本发明实施例中所描述的车载 控制设备 101和第一待升级车载设备 102 的功能可参见上述图 9和图 10中的所述的方法实施例中的相关描述， 此处不再贅述。

图 13所示的设备为通信设备 20时，存储器 302存储的代码可执行以上图 9或图 10提 供的车载设备升级方法中通信设备的动作， 比如向所述车载控制设备发送第一部分密钥， 所述第一部分密钥用于所述车载控制设备与存 储在所述车载控制设备上的第二部分密钥还 原得到第一密钥， 所述第一密钥用于所述车载控制设备对第一升 级文件进行安全处理， 得 到安全处理后的第一升级文件。

需要说明的是， 本发明实施例中所描述的通信设备 20的功能可参见上述图 9和图 10 中的所述的方法实施例中的相关描述， 此处不再贅述。 本发明实施例还提供一种计算机存储介质， 其中， 该计算机存储介质可存储有程序， 该程序执行时包括上述方法实施例中记载的任 意一种的部分或全部步骤。

本发明实施例还提供一种计算机程序， 该计算机程序包括指令， 当该计算机程序被计 算机执行时， 使得计算机可以执行任意一种车载设备升级方 法的部分或全部步骤。

在上述实施例中， 对各个实施例的描述都各有侧重， 某个实施例中没有详述的部分， 可以参见其他实施例的相关描述。

需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表述为一系列的 动作组合， 但是本领域技术人员应该知悉， 本申请并不受所描述的动作顺序的限制， 因为 依据本申请， 某些步骤可能可以采用其他顺序或者同时进行 。 其次， 本领域技术人员也应 该知悉， 说明书中所描述的实施例均属于优选实施例， 所涉及的动作和模块并不一定是本 申请所必须的。

在本申请所提供的几个实施例中， 应该理解到， 所揭露的装置， 可通过其它的方式实 现。 例如， 以上所描述的装置实施例仅仅是示意性的， 例如上述单元的划分， 仅仅为一种 逻辑功能划分， 实际实现时可以有另外的划分方式， 例如多个单元或组件可以结合或者可 以集成到另一个系统， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之 间的耦合或直接耦合或通信连接可以是通过一 些接口，装置或单元的间接耦合或通信连接， 可以是电性或其它的形式。

上述作为分离部件说明的单元可以是或者也可 以不是物理上分开的， 作为单元显示的 部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者也可以分布到多个网络 单元上。 可以根据实际的需要选择其中的部分或者全部 单元来实现本实施例方案的目的。

另外， 在本申请各实施例中的各功能单元可以集成在 一个处理单元中， 也可以是各个 单元单独物理存在， 也可以两个或两个以上单元集成在一个单元中 。 上述集成的单元既可 以采用硬件的形式实现， 也可以采用软件功能单元的形式实现。

上述集成的单元如果以软件功能单元的形式实 现并作为独立的产品销售或使用时， 可 以存储在一个计算机可读取存储介质中。 基于这样的理解， 本申请的技术方案本质上或者 说对现有技术做出贡献的部分或者该技术方案 的全部或部分可以以软件产品的形式体现出 来，该计算机软件产品存储在一个存储介质中 ， 包括若干指令用以使得一台计算机设备（可 以为个人计算机、 服务器或者网络设备等， 具体可以是计算机设备中的处理器） 执行本申 请各个实施例上述方法的全部或部分步骤。 其中， 而前述的存储介质可包括： U 盘、 移动 硬盘、 磁碟、 光盘、 只读存储器 （Read-Only Memory， 缩写： ROM） 或者随机存取存储器 （Random Access Memory, 缩写： RAM） 等各种可以存储程序代码的介质。

以上所述， 以上实施例仅用以说明本申请的技术方案， 而非对其限制； 尽管参照前述 实施例对本申请进行了详细的说明， 本领域的普通技术人员应当理解： 其依然可以对前述 各实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替换； 而这些修 改或者替换， 并不使相应技术方案的本质脱离本申请各实施 例技术方案的精神和范围。