WO2019083440A2 - 一种车载设备升级方法及相关设备 - Google Patents

一种车载设备升级方法及相关设备

Info

Publication number
WO2019083440A2
WO2019083440A2 PCT/SG2017/050530 SG2017050530W WO2019083440A2 WO 2019083440 A2 WO2019083440 A2 WO 2019083440A2 SG 2017050530 W SG2017050530 W SG 2017050530W WO 2019083440 A2 WO2019083440 A2 WO 2019083440A2
Authority
WO
WIPO (PCT)
Prior art keywords
upgrade
vehicle
key
upgraded
target
Prior art date
Application number
PCT/SG2017/050530
Other languages
English (en)
French (fr)
Other versions
WO2019083440A3 (zh
Inventor
杨艳江
魏卓
林孝盈
李铁岩
沈骏强
Original Assignee
华为国际有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为国际有限公司 filed Critical 华为国际有限公司
Priority to PCT/SG2017/050530 priority Critical patent/WO2019083440A2/zh
Priority to EP17929441.8A priority patent/EP3690643B1/en
Priority to JP2020523294A priority patent/JP7139424B2/ja
Priority to CN201780096266.2A priority patent/CN111279310B/zh
Priority to EP22205812.5A priority patent/EP4152144A1/en
Publication of WO2019083440A2 publication Critical patent/WO2019083440A2/zh
Publication of WO2019083440A3 publication Critical patent/WO2019083440A3/zh
Priority to US16/856,897 priority patent/US11662991B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • the present application relates to the field of in-vehicle technology, and in particular, to an in-vehicle device upgrade method and related device. Background technique
  • the technical problem to be solved by the embodiments of the present invention is to provide an in-vehicle device upgrade method and related equipment, which solves the problem that the in-vehicle device cannot perform firmware/software upgrade safely and efficiently.
  • the vehicle control device obtains the vehicle upgrade package, and the vehicle upgrade package includes multiple upgrade files, and each upgrade file is used to upgrade at least one vehicle device to be upgraded; the vehicle control device performs security verification on multiple upgrade files; the vehicle control device will The target upgrade file is sent to the target to be upgraded vehicle target upgrade file that is upgraded using the target upgrade file, and the upgrade file that passes the security verification in the multiple upgrade files.
  • the vehicle verification device needs to be upgraded, and the security verification process is performed on the vehicle control device side to avoid the upgrade capability, and different in-vehicle devices to be upgraded participate in the security verification process, thereby ensuring safe and efficient on-board equipment. Upgrade the car upgrade package.
  • the method further includes: the in-vehicle control device encrypts the plurality of sub-upgrade files by using the third key respectively; the in-vehicle control device generates the plurality of sub-upgrade files by using a preset algorithm to generate a plurality of data associated with each other.
  • the block includes: the vehicle control device uses a plurality of sub-upgrade files encrypted by the third key, and generates a plurality of data blocks associated with each other by using a preset algorithm. Under the premise of ensuring the legality of the vehicle upgrade package, the privacy of the vehicle upgrade package is further ensured to avoid illegal acquisition.
  • the in-vehicle device to be upgraded is configured to receive a target upgrade file sent by the in-vehicle control device, and perform a security upgrade by using the target upgrade file, where the in-vehicle device to be upgraded is the target in-vehicle device to be upgraded.
  • the in-vehicle control device is specifically configured to:
  • the in-vehicle device to be upgraded is specifically configured to: gradually receive a plurality of data blocks that are sent by the in-vehicle control device and carry the second MAC, and use the fifth key to gradually verify the multiple according to the preset algorithm. Data blocks, when the plurality of data blocks are verified to pass, the plurality of data blocks after the pass-through are gradually verified and merged and upgraded.
  • the target in-vehicle device to be upgraded uses the target upgrade file for security upgrade, including: the target to be upgraded vehicle device adopts the A/B system update upgrade mode, and uses the target upgrade file to perform security upgrade, to be upgraded.
  • the device is a first to-be-upgraded in-vehicle device whose resource storage capability and/or processing capability exceeds a preset value or is pre-designated.
  • the A/B system update upgrade mode can be used for upgrade.
  • the application provides an in-vehicle device to be upgraded, the terminal device having the function of implementing the method in the embodiment of the method for upgrading the in-vehicle device.
  • This function can be implemented in hardware or in hardware by executing the corresponding software.
  • the hardware or software includes one or more modules corresponding to the functions described above.
  • the present application provides a target in-vehicle device to be upgraded, where the target to be upgraded in-vehicle device includes a processor configured to support the target to be upgraded in-vehicle device to perform a control of the in-vehicle device upgrade provided by the third aspect The corresponding function in the method.
  • the target in-vehicle device to be upgraded may further include a memory for coupling with the processor, which stores program instructions and data necessary for the target in-vehicle device to be upgraded.
  • the target in-vehicle device to be upgraded may further include a communication interface for the in-vehicle device to be upgraded to communicate with other devices or a communication network.
  • an embodiment of the present invention provides a computer program, where the computer program includes instructions, when the computer program is executed by a computer, to enable a computer to execute the process in the in-vehicle device upgrading method according to any one of the above first aspects. .
  • FIG. 4 is a schematic structural diagram of another in-vehicle system upgrade according to an embodiment of the present invention.
  • the VCU monitors the actions of the lower component controllers, and controls the normal running of the vehicle. Battery energy braking feedback, network management, fault diagnosis and processing, vehicle status monitoring and other functions play a key role.
  • public key cipher (asymmetric cipher), public key cipher is also called asymmetric cipher, asymmetric key algorithm means that the encryption key and decryption key of an encryption algorithm are different, or can not be One of the keys derives another key.
  • Users with public key ciphers have an encryption key and a decryption key, respectively, and the decryption key cannot be obtained by the encryption key.
  • the encryption key is public.
  • the public key cipher is designed based on this principle, and the auxiliary information (the trapdoor information) is used as the secret key.
  • the security strength of such a password depends on the computational complexity of the problem on which it is based.
  • Common public key passwords nowadays are RSA public key cryptography, ElGamal public key cryptography, and elliptic curve cryptography.
  • the same key used for symmetric key encryption and decryption, or the decryption key can be easily derived from the encryption key; 2 symmetric key algorithm
  • the invention has the advantages of simple encryption processing, fast encryption and decryption, short key and long history, and the asymmetric key algorithm has the characteristics of slow encryption and decryption, large key size and short development history.
  • the background Debugging Mode (BDM) interface is programmed to be burned online or the in-vehicle device is disassembled and programmed.
  • the specific method may include the following methods 1 and 2.
  • the Telematics in the vehicle control device is responsible for external communication. In this application, it is responsible for communicating with the upgrade server and the key server, completing the acquisition task of the vehicle upgrade package, and part of the transmission action of the vehicle upgrade package (sent to the OTA). Orchestrator).
  • FIG. 2 is an OTA Orchestrator according to an embodiment of the present invention.
  • the OTA Orchestrator may include a processor CPU and associated volatile memory RAM and non-time-sensitive memory ROM, and secure storage for storing keys, such as a static key shared with the in-vehicle device, and the like;
  • the memory of the 0TA hypervisor is stored, and the 0TA hypervisor is used to implement the management of the upgrade process; it also includes a network interface that can communicate with other in-vehicle devices via the CAN bus or other in-vehicle network.
  • FIG. 4 is a schematic diagram of another in-vehicle system upgrade architecture (referred to as architecture 2) according to an embodiment of the present invention.
  • architecture 2 the in-vehicle system upgrade architecture further includes a dense structure. Key server. Among them, the upgrade server is used to obtain the developer-encrypted vehicle upgrade package from the developer.
  • FIG. 5 is a schematic flowchart of a method for upgrading an in-vehicle device according to an embodiment of the present invention, which can be applied to the in-vehicle system upgrade architecture described in FIG. 1 or FIG. 4, and will be described below with reference to FIG.
  • the description is made with the interaction side of the target in-vehicle device to be upgraded, and the method may include the following steps S501 to S505.
  • Step S502 The in-vehicle control device performs security verification on the plurality of upgrade files.
  • the in-vehicle control device sends the authentication information to the upgrade server; if the authentication information is verified in the upgrade server, a secure channel is established between the in-vehicle control device and the upgrade server; the in-vehicle control device upgrades the server through the secure channel. Get the car upgrade package that needs to be upgraded.
  • the OTA Orchestrator reports the current version information of the in-vehicle device to the upgrade server. If the upgrade server agrees, the OTA Orchestrator downloads the upgrade package [M, ver, ⁇ , ⁇ M' ⁇ ].
  • M is an in-vehicle upgrade package
  • ver represents version information including all metadata information (meta-data) such as a program name, a new version number, a corresponding old version number, etc.
  • o Sign D (M
  • ver) or o Sign s (M
  • M' means the rollback file
  • ⁇ ' ⁇ means that M' is optional and only valid when the target in-vehicle device to be upgraded is a weak device.
  • the OTA Orchestrator verifies the authenticity of the first digital signature ⁇ and discards if the verification fails.
  • OTA Orchestrator also verifies ⁇ ' if needed, assuming M' also has a digital signature.
  • the vehicle upgrade package is encrypted in the upgrade server, so there is no need to establish a dedicated secure channel between the vehicle control device and the upgrade server. And the vehicle control device needs to further decrypt the first key after the first upgrade verification of the vehicle upgrade package.
  • This embodiment is directed to the case where the upgrade file is encrypted by the developer.
  • An added benefit of the developer encrypting the upgrade file is that the developer does not have to consider the credibility of the upgrade server. Further protect the privacy of the upgrade file.
  • OTA Orchestrator obtains the current version information of the target vehicle to be upgraded. You can query the target to upgrade the in-vehicle device or query the database maintained by yourself (assuming OTA Orchestrator itself maintains the basic information of the firmware/software of all in-vehicle devices) .
  • OTA Orchestrator uses K to decrypt C to get the upgrade file M; if necessary, also decrypt C' to get ⁇ ' ( ⁇ ' is the file that can be rolled back when the upgrade fails).
  • step S503 since the different in-vehicle devices to be upgraded may only correspond to the partial upgrade files in the in-vehicle upgrade package, the in-vehicle control device needs to send the target upgrade file through the security verification in the plurality of upgrade files to use the The goal of upgrading the target upgrade file is to upgrade the in-vehicle device. It can be understood that each sub-upgrade file in the target upgrade file can be different in size and content.
  • the target in-vehicle device to be upgraded receives the target upgrade file sent by the in-vehicle control device, and the target upgrade file is an upgrade file that is securely verified by the in-vehicle control device and is used for at least upgrading the in-vehicle device to be upgraded.
  • the process belongs to a secure transmission process of the vehicle-mounted package in the vehicle.
  • a strong or critical device uses the A/B system update upgrade method; a weak device acts as a backup point with OTA Orchestrator to roll back when the upgrade fails.
  • the in-vehicle device deletes the upgrade package and notifies OTA Orchestrator, which deletes the upgrade package, updates the database, and prompts the owner to upgrade successfully.
  • OTA Orchestrator also has the option to notify the upgrade server.
  • OTA Orchestrator can also choose to have the remote attestation of the target vehicle to be upgraded, which proves that the upgrade is successful.
  • the multiple sub-upgrade files are encrypted by a third key; when the multiple data is After the block is verified, the target in-vehicle device to be upgraded will gradually verify that the plurality of data blocks after the pass-through are decrypted by using the third key respectively; the target in-vehicle device to be upgraded will utilize the third key.
  • the decrypted plurality of data blocks are merged and upgraded. That is, the embodiment of the present invention is different from the foregoing embodiment of the invention, and the target in-vehicle device to be upgraded needs to verify the sub-upgrade file after the encryption and transcoding, and then decrypt the sub-upgrade file that has passed the verification. After the decryption succeeds, after the decryption succeeds, Consolidate upgrades together.
  • the target vehicle to be upgraded is upgraded. If there are multiple data blocks, the target data block is not verified by the data block on the target in-vehicle device to be upgraded.
  • the in-vehicle control device retransmits the target data block to the target in-vehicle device to be upgraded, that is, the target in-vehicle device to be upgraded reacquires the target data block from the in-vehicle control device.
  • a merge upgrade will only occur if all data blocks have been verified.
  • the target upgrade file is divided into multiple data blocks, in the case that one or a certain data block fails to be verified, the data block only needs to be re-downloaded, and the entire target upgrade is not required to be downloaded again.
  • OTA Orchestrator divides the upgrade file M into n parts, namely MM 2 , . . . , M n ;
  • the OTA Orchestrator is transferred to the target in-vehicle equipment to be upgraded in two copies. For the first two copies, OTA Orchestrator needs to transmit v, Mi
  • the auxiliary verification data of and M 2 is h 2 , h 6 ; the auxiliary verification data of M 3 and M 4 is empty, because M 3 and M 4 can be verified by h 2 ; the assistance of M 5 and M 6
  • the verification data is h 4 , and the auxiliary verification data of M 7 and M 8 is empty;
  • the embodiment of the present invention can not only accurately locate the error location, but also reduce the calculation amount and computational complexity of the equipment to be upgraded in the vehicle, so that the vehicle equipment to be upgraded can be upgraded safely and efficiently.
  • the above is OTA Orchestrator to split the upgrade file.
  • the partitioning may be performed by an upgrade package developer. Specifically, take the hash chain method as an example:
  • the upgrade package developer divides the upgrade file M into n parts, namely M ⁇ 2 , ..., M n ;
  • M, ver, ⁇ as an upgrade package and deliver it to the upgrade server.
  • M ⁇ 2 , ..., ⁇ ⁇ may also be encrypted to ensure the privacy of the vehicle upgrade package. Refer to the foregoing description about encryption and guarantee the privacy of the upgrade file, and details are not described herein again. .
  • the authenticity of the car upgrade package (Authenticity): The authenticity of the upgrade package to be upgraded.
  • the upgrade package should be digitally signed by the developer or the package server.
  • OTA Orchestrator helps the in-vehicle device to be upgraded to verify the digital signature.
  • the OTA Orchestrator then transcodes (Transcoding), which uses a symmetric crypto mechanism to provide authenticity verification of the upgrade package for the in-vehicle device to be upgraded.
  • Transcoding uses a symmetric crypto mechanism to provide authenticity verification of the upgrade package for the in-vehicle device to be upgraded.
  • OTA Orchestrator shares a key with each in-vehicle device to be upgraded. This key may be distributed in advance by OTA Orchestrator, and the specific distribution process is not within the scope of this application.
  • the in-vehicle upgrade package includes a first digital signature
  • the upgrade management unit is configured to: perform digital signature verification on the plurality of upgrade files by using the first digital signature.
  • the upgrading unit 202 is specifically configured to:
  • the upgrading unit 202 is specifically configured to:
  • the processor 301 can be a general purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the above program.
  • CPU central processing unit
  • ASIC application-specific integrated circuit
  • the code stored in the memory 302 can perform the in-vehicle device upgrade method provided in FIG. 9 above, for example, receiving the target upgrade file sent by the in-vehicle control device, where the target upgrade file is the pass-through device.
  • An upgrade file that is securely verified by the in-vehicle control device and used to upgrade at least the target in-vehicle device to be upgraded; and the target upgrade file is used for security upgrade.
  • the fifth key is a symmetric algorithm key

Abstract

本发明实施例公开了一种车载设备升级方法及相关设备，其中的方法可应用于车载系统，所述车载系统包括车载控制设备和一个或多个待升级车载设备，所述方法可包括：所述车载控制设备获取车载升级包，所述车载升级包包括多个升级文件，且每一个升级文件用于对至少一个待升级车载设备进行升级；所述车载控制设备对所述多个升级文件进行安全验证；所述车载控制设备将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备，所述目标升级文件为所述多个升级文件中通过安全验证的升级文件。采用本申请，可以安全高效的进行车载设备的升级。

Description

一种车载设备升级方法及相关设备
技术领域
本申请涉及车载技术领域， 尤其涉及一种车载设备升级方法及相关设备。 背景技术
未来的每辆车都是车联网中的一个网络节点， 与电脑， 手机等联网设备没有本质的不 同。 据估计， 北美 60%到 70%车辆招回是由于固件 /软件的原因， 因此升级车载设备的固件 /软件是必不可少的环节。传统待升级车载设备的固件 /软件升级是采用车辆招回的方式， 这 种办法的缺点是： 成本高、 周期长。
因此， 未来车载设备的升级应采用更灵活的远程升级， 空中下载技术 (Over-The-Air， OTA)的方式， 就像现在的电脑和手机升级一样通过远程来升级。 对车载设备进行远程固件 /软件升级可带来很多好处。 例如， 便于关键的固件 /软件 bugs得以快速修复、 增加车辆安 全性、 便于车辆在整个生命周期内及时添加新功能或特色等。 因此采用 OTA方式不需要车 辆招回就可进行固件 /软件升级， 可为车辆生产商或销售商节省大量成本， 同时也为车主带 来便利。
然而， 在待升级车载设备的远程升级过程中， 可能会由于部分待升级车载设备的计算 能力、 存储空间有限等问题， 导致该待升级车载设备的升级效率较低， 甚至影响整个车载 系统的升级。因此，如何保证车载设备安全高效的进行固件 /软件升级成为亟待解决的问题。 发明内容
本发明实施例所要解决的技术问题在于， 提供一种车载设备升级方法及相关设备， 解 决了车载设备无法安全高效的进行固件 /软件升级的问题。
第一方面， 本发明实施例提供了一种车载设备升级方法， 可包括：
车载控制设备获取车载升级包， 车载升级包包括多个升级文件， 且每一个升级文件用 于对至少一个待升级车载设备进行升级； 车载控制设备对多个升级文件进行安全验证； 车 载控制设备将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备 目标升级文件为多个升级文件中通过安全验证的升级文件。 本发明实施例， 通过将车载设 备需要进行升级的车载升级包， 在车载控制设备侧进行安全验证处理， 避免升级能力强弱 不同的待升级车载设备参与安全验证过程， 保证了车载设备安全高效的进行车载升级包升 级。
在一种可能的实现方式中， 车载升级包包括第一数字签名； 车载控制设备对多个升级 文件进行安全验证， 包括： 车载控制设备使用第一数字签名对多个升级文件进行数字签名 验证。 即车载升级包经过数据签名的认证， 保证了车载控制设备从车载设备的外部获取车 载升级包的合法性。
在一种可能的实现方式中， 所述方法还包括： 车载控制设备向升级服务器发送身份验 证信息； 若身份验证信息在升级服务器中验证通过， 车载控制设备与升级服务器之间建立 安全通道； 车载控制设备从升级服务器获取车载升级包， 包括： 车载控制设备通过安全通 道从升级服务器获取车载升级包。即通过在车载控制设备和升级服务器之间建立安全通道， 保证了车载升级包在传输过程中的私密性， 此时无需对车载升级包进行额外加密。
在一种可能的实现方式中， 车载升级包经过第一密钥加密， 第一密钥为对称密钥； 方 法还包括： 车载控制设备从密钥服务器处获取第一密钥； 车载控制设备使用第一数字签名 对多个升级文件进行数字签名验证之后， 包括： 若数字签名验证通过， 车载控制设备利用 第一密钥对多个升级文件进行解密。 即通过对车载升级包进行加密， 并且将该加密密钥保 存在专属的密钥服务器中， 有力的保证了车载升级包在传输过程中的私密性。
在一种可能的实现方式中， 车载控制设备将目标升级文件发送给使用所述目标升级文 件进行升级的目标待升级车载设备， 包括： 车载控制设备将目标升级文件划分为多个子升 级文件； 车载控制设备将多个子升级文件通过预设算法生成互相关联的多个数据块， 并利 用第二密钥生成多个数据块的第一消息认证码 MAC, 第二密钥为对称算法密钥； 车载控制 设备将携带第一 MAC 的多个数据块逐步发送给目标待升级车载设备。 即在车载升级包在 车载设备内部传输的过程中通过利用预设算法将升级文件划分为多个有关联关系的数据块 并针对该有关联关系的数据块进行 MAC 处理， 以便于车载控制设备可以将一个完整的升 级文件， 划分为多个可以分开传输并且可以分开验证合法性的数据块。 并且由于多个数据 块之间是有关联关系的， 因此利用相关算法， 可以快速定位出有安全问题的数据块。 不仅 减少了能力较弱的待升级车载设备在单位时间内的计算量和计算复杂度， 并且在升级文件 传输错误后， 可以尽快找出错误的子份， 从而只请求重发出错的部分， 而不是整个升级文 件。 进一步保证了车载设备安全高效的升级。
在一种可能的实现方式中， 所述方法还包括： 车载控制设备对多个子升级文件分別利 用第三密钥加密； 车载控制设备将多个子升级文件通过预设算法生成互相关联的多个数据 块， 包括： 车载控制设备将利用第三密钥加密后的多个子升级文件， 通过预设算法生成互 相关联的多个数据块。 在保证了车载升级包的合法性的前提下， 还进一步的保证车载升级 包的私密性， 避免被非法获取。
在一种可能的实现方式中， 目标升级文件包括多个子升级文件， 多个子升级文件通过 预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成的多个数据块的第二数字 签名， 第四密钥为非对称密钥； 车载控制设备对多个升级文件进行安全验证， 包括： 车载 控制设备对多个数据块的第二数字签名进行校验； 车载控制设备将目标升级文件发送给使 用所述目标升级文件进行升级的目标待升级车载设备， 包括： 车载控制设备利用第五密钥 生成多个数据块的第二 MAC, 第五密钥为对称算法密钥； 车载控制设备将携带第二 MAC 的多个数据块逐步发送给目标待升级车载设备。 即关于车载升级包的分块传输及签名， 可 以是在升级开发者侧完成， 即车载控制设备获取到的是已经经过预设算法分块且签名的数 据块， 此时车载设备需要先分块校验其合法性， 再将校验了合法性之后的数据块重新做 MAC处理， 以便于在保证车载升级文件在车载内传输过程中的合法性的同时， 又可以减少 待升级车载设备的计算量和计算复杂度， 实现了车载设备安全高效的升级。
在一种可能的实现方式中，预设算法包括 Hash Chain算法、 Hash Tree算法、 Bloom Filter 算法中的任意一种。 在预设算法中使用上述算法中的哈希功能， 将目标升级文件划分为具 有相互关联关系的多个数据块， 如此一来， 在进行 MAC 处理的时候， 可以只对多个数据 块中的一块进行 MAC 处理， 从而其他具有关联关系的数据块， 可以利用相互关联的哈希 值来进行校验。
在一种可能的实现方式中， 方法还包括： 车载控制设备将目标数据块重新发送给目标 待升级车载设备， 目标数据块为多个数据块中在目标待升级车载设备上未验证通过的数据 块。 在有关联关系的分块传输的基础上， 不仅可以快速定位出未验证通过的数据块， 也便 于在出现这种传输错误的情况下， 只需要重新请求对应的数据块， 而不是整个升级文件， 节省开销， 提升升级效率， 同时也保证了升级的安全性。 第二方面， 本发明实施例提供了一种智能车辆， 可包括： 车载控制设备和至少一个待 升级车载设备； 其中
所述车载设备用于， 获取车载升级包， 对所述车载升级包中的多个升级文件进行安全 验证， 并将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备， 其中， 每一个升级文件用于对至少一个待升级车载设备进行升级， 所述目标升级文件为所 述多个升级文件中通过安全验证的升级文件；
所述待升级车载设备， 用于接收车载控制设备发送的目标升级文件， 并利用所述目标 升级文件进行安全升级， 所述待升级车载设备为所述目标待升级车载设备。
在一种可能的实现方式中， 所述车载控制设备， 具体用于： 使用所述第一数字签名对 所述多个升级文件进行数字签名验证。 即本发明实施例中的智能车辆中的车载控制设备需 要对从车辆外部获取的车载升级包中的多个升级文件的合法性进行校验， 以保证安全升级。
在一种可能的实现方式中， 所述车载控制设备， 具体用于：
向所述升级服务器发送身份验证信息， 若所述身份验证信息在所述升级服务器中验证 通过， 与所述升级服务器之间建立安全通道， 并通过所述安全通道从所述升级服务器获取 所述车载升级包； 或者所述车载升级包经过第一密钥加密， 所述第一密钥为对称密钥； 所 述车载控制设备， 具体用于： 从密钥服务器处获取所述第一密钥， 并在使用所述第一数字 签名对所述多个升级文件进行数字签名验证通过之后， 利用所述第一密钥对所述多个升级 文件进行解密。 即本发明实施例中的智能车辆中的车载控制设备， 可以与服务器端建立安 全通道， 以保证获取车载升级包的过程的安全性。
在一种可能的实现方式中， 所述车载控制设备， 具体用于： 将所述目标升级文件划分 为多个子升级文件， 并通过预设算法生成互相关联的多个数据块， 利用第二密钥生成所述 多个数据块的第一消息认证码 MAC, 再将携带所述第一 MAC的所述多个数据块逐步发送 给所述目标待升级车载设备， 所述第二密钥为对称算法密钥；
所述待升级车载设备， 具体用于： 逐步接收所述车载控制设备发送的携带第一 MAC 的多个数据块， 并根据所述预设算法， 利用所述第二密钥逐步验证所述多个数据块， 当所 述多个数据块均验证通过， 将逐步验证通过后的所述多个数据块进行合并升级。
即本发明实施例中的智能车辆中的车载控制设备， 通过在验证了从车辆外部获取的车 载升级包的合法性之后， 再在车辆内部通过将升级文件分块以及 MAC 处理， 以保证升级 文件在车辆内部传输的合法性。 并且待升级车载设备由于可以分块接收并校验升级文件， 因此， 可以快速定位出错位置， 且由于对 MAC 的校验， 计算复杂度较小， 因此可以保证 车辆内升级能力较弱的待升级车载设备， 较容易校验并升级， 以保证车辆升级的高效性和 安全性。
在一种可能的实现方式中， 所述车载控制设备， 具体用于：
对所述多个子升级文件分別利用第三密钥加密， 将所述利用第三密钥加密后的所述多 个子升级文件， 通过预设算法生成互相关联的多个数据块；
所述待升级车载设备， 具体用于： 当所述多个数据块均验证通过， 将逐步验证通过后 的所述多个数据块分別利用所述第三密钥进行解密， 再将利用所述第三密钥进行解密后的 所述多个数据块进行合并升级。
即本发明实施例中的智能车辆中的车载控制设备， 在车内传输升级文件的过程中， 进 一步通过加密来保证升级文件的私密性。
在一种可能的实现方式中， 所述目标升级文件包括多个子升级文件， 所述多个子升级 文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成的所述多个数据 块的第二数字签名， 所述第四密钥为非对称密钥；
所述车载控制设备， 具体用于： 对所述多个数据块的第二数字签名进行校验， 利用第 五密钥生成所述多个数据块的第二 MAC, 将携带所述第二 MAC的所述多个数据块逐步发 送给所述目标待升级车载设备。 所述第五密钥为对称算法密钥；
所述待升级车载设备， 具体用于： 逐步接收所述车载控制设备发送的携带第二 MAC 的多个数据块， 并根据所述预设算法， 利用所述第五密钥逐步验证所述多个数据块， 当所 述多个数据块均验证通过， 将逐步验证通过后的所述多个数据块进行合并升级。
即本发明实施例中的智能车辆中的车载控制设备， 通过在验证了从车辆外部获取的经 过分块且经过签名的升级文件的合法性之后，再在车辆内部通过将升级文件分块以及 MAC 处理， 以保证升级文件在车辆内部传输的合法性。 并且待升级车载设备由于可以分块接收 并校验升级文件， 因此， 可以快速定位出错位置， 且由于对 MAC 的校验， 计算复杂度较 小， 因此可以保证车辆内升级能力较弱的待升级车载设备， 较容易校验并升级， 以保证车 辆升级的高效性和安全性。 第三方面， 本发明实施例提供了一种车载设备升级方法， 可包括：
目标待升级车载设备接收车载控制设备发送的目标升级文件， 目标升级文件为通过车 载控制设备安全验证的且至少用于对所述目标待升级车载设备进行升级的升级文件； 目标 待升级车载设备利用目标升级文件进行安全升级。 本发明实施例， 目标待升级车载设备通 过接收已经在车载控制设备侧进行了安全验证处理的升级文件， 并利用该升级文件进行设 备升级， 避免升级能力强弱不同的待升级车载设备参与安全验证过程， 保证了待升级车载 设备安全高效的进行车载升级包升级。
在一种可能的实现方式中， 目标待升级车载设备利用目标升级文件进行安全升级， 包 括：目标待升级车载设备采用 A/B系统更新升级模式，并利用目标升级文件进行安全升级， 待升级车载设备为资源存储能力和 /或处理能力超过预设值的或者预先指定的第一待升级 车载设备。 针对能力较强的待升级车载设备， 可以采用 A/B系统更新升级模式进行升级。
在一种可能的实现方式中， 目标升级文件包括多个子升级文件； 目标待升级车载设备 接收车载控制设备发送的目标升级文件， 包括： 目标待升级车载设备逐步接收车载控制设 备发送的携带第一 MAC 的多个数据块， 多个数据块为将多个子升级文件通过预设算法生 成的互相关联的多个数据块，第一 MAC为利用第二密钥生成的多个数据块的消息认证码， 第二密钥为对称密钥； 目标待升级车载设备利用目标升级文件进行安全升级， 包括： 目标 待升级车载设备根据预设算法， 利用第二密钥逐步验证多个数据块； 当多个数据块均验证 通过， 目标待升级车载设备将逐步验证通过后的多个数据块进行合并升级。 即在车载升级 包在车载设备内部传输的过程中通过利用预设算法将升级文件划分为多个有关联关系的数 据块， 并针对该有关联关系的数据块进行 MAC 处理， 以便于车载控制设备可以将一个完 整的升级文件， 划分为多个可以分开传输并且可以分开验证合法性的数据块。 并且由于多 个数据块之间是有关联关系的，因此利用相关算法，可以快速定位出有安全问题的数据块。 不仅减少了能力较弱的待升级车载设备在单位时间内的计算量和计算复杂度， 并且在升级 文件传输错误后， 可以尽快找出错误的子份， 从而只请求重发出错的部分， 而不是整个升 级文件。 进一步保证了车载设备安全高效的升级。
在一种可能的实现方式中， 多个子升级文件经过第三秘钥加密； 当多个数据块均验证 通过， 目标待升级车载设备将逐步验证通过后的多个数据块进行合并升级， 包括： 当多个 数据块均验证通过， 目标待升级车载设备将逐步验证通过后的多个数据块分別利用第三密 钥进行解密； 目标待升级车载设备将利用第三密钥进行解密后的多个数据块进行合并升级。 在保证了车载升级包的合法性的前提下， 还进一步的保证车载升级包的私密性， 避免被非 法获取。
在一种可能的实现方式中， 目标升级文件包括多个子升级文件； 目标待升级车载设备 接收车载控制设备发送的目标升级文件， 包括： 目标待升级车载设备逐步接收车载控制设 备发送的携带第二 MAC 的多个数据块， 多个数据块为将多个子升级文件通过预设算法生 成互相关联的多个数据块， 第二 MAC 为利用第五密钥生成的多个数据块的消息认证码， 第五密钥为对称算法； 目标待升级车载设备利用目标升级文件进行安全升级， 包括： 目标 待升级车载设备根据预设算法， 并利用第五密钥逐步验证多个数据块； 当多个数据块均验 证通过， 目标待升级车载设备将逐步验证通过后的多个数据块进行合并升级。 即关于车载 升级包的分块传输及签名， 可以是在升级开发者侧完成， 即车载控制设备获取到的是已经 经过预设算法分块且签名的数据块， 此时车载设备需要先分块校验其合法性， 再将校验了 合法性之后的数据块重新做 MAC 处理， 以便于在保证车载升级文件在车载内传输过程中 的合法性的同时， 又可以减少待升级车载设备的计算量和计算复杂度， 实现了车载设备安 全高效的升级。
在一种可能的实现方式中， 方法还包括： 目标待升级车载设备从车载控制设备处重新 获取目标数据块， 目标数据块为多个数据块中在目标待升级车载设备上未验证通过的数据 块。 在有关联关系的分块传输的基础上， 不仅可以快速定位出未验证通过的数据块， 也便 于在出现这种传输错误的情况下， 只需要重新请求对应的数据块， 而不是整个升级文件， 节省开销， 提升升级效率， 同时也保证了升级的安全性。 第四方面， 本申请提供一种车载设备升级装置， 该车载设备升级装置具有实现上述任 意一种车载设备升级方法实施例中方法的功能。 该功能可以通过硬件实现， 也可以通过硬 件执行相应的软件实现。 该硬件或软件包括一个或多个与上述功能相对应的模块。
第五方面， 本申请提供一种待升级车载装置， 该终端设备具有实现上述任意一种车载 设备升级方法实施例中方法的功能。 该功能可以通过硬件实现， 也可以通过硬件执行相应 的软件实现。 该硬件或软件包括一个或多个与上述功能相对应的模块。
第六方面， 本申请提供一种车载控制设备， 该车载控制设备中包括处理器， 处理器被 配置为支持该车载控制设备执行第一方面提供的一种车载设备升级方法中相应的功能。 该 车载控制设备还可以包括存储器， 存储器用于与处理器耦合， 其保存该车载控制设备必要 的程序指令和数据。 该车载控制设备还可以包括通信接口， 用于该车载控制设备与其他设 备或通信网络通信。
第七方面， 本申请提供一种目标待升级车载设备， 该目标待升级车载设备中包括处理 器， 处理器被配置为支持该目标待升级车载设备执行第三方面提供的一种控制车载设备升 级方法中相应的功能。 该目标待升级车载设备还可以包括存储器， 存储器用于与处理器耦 合， 其保存该目标待升级车载设备必要的程序指令和数据。 该目标待升级车载设备还可以 包括通信接口， 用于该目标待升级车载设备与其他设备或通信网络通信。
第八方面， 本申请提供一种计算机存储介质， 用于储存为上述第六方面提供的车载控 制设备所用的计算机软件指令， 其包含用于执行上述方面所设计的程序。
第九方面， 本申请提供一种计算机存储介质， 用于储存为上述第七方面提供的目标待 升级车载设备所用的计算机软件指令， 其包含用于执行上述方面所设计的程序。
第十方面， 本发明实施例提供了一种计算机程序， 该计算机程序包括指令， 当该计算 机程序被计算机执行时， 使得计算机可以执行上述第一方面中任意一项的车载设备升级方 法中的流程。
第十一方面， 本发明实施例提供了一种计算机程序， 该计算机程序包括指令， 当该计 算机程序被计算机执行时， 使得计算机可以执行上述第三方面中任意一项的车载设备升级 方法中的流程。
第十二方面， 本申请提供了一种芯片系统， 该芯片系统包括处理器， 用于支持目标待 升级车载设备或车载控制设备实现上述方面中所涉及的功能， 例如， 例如接收或处理上述 方法中所涉及的数据和 /或信息。 在一种可能的设计中， 所述芯片系统还包括存储器， 所述 存储器， 用于保存目标待升级车载设备或车载控制设备必要的程序指令和数据。 该芯片系 统， 可以由芯片构成， 也可以包含芯片和其他分立器件。 附图说明
图 1是本发明实施例提供的一种车载系统升级架构图；
图 2是本发明实施例提供的一种 OTA Orchestrator的结构示意图；
图 3为本发明实施例提供的一种待升级车载设备的结构示意图；
图 4是本发明实施例提供的另一种车载系统升级架构图；
图 5是本发明实施例提供的一种车载设备升级方法的流程示意图图 4 ;
图 6是本发明实施例提供的一种车载升级装置的结构示意图；
图 7是本发明实施例提供的一种待升级车载装置的结构示意图； 图 8是本发明实施例提供的一种设备的结构示意图；
图 9是本发明实施例提供的一种智能车辆的结构示意图。 具体实施方式
下面将结合本发明实施例中的附图， 对本发明实施例进行描述。
本申请的说明书和权利要求书及所述附图中的术语"第一"、 "第二"、 "第三"和"第四" 等是用于区別不同对象， 而不是用于描述特定顺序。 此外， 术语"包括"和"具有"以及它们 任何变形， 意图在于覆盖不排他的包含。 例如包含了一系列步骤或单元的过程、 方法、 系 统、 产品或设备没有限定于已列出的步骤或单元， 而是可选地还包括没有列出的步骤或单 元， 或可选地还包括对于这些过程、 方法、 产品或设备固有的其它步骤或单元。
在本文中提及 "实施例"意味着， 结合实施例描述的特定特征、 结构或特性可以包含在 本申请的至少一个实施例中。 在说明书中的各个位置出现该短语并不一定均是指相同的实 施例， 也不是与其它实施例互斥的独立的或备选的实施例。 本领域技术人员显式地和隐式 地理解的是， 本文所描述的实施例可以与其它实施例相结合。
在本说明书中使用的术语"部件"、"模块"、 "系统"等用于表示计算机相关的实体、硬件、 固件、 硬件和软件的組合、 软件、 或执行中的软件。 例如， 部件可以是但不限于， 在处理 器上运行的进程、 处理器、 对象、 可执行文件、 执行线程、 程序和 /或计算机。 通过图示， 在计算设备上运行的应用和计算设备都可以是部件。 一个或多个部件可驻留在进程和 /或执 行线程中， 部件可位于一个计算机上和 /或分布在 2个或更多个计算机之间。 此外， 这些部 件可从在上面存储有各种数据结构的各种计算机可读介质执行。 部件可例如根据具有一个 或多个数据分組 （例如来自与本地系统、 分布式系统和 /或网络间的另一部件交互的二个部 件的数据，例如通过信号与其它系统交互的互联网）的信号通过本地和 /或远程进程来通信。 首先， 对本申请中的部分用语进行解释说明， 以便于本领域技术人员理解。
( 1 )、 空中下载技术 （Over the Air Technology, OTA)。 是通过移动通信的空中接口进 行远程固件或软件远程升级的技术。
(2)、 车载信息服务 （Telematics) 是远距离通信的电信 （Telecommunications) 与信息 科学 （Informatics) 的合成词， 按字面可定义为通过内置在汽车、 航空、 船舶、 火车等运输 工具上的计算机系统、 无线通信技术、 卫星导航装置、 交换文字、 语音等信息的互联网技 术而提供信息的服务系统。简单的说就通过无线网络将车辆接入互联网，为车主提供驾驶、 生活所必需的各种信息。
(3 )、 电子控制单元 （Electronic Control Unit, ECU) , 从用途上讲则是汽车专用微机 控制器。 它和普通的电脑一样，由微处理器 （CPU)、 存储器 （ROM、 RAM) , 输入 /输出接 口 （1/0)、 模数转换器 （A/D) 以及整形、 驱动等大规模集成电路組成。
(4)、 车辆控制单元 (Vehicle control unit, VCU), 也可以称之为电动汽车整车控制器 VCU是电动汽车动力系统的总成控制器， 负责协调发动机、 驱动电机、 变速箱、 动力电池 等各部件的工作， 具有提高车辆的动力性能、 安全性能和经济性等作用。 是电动汽车整车 控制系统的核心部件， 是用来控制电动车电机的启动、 运行、 进退、 速度、 停止以及电动 车的其它电子器件的核心控制器件。 VCU作为纯电动汽车控制系统最核心的部件， 其承担 了数据交换、 安全管理、 驾驶员意图解释、 能量流管理的任务。 VCU采集电机控制系统信 号、 加速踏板信号、 制动踏板信号及其他部件信号， 根据驾驶员的驾驶意图综合分析并作 出响应判断后， 监控下层的各部件控制器的动作， 对汽车的正常行驶、 电池能量的制动回 馈、 网络管理、 故障诊断与处理、 车辆状态监控等功能起着关键作用。
(6)、 控制器局域网络 (Controller Area Network, CAN)总线， 是国际上应用最广泛的 现场总线之一。 其所具有的高可靠性和良好的错误检测能力受到重视， 被广泛应用于汽车 计算机控制系统和环境温度恶劣、 电磁辐射强和振动大的工业环境。 CAN总线是一种应用 广泛的现场总线， 在工业测控和工业自动化等领域有很大的应用前景。 CAN属于总线式串 行通信网络。 CAN 总线在数据通信方面具有可靠、 实时和灵活的优点。 为使设计透明和执 行灵活，遵循 ISO /OSI标准模型， CAN总线结构划分为两层物理层和数据链路层 (；包括逻辑 链路控制子层 LLC和媒体访问控制子层 MAC)。
(7)、 消息验证码 （Message Authentication Code, MAC)。 MAC是对信源的一个编码 函数。 MAC类似于摘要算法， 但是它在计算的时候还要采用一个密钥， 因此 MAC同时依 赖于所使用的密钥以及要计算起 MAC的信息。实际上 MAC通常是根据摘要算法构造得出 的。
(8)、 密钥导出算法 (Key Derivation Function, KDF), 是加解密过程使用到的密钥派生 函数， 作用是从一个共享的秘密比特串口派生出密钥数据， 在密钥协商过程中， 密钥派生 函数作用在密钥交换所获动向的秘密比特串上， 从中产生所需的会话密钥或进一步加密所 需的密钥数据。
(9)、 公钥密码 （非对称密码）， 公钥密码又称为非对称密码， 非对称密钥算法是指一 个加密算法的加密密钥和解密密钥是不一样的， 或者说不能由其中一个密钥推导出另一个 密钥。 拥有公钥密码的用户分別拥有加密密钥和解密密钥， 通过加密密钥不能得到解密密 钥。 并且加密密钥是公开的。 公钥密码就是基于这一原理而设计的， 将辅助信息 （陷门信 息） 作为秘密密钥。 这类密码的安全强度取决于它所依据的问题的计算复杂度。 现在常见 的公钥密码有 RSA公钥密码、 ElGamal公钥密码、 椭圆曲线密码。
( 10)、 对称密码， 对称密钥加密又叫专用密钥加密， 即发送和接收数据的双方必使用 相同的密钥对明文进行加密和解密运算。 即加密密钥能够从解密密钥中推算出来， 反过来 也成立。 在大多数对称算法中， 加密解密密钥是相同的。 这些算法也叫秘密密钥算法或单 密钥算法， 它要求发送者和接收者在安全通信之前， 商定一个密钥。 对称算法的安全性依 赖于密钥， 泄漏密钥就意味着任何人都能对消息进行加密解密。 只要通信需要保密， 密钥 就必须保密。
从上述对对称密钥算法和非对称密钥算法的描述中可看出， 对称密钥加解密使用的同 一个密钥， 或者能从加密密钥很容易推出解密密钥； ②对称密钥算法具有加密处理简单， 加解密速度快， 密钥较短， 发展历史悠久等特点， 非对称密钥算法具有加解密速度慢的特 点， 密钥尺寸大， 发展历史较短等特点。
( 11 )、 传输层安全协议 (Transport Layer Security, TLS), 用于两个应用程序之间提供 保密性和数据完整性。 该协议由两层組成： TLS记录协议 （TLS Record) 和 TLS握手协议
(TLS Handshake)。 安全传输层协议 （TLS) 用于在两个通信应用程序之间提供保密性和 数据完整性。 首先， 提出本申请需要解决的技术问题及应用场景。 在现有技术中， 传统车载设备的 固件 /软件升级是采用车辆招回的方式， 即将车招回到指定的地点， 如維修厂 /4S 店， 然后 采用下述方法进行固件 /软件升级： 具体实现有如下方案一和方案二：
方案一： 借助联合测试工作組 （Joint Test Action Group, JTAG) 接口或 （调试模式
Background Debugging Mode, BDM)接口在线烧写或者将车载设备拆卸烧写， 具体可以包 括如下方式一和方式二。
方式一，先把要升级的软件通过个人计算机 (personal computer, PC)下载到程序烧录仪， 然后将程序烧录仪连接到烧录工装，接着将汽车电子控制系统的印制电路板（Printed Circuit
Board, PCB) 放入烧录工装对准下载接口， 最后通电烧录软件。
方式二， 将 PC机、 单片机程序下载数据线和汽车电子控制系统的 PCB板串联起来， 通过操作 PC机直接将程序下载到单片机中。
上述方式一和方式二的问题是需要专业人员， 增加成本， 操作起来非常不方便。
方案二：基于 CAN线的车载诊断系统（On-Board Diagnostic, OBD)进行 Flash烧写。 步骤 1 :从汽车电子系统正常的应用程序运行状态进入到刷新模式；（中断或诊断触发）； 步骤 2:对汽车电子控制器芯片的存储器进行检验， 并判断存储器中是否保存有正确的 应用程序；
步骤 3:如果存储器中没有正确的应用程序， 从诊断设备下载应用程序软件， 通过 CAN 总线传输， 并刷新 Flash中的应用程序 (刷新模块用于启动引导和软件烧写）。
上述方案二的问题是需要专业人员， 且周期长。
除了上述方案一和方案二， 现在一些车辆也实现了远程升级， 但是通常这些已实现的 远程升级主要针对于计算能力较强和存储空间较大的车载设备， 即对于计算能力较弱或者 存储空间较小的车载设备， 当前无法提供安全有效的固件 /软件升级方法。 因此， 如何在车 载系统中待升级车载设备升级能力强弱不同的情况下， 安全且高效的进行固件 /软件升级是 本申请实际要解决的技术问题。 为了便于理解本发明实施例， 基于上述， 下面先对本发明实施例所基于的车载升级系 统架构进行描述。 请参见图 1， 图 1 是本发明实施例提供的一种车载系统升级架构图 （简 称为架构一）， 本申请提出的车载设备升级方法可以应用于该系统架构。 该系统架构中包含 了升级服务器、 车载控制设备和多个待升级车载设备， 例如 HMI(人机界面）、 BMS (电池管 理系统)、 ECU1和 ECU2)， 而车载控制设备可以包括 Telematics单元和 OTA协调器 （OTA Orchestrator)单元， 用于管理和辅助多个待升级车载设备的升级过程。在上述系统架构下， 车载设备远程升级可以包括以下基本过程： 升级包发布， 升级包获取， 升级包车内传输， 升级与确认。 其中，
升级服务器， 用于从开发者处获取未经过加密的车载升级包。
车载控制设备中的 Telematics, 负责对外通信， 在本申请中负责与升级服务器和密钥服 务器通信， 完成车载升级包的获取任务， 以及车载升级包的部分传输动作 （发送给 OTA Orchestrator)。
车载控制设备中的 OTA Orchestrator, 负责与车载内的待升级车载设备通信。 本申请中 车载升级包通过 Telematics和管理单元 /模块而最终抵达目标待升级车载设备。 其主要功能 是管理和辅助车载设备的升级过程。 具体来说， OTA Orchestrator应具有如下功能： 密钥分 发及管理； 管理 OTA过程； 帮助其他较弱的待升级车载设备分担计算量大的操作， 如验证 升级包的完整性和真实性， 及 Transcoding (转码)等； 作为其他较弱的待升级车载设备的备 份点， 以便升级失败时回滚。 OTA Orchestrator是个逻辑实体， 物理上可以部署任何功能强 大的单元或模块上， 例如 Telematics, Gateway, VCU等， 其结构可以如图 2所示， 图 2为 本发明实施例提供的一种 OTA Orchestrator的结构示意图。 其中， OTA Orchestrator可包括 处理器 CPU 以及相关的易失性存储器 RAM和非易时性存储器 ROM, 和用于存放密钥的 安全存储，如与车载设备共享的静态密钥等；还包括用于存储 0TA管理程序的存储器， 0TA 管理程序用于实现对升级过程的管理； 还包括以及可通过 CAN bus或其他车内网络与其他 车载设备通信的网络接口。 可以理解的是， 如果 OTA Orchestrator实现在 Telemantics上， 它还需有与外部网络通信的网络接口。即 OTA Orchestrator应有较强的计算能力和较多资源 辅助车载设备完成远程升级，并被其他车载设备信任。从逻辑架构上划分， OTA Orchestrator 把该架构分为车外通信部分和车内通信部分。 车内部分的各设备无需进行公钥密码操作而 只需进行对称密码操作； 如涉及公钥密钥操作， 则代理给 OTA Orchestrator, 以减少车载内 待升级设备的计算量和计算复杂度。
待升级车载设备， 任意一个待升级车载设备的构成可以如图 3所示， 图 3为本发明实 施例提供的一种待升级车载设备的结构示意图。 待升级车载设备可以包括微型控制器 (Micro controller)， CAN控制器 (CAN controller)和收发器 (Transceiver)。 其中， 待升级车载 设备通过收发器 Transceiver与车内网络如 CAN bus通信， CAN controller则用于实现 CAN 协议， 微型控制器则用于实现待升级以及升级后的相关的计算处理， 例如可以实现本申请 中关于待升级车载设备所执行的车载设备升级方法。 结合上述结构示意图， 在本申请中， 目标待升级车载设备基于车内网络如 CAN bus, 通过收发器 (Transceiver)接收车载控制设备 发送的目标升级文件， 并通过微型控制器 (Micro Controlller)利用所述目标升级文件进行安 全升级。 更具体的功能可以参照后续实施例中关于待升级车载设备相关功能的描述。
由上述待升级车载设备的结构示意图可以知道， 现在车内普遍采用的 CAN 总线， 而 CAN总线会影响带宽。 因此， 导致在一些升级场景中， 车载设备的固件 /软件远程升级不能 达到最大升级效率。 请参见图 4，图 4是本发明实施例提供的另一种车载系统升级架构图（简称为架构二）， 与图 1提供的系统升级架构不同之处在于，该车载系统升级架构还包括密钥服务器。其中， 升级服务器， 用于从开发者处获取经过开发者加密的车载升级包。
密钥服务器， 用于在车载升级包被开发者加密的情况下， 该密钥服务器通过安全通道 从开发者处获取密钥并存储密钥， 并且最终将密钥提供给车载控制设备。
可以理解的是其它关于载控制设备和多个待升级车载设备的具体功能， 请参照上述图 1对应的车载系统升级架构中的各个功能实体或单元的描述， 在此不再贅述。 还以理解的是， 本申请中的车载系统升级架构还可以包括开发者， 开发者在固件 /软件 发布的开发和测试升级程序后， 将车载升级包交付给升级服务器， 该交付的车载升级包需 要经过数字签名。 可选的， 在经过数字签名之前， 还可以对该车载升级包经过加密。 若不 经过加密， 则对应上述图 1 中的系统架构， 若经过加密则对应上述图 2中的系统架构。 后 述会详细描述对应实施例。
需要说明的是， 图 1和图 2中的车载系统升级架构只是本发明实施例中的两种示例性 的实施方式， 本发明实施例中的通信系统架构包括但不仅限于以上系统架构。 下面结合本申请中提供的车载设备升级方法的实施例， 对本申请中提出的技术问题进 行具体分析和解决。
请参见图 5， 是本发明实施例提供的一种车载设备升级方法的流程示意图， 可应用于 上述图 1或者图 4中所述的车载系统升级架构， 下面将结合附图 5从车载控制设备和目标 待升级车载设备的交互侧进行描述， 该方法可以包括以下步骤 S501-步骤 S505。
步骤 S501 : 车载控制设备获取车载升级包。
步骤 S502 : 所述车载控制设备对所述多个升级文件进行安全验证。
步骤 S503： 车载控制设备将目标升级文件发送给使用所述目标升级文件进行升级的目 标待升级车载设备， 所述目标升级文件为所述多个升级文件中通过安全验证的升级文件。
步骤 S504 : 目标待升级车载设备接收车载控制设备发送的目标升级文件， 所述目标升 级文件为通过所述车载控制设备安全验证的且用于对所述待升级车载设备进行升级的升级 文件。
步骤 S505 : 目标待升级车载设备利用所述目标升级文件进行安全升级。
具体地， 车载升级包包括多个升级文件， 且每一个升级文件用于对至少一个待升级车 载设备进行升级。 即车载系统内的待升级车载设备可以对应一个或者多个升级文件。
在车载控制设备执行上述步骤 S501之前， 还涉及到车载升级包的发布， 通常情况下， 车载升级包 （固件 /软件） 的开发者会在开发和测试升级程序后， 将车载升级包交付给升级 服务器。 在一种可能的实现方式中， 所述车载升级包包括第一数字签名。 假设车载升级包 是 M， 版本信息是 ver (如程序名、 新版本号、 旧版本号等所有源数据信息 (meta-data)等）。 本发明实施例， 关于车载升级包的发布可以提供以下两种数字签名方式： 开发者数字签名 升级包或升级服务器数字签名升级包， 如图 6所示， 图 6是本发明实施例提供的两种数字 签名示意图。 包括以下情况 1和情况 2。
情况 1， o=SignD(M||ver;)代表开发者对 M||ver做数字签名，即本申请中的第一数字签名。 情况 2，
Figure imgf000013_0001
代表升级服务器对 M||ver做数字签名， 即本申请中的第一数 字签名。
本申请对以上两种签名方式所用的数字签名算法不作具体限定。 可选的， 开发者和升 级服务器之间可建立安全通道来传递信息， 安全通道可以是网络通道也可以是物理通道， 如挂号信件等。 总之， 在上述车载升级包的发布的执行， 使得升级服务器更新了车载升级 包 [M,ver, σ]， 并对外发布有新的车载升级包更新或存在的信息。 本申请提供两种车载系统升级架构。 即上述图 1 中不包含有密钥服务器的架构一和上 述图 4中包含有密钥服务器的架构二：
在架构一中： 车载升级包未经过加密， 但是升级服务器需要验证车载控制设备的身份 信息， 并在验证通过后与之建立安全通道， 并在这个安全通道上进行车载升级包的获取。 该过程是车载控制设备中的 OTA Orchestrator通过 Telematics单元从升级服务器获取升级 包的过程。
具体地， 车载控制设备向升级服务器发送身份验证信息； 若所述身份验证信息在升级 服务器中验证通过， 则车载控制设备与升级服务器之间建立安全通道； 车载控制设备通过 该安全通道从升级服务器获取需要升级的车载升级包。
在具体实施方式中， OTA Orchestrator通过查询升级服务器或是升级服务器通过推送更 新消息给 OTA Orchestrator。 升级包的获取具体可以包括如下步骤：
1、 0TA协调器 OTA Orchestrator获取目标待升级车载设备的当前版本信息， 可以通过 查问目标待升级车载设备或是通过查询自己維护的数据库 （假设 OTA Orchestrator 本身維 护所有车载设备的固件 /软件的基本信息)。
2、 OTA Orchestrator决定是否需要进行升级。 如需要升级， OTA Orchestrator可选择提 示车主是否进行升级， 如车主同意则继续进行。
3、 OTA Orchestrator向升级服务器认证并与之建立安全通道， 在该安全通道进行数据 包传输。
4、 OTA Orchestrator向升级服务器汇报车载设备的当前版本信息，如升级服务器同意， 那么 OTA Orchestrator下载升级包 [M, ver, σ, {M' }]。 其中， M为车载升级包； ver代表版本 信息包括如程序名， 新版本号， 对应的旧版本号等所有元数据信息（meta-data) ; o=SignD(M||ver)或者 o=Signs(M||ver)为第一数字签名， M'表示回滚文件； {Μ' }表示 M'是可 选项， 只在目标待升级车载设备是弱设备时有效。
5、 OTA Orchestrator验证第一数字签名 σ的真实性， 如果验证失败则放弃。 可选的， 如需要， OTA Orchestrator也验证 Μ'， 假设 M'也带有数字签名。 在架构二中， 车载升级包在升级服务器中经过加密， 因此车载控制设备与升级服务器 之间可以不需要建立专属的安全通道。 并且车载控制设备在对车载升级包经过第一签名验 证后，还需要进一步的通过第一密钥的解密。该实施例针对升级文件被开发者加密的情况。 开发者加密升级文件的一个额外好处是开发者不必考虑升级服务器的可信性。 进一步保护 升级文件的私密性。
具体地， 车载升级包经过第一密钥加密， 第一密钥为对称密钥； 车载控制设备从密钥 服务器处获取所述第一密钥； 车载控制设备使用所述第一数字签名对所述多个升级文件进 行数字签名验证之后， 若所述数字签名验证通过， 所述车载控制设备利用所述第一密钥对 所述多个升级文件进行解密。
车载升级包 （固件 /软件） 的开发者开发和测试升级程序后， 将升级文件交付给升级服 务器。该过程所对应的架构如图 4所示。与架构一相比，本构架需要一个额外密钥服务器。
假设升级文件是 M， ver代表版本信息包括如程序名， 新版本号， 对应的旧版本号等所 有元数据信息 (meta-data；)。 开发者选取一任意密钥 K (第一密钥）， 并用 Κ加密 Μ， 即得 C = Ε(Κ, Μ)， 这里 Ε(Κ, .)表示用 Κ的加密， 如群組加密。
针对第一数字签名， 同上述描述， 其一是开发者数字签名升级包， 其二是升级服务器 签名升级包。 该两种情况下， 开发者都需将加密了的升级文件的密钥 Κ通过安全通道发送 给密钥服务器， 而传输加密的升级文件的通道无需保护。 怎样建立开发者和密钥服务器之 间的秘密通道有多种方法， 如通过 TLS。 本申请对此不作具体限定。
在具体实施方式中，该过程是 OTA Orchestrator从升级服务器获取升级包及从密钥服务 器获取解密升级软件的密钥的过程。具体的， 当 OTA Orchestrator知道有新的针对某一车载 设备的升级包存在后启动该过程。 OTA Orchestrator获知该消息可通过查询升级服务器或升 级服务器通过推送信息给 OTA Orchestrator。 升级包的获取可以包括如下步骤：
1、 OTA Orchestrator获取目标待升级车载设备的当前版本信息， 可以通过查询目标待 升级车载设备或是通过查询自己維护的数据库 （假设 OTA Orchestrator 本身維护所有车载 设备的固件 /软件的基本信息） 。
2、 OTA Orchestrator决定是否需要进行升级。 如需升级， OTA Orchestrator可选择提示 车主是否进行升级， 如车主同意则继续进行。
3、 OTA Orchestrator从升级服务器下载升级包 [C, ver, σ, {C'}] 。 注意 C'表示可在升级 失败时回滚的加密及数字签名了的文件； {C'}表示 C'是可选项， 只在目标待升级车载设备 是弱设备时有效。
4、 OTA Orchestrator验证 σ的真实性 （即验证第一数字签名的真实性）， 如验证失败则 放弃。 如需要 OTA Orchestrator也验证 C '。
5、 OTA Orchestrator向密钥服务器认证并与之建立安全通道， 并通过该安全通道获取 升级包的解密密钥 K (即第一密钥） ， 如需要也需获取解密 C'的解密密钥。
6、 OTA Orchestrator用 K解密 C获得升级文件 M;如需要， 也需解密 C'获取 Μ' (Μ'是 可在升级失败时回滚的文件)。
在一种可能的实现方式中， 如需同时保护升级文件的私密性， 那么 OTA Orchestrator 在获取升级包后， 不解密 C， 而是将 C分成 n份 d, C2, Cn， 然后将 d, C2, Cn用于 后续基于 Hash Chain, 基于 Hash Tree, 和基于 Bloom Filter的处理方法中。 OTA Orchestrator 也需将共享密钥 K通过秘密通道传送给目标待升级车载设备以便后者解密。 在上述步骤 S502中，车载控制设备需要从升级服务器处获得的车载升级包中的多个升 级文件进行安全验证。 在一种可能的实现方式中， 所述车载升级包包括第一数字签名， 车 载控制设备 OTA Orchestrator使用所述第一数字签名对所述多个升级文件进行数字签名验 证。 即车载控制设备在获取到车载升级包之后， 不同于现有技术中的直接将升级包发送给 对应的待升级车载设备进行升级， 而是首先在车载控制设备侧先进行车载升级包中的多个 升级文件的安全验证 （例如真实性验证）， 再将该经过安全验证的升级文件进行转码 (transdoding)然后发送给对应的待升级车载设备进行安全升级。 需要说明的是， 本申请中的 转码是指将划分的多个子升级文件分別利用算法（Hash Chain, Hash Tree, 以及 Bloom Filter) 进行哈希关联处理， 并对其中的某一个或几个节点进行 MAC 处理， 进一步实现适用于车 内网络的数据包分段安全传输。 这样做减小了待升级车载设备需要进行大量的安全验证的 操作， 即减小了在单个待升级车载设备的安全验证的运算量以及运算复杂度等。
在上述步骤 S503中，由于不同的待升级车载设备可能只对应了车载升级包中的部分升 级文件， 因此车载控制设备需要将所述多个升级文件中通过安全验证的目标升级文件发送 给使用该目标升级文件进行升级的目标待升级车载设备。 可以理解的是， 目标升级文件中 的每个子升级文件之间大小可以不同， 内容也不同。
在一种可能的实现方式中， 车载控制设备将目标升级文件划分为多个子升级文件 （也 可理解为多个片段）， 并将所述多个子升级文件通过预设算法生成互相关联的多个数据块， 再利用第二密钥生成所述多个数据块的第一消息认证码 MAC, 最终将携带所述第一 MAC 的所述多个数据块逐步发送给目标待升级车载设备，其中，所述第二密钥为对称算法密钥。 具体地， 在车载升级包在车载设备内部传输的过程中， 车载控制设备通过利用预设算法将 升级文件划分为多个有关联关系的数据块，并针对该有关联关系的数据块进行 MAC处理， 以便于车载控制设备可以将一个完整的升级文件， 划分为多个可以分开传输并且可以分开 验证合法性的数据块。 并且， 由于多个数据块之间是有关联关系的， 因此利用相关算法， 可以快速定位出有安全问题的数据块。 其中， 预设算法包括 Hash Chain算法、 Hash Tree算 法、 Bloom Filter算法中的任意一种。 在本申请中， 由于车载控制设备将目标升级文件划分 为多个子升级文件的目的就是避免一次性将目标升级文件发送给待升级车载设备， 从而使 得待升级车载设备可以分散接收并处理子升级文件。 因此， 本申请中的逐步， 可以包括一 个接着一个， 也可以表示多个接着多个， 例如， 先发送两个， 再发送两个， 以此类推； 还 可以是先发一个， 再发两个等等。 即只要是将目标升级文件划分的多个子升级文件， 分批 次发送给待升级车载设备即可， 具体是如何划分并逐步发送给待升级车载设备， 本申请不 作具体限定。 在本申请中， 为应对车载设备能力弱、 存储资源不足、 以及车内网络带宽有 限的问题， 部署的 OTA Orchestrator 能够对车载升级包做转码 (transcoding)。 借助 OTA Orchestrator的转码功能， 车载设备无需进行公钥密码操作， 减轻车载设备的工作量。 不仅 减少了能力较弱的待升级车载设备在单位时间内的计算量和计算复杂度， 并且在升级文件 传输错误后， 可以尽快找出错误的子份， 从而只请求重发出错的部分， 而不是整个升级文 件。 进一步保证了车载设备安全高效的升级。
在一种可能的实现方式中， 车载控制设备将目标升级文件划分为多个子升级文件， 并 先经过加密 （保证私密性） 再进行转码 （保证真实性）， 再将加密并转码后的子升级文件逐 步的发送给目标待升级车载设备。 具体地， 车载控制设备对所述多个子升级文件分別利用 第三密钥加密， 并将所述利用第三密钥加密后的所述多个子升级文件， 通过预设算法生成 互相关联的多个数据块， 最终将携带所述第一 MAC 的所述多个数据块逐步发送给所述目 标待升级车载设备。 即本发明实施例不同于上述发明实施例， 车载控制设备需要对多个子 升级文件进行转码之前进行加密， 保证多个子升级文件的私密性， 然后再对加密后的子升 级文件进行转码。
在一种可能的实现方式中， 所述目标升级文件包括多个子升级文件， 所述多个子升级 文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成的所述多个数据 块的第二数字签名， 所述第四密钥为非对称密钥； 所述车载控制设备对所述多个数据块的 第二数字签名进行校验；所述车载控制设备利用第五密钥生成所述多个数据块的第二 MAC 所述第五密钥为对称算法密钥； 所述车载控制设备将携带所述第二 MAC 的所述多个数据 块逐步发送给所述目标待升级车载设备。 即关于车载升级包的分块传输及签名， 可以是在 升级开发者侧完成， 即车载控制设备获取到的是已经经过预设算法分块且签名的数据块， 此时车载设备需要先分块校验其合法性， 再将校验了合法性之后的数据块重新做 MAC 处 理， 由于针对 MAC 的校验相较于签名的计算量和计算复杂度会大大减小， 因此， 可以在 保证车载升级文件在车载内传输过程中的合法性的同时， 又可以减少待升级车载设备的计 算量和计算复杂度， 实现了车载设备安全高效的升级。
在上述步骤 S504中： 目标待升级车载设备接收车载控制设备发送的目标升级文件， 该 目标升级文件为通过车载控制设备安全验证的且至少用于对所述目标待升级车载设备进行 升级的升级文件。 具体地， 该过程属于车载包在车内的安全传输过程。
在上述步骤 S505中： 目标待升级车载设备利用目标升级文件进行安全升级。在一种可 能的实现方式中， 当待升级车载设备为资源存储能力和 /或处理能力超过预设值的或者预先 指定的第一待升级车载设备，例如处理能力或者存储能力较强的强设备，或者指定的设备。 则该目标待升级车载设备采用 A/B系统更新 （A/B System Updates)升级模式， 即目标待升 级车载设备有 A区和 B区， 待升级程序（固件或软件)运行于 A区， 新的升级程序则写入 B 区，升级完成后再切换到 B去执行，不影响车载升级过程中， 旧版系统的正常运行。例如， 强或关键设备采用 A/B系统更新升级方法； 弱设备借助 OTA Orchestrator充当备份点， 以 便在升级失败时回滚。 当升级成功后， 车载设备刪除升级包并通知 OTA Orchestrator, 后者 刪除升级包， 更新数据库并提示车主升级成功。 OTA Orchestrator也可以选择通知升级服务 器。 另外， OTA Orchestrator还可以选择让目标待升级车载设备做 remote attestation, 证明 升级成功。
在一种可能的实现方式中， 所述目标待升级车载设备逐步接收所述车载控制设备发送 的携带第一 MAC 的多个数据块， 所述多个数据块为将所述多个子升级文件通过预设算法 生成的互相关联的多个数据块， 所述第一 MAC 为利用第二密钥生成的所述多个数据块的 消息认证码， 所述第二密钥为对称密钥， 即第二密钥为共享密钥。 即在目标待升级设备和 车载控制设备之间， 只需要经过简单的对称密钥进行真实性的验证即可。 减少了目标待升 级设备的运算复杂度和运算量，如此一来， 即使是计算能力较弱或者存储空间较小的 "弱" 待升级车载设备， 也可以因为只需要较小的运算量和较小的运算复杂度， 进行安全高效的 升级。
在一种可能的实现方式中， 所述目标待升级车载设备根据所述预设算法， 利用所述第 二密钥逐步验证所述多个数据块； 当所述多个数据块均验证通过， 所述目标待升级车载设 备将逐步验证通过后的所述多个数据块进行合并升级。 即目标待升级设备需要在接收到车 载控制设备发送的经过第二密钥和预设算法转码的多个子升级文件后， 利用第二密钥校验 上述第一 MAC, 并利用预设算法生成的相互关联的数据块的特性， 对多个数据块进行关联 值的校验。 待所有数据块均解码验证通过后， 即确定所有的数据块都验证通过， 才确定将 该多个子升级文件进行完整的合并升级。
在一种可能的实现方式中， 所述多个子升级文件经过第三秘钥加密； 当所述多个数据 块均验证通过， 所述目标待升级车载设备将逐步验证通过后的所述多个数据块分別利用所 述第三密钥进行解密； 所述目标待升级车载设备将利用所述第三密钥进行解密后的所述多 个数据块进行合并升级。 即本发明实施例不同于上述发明实施例， 目标待升级车载设备需 要对加密并转码后的子升级文件进行验证后， 再对多个验证通过的子升级文件进行解密， 解密成功后， 在一起进行合并升级。
在一种可能的实现方式中， 所述目标升级文件包括多个子升级文件； 所述目标待升级 车载设备逐步接收所述车载控制设备发送的携带第二 MAC 的多个数据块， 所述多个数据 块为将所述多个子升级文件通过预设算法生成互相关联的多个数据块， 所述第二 MAC 为 利用第五密钥生成的所述多个数据块的消息认证码， 所述第五密钥为对称算法。 所述目标 待升级车载设备根据所述预设算法， 并利用所述第五密钥逐步验证所述多个数据块； 当所 述多个数据块均验证通过， 所述目标待升级车载设备将逐步验证通过后的所述多个数据块 进行合并升级。 即关于车载升级包的分块传输及签名， 可以是在升级开发者侧完成， 即车 载控制设备获取到的是已经经过预设算法分块且签名的数据块， 此时车载设备需要先分块 校验其合法性， 再将校验了合法性之后的数据块重新做 MAC处理， 由于针对 MAC的校验 相较于签名的计算量和计算复杂度会大大减小， 因此， 可以在保证车载升级文件在车载内 传输过程中的合法性的同时， 又可以减少待升级车载设备的计算量和计算复杂度， 实现了 车载设备安全高效的升级。
进一步地， 在目标待升级车载设备进行升级操作的阶段。 若多个数据块中有目标数据 块在该目标待升级车载设备上未验证通过的数据块。 车载控制设备将目标数据块重新发送 给所述目标待升级车载设备， 即目标待升级车载设备从所述车载控制设备处重新获取目标 数据块。 在所有数据块均验证通过的情况下， 才会进行合并升级。 本发明实施例中由于将 目标升级文件划分为多个数据块， 因此可以在某个或者某几个数据块验证失败的情况下， 只需要重新下载该数据块， 而不需要重新下载整个目标升级文件， 节省开销， 提升升级效 率。 以下对上述实施例中的关于车载控制设备和目标待升级设备之间的真实性验证， 即车 载控制设备将车载升级包中的目标升级文件如何经过预设算法进行转码， 进行说明。
具体实施方式中， 当 OTA Orchestrator验证车载升级包的真实性后， 它将在适当的时机 开始该过程， 如停车状态， 或者 OTA Orchestrator 可选择再次征求车主确认升级， 0TA Orchestrator将执行对车载升级包进行分份和转码处理， 并将转码后的子升级文件逐步传送 给目标待升级车载设备。本申请提供三种互相独立的转码方法：基于 Hash Chain,基于 Hash Tree和基于 Bloom Filter方案。基于这三种转码方法的升级包车内传输过程如下， 首先， 假 设 OTA Orchestrator与目标待升级车载设备共享一个密钥 k。 该共享 可以是静态的， 也可 以是 OTA Orchestrator与目标待升级车载设备临时生成。
方法一： 基于 Hash Chain转码方法
1、 OTA Orchestrator把升级文件 M分割为 n份， 即 M M2, . . . , Mn；
2、 将 Mi, M2, . . . , M„組成一 Hash Chain如下， H(.)代表一 Cryptographic Hash Function: hn = H(Mn) i = H(Mi, hi+1)
h2= H(M2, h3)
3、 用共享密钥 k (第二密钥）， OTA Orchestrator计算 v = MAC(k, Mi||ver, h2)， 这里 MAC是一标准的消息认证码 Message Authentication Code, 即为第一 MAC；
4、 从第一份开始， OTA Orchestrator逐份将 Mi传送目标待升级车载设备。 对于第一份 OTA Orchestrator需传送 v, Mi, ver, h2; 对于余下的份 OTA Orchestrator只需传送 Mi和 hi+1；
5、 目标待升级车载设备用共享密钥 k逐份验证 Mi。 如某份验证失败， 目标待升级车 载设备可要求重传。 当收到并验证所有份后， 目标待升级车载设备将其合成完整的升级文 件 方法二： 基于 Hash Tree转码方法
1、 OTA Orchestrator把升级文件 M分割为 n份， 即 M M2, ... , Mn；
2、 将M1, M2, ..., Mn組成一 binary tree如图所示： 叶节点代表数据， 每个中间节点包 括根节点的值可由其子节点的值通过 hash得到， 如 = H(Mi||ver||M2), h5 = H(hi||h2) ;
3、 OTA Orchestrator用共享密钥 k (第二密钥）计算根节点值， 如图中例子 v = MAC(k, h5||h6), 即为第一 MAC ;
4、 从 M1和M2开始， OTA Orchestrator每次两份传送给目标待升级车载设备。 对于前 两份， OTA Orchestrator需传送 v， Mi||ver, M2, , h2, h6 ; 对于余下的份 OTA Orchestrator需传 送两份数据及其所对于的辅助验证数据。 在图例中， 和 M2的辅助验证数据是 h2, h6 ; M3和 M4的辅助验证数据是空， 因为通过 h2就可以验证 M3和 M4； M5和 M6的辅助验证数 据是 h4， 而 M7和 M8的辅助验证数据是空；
5、 目标待升级车载设备用共享密钥 k对每两份验证。 如某两份验证失败， 目标待升级 车载设备可要求重传。 当收到并验证所有份后， 目标待升级车载设备将其合成完整的升级 文件 M。 方法三： 基于 Bloom Filter转码方法
Bloom Filter是一个用来决定数据是否于某集合中存在的存储高效的数据结构。例如下： 设置一长为 £的数組 F (Bloom Filter), 起始每个单元设值为 0。 选取 t个 hash functions Hi, H2, ..., ¾， 每个 hash fimction是集合到 { 1, 2, £}的映射， 即映射该集合中的每个元素 到 { 1, 2, ..., £}中的某一任意值。 把集合中的某个元素 e加入到 Bloom filter的方法如下： 计 算 Hi(e)， 并修改 F中 (e)指向的位置为 1。 根据 F判断某个元素 e'是否在集合中的方法就 是计算 e'的所有 hash值， 当且仅当所有 hash值所指向的 F的位置均为 1， 才判断元素 e' 存在集合中。
用 Bloom filter来判断元素是否在集合有如下性质：
只要有一个该元素的 hash值所指明的 F中位置是 0，那么可以断定该元素不在集合中； 如果所有该元素的 hash值指明的位置是 1，虽可判断该元素在集合中，但存在 false positive, 并且 false positive的概率是（1 - e-1!)1, n是加入 Bloom Filter的元素的个数；
用来添加元素或判断某元素是否在集合中的时间都是常数。 基于 Bloom Filter转码的升级包车内传输过程如下：
1、 OTA Orchestrator把升级文件 M分割为 n份， 即 M M2, ... , Mn；
2、 OTA Orchestrator设置一 Bloom filter F并加入 M M2, . . Mr^'j F c 利用共享密钥 k (第二密钥） 计算 v = MAC(k, F)， 即为第二 MAC ;
3、 传送 F和 v给目标待升级车载设备， 并逐份传送 Mi ;
4、 目标待升级车载设备先用共享密钥用 k验证 F， 如验证失败， 可要求重传 F和v。 当收到每份 Mi时， 判断其是否存在 F中， 如不在， 则要求重传 Mi。 最后将所有收到的 M M2, ... , Mn合成完整的升级文件 M。
针对上述三种方式， 是假设车内通信无需保护升级文件的私密性 (confidentiality；)。如果 要同时保护升级文件的私密性，那么 OTA Orchestrator需要先把每份 Mi加密获得密文 Ci(即 利用本申请中的第三密钥加密）， 然后在上述基于 Hash Chain, 基于 Hash Tree, 基于 Bloom Filter的方法中将 Ci替代 Mb 即上述提到的利用第三密钥进行加密。 在目标待升级车载设 备收到每份后， 在验证真实性后解密 Ci获得 Mi。 值得注意的是加密的密钥和在 MAC中用 的密钥最好不同。 例如， 如果共享 k足够长， 可分成两个不同密钥； 否则可用 k通过 key derivation function生成两个密钥。
以上三种 OTA Orchestrator将升级文件分段并转码的一个好处是目标待升级车载设备 无需验证数字签名， 只需进行对称密码操作即计算 MAC和 Hash。 并且， 对称密码操作比 公钥密码操作要高效的多。 此外， 因为待升级车载设备可以分段验证各段的合法性， 因此 可及时检验出非法或出错段，从而请求 OTA Orchestrator重发该段， 而无需重发整个升级文 件。 如果不进行分段转码， 只是进行常规转码即将数字签名转换成 MAC, 则目标待升级车 载设备无法精确定位出错位置， 需请求 OTA Orchestrator重发整个升级文件。 因此本发明实 施例，不仅可以精确定位出错位置，还可以减少车载内待升级设备的计算量和计算复杂度， 使得待升级车载设备可以安全高效的进行升级。 以上是 OTA Orchestrator将升级文件分份。在另一种实施例中， 分份可由升级包开发者 进行。 具体的， 以 hash chain方法为例：
1、 升级包开发者把升级文件 M分割为 n份， 即 M Μ2, ..., Mn;
2、 将 Mi, M2, M„組成一 Hash Chain如下， H(.)代表一 Cryptographic Hash Function: hn = H(Mn)
i = H(Mi, hi+1)
h2= H(M2, h3)
3、 用签名私钥计算 o=SignD(M||ver, h2)， 该签名即为本申请中的第二数字签名， 签名 私钥即为第四密钥；
4、 将 [M,ver, σ]作为升级包， 交给升级服务器发布。 可选的， 上述 M Μ2, ..., Μη还可 以经过加密， 以保证车载升级包的私密性， 可以参照前述关于加密并保证升级文件的私密 性的相关描述， 在此不再贅述。
当 OTA Orchestrator需从升级服务器获取升级包时，从第一份开始，升级服务器逐段将 Mi传送目标待升级车载设备。对于第一份升级服务器需传送 σ, Mi, ver, h2; 对于余下的份升 级服务器只需传送 Mi和 hi+1；
对于第一份 , OTA Orchestrator需验证数字签名 σ；对于余下的份 Mb OTA Orchestrator 只需验证 hi = H(Mi, hi+i) ;
当收到并验证所有份后， OTA Orchestrator做转码如上所述即用共享密钥 k (即为本申 请中的第五密钥）， 计算 V = MAC(k, M lver, h2)， 该 MAC即为第二 MAC。 后续的升级包 车内传输， 升级与确认过程与上述方法一、 方法二、 方法三的完全相同。 并且， 另外两种 方法基于 Hash Tree, 基于 Bloom Filter的转码方式可以结合此发明实施例并结合上述方法 二和方法三， 在此不再贅述。
在本发明实施例中， 当车载升级包在车载控制设备中完成了真实性的验证之后 （可选 的， 也可以在进行真实性验证之前经过私密性验证）， 车载控制设备需要将经过真实性验证 (可选的也可以包括私密性验证） 之后的多个升级文件， 在车载系统内传输给对应的待升 级车载设备。 由于传输的发送方和接收方发生了变化， 即由车载升级包在车外的传输转变 为车载升级包在车内的传输。所以需要重新进行真实性的验证，甚至私密性的验证。并且， 本发明实施例将计算量大、 计算复杂度大的签名认证， 放在车载控制设备侧完成， 而将计 算量小以及计算复杂度小的 MAC认证， 保留在待升级车载设备上完成， 不仅可以保证车 载升级过程中， 车内车外的安全性， 而且还可以保证能力较弱的待升级车载设备升级的高 效性。 基于上述， 可以理解， 在本申请中提供了以下几个关键技术点。
首先， 是车载升级包的真实性 （Authenticity) : 待升级车载设备检验升级包的真实性。 为了保障升级包的真实性， 升级包应由开发者或升级服务器 (package server)提供数字签名。 当升级包抵达 OTA Orchestrator时，由 OTA Orchestrator帮助待升级车载设备验证数字签名。 然后 OTA Orchestrator进行转码操作 (Transcoding)， 该转码操作使用对称密码机制来为待升 级车载设备提供升级包的真实性验证。假设 OTA Orchestrator和每一个待升级车载设备共享 一个密钥。该密钥可由 OTA Orchestrator事先分发，具体的分发过程并不在本申请的范围内。 转码 (Transcoding) 操作会把升级包分成多份， 并按份传输到待升级车载设备。 具体地， 提 出基于 Hash Chain, Hash Tree和 Bloom Filter三种转码操作。 基于分份的转码操作及按份 传输技术的优点是： 充分考虑车载设备计算能力有限和车内通信网络带宽有限的事实。 它 可以使车载设备在升级包传输错误后， 尽快找出传输错误的子份， 从而只请求重发出错的 份而不是整个升级包。
其次， 是车载升级包的私密性 （Confidentiality) : 攻击者可能会利用逆向工程技术分析 升级包的内容， 因此应保护车载升级包的私密性。 下面分两种情况提出保护方案：
a. 如果升级包在升级服务器上是不加密的， 那么车载 Telematics在获取升级包时， 升 级服务器应对车载 Telematics进行身份验证并建立一个安全通道， 从而在安全通道内发送 升级包；
b. 如果升级包在升级服务器上是加密的（用一个对称密钥加密）， 那么车载 Telematics 应从另一个密钥服务器获取该加密密钥， 其他步骤同 a。
最终， 基于能力的升级策略： 不同的车载设备的计算能力和内存资源是不同的， 例如 车载 Telematics, Gateway和 VCU通常比较强的， 而多数车载设备 （ECU) 处理能力较弱。 因此提出基于能力的升级策略， 即资源强或关键设备应采用 A/B系统更新升级模式， 而资 源限弱设备可借助 OTA Orchestrator的帮助， 实现待升级车载设备旧版固件或软件的备份， 以便在升级失败时回滚。 上述详细阐述了本发明实施例的方法， 下面提供了本发明实施例的相关装置。
请参见图 6， 图 6是本发明实施例提供的一种车载升级装置的结构示意图， 该车载升 级装置应用于车载系统， 所述车载系统包括车载控制设备和一个或多个待升级车载设备， 该车载升级装置 10可以为上述系统中的车载控制设备， 装置 10可以包括升级包获取单元 101、 升级管理单元 102和升级传输单元 103， 其中， 各个单元的详细描述如下。
升级包获取单元 101， 用于获取车载升级包， 所述车载升级包包括多个升级文件， 且 每一个升级文件用于对至少一个待升级车载设备进行升级；
升级管理单元 102， 用于对所述多个升级文件进行安全验证；
升级传输单元 103， 将目标升级文件发送给使用所述目标升级文件进行升级的目标待 升级车载设备， 所述目标升级文件为所述多个升级文件中通过安全验证的升级文件。
在一种可能的实现方式中， 所述车载升级包包括第一数字签名； 升级管理单元， 具体 用于： 使用所述第一数字签名对所述多个升级文件进行数字签名验证。
在一种可能的实现方式中， 装置 10还包括：
身份验证单元， 用于向所述升级服务器发送身份验证信息；
通道建立单元， 用于若所述身份验证信息在所述升级服务器中验证通过， 所述车载控 制设备与所述升级服务器之间建立安全通道；
所述升级包获取单元， 具体用于： 通过所述安全通道从所述升级服务器获取所述车载 升级包。
在一种可能的实现方式中， 所述车载升级包经过第一密钥加密， 所述第一密钥为对称 密钥； 所述装置还包括：
密钥获取单元， 用于从密钥服务器处获取所述第一密钥；
装置 10还包括：
解密单元， 用于使用所述第一数字签名对所述多个升级文件进行数字签名验证之后， 若所述数字签名验证通过， 所述车载控制设备利用所述第一密钥对所述多个升级文件进行 解密。
在一种可能的实现方式中， 升级传输单元 103， 具体用于：
将所述目标升级文件划分为多个子升级文件； 将所述多个子升级文件通过预设算法生 成互相关联的多个数据块， 并利用第二密钥生成所述多个数据块的第一消息认证码 MAC, 所述第二密钥为对称算法密钥； 将携带所述第一 MAC 的所述多个数据块逐步发送给所述 目标待升级车载设备。
在一种可能的实现方式中， 装置 10还包括：
加密单元， 用于对所述多个子升级文件分別利用第三密钥加密；
升级传输单元 103， 具体用于： 将所述目标升级文件划分为多个子升级文件； 所述车载控制设备将所述利用第三密钥 加密后的所述多个子升级文件， 通过预设算法生成互相关联的多个数据块， 并利用第二密 钥生成所述多个数据块的第一消息认证码 MAC, 所述第二密钥为对称算法密钥；将携带所 述第一 MAC的所述多个数据块逐步发送给所述目标待升级车载设备。
在一种可能的实现方式中， 所述目标升级文件包括多个子升级文件， 所述多个子升级 文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成的所述多个数据 块的第二数字签名， 所述第四密钥为非对称密钥；
升级管理单元 102， 具体用于： 所述车载控制设备对所述多个数据块的第二数字签名 进行校验；
升级传输单元 103， 具体用于： 利用第五密钥生成所述多个数据块的第二 MAC, 所述 第五密钥为对称算法密钥； 将携带所述第二 MAC 的所述多个数据块逐步发送给所述目标 待升级车载设备。
在一种可能的实现方式中，所述预设算法包括 Hash Chain算法、 Hash Tree算法、 Bloom Filter算法中的任意一种。
在一种可能的实现方式中， 装置 10还包括：
重传单元， 用于将目标数据块重新发送给所述目标待升级车载设备， 所述目标数据块 为所述多个数据块中在所述目标待升级车载设备上未验证通过的数据块。
需要说明的是，本发明实施例中所描述的车载升级装置 10中各功能单元的功能可参见 上述图 1-图 6所述的方法实施例的相关描述， 此处不再贅述。 请参见图 7， 图 7是本发明实施例提供的一种待升级车载装置的结构示意图， 该待升 级车载装置 20应用于车载系统，所述车载系统包括车载控制设备和一个或多个待升级车载 设备， 该待升级车载装置 20可以为上述系统中的待升级车载设备， 装置 20可以包括接收 单元， 201和升级单元 202， 其中， 各个单元的详细描述如下。
接收单元 201， 用于接收车载控制设备发送的目标升级文件， 所述目标升级文件为通 过所述车载控制设备安全验证的且至少用于对所述目标待升级车载设备进行升级的升级文 件；
升级单元 202， 用于利用所述目标升级文件进行安全升级。
在一种可能的实现方式中， 升级单元 202， 具体用于：
采用 A/B系统更新升级模式， 并利用所述目标升级文件进行安全升级， 所述待升级车 载设备为资源存储能力和 /或处理能力超过预设值的或者预先指定的第一待升级车载设备； 在一种可能的实现方式中，所述目标升级文件包括多个子升级文件；所述接收单元 201， 具体用于：
逐步接收所述车载控制设备发送的携带第一 MAC 的多个数据块， 所述多个数据块为 将所述多个子升级文件通过预设算法生成的互相关联的多个数据块， 所述第一 MAC 为利 用第二密钥生成的所述多个数据块的消息认证码， 所述第二密钥为对称密钥；
所述升级单元 202， 具体用于：
根据所述预设算法， 利用所述第二密钥逐步验证所述多个数据块； 当所述多个数据块 均验证通过， 将逐步验证通过后的所述多个数据块进行合并升级。
在一种可能的实现方式中， 所述多个子升级文件经过第三秘钥加密；
升级单元 202， 具体用于：
根据所述预设算法， 利用所述第二密钥逐步验证所述多个数据块； 当所述多个数据块 均验证通过， 将逐步验证通过后的所述多个数据块分別利用所述第三密钥进行解密； 将利 用所述第三密钥进行解密后的所述多个数据块进行合并升级。
在一种可能的实现方式中， 接收单元 201， 具体用于：
逐步接收所述车载控制设备发送的携带第二 MAC 的多个数据块， 所述多个数据块为 将所述多个子升级文件通过预设算法生成互相关联的多个数据块， 所述第二 MAC 为利用 第五密钥生成的所述多个数据块的消息认证码， 所述第五密钥为对称算法；
升级单元 202， 具体用于：
根据所述预设算法， 并利用所述第五密钥逐步验证所述多个数据块； 当所述多个数据 块均验证通过， 将逐步验证通过后的所述多个数据块进行合并升级。
在一种可能的实现方式中， 装置 20还包括：
重传单元， 用于从所述车载控制设备处重新获取目标数据块， 所述目标数据块为所述 多个数据块中在所述目标待升级车载设备上未验证通过的数据块。
需要说明的是，本发明实施例中所描述的待升级车载装置 20中各功能单元的功能可参 见上述图 1-图 6所述的方法实施例的相关描述， 此处不再贅述。 如图 8所示， 图 8是本发明实施例提供的一种设备的结构示意图。 待升级车载装置 10 和待升级车载装置 20，均可以以图 8中的结构来实现，该设备 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中存储的应用程序代码。 图 8所示的设备为车载设备升级装置 10时，存储器 302存储的代码可执行以上图 2提 供的车载设备升级方法， 比如获取车载升级包， 所述车载升级包包括多个升级文件， 且每 一个升级文件用于对至少一个待升级车载设备进行升级； 对所述多个升级文件进行安全验 证； 将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备， 所述 目标升级文件为所述多个升级文件中通过安全验证的升级文件。
需要说明的是，本发明实施例中所描述的车载设备升级装置 10中各功能单元的功能可 参见上述图 5中所述的方法实施例中的步骤 S502-步骤 S503相关描述， 此处不再贅述。
图 8所示的设备为待升级车载装置 20时，存储器 302存储的代码可执行以上图 9提供 的车载设备升级方法， 比如接收车载控制设备发送的目标升级文件， 所述目标升级文件为 通过所述车载控制设备安全验证的且至少用于对所述目标待升级车载设备进行升级的升级 文件； 利用所述目标升级文件进行安全升级。
需要说明的是，本发明实施例中所描述的待升级车载装置 20中各功能单元的功能可参 见上述图 5中所述的方法实施例中的步骤 S504-步骤 S505相关描述， 此处不再贅述。 如图 9所示， 图 9是本发明实施例提供的一种智能车辆的结构示意图。 该智能车辆 40 包括车载控制设备 401和至少一个待升级车载设备 402。 其中
车载设备 401， 用于获取车载升级包， 对所述车载升级包中的多个升级文件进行安全 验证， 并将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备， 其中， 每一个升级文件用于对至少一个待升级车载设备进行升级， 所述目标升级文件为所 述多个升级文件中通过安全验证的升级文件；
待升级车载设备 402， 用于接收车载控制设备发送的目标升级文件， 并利用所述目标 升级文件进行安全升级， 所述待升级车载设备为所述目标待升级车载设备。
在一种可能的实现方式中， 车载控制设备 401， 具体用于： 使用所述第一数字签名对 所述多个升级文件进行数字签名验证。
在一种可能的实现方式中， 车载控制设备 401， 具体用于：
向所述升级服务器发送身份验证信息， 若所述身份验证信息在所述升级服务器中验证 通过， 与所述升级服务器之间建立安全通道， 并通过所述安全通道从所述升级服务器获取 所述车载升级包； 或者
所述车载升级包经过第一密钥加密， 所述第一密钥为对称密钥； 车载控制设备 401， 具体用于：
从密钥服务器处获取所述第一密钥， 并在使用所述第一数字签名对所述多个升级文件 进行数字签名验证通过之后， 利用所述第一密钥对所述多个升级文件进行解密。
在一种可能的实现方式中， 车载控制设备 401， 具体用于：
将所述目标升级文件划分为多个子升级文件， 并通过预设算法生成互相关联的多个数 据块，利用第二密钥生成所述多个数据块的第一消息认证码 MAC,再将携带所述第一 MAC 的所述多个数据块逐步发送给所述目标待升级车载设备， 所述第二密钥为对称算法密钥； 待升级车载设备 402， 具体用于：
逐步接收所述车载控制设备发送的携带第一 MAC 的多个数据块， 并根据所述预设算 法， 利用所述第二密钥逐步验证所述多个数据块， 当所述多个数据块均验证通过， 将逐步 验证通过后的所述多个数据块进行合并升级。
在一种可能的实现方式中， 车载控制设备 401， 具体用于：
对所述多个子升级文件分別利用第三密钥加密， 将所述利用第三密钥加密后的所述多 个子升级文件， 通过预设算法生成互相关联的多个数据块；
待升级车载设备 402， 具体用于：
当所述多个数据块均验证通过， 将逐步验证通过后的所述多个数据块分別利用所述第 三密钥进行解密， 再将利用所述第三密钥进行解密后的所述多个数据块进行合并升级。
在一种可能的实现方式中， 所述目标升级文件包括多个子升级文件， 所述多个子升级 文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成的所述多个数据 块的第二数字签名， 所述第四密钥为非对称密钥；
车载控制设备 401， 具体用于：
对所述多个数据块的第二数字签名进行校验， 利用第五密钥生成所述多个数据块的第 二 MAC, 将携带所述第二 MAC的所述多个数据块逐步发送给所述目标待升级车载设备。 所述第五密钥为对称算法密钥；
待升级车载设备 402， 具体用于：
逐步接收所述车载控制设备发送的携带第二 MAC 的多个数据块， 并根据所述预设算 法， 利用所述第五密钥逐步验证所述多个数据块， 当所述多个数据块均验证通过， 将逐步 验证通过后的所述多个数据块进行合并升级。
需要说明的是，本发明实施例中所描述的智能车辆 40中的车载控制设备 401和待升级 车载设备 402可参见上述图 5中所述的方法实施例中的车载控制设备和待升级车载设备相 关描述， 此处不再贅述。
可以理解的是， 智能车辆 40还可以运用计算机、 现代传感、 信息融合、 通讯、 人工智 能及自动控制等技术， 集成智能驾驶系统、 生活服务系统、 安全防护系统、 位置服务系统 以及用车服务系统等功能， 本申请对此不作具体限定， 也不再贅述。 本发明实施例还提供一种计算机存储介质， 其中， 该计算机存储介质可存储有程序， 该程序执行时包括上述方法实施例中记载的任意一种的部分或全部步骤。
本发明实施例还提供一种计算机程序， 该计算机程序包括指令， 当该计算机程序被计 算机执行时， 使得计算机可以执行任意一种车载设备升级方法的部分或全部步骤。
在上述实施例中， 对各个实施例的描述都各有侧重， 某个实施例中没有详述的部分， 可以参见其他实施例的相关描述。
需要说明的是， 对于前述的各方法实施例， 为了简单描述， 故将其都表述为一系列的 动作組合， 但是本领域技术人员应该知悉， 本申请并不受所描述的动作顺序的限制， 因为 依据本申请， 某些步骤可能可以采用其他顺序或者同时进行。 其次， 本领域技术人员也应 该知悉， 说明书中所描述的实施例均属于优选实施例， 所涉及的动作和模块并不一定是本 申请所必须的。
在本申请所提供的几个实施例中， 应该理解到， 所揭露的装置， 可通过其它的方式实 现。 例如， 以上所描述的装置实施例仅仅是示意性的， 例如上述单元的划分， 仅仅为一种 逻辑功能划分， 实际实现时可以有另外的划分方式， 例如多个单元或組件可以结合或者可 以集成到另一个系统， 或一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之 间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接， 可以是电性或其它的形式。
上述作为分离部件说明的单元可以是或者也可以不是物理上分开的， 作为单元显示的 部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者也可以分布到多个网络 单元上。 可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外， 在本申请各实施例中的各功能单元可以集成在一个处理单元中， 也可以是各个 单元单独物理存在， 也可以两个或两个以上单元集成在一个单元中。 上述集成的单元既可 以采用硬件的形式实现， 也可以采用软件功能单元的形式实现。
上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时， 可 以存储在一个计算机可读取存储介质中。 基于这样的理解， 本申请的技术方案本质上或者 说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出 来，该计算机软件产品存储在一个存储介质中， 包括若干指令用以使得一台计算机设备（可 以为个人计算机、 服务器或者网络设备等， 具体可以是计算机设备中的处理器） 执行本申 请各个实施例上述方法的全部或部分步骤。 其中， 而前述的存储介质可包括： U 盘、 移动 硬盘、 磁碟、 光盘、 只读存储器 （Read-Only Memory, 縮写： ROM) 或者随机存取存储器 (Random Access Memory, 縮写： RAM) 等各种可以存储程序代码的介质。
以上所述， 以上实施例仅用以说明本申请的技术方案， 而非对其限制； 尽管参照前述 实施例对本申请进行了详细的说明， 本领域的普通技术人员应当理解： 其依然可以对前述 各实施例所记载的技术方案进行修改， 或者对其中部分技术特征进行等同替换； 而这些修 改或者替换， 并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims

权利要求
1、 一种车载设备升级方法， 应用于车载系统， 其特征在于， 所述车载系统包括车载控 制设备和一个或多个待升级车载设备， 所述方法包括：
所述车载控制设备获取车载升级包， 所述车载升级包包括多个升级文件， 且每一个升 级文件用于对至少一个待升级车载设备进行升级；
所述车载控制设备对所述多个升级文件进行安全验证；
所述车载控制设备将目标升级文件发送给使用所述目标升级文件进行升级的目标待升 级车载设备， 所述目标升级文件为所述多个升级文件中通过安全验证的升级文件。
2、 根据权利要求 1所述的方法， 其特征在于， 所述车载升级包包括第一数字签名； 所 述车载控制设备对所述多个升级文件进行安全验证， 包括：
所述车载控制设备使用所述第一数字签名对所述多个升级文件进行数字签名验证。
3、 根据权利要求 2所述的方法， 其特征在于， 所述方法还包括：
所述车载控制设备向升级服务器发送身份验证信息；
若所述身份验证信息在所述升级服务器中验证通过， 所述车载控制设备与所述升级服 务器之间建立安全通道；
所述车载控制设备获取车载升级包， 包括：
所述车载控制设备通过所述安全通道从所述升级服务器获取所述车载升级包。
4、 根据权利要求 2所述的方法， 其特征在于， 所述车载升级包经过第一密钥加密， 所 述第一密钥为对称密钥； 所述方法还包括： 所述车载控制设备从密钥服务器处获取所述第 一密钥；
所述车载控制设备使用所述第一数字签名对所述多个升级文件进行数字签名验证之后 包括：
若所述数字签名验证通过， 所述车载控制设备利用所述第一密钥对所述多个升级文件 进行解密。
5、 根据权利要求 1-4任意一项所述的方法， 其特征在于， 所述车载控制设备将目标升 级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备， 包括：
所述车载控制设备将所述目标升级文件划分为多个子升级文件；
所述车载控制设备将所述多个子升级文件通过预设算法生成互相关联的多个数据块， 并利用第二密钥生成所述多个数据块的第一消息认证码 MAC,所述第二密钥为对称算法密 钥；
所述车载控制设备将携带所述第一 MAC 的所述多个数据块逐步发送给所述目标待升 级车载设备。
6、 根据权利要求 5所述的方法， 其特征在于， 所述方法还包括：
所述车载控制设备对所述多个子升级文件分別利用第三密钥加密；
所述车载控制设备将所述多个子升级文件通过预设算法生成互相关联的多个数据块， 包括：
所述车载控制设备将所述利用第三密钥加密后的所述多个子升级文件， 通过预设算法 生成互相关联的多个数据块。
7、根据权利要求 1所述的方法，其特征在于，所述目标升级文件包括多个子升级文件， 所述多个子升级文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥生成 的所述多个数据块的第二数字签名， 所述第四密钥为非对称密钥；
所述车载控制设备对所述多个升级文件进行安全验证， 包括：
所述车载控制设备对所述多个数据块的第二数字签名进行校验；
所述车载控制设备将目标升级文件发送给使用所述目标升级文件进行升级的目标待升 级车载设备， 包括：
所述车载控制设备利用第五密钥生成所述多个数据块的第二 MAC，所述第五密钥为对 称算法密钥；
所述车载控制设备将携带所述第二 MAC 的所述多个数据块逐步发送给所述目标待升 级车载设备。
8、根据权利要求 5-7任意一项所述的方法，其特征在于，所述预设算法包括 Hash Chain 算法、 Hash Tree算法、 Bloom Filter算法中的任意一种。
9、 根据权利要求 5-8任意一项所述的方法， 其特征在于， 所述方法还包括： 所述车载控制设备将目标数据块重新发送给所述目标待升级车载设备， 所述目标数据 块为所述多个数据块中在所述目标待升级车载设备上未验证通过的数据块。
10、 一种智能车辆， 其特征在于， 所述智能车辆， 包括： 车载控制设备和至少一个待 升级车载设备； 其中
所述车载设备用于， 获取车载升级包， 对所述车载升级包中的多个升级文件进行安全 验证， 并将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级车载设备， 其中， 每一个升级文件用于对至少一个待升级车载设备进行升级， 所述目标升级文件为所 述多个升级文件中通过安全验证的升级文件；
待升级车载设备， 用于接收车载控制设备发送的目标升级文件， 并利用所述目标升级 文件进行安全升级， 所述待升级车载设备为所述目标待升级车载设备。
11、 根据权利要求 10所述的智能车辆， 其特征在于， 所述车载控制设备， 具体用于： 使用所述第一数字签名对所述多个升级文件进行数字签名验证。
12、 根据权利要求 11所述的智能车辆， 其特征在于， 所述车载控制设备， 具体用于： 向所述升级服务器发送身份验证信息， 若所述身份验证信息在所述升级服务器中验证 通过， 与所述升级服务器之间建立安全通道， 并通过所述安全通道从所述升级服务器获取 所述车载升级包； 或者
所述车载升级包经过第一密钥加密， 所述第一密钥为对称密钥； 所述车载控制设备， 具体用于：
从密钥服务器处获取所述第一密钥， 并在使用所述第一数字签名对所述多个升级文件 进行数字签名验证通过之后， 利用所述第一密钥对所述多个升级文件进行解密。
13、根据权利要求 10-12任意一项所述的智能车辆， 其特征在于， 所述车载控制设备， 具体用于：
将所述目标升级文件划分为多个子升级文件， 并通过预设算法生成互相关联的多个数 据块，利用第二密钥生成所述多个数据块的第一消息认证码 MAC,再将携带所述第一 MAC 的所述多个数据块逐步发送给所述目标待升级车载设备， 所述第二密钥为对称算法密钥； 所述待升级车载设备， 具体用于：
逐步接收所述车载控制设备发送的携带第一 MAC 的多个数据块， 并根据所述预设算 法， 利用所述第二密钥逐步验证所述多个数据块， 当所述多个数据块均验证通过， 将逐步 验证通过后的所述多个数据块进行合并升级。
14、 根据权利要求 13所述的智能车辆， 其特征在于， 所述车载控制设备， 具体用于： 对所述多个子升级文件分別利用第三密钥加密， 将所述利用第三密钥加密后的所述多 个子升级文件， 通过预设算法生成互相关联的多个数据块；
所述待升级车载设备， 具体用于：
当所述多个数据块均验证通过， 将逐步验证通过后的所述多个数据块分別利用所述第 三密钥进行解密， 再将利用所述第三密钥进行解密后的所述多个数据块进行合并升级。
15、 根据权利要求 10所述的智能车辆， 其特征在于， 所述目标升级文件包括多个子升 级文件， 所述多个子升级文件通过预设算法生成互相关联的多个数据块， 且携带利用第四 密钥生成的所述多个数据块的第二数字签名， 所述第四密钥为非对称密钥；
所述车载控制设备， 具体用于：
对所述多个数据块的第二数字签名进行校验， 利用第五密钥生成所述多个数据块的第 二 MAC, 将携带所述第二 MAC的所述多个数据块逐步发送给所述目标待升级车载设备。 所述第五密钥为对称算法密钥；
所述待升级车载设备， 具体用于：
逐步接收所述车载控制设备发送的携带第二 MAC 的多个数据块， 并根据所述预设算 法， 利用所述第五密钥逐步验证所述多个数据块， 当所述多个数据块均验证通过， 将逐步 验证通过后的所述多个数据块进行合并升级。
16、 一种车载设备升级装置， 其特征在于， 应用于车载系统， 所述车载系统包括车载 控制设备和一个或多个待升级车载设备， 所述方法包括：
升级包获取单元， 用于从升级服务器获取车载升级包， 所述车载升级包包括多个升级 文件， 且每一个升级文件用于对至少一个待升级车载设备进行升级；
升级管理单元， 用于对所述多个升级文件进行安全验证；
升级传输单元， 将目标升级文件发送给使用所述目标升级文件进行升级的目标待升级 车载设备， 所述目标升级文件为所述多个升级文件中通过安全验证的升级文件。
17、 根据权利要求 16所述的装置， 其特征在于， 所述车载升级包包括第一数字签名； 升级管理单元，具体用于：使用所述第一数字签名对所述多个升级文件进行数字签名验证。
18、 根据权利要求 17所述的装置， 其特征在于， 所述装置还包括：
身份验证单元， 用于向所述升级服务器发送身份验证信息；
通道建立单元， 用于若所述身份验证信息在所述升级服务器中验证通过， 所述车载控 制设备与所述升级服务器之间建立安全通道；
所述升级包获取单元， 具体用于： 通过所述安全通道从所述升级服务器获取所述车载 升级包。
19、 根据权利要求 17所述的装置， 其特征在于， 所述车载升级包经过第一密钥加密， 所述第一密钥为对称密钥； 所述装置还包括：
密钥获取单元， 用于从密钥服务器处获取所述第一密钥；
所述装置还包括：
解密单元， 用于使用所述第一数字签名对所述多个升级文件进行数字签名验证之后， 若所述数字签名验证通过， 所述车载控制设备利用所述第一密钥对所述多个升级文件进行 解密。
20、 根据权利要求 16-19任意一项所述的装置， 其特征在于， 所述升级传输单元， 具 体用于：
将所述目标升级文件划分为多个子升级文件； 将所述多个子升级文件通过预设算法生 成互相关联的多个数据块， 并利用第二密钥生成所述多个数据块的第一消息认证码 MAC, 所述第二密钥为对称算法密钥； 将携带所述第一 MAC 的所述多个数据块逐步发送给所述 目标待升级车载设备。
21、 根据权利要求 20所述的装置， 其特征在于， 所述装置还包括：
加密单元， 用于对所述多个子升级文件分別利用第三密钥加密；
所述升级传输单元， 具体用于：
将所述目标升级文件划分为多个子升级文件； 所述车载控制设备将所述利用第三密钥 加密后的所述多个子升级文件， 通过预设算法生成互相关联的多个数据块， 并利用第二密 钥生成所述多个数据块的第一消息认证码 MAC, 所述第二密钥为对称算法密钥；将携带所 述第一 MAC的所述多个数据块逐步发送给所述目标待升级车载设备。
22、 根据权利要求 16所述的装置， 其特征在于， 所述目标升级文件包括多个子升级文 件， 所述多个子升级文件通过预设算法生成互相关联的多个数据块， 且携带利用第四密钥 生成的所述多个数据块的第二数字签名， 所述第四密钥为非对称密钥；
所述升级管理单元， 具体用于： 所述车载控制设备对所述多个数据块的第二数字签名 进行校验；
所述升级传输单元， 具体用于： 利用第五密钥生成所述多个数据块的第二 MAC, 所述 第五密钥为对称算法密钥； 将携带所述第二 MAC 的所述多个数据块逐步发送给所述目标 待升级车载设备。
PCT/SG2017/050530 2017-10-24 2017-10-24 一种车载设备升级方法及相关设备 WO2019083440A2 (zh)

Priority Applications (6)

Application Number Priority Date Filing Date Title
PCT/SG2017/050530 WO2019083440A2 (zh) 2017-10-24 2017-10-24 一种车载设备升级方法及相关设备
EP17929441.8A EP3690643B1 (en) 2017-10-24 2017-10-24 Vehicle-mounted device upgrading method and related device
JP2020523294A JP7139424B2 (ja) 2017-10-24 2017-10-24 車両搭載機器アップグレード方法および関連機器
CN201780096266.2A CN111279310B (zh) 2017-10-24 2017-10-24 一种车载设备升级方法及相关设备
EP22205812.5A EP4152144A1 (en) 2017-10-24 2017-10-24 Vehicle-mounted device upgrade method and related device
US16/856,897 US11662991B2 (en) 2017-10-24 2020-04-23 Vehicle-mounted device upgrade method and related device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2017/050530 WO2019083440A2 (zh) 2017-10-24 2017-10-24 一种车载设备升级方法及相关设备

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/856,897 Continuation US11662991B2 (en) 2017-10-24 2020-04-23 Vehicle-mounted device upgrade method and related device

Publications (2)

Publication Number Publication Date
WO2019083440A2 true WO2019083440A2 (zh) 2019-05-02
WO2019083440A3 WO2019083440A3 (zh) 2019-06-20

Family

ID=66246647

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2017/050530 WO2019083440A2 (zh) 2017-10-24 2017-10-24 一种车载设备升级方法及相关设备

Country Status (5)

Country Link
US (1) US11662991B2 (zh)
EP (2) EP4152144A1 (zh)
JP (1) JP7139424B2 (zh)
CN (1) CN111279310B (zh)
WO (1) WO2019083440A2 (zh)

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110597542A (zh) * 2019-09-17 2019-12-20 Oppo（重庆）智能科技有限公司 软件自动ota升级方法及装置、电子设备
CN110647341A (zh) * 2019-09-21 2020-01-03 深圳市英博超算科技有限公司 Ota升级方法、装置、车辆以及计算机可读存储介质
CN111651771A (zh) * 2020-06-08 2020-09-11 湖北阿桑奇汽车电子科技有限公司 一种安全fota使用方法
CN112134911A (zh) * 2019-06-25 2020-12-25 联合汽车电子有限公司 一种远程程序升级方法、装置和介质
CN112394966A (zh) * 2019-08-19 2021-02-23 云丁网络技术(北京)有限公司 设备升级方法、装置、计算机可读介质及设备
CN112534793A (zh) * 2020-02-14 2021-03-19 华为技术有限公司 一种车载设备升级方法及相关装置
CN113170003A (zh) * 2021-03-09 2021-07-23 华为技术有限公司 一种通过空中下载ota技术获取文件的方法及相关设备
CN113497719A (zh) * 2020-03-20 2021-10-12 广州汽车集团股份有限公司 面向服务的车载ecu软件升级方法及系统、相关设备
CN113630437A (zh) * 2021-06-25 2021-11-09 际络科技(上海)有限公司 车辆的控制单元升级方法、装置及车辆
CN113727299A (zh) * 2021-07-15 2021-11-30 江铃汽车股份有限公司 一种握手认证方法、装置、可读存储介质及车辆
CN113810446A (zh) * 2020-06-16 2021-12-17 上海赫千电子科技有限公司 一种车载网络的ecu的安全升级管理方法
CN114024732A (zh) * 2021-10-29 2022-02-08 百度在线网络技术（北京）有限公司 升级包下载方法、设备、存储介质及程序产品
CN114461240A (zh) * 2021-06-30 2022-05-10 荣耀终端有限公司 软件升级方法、软件升级系统及电子设备
WO2022140903A1 (zh) * 2020-12-28 2022-07-07 华为技术有限公司 一种ota升级方法及装置
CN115175171A (zh) * 2022-06-29 2022-10-11 智己汽车科技有限公司 车辆ota升级系统及车辆ota升级方法
US11662991B2 (en) 2017-10-24 2023-05-30 Huawei International Pte. Ltd. Vehicle-mounted device upgrade method and related device
AU2020352532B2 (en) * 2019-09-25 2023-06-01 Shift5, Inc. Passive monitoring and prevention of unauthorized firmware or software upgrades between computing devices
EP4086757A4 (en) * 2020-01-23 2023-06-21 Huawei Technologies Co., Ltd. SOFTWARE UPGRADE METHOD AND DEVICE
CN117097462A (zh) * 2023-07-06 2023-11-21 南京中科齐信科技有限公司 一种基于量子密钥体系的车载智能软件升级加密系统
CN117201193A (zh) * 2023-11-06 2023-12-08 新华三网络信息安全软件有限公司 病毒检测方法、装置、存储介质及电子设备

Families Citing this family (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102396049B1 (ko) * 2018-10-01 2022-05-10 엘지전자 주식회사 이동 its 스테이션 및 상기 이동 its 스테이션의 메시지 송수신 방법
KR20210151498A (ko) * 2020-06-05 2021-12-14 현대자동차주식회사 차량 업데이트 시스템 및 방법
CN111722861B (zh) * 2020-06-17 2023-03-10 中国第一汽车股份有限公司 一种应用程序升级方法、装置、设备及存储介质
JP7314867B2 (ja) * 2020-06-18 2023-07-26 トヨタ自動車株式会社 マスタ、ネットワークシステム、方法、プログラム、センタ、および車両
CN112188434A (zh) * 2020-09-21 2021-01-05 西安墨科通讯科技有限公司 Ota升级方法及系统
CN112740210B (zh) * 2020-09-30 2022-02-11 华为技术有限公司 验证车辆中电子设备软件安全性的方法及相关设备
CN112286552B (zh) * 2020-10-22 2024-04-02 百度在线网络技术（北京）有限公司 一种任务创建方法、装置、电子设备以及存储介质
CN112312358B (zh) * 2020-10-26 2023-04-18 潍柴动力股份有限公司 一种通信方法及车载终端
CN112231228A (zh) * 2020-11-06 2021-01-15 广州极飞科技有限公司 一种固件升级测试方法、装置、平台、设备及存储介质
CN114691346A (zh) * 2020-12-25 2022-07-01 华为技术有限公司 一种算力资源的配置方法及设备
CN112732293A (zh) * 2020-12-31 2021-04-30 青岛海信电子产业控股股份有限公司 一种车载系统的升级方法和车载终端
CN112883382B (zh) * 2021-03-03 2023-05-23 一汽解放汽车有限公司 一种车辆刷写的方法、车联网盒、车辆及存储介质
CN113114729A (zh) * 2021-03-22 2021-07-13 一汽奔腾轿车有限公司 一种用于ota可靠性的验证系统及方法
CN113110850B (zh) * 2021-05-12 2022-09-20 宝能(广州)汽车研究院有限公司 车辆升级方法、装置、设备、车辆及存储介质
CN113515747B (zh) * 2021-05-17 2024-02-09 深圳市友华通信技术有限公司 设备升级方法、装置、设备及存储介质
US11681811B1 (en) * 2021-06-25 2023-06-20 Northrop Grumman Systems Corporation Cybersecurity for configuration and software updates of vehicle hardware and software based on fleet level information
US11409866B1 (en) 2021-06-25 2022-08-09 Northrop Grumman Systems Corporation Adaptive cybersecurity for vehicles
CN113660317B (zh) * 2021-07-30 2023-07-04 江西五十铃汽车有限公司 一种基于ftp协议的车载终端远程升级方法
CN113760337A (zh) * 2021-09-14 2021-12-07 远峰科技股份有限公司 一种fota的升级回滚方法及升级回滚系统
CN113992660A (zh) * 2021-10-29 2022-01-28 维沃移动通信有限公司 文件传输方法、装置、电子设备及存储介质
CN114124701B (zh) * 2021-11-05 2024-01-26 交控科技股份有限公司 车载设备远程升级方法及系统
CN114143197B (zh) * 2021-11-29 2024-04-02 武汉天喻信息产业股份有限公司 物联网设备ota升级方法、装置、设备及可读存储介质
CN115242634B (zh) * 2022-07-05 2024-03-12 蔚来汽车科技(安徽)有限公司 软件升级方法、设备和存储介质
CN115390882A (zh) * 2022-10-25 2022-11-25 广州万协通信息技术有限公司 基于车联网的车载终端程序更新方法及装置
CN116185460A (zh) * 2023-04-26 2023-05-30 深圳市鼎盛科电子有限公司 一种嵌入式系统软件自动升级的方法及装置
CN116880878A (zh) * 2023-07-18 2023-10-13 上海正泰智能科技有限公司 一种升级方法、装置、设备及存储介质
CN117009992B (zh) * 2023-07-28 2024-04-16 广州汽车集团股份有限公司 升级包处理方法、装置、电子设备及存储介质
CN116723053B (zh) * 2023-08-07 2023-10-31 北京云驰未来科技有限公司 一种基于总线调试设备调试jtag的方法及系统
CN117193819B (zh) * 2023-09-07 2024-03-26 迈胜医疗设备有限公司 放射治疗系统、固件升级方法、设备及相关装置

Family Cites Families (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19842779A1 (de) * 1998-09-18 2000-03-23 Alcatel Sa Verfahren zum Laden von Daten und Software in einen Fahrzeugcomputer
US6947556B1 (en) * 2000-08-21 2005-09-20 International Business Machines Corporation Secure data storage and retrieval with key management and user authentication
JP2002144983A (ja) 2000-11-14 2002-05-22 Toyoda Mach Works Ltd 車両制御装置の制御ソフト変更装置及びその方法
AU2002220534A1 (en) 2000-12-07 2002-06-18 Cryptico A/S A method of performing mathematical operations in an electronic device, a method of generating pseudo-random numbers in an electronic device, and a method of encrypting and decrypting electronic data
JP2003202931A (ja) 2002-01-09 2003-07-18 Toshiba Corp ソフトウェアダウンロードシステム、サーバ装置、端末装置、サーバ制御プログラム、端末制御プログラム、サーバ制御方法、端末制御方法
US7096311B2 (en) * 2002-09-30 2006-08-22 Innopath Software, Inc. Updating electronic files using byte-level file differencing and updating algorithms
JP2005202503A (ja) * 2004-01-13 2005-07-28 Hitachi Ltd 車載情報装置、車載機器管理システム、車両の制御機器のプログラムのバージョンアップ情報の配信方法、車両の制御機器のプログラムのバージョンアップ方法及び車両の制御機器のプログラムのバージョンアップシステム
US7366589B2 (en) * 2004-05-13 2008-04-29 General Motors Corporation Method and system for remote reflash
US8832466B1 (en) 2006-01-27 2014-09-09 Trustwave Holdings, Inc. Methods for augmentation and interpretation of data objects
US8356178B2 (en) 2006-11-13 2013-01-15 Seagate Technology Llc Method and apparatus for authenticated data storage
US8189769B2 (en) 2007-07-31 2012-05-29 Apple Inc. Systems and methods for encrypting data
US8296584B2 (en) 2007-12-28 2012-10-23 Alcatel Lucent Storage and retrieval of encrypted data blocks with in-line message authentication codes
US20090300595A1 (en) 2008-05-30 2009-12-03 Ise Corporation System and Method for Remotely Updating Control Software in a Vehicle With an Electric Drive System
WO2010024379A1 (ja) 2008-08-29 2010-03-04 日本電気株式会社 通信システム、送信側及び受信又は転送側の通信装置、データ通信方法、データ通信プログラム
CN101373440B (zh) * 2008-10-09 2011-12-28 飞天诚信科技股份有限公司 一种固件升级数据处理方法和装置
US9464905B2 (en) 2010-06-25 2016-10-11 Toyota Motor Engineering & Manufacturing North America, Inc. Over-the-air vehicle systems updating and associate security protocols
CN102158544A (zh) 2011-02-25 2011-08-17 深圳市元征软件开发有限公司 车载电子装置的远程升级方法及装置
US8782441B1 (en) 2012-03-16 2014-07-15 Google Inc. Methods and systems for storage of large data objects
CN102930004B (zh) 2012-10-29 2015-07-08 华为技术有限公司 哈希值存储方法、装置及芯片
US9418072B2 (en) * 2013-03-04 2016-08-16 Vmware, Inc. Cross-file differential content synchronization
WO2014164893A2 (en) * 2013-03-13 2014-10-09 Arynga Inc. Remote transfer of electronic images to a vehicle
JP5864510B2 (ja) 2013-10-18 2016-02-17 富士通株式会社 修正プログラム確認方法、修正プログラム確認プログラム、及び情報処理装置
CN103559057B (zh) * 2013-11-06 2016-10-12 广东小天才科技有限公司 一种嵌入式系统加载启动方法及装置
KR101551206B1 (ko) 2013-12-13 2015-09-09 현대자동차주식회사 차량 데이터 제어 시스템 및 제어 방법
KR101527779B1 (ko) * 2014-01-13 2015-06-10 현대자동차주식회사 효율적인 차량용 리프로그래밍 장치 및 그 제어방법
KR101575447B1 (ko) * 2014-02-06 2015-12-07 현대자동차주식회사 차량의 소프트웨어 업데이트 방법
KR101551904B1 (ko) 2014-03-06 2015-09-09 재단법인 다차원 스마트 아이티 융합시스템 연구단 저장 공간을 절약하는 차량용 블랙박스의 제어방법
JP6407981B2 (ja) * 2014-05-08 2018-10-17 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 車載ネットワークシステム、電子制御ユニット及び不正対処方法
US10211990B2 (en) * 2014-07-25 2019-02-19 GM Global Technology Operations LLC Authenticating messages sent over a vehicle bus that include message authentication codes
US9984255B2 (en) * 2014-09-30 2018-05-29 Samsung Electronics Co., Ltd. Methods and apparatus to enable runtime checksum verification of block device images
DE102015209116A1 (de) * 2015-05-19 2016-11-24 Robert Bosch Gmbh Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
US10042635B2 (en) 2015-06-16 2018-08-07 Lear Corporation Method for wireless remote updating vehicle software
JP6345157B2 (ja) * 2015-06-29 2018-06-20 クラリオン株式会社 車載情報通信システム及び認証方法
JP6197000B2 (ja) 2015-07-03 2017-09-13 Kddi株式会社 システム、車両及びソフトウェア配布処理方法
WO2017030886A1 (en) * 2015-08-14 2017-02-23 Pcms Holding, Inc. Securely upgrading resource constrained devices
JP6675271B2 (ja) * 2015-09-14 2020-04-01 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ ゲートウェイ装置、車載ネットワークシステム及びファームウェア更新方法
DE102015220489A1 (de) * 2015-10-21 2017-04-27 Ford Global Technologies, Llc Verfahren zur Autorisierung einer Softwareaktualisierung in einem Kraftfahrzeug
US10437680B2 (en) * 2015-11-13 2019-10-08 Kabushiki Kaisha Toshiba Relay apparatus, relay method, and computer program product
CN105573790A (zh) * 2015-12-15 2016-05-11 上海博泰悦臻网络技术服务有限公司 一种车载系统软件升级方法、车载系统及软件服务器
US10114634B2 (en) * 2016-01-22 2018-10-30 2236008 Ontario Inc. Updating a controller unit in a vehicle
US20170242678A1 (en) * 2016-02-19 2017-08-24 Ford Global Technologies, Llc Method and apparatus for vehicle software update installation
CN106021462A (zh) * 2016-05-17 2016-10-12 深圳市中博科创信息技术有限公司 集群文件系统文件存储的方法及集群文件系统
US10078638B2 (en) * 2016-06-07 2018-09-18 Globalfoundries Inc. Secure hyper transfer of large files
CN106385420A (zh) * 2016-09-29 2017-02-08 中国联合网络通信集团有限公司 一种ecu软件下载方法及装置
CN106528125A (zh) * 2016-10-26 2017-03-22 腾讯科技（深圳）有限公司 一种数据文件的增量更新方法和服务器、客户端以及系统
CN106790053B (zh) * 2016-12-20 2019-08-27 江苏大学 一种can总线中ecu安全通信的方法
JP2019036238A (ja) * 2017-08-21 2019-03-07 株式会社東芝 更新制御装置、端末、更新制御方法およびプログラム
US10264399B2 (en) * 2017-09-01 2019-04-16 GM Global Technology Operations LLC Location-based vehicle wireless communications
WO2019083440A2 (zh) 2017-10-24 2019-05-02 华为国际有限公司 一种车载设备升级方法及相关设备
CN108337234B (zh) 2017-12-28 2021-03-23 宁德时代新能源科技股份有限公司 车载程序文件加密方法和装置
CN108200044B (zh) 2017-12-28 2021-02-19 宁德时代新能源科技股份有限公司 车载程序文件加密方法和系统
WO2019182509A1 (en) 2018-03-19 2019-09-26 Huawei International Pte. Ltd. Method and apparatus for updating devices in a remote network
EP3780481B1 (en) 2018-04-30 2024-02-14 Huawei International Pte. Ltd. Method for upgrading vehicle-mounted device, and related device

Cited By (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11662991B2 (en) 2017-10-24 2023-05-30 Huawei International Pte. Ltd. Vehicle-mounted device upgrade method and related device
CN112134911A (zh) * 2019-06-25 2020-12-25 联合汽车电子有限公司 一种远程程序升级方法、装置和介质
CN112394966A (zh) * 2019-08-19 2021-02-23 云丁网络技术(北京)有限公司 设备升级方法、装置、计算机可读介质及设备
CN110597542B (zh) * 2019-09-17 2023-01-31 Oppo（重庆）智能科技有限公司 软件自动ota升级方法及装置、电子设备
CN110597542A (zh) * 2019-09-17 2019-12-20 Oppo（重庆）智能科技有限公司 软件自动ota升级方法及装置、电子设备
CN110647341A (zh) * 2019-09-21 2020-01-03 深圳市英博超算科技有限公司 Ota升级方法、装置、车辆以及计算机可读存储介质
US11847224B2 (en) 2019-09-25 2023-12-19 Shift5, Inc. Passive monitoring and prevention of unauthorized firmware or software upgrades between computing devices
EP4034996A4 (en) * 2019-09-25 2023-07-05 Shift5, Inc. PASSIVE MONITORING AND PREVENTING UNAUTHORIZED FIRMWARE OR SOFTWARE UPGRADE BETWEEN COMPUTING DEVICES
AU2020352532B2 (en) * 2019-09-25 2023-06-01 Shift5, Inc. Passive monitoring and prevention of unauthorized firmware or software upgrades between computing devices
EP4086757A4 (en) * 2020-01-23 2023-06-21 Huawei Technologies Co., Ltd. SOFTWARE UPGRADE METHOD AND DEVICE
WO2021159530A1 (zh) * 2020-02-14 2021-08-19 华为技术有限公司 一种车载设备升级方法及相关装置
CN112534793A (zh) * 2020-02-14 2021-03-19 华为技术有限公司 一种车载设备升级方法及相关装置
JP7371103B2 (ja) 2020-02-14 2023-10-30 華為技術有限公司 車載デバイスアップグレード方法及び関連装置
EP3893108A4 (en) * 2020-02-14 2022-03-23 Huawei Technologies Co., Ltd. METHOD FOR UPGRADING ON-BOARD DEVICE AND ASSOCIATED APPARATUS
JP2022522607A (ja) * 2020-02-14 2022-04-20 華為技術有限公司 車載デバイスアップグレード方法及び関連装置
US11321074B2 (en) 2020-02-14 2022-05-03 Huawei Technologies Co., Ltd. Vehicle-mounted device upgrade method and related apparatus
CN113497719A (zh) * 2020-03-20 2021-10-12 广州汽车集团股份有限公司 面向服务的车载ecu软件升级方法及系统、相关设备
CN111651771A (zh) * 2020-06-08 2020-09-11 湖北阿桑奇汽车电子科技有限公司 一种安全fota使用方法
CN113810446A (zh) * 2020-06-16 2021-12-17 上海赫千电子科技有限公司 一种车载网络的ecu的安全升级管理方法
WO2022140903A1 (zh) * 2020-12-28 2022-07-07 华为技术有限公司 一种ota升级方法及装置
CN113170003A (zh) * 2021-03-09 2021-07-23 华为技术有限公司 一种通过空中下载ota技术获取文件的方法及相关设备
CN113630437A (zh) * 2021-06-25 2021-11-09 际络科技(上海)有限公司 车辆的控制单元升级方法、装置及车辆
CN114461240A (zh) * 2021-06-30 2022-05-10 荣耀终端有限公司 软件升级方法、软件升级系统及电子设备
CN113727299A (zh) * 2021-07-15 2021-11-30 江铃汽车股份有限公司 一种握手认证方法、装置、可读存储介质及车辆
CN113727299B (zh) * 2021-07-15 2024-03-08 江铃汽车股份有限公司 一种握手认证方法、装置、可读存储介质及车辆
CN114024732A (zh) * 2021-10-29 2022-02-08 百度在线网络技术（北京）有限公司 升级包下载方法、设备、存储介质及程序产品
CN115175171A (zh) * 2022-06-29 2022-10-11 智己汽车科技有限公司 车辆ota升级系统及车辆ota升级方法
CN117097462A (zh) * 2023-07-06 2023-11-21 南京中科齐信科技有限公司 一种基于量子密钥体系的车载智能软件升级加密系统
CN117201193A (zh) * 2023-11-06 2023-12-08 新华三网络信息安全软件有限公司 病毒检测方法、装置、存储介质及电子设备
CN117201193B (zh) * 2023-11-06 2024-01-26 新华三网络信息安全软件有限公司 病毒检测方法、装置、存储介质及电子设备

Also Published As

Publication number Publication date
EP4152144A1 (en) 2023-03-22
CN111279310B (zh) 2023-09-12
EP3690643A2 (en) 2020-08-05
WO2019083440A3 (zh) 2019-06-20
US20200264864A1 (en) 2020-08-20
EP3690643A4 (en) 2020-10-28
EP3690643B1 (en) 2023-01-25
US11662991B2 (en) 2023-05-30
JP2021500816A (ja) 2021-01-07
CN111279310A (zh) 2020-06-12
JP7139424B2 (ja) 2022-09-20

Similar Documents

Publication Publication Date Title
CN111279310B (zh) 一种车载设备升级方法及相关设备
US20210051000A1 (en) Vehicle-mounted device upgrade method and related device
EP3926500B1 (en) Device upgrade method and related device
CN112585905B (zh) 一种设备升级方法及相关设备
JP5310761B2 (ja) 車両ネットワークシステム
CN108270573B (zh) 无人驾驶汽车的隐私保护方法
US20220276855A1 (en) Method and apparatus for processing upgrade package of vehicle
US11228438B2 (en) Security device for providing security function for image, camera device including the same, and system on chip for controlling the camera device
US11212109B2 (en) Data provision system, data security device, data provision method, and computer program
US10970398B2 (en) Data provision system, data security device, data provision method, and computer program
JP6203798B2 (ja) 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム
WO2023103316A1 (zh) 应用管理方法及相关产品
JP2018006782A (ja) データ提供システム、データ提供装置、車載コンピュータ、データ提供方法、及びコンピュータプログラム
Kathiresh et al. Vehicle diagnostics over internet protocol and over-the-air updates
Wu et al. Security design of OTA upgrade for intelligent connected vehicle
CN112055952B (zh) 一种车载设备升级方法及相关设备
US11818280B2 (en) Systems and methods for centrally managing and routing multiple credentials
KR20190060032A (ko) 차량용 제어 유닛의 업데이트 방법 및 차량
CN112468304B (zh) 数据加密方法、装置、计算机设备及存储介质
CN117850846A (zh) 目标电子控制单元的升级方法、装置、设备及存储介质
CN117544321A (zh) 一种信息认证方法、装置、设备和存储介质
CN117354016A (zh) 一种整车ota安全升级方法、装置、设备及介质
JP2017225186A (ja) 車載制御システム、車両、管理装置、車載コンピュータ、データ共有方法、及びコンピュータプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17929441

Country of ref document: EP

Kind code of ref document: A2

ENP Entry into the national phase

Ref document number: 2020523294

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2017929441

Country of ref document: EP

Effective date: 20200430