WO2022140903A1 - 一种ota升级方法及装置 - Google Patents

一种ota升级方法及装置 Download PDF

Info

Publication number
WO2022140903A1
WO2022140903A1 PCT/CN2020/140094 CN2020140094W WO2022140903A1 WO 2022140903 A1 WO2022140903 A1 WO 2022140903A1 CN 2020140094 W CN2020140094 W CN 2020140094W WO 2022140903 A1 WO2022140903 A1 WO 2022140903A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
terminal
key
upgrade
target component
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/CN2020/140094
Other languages
English (en)
French (fr)
Inventor
王勇
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202080004762.2A priority Critical patent/CN112913189B/zh
Priority to PCT/CN2020/140094 priority patent/WO2022140903A1/zh
Priority to EP20967255.9A priority patent/EP4258593A4/en
Publication of WO2022140903A1 publication Critical patent/WO2022140903A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • 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
    • H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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
    • H04L63/0442—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 wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • 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
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/168—Implementing security features at a particular protocol layer above the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • 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/0825—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) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • 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/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • 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/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • 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/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • 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
    • 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 Internet of Vehicles and communication technologies, and in particular, to an OTA upgrade method and device.
  • Over the Air is a technology for downloading data through a wireless network, and has been widely used in the upgrade of devices such as vehicles, TVs, mobile phones, tablet computers, and set-top boxes.
  • the OTA technology mainly performs automatic upgrade by downloading the OTA upgrade package (it also supports the upgrade by copying the OTA upgrade package to the SD card).
  • vehicle manufacturers OEM, or original equipment manufacturers
  • upgrade the relevant hardware or software of vehicles through OTA technology which helps manufacturers reduce recall costs, respond quickly to demand, and improve user experience.
  • the existing OTA upgrade mode is dominated by the OEM, who is responsible for reviewing the software version of the upgrade package and distributing the upgrade package.
  • the OEM who is responsible for reviewing the software version of the upgrade package and distributing the upgrade package.
  • the core technology of the parts supplier may be leaked or the data involved may be compromised. exposure.
  • the embodiments of the present application disclose an OTA upgrade method and device, which can protect core assets such as secret-related data and key codes in the upgrade data, and improve the security of the OTA upgrade.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first server encrypts the upgrade data of the target component according to the first key to obtain the first ciphertext, wherein the first server is a server for providing the upgrade data of the target component;
  • the first server sends the first ciphertext to the OTA server
  • the first server sends a second key to the first terminal on which the target component is deployed, where the second key is a decryption key corresponding to the first key.
  • the first server is a server for providing upgrade data of the target component, which may be a single server or a server cluster composed of multiple servers.
  • the target component is an assembly to be upgraded.
  • the first key and the second key may be the same key (for example, the first key and the second key are symmetric keys), or may be different keys (for example, the first key and the second key are symmetric keys)
  • the key is the public key and the second key is the private key).
  • the upgrade data can be encrypted to obtain the first ciphertext, and the first terminal can obtain the first ciphertext through the OTA server. Subsequently, the first server may send the second key to the first terminal, so that the first terminal can perform an upgrade after decrypting the first ciphertext. Since the upgrade data of the target component is encrypted and transmitted, only the first server and the first terminal can obtain the upgrade data through the second key, which prevents other intermediate devices from obtaining the upgrade data and improves the confidentiality of the upgrade data. When the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • the above-mentioned first server belongs to a server used by the supplier of the target component to maintain the target component.
  • the first server sends a second key to the first terminal on which the target component is deployed, including:
  • the first server sends the second key to the first terminal through the secure channel.
  • the secure channel may be a transmission channel based on Secure Sockets Layer (SSL) or Transport Layer Security (Transport Layer Security, TLS) for secure data transmission. Since the secure channel is a secure and trusted channel, the first server and the first terminal transmit the second key through the secure channel, which can ensure the security of the second key.
  • SSL Secure Sockets Layer
  • TLS Transport Layer Security
  • the first server may specifically establish a secure channel with the target component in the first terminal, and send the second key to the target component in the first terminal.
  • the first server may specifically establish a secure channel with the upgrade control component in the first terminal, and send the second key to the upgrade control component in the first terminal.
  • the first server sends a second key to the first terminal on which the target component is deployed, including:
  • the first server encrypts the second key according to a first security parameter to obtain a second ciphertext, where the first security parameter is the shared key between the first server and the first terminal or is the shared key between the first server and the first terminal. the first public key of the first terminal;
  • the first server sends the second ciphertext to the first terminal on which the target component is deployed.
  • the first security parameter may be a public key, a symmetric key, or a share negotiated between the first server and the first terminal (or specifically a target component in the first terminal or an upgrade control component in the first terminal, etc.) key.
  • the first terminal (specifically, the target component in the first terminal or the upgrade control component in the first terminal, etc.) may determine a private key pair, and the public-private key pair includes the first public key and the first private key , the first public key can be sent to the first server as the first security parameter, and the first private key can be used as the second security parameter for the first terminal to decrypt the second ciphertext to obtain the second key.
  • the first server may specifically send the second ciphertext to the target component in the first terminal.
  • the first server may specifically send the second ciphertext to the upgrade control component in the first terminal.
  • the confidentiality of the second ciphertext can be improved by encrypting and transmitting the second key through the security parameter, thereby improving the confidentiality of the upgrade data.
  • the method before the first server encrypts the second key according to the first security parameter to obtain the second ciphertext, the method further includes:
  • the first server receives a key acquisition request from the first terminal.
  • the first security parameter belongs to a temporary key or a one-time key.
  • a one-time key can be understood as a key that is only used once or that becomes invalid or deleted after being used once.
  • the first security parameter is deleted; after the first terminal decrypts the second ciphertext with the second security parameter, the second security parameter can be deleted.
  • the first security parameter is only used for encryption once and the second security parameter is used for decryption only once, so that the first security parameter and the second security parameter are not easily broken, and data security is improved.
  • the first security parameter is a first public key of the first terminal; the first server encrypts the Before the second key obtains the second ciphertext, it further includes:
  • the first server authenticates the first public key of the first terminal through the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key;
  • the digital certificate authenticates the first public key of the first terminal, including:
  • the first server determines that the first public key is authenticated according to the second public key, the first signature and the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; Before obtaining the second ciphertext by encrypting the second key with the first security parameter, the method further includes:
  • the first server negotiates with the first terminal through a key agreement algorithm to obtain the shared key
  • the first server authenticates the identity of the first terminal through a pre-shared key PSK between the first server and the first terminal, and the PSK is the relationship between the first server and the target component. between preset secret values.
  • the first security parameter (and the second security parameter subsequently used for decrypting the second ciphertext) may be determined by the first server and the first terminal through a key agreement algorithm. In this way, different terminals and the first server can negotiate to obtain different security parameters, so that the first security parameters and the second security parameters are not easily broken, and data security is improved.
  • the first server authenticates the first terminal through a pre-shared key PSK between the first server and the first terminal identity, including:
  • the first server sends a second message to the first terminal, the second information includes a first authentication parameter and a second random number; the first authentication parameter is based on the first message, the second The random number and the PSK obtained;
  • the first server determines that the identity authentication of the target component is passed according to the second message, the first random number and the PSK.
  • the first server sends a second key to the first terminal on which the target component is deployed, including:
  • the first server sends the second key to the target component of the first terminal.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first terminal receives the first ciphertext sent by the OTA server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key, and the first ciphertext is obtained by encrypting the upgrade data of the target component on the first terminal.
  • the server is a server for providing upgrade data of the target component;
  • the first terminal receives a second key from the first server, where the second key is a decryption key corresponding to the first key;
  • the first terminal decrypts the first ciphertext through the second key to obtain the upgrade data of the target component
  • the first terminal upgrades the target component through the upgrade data of the target component.
  • the first terminal receives the second key from the first server, including:
  • the first terminal receives the second key of the first server through the secure channel.
  • the first terminal receives the second key sent from the first server, including:
  • the first terminal receives the second ciphertext from the first server; the second ciphertext is obtained by encrypting the second key according to the first security parameter;
  • the first terminal decrypts the second ciphertext according to a second security parameter to obtain the second key, where the second security parameter is a shared key between the first server and the first terminal or the first private key of the first terminal.
  • the method before the first terminal receives the second key from the first server, the method further includes:
  • the first terminal sends a key acquisition request to the first server.
  • the second security parameter belongs to a temporary key or a one-time key.
  • the second security parameter is a first private key corresponding to the first public key, and the first security parameter is the target zero the first public key of the component;
  • the first public key is authenticated by the first digital certificate of the target component.
  • the first digital certificate corresponds to a second public key and a second private key; the first terminal receives the first digital certificate from the first server Before the second ciphertext, it also includes:
  • the first terminal determines the first public key and the first private key
  • the first terminal signs the first public key by using the second private key to obtain a first signature
  • the first terminal sends the first signature and the first public key to the first server; the first signature is used by the first server to authenticate the certificate according to the second public key corresponding to the first signature certificate. the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the first terminal is based on Before the second security parameter decrypts the second ciphertext and obtains the second key, the method further includes:
  • the first terminal negotiates with the first server through a key agreement algorithm to obtain the shared key
  • the first terminal authenticates the identity of the first server through a pre-shared key PSK between the first server and the first terminal, and the PSK is the relationship between the first server and the first terminal. between preset secret values.
  • the first terminal authenticates the first server through a pre-shared key PSK between the first server and the first terminal identity, including:
  • the first terminal determines that the identity authentication of the first server has passed according to the first authentication parameter, the first message, the second random number and the PSK;
  • the first terminal sends a third message to the first server, where the third message includes a second authentication parameter; the second authentication parameter is based on the first random number, the second message and the PSK obtained.
  • the second authentication parameter is used to authenticate the identity of the first terminal.
  • the OTA upgrade method is specifically applied to the target component in the first terminal;
  • the first terminal further includes an upgrade control component, and the OTA upgrade method is specifically applied to the upgrade control component.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the OTA server receives the first ciphertext from the first server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key, and the first ciphertext is obtained by encrypting the upgrade data of the target component on the first terminal by the first server.
  • the server is a server for providing upgrade data of the target component;
  • the OTA server sends an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the method further includes:
  • the OTA server sends the first ciphertext to the first terminal through the secure channel, where the secure channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the upgrade rules are used to define the upgrade order, whether to roll back and other rules.
  • the upgrade conditions can include whether the power supply is normal, storage space, network status, and the status of other devices with dependencies, etc.
  • the download rules are used to define the download rules. order, indicate which part to download, etc.
  • the method further includes:
  • the OTA server determines the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • the OTA server determines the size of the storage space required by the first terminal according to the information of the first terminal and the file size of the first ciphertext.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first server sends the metadata of the upgrade data of the target component to the OTA server, wherein the first server is a server for providing the upgrade data of the target component, and the metadata of the upgrade data includes the upgrade The first download address of the data and the version information of the upgrade data;
  • the first server sends the upgrade data of the target component to the first terminal on which the target component is deployed through a secure channel, and the secure channel is a secure channel for the first terminal to communicate with the target component according to the first download address.
  • the first server is jointly established.
  • the first server sends the metadata of the upgrade data to the OTA server
  • the OTA server sends the first download address of the upgrade data to the first terminal.
  • the first terminal downloads the upgrade data from the first server through the first download address, which avoids other intermediate devices (eg, an OTA server) from acquiring the upgrade data of the target component, and ensures the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target component is directly obtained from the first server, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade efficiency is improved.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the first server belongs to a server used by the supplier of the target component to maintain the target component.
  • the first server sends the upgrade data of the target component to the first terminal on which the target component is deployed through a secure channel, specifically Can be:
  • the first server sends the upgrade data of the target component to the upgrade control component in the first terminal through the secure channel.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first terminal receives the download strategy sent by the OTA server, where the download strategy includes the first download address of the upgrade data of the target component; the target component is deployed on the first terminal;
  • the first terminal establishes a secure channel together with a first server based on the first download address, where the first server is a server for providing upgrade data of the target component;
  • the first terminal receives, through the secure channel, the upgrade data of the target component sent by the first server;
  • the first terminal upgrades the target component according to the upgrade data of the target component.
  • the OTA upgrade method is specifically applied to the target component.
  • the first terminal further includes an upgrade control component, and the OTA upgrade method is specifically applied to the upgrade control component.
  • the technical solution of the fifth aspect may correspond to the technical solution of the fourth aspect, and related beneficial effects may refer to the beneficial effects of the fourth aspect, which will not be repeated here.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the OTA server receives the metadata of the upgrade data of the target component sent by the first server, wherein the first server is a server for providing the upgrade data of the target component, and the metadata of the upgrade data includes the The first download address of the upgrade data and the version information of the upgrade data;
  • the OTA server sends an upgrade policy to the first terminal, where the upgrade policy includes the first download address.
  • the method further includes:
  • the OTA server determines the upgrade policy according to the information of the first terminal and/or the metadata of the upgrade data.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the metadata further includes the file size of the upgrade data of the target component.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first server encrypts the upgrade data of the target component according to the first key to obtain the first ciphertext, wherein the first server is a server for providing the upgrade data of the target component;
  • the first server obtains the second ciphertext by encrypting the second key of the first security parameter, wherein the first security parameter is the shared key between the first server and the first terminal or is The first public key of the first terminal, the first terminal is a terminal deployed with a first target component, the first target component is one of the target components, the second key is the decryption key of the first key;
  • the first server sends the first ciphertext and the second ciphertext to the OTA server, where the second ciphertext is used by the first terminal to decrypt the first ciphertext.
  • the second key is encrypted by using the first security parameter, and the data size of the key is usually smaller than the data size of the upgrade data. Therefore, for a supplier who has multiple or multiple parts to be upgraded, considering the situation that the security parameters of the multiple parts may be different, compared with directly encrypting the upgrade data with the security parameters, this embodiment can significantly reduce the The amount of calculation and storage in the encryption process improves the efficiency of the upgrade.
  • the first server belongs to a server used by the supplier of the target component to maintain the target component.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the OTA server receives the first ciphertext and the second ciphertext sent by the first server, wherein the first ciphertext is obtained by encrypting the upgrade data of the target component according to the first key, and the second ciphertext is Obtained by encrypting the second key according to the first security parameter, where the first security parameter is the shared key between the first server and the first terminal or the first public key of the first terminal, so
  • the first terminal is a terminal deployed with a first target component, the first target component is one of the target components, and the second key is a decryption key of the first key;
  • the OTA server sends the first ciphertext and the second ciphertext to the first terminal, wherein the second ciphertext is used by the first terminal to decrypt the first ciphertext to obtain the Describe the upgrade data of the target component.
  • sending the first ciphertext and the second ciphertext to the first terminal by the OTA server includes:
  • the OTA server generates an upgrade policy according to the attribute of the upgrade package where the first ciphertext is located and the information of the first terminal; the upgrade policy includes the first ciphertext of the first ciphertext and the second ciphertext. download link;
  • the OTA server sends the first ciphertext and the second ciphertext to the first terminal through a secure channel, where the secure channel is for the first terminal to communicate with the OTA server according to the first download address jointly established.
  • the technical solution of the eighth aspect may correspond to the technical solution of the seventh aspect, and related beneficial effects may refer to the beneficial effects of the seventh aspect, which will not be repeated here.
  • an embodiment of the present application discloses an OTA upgrade method, which is applied to a first terminal deployed with a first target component, where the first target component is one of the target components, and the method includes:
  • the first terminal receives the first ciphertext and the second ciphertext sent by the OTA server, and the first ciphertext is obtained by the first server encrypting the upgrade data of the target component according to the first key, wherein, the first server is a server for providing upgrade data of the target component;
  • the first terminal decrypts the second ciphertext according to the second security parameter to obtain a second key, the second key is the decryption key of the first key, and the second security parameter is the the shared key between the first server and the first terminal or the first private key of the first terminal;
  • the first terminal decrypts the first ciphertext according to the second key to obtain the upgrade data of the target component
  • the first terminal upgrades the first target component according to the upgrade data of the target component.
  • the OTA upgrade method is specifically applied to the first target component in the first terminal;
  • the first terminal in the OTA upgrade system further includes an upgrade control component, and the OTA upgrade method is specifically applied to the upgrade control component.
  • the upgrade control component is used to control the upgrade of the first target component.
  • the first terminal receives the first ciphertext and the second ciphertext sent by the OTA server, including:
  • the first terminal establishes a secure channel with the OTA server through the first download address
  • the first terminal receives the first ciphertext and the second ciphertext sent by the OTA server through the secure channel.
  • the method further includes:
  • the first terminal receives a download policy from the OTA server, where the download policy includes the first download address.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the first server encrypts the upgrade data of the target component according to a first security parameter to obtain a first ciphertext, and the first security parameter is a preset shared between the first server and the first terminal
  • the key or the preset first public key of the first terminal the first server is a server for providing the upgrade data of the target component;
  • the first terminal is a server where the target zero is deployed the terminal of the component;
  • the first server sends the first ciphertext to the OTA server; the first ciphertext is used to be sent by the OTA server to the first terminal to upgrade the target component in the first terminal .
  • the first security parameter and the second security parameter may be pre-configured or pre-acquired
  • the first server uses the first security parameter to encrypt the upgrade data of the target component
  • the first terminal uses the second security parameter to encrypt the A ciphertext is decrypted to obtain the upgrade data of the target component. Since the upgrade data of the target parts and components are encrypted and transmitted, without obtaining the second security parameters, the second ciphertext cannot be decrypted to obtain the second key, and the first ciphertext cannot be decrypted to obtain the upgrade data of the target parts. Confidentiality of upgrade data. When the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the above-mentioned first server belongs to a server used by the supplier of the target component to maintain the target component.
  • an embodiment of the present application discloses an OTA upgrade method, which is applied to a first terminal deployed with a first target component, where the first target component is one of the target components, and the method includes: :
  • the first terminal receives the first ciphertext sent by the OTA server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component according to the first security parameter, and the first server is used to provide a server for the upgrade data of the target component, and the first security parameter is a shared key between the first server and the first terminal or a first public key of the first terminal;
  • the first terminal decrypts the first ciphertext in the upgrade package according to the second security parameter to obtain the upgrade data of the target component, and the second security parameter is the shared key or the first ciphertext. the first private key of the terminal;
  • the first terminal upgrades the target component according to the upgrade data of the target component.
  • the OTA upgrade method is specifically applied to the target component.
  • an upgrade control component is further deployed on the first terminal, and the OTA upgrade method is specifically applied to the upgrade control component.
  • the technical solution of the eleventh aspect may correspond to the technical solution of the tenth aspect, and the relevant beneficial effects may refer to the beneficial effects of the tenth aspect, which will not be repeated here.
  • an embodiment of the present application discloses an OTA upgrade method, including:
  • the OTA server receives the first ciphertext from the first server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first security parameter, and the first ciphertext is obtained by encrypting the upgrade data of the target component on the first terminal.
  • the server is a server for providing upgrade data of the target component;
  • the OTA server sends an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the method further includes:
  • the OTA server sends the first ciphertext to the first terminal through the secure channel, where the secure channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the method further includes:
  • the OTA server determines the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • an embodiment of the present application discloses an OTA upgrade device.
  • the OTA upgrade device may include a processing unit and a sending unit, and the OTA upgrade device is used to implement the first aspect or any possibility of the first aspect. The method described in the embodiment.
  • the processing unit is configured to encrypt the upgrade data of the target component according to a first key to obtain a first ciphertext, wherein the first server is used to provide the target A server for the upgrade data of components;
  • the sending unit configured to send the first ciphertext to the OTA server
  • the sending unit is further configured to send a second key to the first terminal on which the target component is deployed, where the second key is a decryption key corresponding to the first key.
  • the above-mentioned OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • the processing unit is further configured to establish a secure channel with the first terminal on which the target component is deployed;
  • the sending unit is further configured to send the second key to the first terminal through the secure channel.
  • the processing unit is further configured to encrypt the second key according to the first security parameter to obtain a second ciphertext
  • the first A security parameter is a shared key between the first server and the first terminal or a first public key of the first terminal
  • the sending unit is further configured to send the second ciphertext to the first terminal on which the target component is deployed.
  • the device further includes:
  • a receiving unit configured to receive a key acquisition request from the first terminal.
  • the first security parameter belongs to a temporary key or a one-time key.
  • the first security parameter is the first public key of the first terminal; the receiving unit is further configured to receive the the first public key of the first terminal sent by the first terminal;
  • the processing unit is further configured to authenticate the first public key of the first terminal through the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key;
  • the receiving unit is further configured to receive data from the a first signature sent by the first terminal, where the first signature is obtained by using the second private key to sign the first public key;
  • the processing unit is further configured to determine that the first public key has passed the authentication according to the second public key, the first signature and the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the processing unit , also used for:
  • the identity of the first terminal is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • the receiving unit is further configured to receive a first message sent by the first terminal, where the first information includes a first random number;
  • the sending unit is further configured to send a second message to the first terminal, where the second information includes a first authentication parameter and a second random number; the first authentication parameter is based on the first message, the obtained from the second random number and the PSK;
  • the receiving unit is further configured to receive a third message sent by the first terminal, where the third information includes a second authentication parameter;
  • the processing unit is specifically configured to determine, according to the second message, the first random number and the PSK, that the identity authentication of the target component has passed.
  • the sending unit is specifically configured to:
  • the second key is sent to the target component of the first terminal.
  • an embodiment of the present application discloses an OTA upgrade device, including a receiving unit and a processing unit, the OTA upgrade device is used to implement the second aspect or any one of the possible implementations of the second aspect. method.
  • the receiving unit is configured to receive the first ciphertext sent by the OTA server, where the first ciphertext is the target on the first terminal that is paired by the first server according to the first key.
  • the upgrade data of the component is encrypted and obtained, and the first server is a server for providing the upgrade data of the target component;
  • the receiving unit is further configured to receive a second key from the first server, where the second key is a decryption key corresponding to the first key;
  • the processing unit is further configured to decrypt the first ciphertext through the second key to obtain the upgrade data of the target component;
  • the processing unit is further configured to upgrade the target component through the upgrade data of the target component.
  • the processing unit is further configured to establish a secure channel with the first server
  • the receiving unit is specifically configured to receive the second key of the first server through the secure channel.
  • the receiving unit is specifically configured to receive the second ciphertext from the first server; the second ciphertext is obtained by encrypting the second key according to the first security parameter;
  • the processing unit is further configured to decrypt the second ciphertext according to a second security parameter to obtain the second key, and the second security parameter is the communication between the first server and the first terminal.
  • the device further includes:
  • a sending unit configured to send a key acquisition request to the first server.
  • the second security parameter belongs to a temporary key or a one-time key.
  • the second security parameter is the first private key corresponding to the first public key, and the first security parameter is the first public key of the first terminal;
  • the first public key is authenticated by the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key
  • the processing unit further configured to determine the first public key and the first private key
  • the processing unit is further configured to sign the first public key by using the second private key to obtain a first signature
  • the sending unit is further configured to send the first signature and the first public key to the first server; the first signature is used by the first server according to the second public key corresponding to the first signature certificate. key to authenticate the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the processing unit , also used for:
  • the identity of the first server is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • the sending unit is further configured to send a first message to the first server, where the first message includes a first random number ;
  • the receiving unit is further configured to receive a second message sent by the first server, where the second message includes a first authentication parameter and a second random number;
  • the processing unit is specifically configured to determine that the identity authentication of the first server has passed according to the first authentication parameter, the first message, the second random number and the PSK;
  • the sending unit is further configured to send a third message to the first server, where the third message includes a second authentication parameter; the second authentication parameter is based on the first random number, the second message and the PSK obtained.
  • the second authentication parameter is used to authenticate the identity of the first terminal.
  • the OTA upgrade device is specifically the target component in the first terminal
  • the OTA upgrade apparatus is specifically an upgrade control component in the first terminal.
  • an embodiment of the present application discloses an OTA upgrade device, including a receiving unit and a sending unit, the OTA upgrade device is used to implement the third aspect or any one of the possible implementations of the third aspect. method.
  • the receiving unit is configured to receive a first ciphertext from a first server, where the first ciphertext is a pair of ciphertexts on the first terminal by the first server according to a first key.
  • the upgrade data of the target component is encrypted and obtained, and the first server is a server for providing the upgrade data of the target component;
  • the sending unit is configured to send an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the sending unit is specifically configured to send the first ciphertext to the first terminal through the secure channel, and the secure The channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the upgrade rules are used to define the upgrade order, whether to roll back and other rules.
  • the upgrade conditions can include whether the power supply is normal, storage space, network status, and the status of other devices with dependencies, etc.
  • the download rules are used to define the download rules. order, indicate which part to download, etc.
  • the apparatus further includes:
  • the processing unit 1503 is configured to determine the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • the OTA server determines the size of the storage space required by the first terminal according to the information of the first terminal and the file size of the first ciphertext.
  • an embodiment of the present application discloses an OTA upgrade apparatus, including a sending unit, where the OTA upgrade apparatus is configured to implement the method described in the fourth aspect or any possible implementation manner of the fourth aspect.
  • the OTA upgrade device is a device for providing upgrade data of the target component,
  • the sending unit is configured to send the metadata of the upgrade data of the target component to the OTA server, where the metadata of the upgrade data includes the first download address of the upgrade data and the The version information of the upgrade data;
  • the sending unit is further configured to send the upgrade data of the target component to the first terminal on which the target component is deployed through a secure channel, where the secure channel is for the first terminal to download the address according to the first download address. jointly established with the first server.
  • the OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • the OTA upgrade apparatus further includes:
  • the processing unit is configured to determine the metadata of the upgrade data of the target component.
  • the sending unit is specifically configured to:
  • the upgrade data of the target component is sent to the upgrade control component in the first terminal through the secure channel.
  • an embodiment of the present application discloses an OTA upgrade device, the OTA upgrade device includes a receiving unit and a processing unit, and the OTA upgrade device is used to implement the fifth aspect or any one of the possible possibilities of the fifth aspect.
  • Target components are deployed in the OTA upgrade device.
  • the receiving unit is configured to receive a download strategy sent by the OTA server, where the download strategy includes a first download address of the upgrade data of the target component; the target component is deployed in the on the first terminal;
  • the processing unit configured to jointly establish a secure channel with a first server based on the first download address, where the first server is a server for providing upgrade data of the target component;
  • the processing unit is further configured to receive, through the secure channel, the upgrade data of the target component sent by the first server;
  • the processing unit is further configured to upgrade the target component according to the upgrade data of the target component.
  • the OTA upgrade device is specifically the target component in the first terminal
  • the OTA upgrade apparatus is specifically an upgrade control component in the first terminal.
  • an embodiment of the present application discloses an OTA upgrade device, which includes a receiving unit and a sending unit, and the OTA upgrade device is used to implement the sixth aspect or any possible implementation manner of the sixth aspect. method.
  • the receiving unit is configured to receive the metadata of the upgrade data of the target component sent by the first server, wherein the first server is used to provide the upgrade of the target component a data server, wherein the metadata of the upgrade data includes the first download address of the upgrade data and the version information of the upgrade data;
  • the sending unit is configured to send an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the apparatus further includes:
  • a processing unit configured to determine the upgrade policy according to the information of the first terminal and/or the metadata of the upgrade data.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the metadata further includes the file size of the upgrade data of the target component.
  • an embodiment of the present application discloses an OTA upgrade device, including a processing unit and a sending unit, where the OTA device is configured to implement the method described in the seventh aspect or any possible implementation manner of the seventh aspect .
  • the OTA upgrade device may be a device for providing upgrade data of the target component.
  • the processing unit is configured to encrypt the upgrade data of the target component according to a first key to obtain a first ciphertext, wherein the first server is used to provide the target A server for the upgrade data of components;
  • the processing unit is configured to obtain a second ciphertext by encrypting a second key of a first security parameter, wherein the first security parameter is a shared key between the first server and the first terminal Or the first public key of the first terminal, the first terminal is a terminal on which a first target component is deployed, the first target component is one of the target components, and the second target component is one of the target components.
  • the key is the decryption key of the first key;
  • the sending unit is configured to send the first ciphertext and the second ciphertext to the OTA server, where the second ciphertext is used for the first terminal to decrypt the first ciphertext.
  • the OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • an embodiment of the present application discloses an OTA upgrade device, including a receiving unit and a sending unit, and the OTA upgrade device is configured to implement the eighth aspect or any one of the possible implementations of the eighth aspect. method.
  • the receiving unit is configured to receive a first ciphertext and a second ciphertext sent by a first server, wherein the first ciphertext is a target component paired according to a first key
  • the second ciphertext is obtained by encrypting the second key according to the first security parameter
  • the first security parameter is the shared key between the first server and the first terminal
  • the first terminal is a terminal on which a first target component is deployed, the first target component is one of the target components, and the second target component is one of the target components.
  • the key is the decryption key of the first key
  • the sending unit configured to send the first ciphertext and the second ciphertext to the first terminal, wherein the second ciphertext is used by the first terminal to decrypt the first ciphertext, to obtain the upgrade data of the target component.
  • the apparatus further includes:
  • a processing unit configured to generate an upgrade policy according to the attribute of the upgrade package where the first ciphertext is located and the information of the first terminal; the upgrade policy includes the first ciphertext and the second ciphertext of the second ciphertext a download address;
  • the sending unit is further configured to send the upgrade policy to the first terminal
  • the sending unit is further configured to send the first ciphertext and the second ciphertext to the first terminal through a secure channel, where the secure channel is the connection between the first terminal and the first download address according to the first download address.
  • the OTA server is jointly established.
  • an embodiment of the present application discloses an OTA upgrade device, including a receiving unit and a processing unit, and the OTA upgrade device is used to implement the ninth aspect or any one of the possible implementations described in the ninth aspect.
  • Methods wherein, a first target component is deployed in the OTA upgrade device (or in a device where the OTA upgrade device is located), and the first target component is one of the target components.
  • the receiving unit is configured to receive the first ciphertext and the second ciphertext sent by the OTA server, where the first ciphertext is the first server pairing the target with the first key according to the first key.
  • the upgrade data of the component is encrypted and obtained, wherein the first server is a server used to provide the upgrade data of the target component;
  • the processing unit is configured to decrypt the second ciphertext according to the second security parameter to obtain a second key, where the second key is the decryption key of the first key, and the second security parameter is The shared key between the first server and the first terminal or the first private key of the first terminal;
  • the processing unit is also used to decrypt the first ciphertext according to the second key to obtain the upgrade data of the target component;
  • the processing unit is further configured to upgrade the first target component according to the upgrade data of the target component.
  • the OTA upgrade device is specifically the first target component in the first terminal;
  • the OTA upgrade apparatus is specifically an upgrade control component in the first terminal.
  • the processing unit is further configured to establish a secure channel with the OTA server through the first download address;
  • the receiving unit is specifically configured to receive the first ciphertext and the second ciphertext sent by the OTA server through the secure channel.
  • the receiving unit is further configured to receive a download policy from the OTA server, where the download policy includes the first A download address.
  • an embodiment of the present application discloses an OTA upgrade device, including a processing unit and a sending unit, and the OTA upgrade device is used to implement the tenth aspect or any one of the possible implementations described in the tenth aspect.
  • the OTA upgrade device may be a device for providing upgrade data of the target component.
  • the processing unit is configured to encrypt the upgrade data of the target component according to a first security parameter to obtain a first ciphertext
  • the first security parameter is the preset
  • the shared key between the first server and the first terminal or the preset first public key of the first terminal, and the first server is a server for providing upgrade data of the target component ;
  • the first terminal is a terminal where the target component is deployed;
  • the sending unit is used for sending the first ciphertext to an OTA server; the first ciphertext is used for sending by the OTA server to a first terminal so as to detect the target component in the first terminal to upgrade.
  • the above-mentioned OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • an embodiment of the present application discloses an OTA upgrade device, including a receiving unit and a processing unit, and the OTA upgrade device is used to implement the eleventh aspect or any possible implementation manner of the eleventh aspect the described method.
  • a first target component is deployed in the OTA upgrade device, and the first target component is one of the target components.
  • the receiving unit is configured to receive the first ciphertext sent by the OTA server, where the first ciphertext is the upgrade data of the target component by the first server according to the first security parameter obtained by encryption, the first server is a server for providing upgrade data of the target component, and the first security parameter is a shared key between the first server and the first terminal or a the first public key of the first terminal;
  • the processing unit is configured to decrypt the first ciphertext in the upgrade package according to the second security parameter to obtain the upgrade data of the target component, and the second security parameter is the shared key or the the first private key of the first terminal;
  • the processing unit is further configured to upgrade the target component according to the upgrade data of the target component.
  • the OTA upgrade device is specifically the target component in the first terminal
  • the OTA upgrade apparatus is specifically an upgrade control component in the first terminal.
  • an embodiment of the present application discloses an OTA upgrade device, comprising a receiving unit and a sending unit, and the OTA upgrade device is used to implement the twelfth aspect or any possible implementation manner of the twelfth aspect the described method.
  • the receiving unit is configured to receive a first ciphertext from a first server, where the first ciphertext is the first ciphertext of the first server on the first terminal according to the first security parameter.
  • the upgrade data of the target component is encrypted and obtained, and the first server is a server for providing the upgrade data of the target component;
  • the sending unit is configured to send an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the sending unit is specifically configured to send the first ciphertext to the first terminal through the secure channel, so The secure channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the device further includes:
  • a processing unit configured to determine the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • an embodiment of the present application further provides a first server, where the server includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, and the at least one processor is used for At least one computer program stored in a memory is invoked, so that the first server implements the method described in the first aspect or any possible implementation manner of the first aspect; or implements the fourth aspect or any one of the fourth aspect the method described in one possible implementation manner; or implement the method described in the seventh aspect or any one possible implementation manner of the seventh aspect; or implement any one possibility of the eleventh aspect or the eleventh aspect The method described in the embodiment.
  • an embodiment of the present application further provides a first terminal, where the first terminal includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, the at least one processing
  • the device is used to call the computer program stored in at least one memory, so that the first terminal implements the method described in the second aspect or any possible implementation manner of the second aspect; or implements the fifth aspect or the fifth aspect.
  • the first terminal may be a gateway, a vehicle integrated unit, a T-box, or other devices, or may be an intelligent device such as a vehicle, a robot, or an unmanned aerial vehicle, or a transportation terminal.
  • an embodiment of the present application further provides an OTA server, where the OTA server includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, and the at least one processor is used for Invoking a computer program stored in at least one memory, so that the OTA server implements the method described in the third aspect or any possible implementation manner of the third aspect; or implements the sixth aspect or any one of the sixth aspect The method described in the possible implementation manner; or realize the eighth aspect or the method described in any possible implementation manner of the eighth aspect; or realize the twelfth aspect or any possible implementation manner of the twelfth aspect The method described in the embodiment.
  • an embodiment of the present application further provides an OTA upgrade system, where the OTA upgrade system includes a first server and a target component.
  • the first server is used to implement the method described in the first aspect or another possible implementation of the first aspect
  • the target component is used to implement the second aspect or a possible implementation of the second aspect. Implement the method described by the way;
  • the first server is used to implement the method described in the fourth aspect or another possible implementation manner of the fourth aspect
  • the target component is used to implement the fifth aspect or a possible implementation manner of the fifth aspect.
  • the first server is used to implement the method described in the seventh aspect or another possible implementation manner of the seventh aspect
  • the target component is used to implement the ninth aspect or a possible implementation manner of the ninth aspect.
  • the first server is used to implement the method described in the tenth aspect or another possible implementation manner of the tenth aspect
  • the target component is used to implement the eleventh aspect or one of the eleventh aspects. possible implementations of the described methods.
  • an embodiment of the present application further provides an OTA upgrade system, where the OTA upgrade system includes an OTA server and a first terminal.
  • the OTA server is used to implement the method described in the third aspect or another possible implementation of the third aspect
  • the first terminal is used to implement the second aspect or a possible implementation of the second aspect. the method described in the manner;
  • the OTA server is used to implement the method described in the sixth aspect or another possible implementation of the sixth aspect
  • the first terminal is used to implement the fifth aspect or a possible implementation of the fifth aspect the method described in the manner;
  • the OTA server is used to implement the method described in the eighth aspect or another possible implementation of the eighth aspect
  • the first terminal is used to implement the ninth aspect or a possible implementation of the ninth aspect the method described in the manner;
  • the OTA server is used to implement the method described in the twelfth aspect or another possible implementation manner of the twelfth aspect
  • the first terminal is used to implement the eleventh aspect or another possible implementation of the twelfth aspect.
  • an embodiment of the present application discloses a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program runs on one or more processors, the first The methods described in one aspect to the twelfth aspect (or also including possible embodiments thereof).
  • an embodiment of the present application discloses a computer program product that, when the computer program product runs on one or more processors, implements the first to twelfth aspects (or also includes the possibility of implementation of the method) described.
  • FIG. 1 is a schematic diagram of the architecture of an OTA upgrade system according to an embodiment of the present application.
  • FIG. 2 is a schematic structural diagram of a vehicle upgrade system provided by an embodiment of the present application.
  • FIG. 3 is a schematic flowchart of an OTA upgrade method provided by an embodiment of the present application.
  • FIG. 4 is a schematic structural diagram of a vehicle provided by an embodiment of the present application.
  • FIG. 5 is a schematic flowchart of a method for determining a first security parameter provided by an embodiment of the present application
  • FIG. 6 is a schematic flowchart of another method for determining a first security parameter provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of the architecture of another OTA upgrade system provided by an embodiment of the present application.
  • FIG. 8 is a schematic flowchart of another OTA upgrade method provided by an embodiment of the present application.
  • FIG. 9 is a schematic diagram of the architecture of still another OTA upgrade system provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of still another OTA upgrade method provided by an embodiment of the present application.
  • FIG. 11 is a schematic diagram of the architecture of still another OTA upgrade system provided by an embodiment of the present application.
  • FIG. 12 is a schematic flowchart of still another OTA upgrade method provided by an embodiment of the present application.
  • FIG. 13 is a schematic structural diagram of an OTA upgrade device provided by an embodiment of the present application.
  • FIG. 14 is a schematic structural diagram of another OTA upgrade device provided by an embodiment of the present application.
  • 15 is a schematic structural diagram of still another OTA upgrade device provided by an embodiment of the present application.
  • FIG. 16 is a schematic structural diagram of still another OTA upgrade apparatus provided by an embodiment of the present application.
  • At least one refers to one or more, and the “plurality” refers to two or more.
  • At least one item(s) below” or similar expressions thereof refer to any combination of these items, including any combination of single item(s) or plural items(s).
  • at least one (a) of a, b, or c may represent: a, b, c, (a and b), (a and c), (b and c), or (a and b and c), wherein a, b, c can be single or multiple.
  • ordinal numbers such as “first” and “second” are used in the embodiments of the present application to distinguish multiple objects, and are not used to limit the order, sequence, priority, or importance of multiple objects degree.
  • first detection device and the second detection device are only used to distinguish different detection devices, but do not indicate the difference in structure, detection principle, and importance of the two devices.
  • Hash algorithm is also known as hash function, hash algorithm, hash algorithm can output a piece of data (such as string, number, file, etc.) as a preset length (such as 80 bits, or 128 bits, etc. ) of the hash value (the hash value can also be called hash value, digest value, etc.), and it is difficult to find the reverse rule.
  • hash algorithms mainly include secure hash algorithm 1 (SHA-1), message digest (MD) algorithm (such as MD2, MD4 or MD5, etc.).
  • Encryption algorithms are used to protect the confidentiality of data, usually by encrypting plaintext to obtain ciphertext.
  • the encryption algorithm may include encryption operations (eg, elliptic point addition operation, XOR operation, etc.), and may also include various algorithms with higher security.
  • Common encryption algorithms mainly include XOR operation, data encryption standard (DES), triple data encryption algorithm (3DES), advanced encryption standard (AES), RSA encryption algorithm, data encryption algorithm Structural analysis algorithm (data structure analysis, DSA) and so on.
  • the integrity protection algorithm is an algorithm used to protect the integrity of data (data integrity), which can also be called the integrity protection algorithm.
  • the integrity protection algorithm usually outputs a message authentication code (message authentication code, MAC).
  • the integrity protection algorithm is also called a MAC algorithm.
  • the integrity protection algorithm can be implemented by a variety of hash algorithms.
  • the integrity protection algorithm implemented by the hash algorithm is called the hash-based message authentication code (HMAC) algorithm.
  • the algorithm can be one of MD5, SHA-1, SHA-256, etc. These different HMAC implementations are usually labeled: HMAC-MD5, HMAC-SHA1, HMAC-SHA256, etc.
  • the data can be encrypted and the message authentication code can be generated for the given original text. Therefore, the authentication encryption algorithm can be used as both an encryption algorithm and a security algorithm.
  • the AES algorithm based on GMAC and counter encryption mode AES-Galois/counter mode, AES-GCM
  • AES-CMAC/counter Mode AES-CCM
  • the message is authenticated and encrypted, and the integrity of the message can also be protected during the process of authentication and encryption.
  • Key derivation algorithms are used to derive one or more secret values from a secret value, also known as key derivation algorithms.
  • key derivation algorithms include password-based key derivation function (PBKDF), scrypt algorithm, etc.
  • PBKDF password-based key derivation function
  • the PBKDF algorithm includes the first generation PBKDF1 and the second generation PBKDF2.
  • some KDF algorithms use a hash algorithm to hash the input secret value in the process of deriving a key, so the KDF function can also receive an algorithm identifier as an input to indicate which hash algorithm to use.
  • KDF is not only used in the process of deriving secret values, but also in scenarios such as generating authentication information and identity information.
  • Key negotiation is a process in which two parties negotiate to obtain a key by exchanging some parameters.
  • the algorithm used for key agreement is called a key agreement algorithm, and it can also be called a key exchange algorithm.
  • key agreement algorithms include Diffie-Hellman (DH) algorithm, Diffie-Hellman (ECDH) algorithm based on Elliptic Curve Cryptosystems (ECC), Oakley (Oakley) algorithm, National secret algorithms (such as SM1, SM2, SM3 and SM4), etc.
  • the two devices use two large prime numbers p and random numbers g, and generate random numbers a and b respectively.
  • K K ⁇ G
  • K and G are points on the elliptic curve Ep(a, b)
  • k is an integer less than n.
  • the elliptic curve algorithm in actual use makes p quite large in principle, and n is also quite large, it is a mathematical problem to calculate the k points one by one and compare them with K.
  • the freshness parameter is used to generate keys and authentication parameters, etc., and can also be called freshness or freshness parameters, which can include a random number (number once, NONCE), a count value (counter), a serial number (serial number), and a sequence number ( sequence number) and so on.
  • NONCE is a random value that is used only once (or non-repeating).
  • the freshness parameters generated at different times are usually different, that is, the specific value of the freshness parameter will change each time the freshness parameter is generated, so that the freshness parameter used for generating the key (or authentication parameter, etc.) this time Different from the freshness parameter used when the key (or authentication parameter, etc.) was generated last time, the security of the generated key (or authentication parameter, etc.) can be improved.
  • the freshness parameter can be a random number obtained by the node through a random number generator.
  • a digital certificate (also known as a security certificate) is a digital certification that identifies an identity, and is usually a relatively authoritative and fair certificate issued by a Certificate Authority (CA) center or a trusted third-party device.
  • CA Certificate Authority
  • the CA center certifies the long-term public key PK, and the CA center uses its own private key cpk to certify the long-term public key PK and the long-term private key SK.
  • Some related information (such as description information for the second node) is encrypted together to generate the DC.
  • the first terminal uses the private key corresponding to the certificate to generate the signature of the first public key (ie "private key signature"), and sends the first public key, the signature of the first public key, and the DC to the first server, and the first server uses the CA
  • the public key csk of the center decrypts the certificate, it can be determined that the DC is issued by the CA, and that the long-term public key PK in the DC is from the first terminal, thereby certifying the source of the long-term public key PK.
  • the first server verifies the signature of the first public key by using the long-term public key PK (ie, "public key verification"), so as to determine that the first public key comes from the first terminal.
  • FIG. 1 is a schematic diagram of an OTA upgrade system provided by an embodiment of the present application, including a first server 101, an OTA server (server) 102, and a terminal 103, wherein:
  • the first server 101 is a device with data processing capability, which may be a physical device such as a host, a server, etc., or a virtual device such as a virtual machine, a container, and the like. It should be noted that, for convenience of description, it is referred to as a server here, and in a specific implementation process, it may be a server, or may be other devices with data processing capabilities.
  • the first server 101 is a server that provides upgrade data of target components.
  • the first server may belong to a server where the supplier of the target component maintains the target component.
  • the OTA server 102 is a server that exchanges information with the terminal during the OTA upgrade process.
  • the OTA server can indicate that the terminal needs to upgrade a certain component.
  • the OTA server can also send the upgrade data of the component to the terminal.
  • the OTA server is also referred to as the OTA cloud.
  • the first terminal 103 is a terminal on which the target component 104 is deployed.
  • the first terminal 103 can obtain the upgrade data through the OTA server 102, so as to upgrade the target component 104.
  • the target component 104 has the ability to transmit and receive data, so that the upgrade data can be obtained from the OTA server 102 for upgrading.
  • an upgrade control component 105 may be deployed on the first terminal 103 , and the first terminal 103 may obtain upgrade data from the OTA server 102 through the upgrade control component 105 . Further, the first terminal 103 can upgrade the target component 104 through the upgrade control component 105 , or control the target component 104 to upgrade through the upgrade control component 105 . For example, one or more of the upgrade control component 105 for receiving the upgrade data, instructing the upgrade sequence, checking the upgrade status, flashing the upgrade data, etc. can be regarded as the upgrade control component 105 controlling the target component 104 to upgrade.
  • the upgrade control component 105 of the first terminal 103 may specifically include an OTA master module (Master) and an OTA slave module (slave), and the OTA master module distributes the upgrade package obtained from the OTA server to the terminal in the terminal.
  • One or more OTA slave modules, the one or more OTA slave modules instruct the components in the terminal to install and activate the upgrade package to complete the upgrade.
  • FIG. 2 is a schematic diagram of a possible vehicle upgrade system exemplified in an embodiment of the present application, including a supplier server 201 , an OTA cloud 202 and a vehicle 203 .
  • the vehicle 203 is a vehicle based on the vehicle electrical/electronic architecture (E/E) architecture, see area 204, the vehicle 203 may include the following components: mobile data center (Mobile Data Center, MDC), human-machine interaction (Human-Machine) Interaction, HMI), gateway (gateway, GW), car box (Telematics BOX, Tbox or TCU), electronic control unit (Electronic Control Unit, ECU) and other modules.
  • the GW is the core component in the electronic and electrical architecture of the vehicle.
  • GW can integrate the Controller Area Network (CAN), Local Interconnect Network (LIN), multimedia Data transmission (Media Oriented System Transport, MOST), FlexRay and other network data are routed in different networks.
  • CAN Controller Area Network
  • LIN Local Interconnect Network
  • MOST Media Oriented System Transport
  • FlexRay FlexRay
  • MDC is an intelligent in-vehicle computing platform for automobiles.
  • the T-BOX is mainly used to communicate with the outside of the car, the background system and the mobile phone application (application, APP).
  • HMI is the infotainment system of a car.
  • ECU is a special-purpose microcomputer controller for automobiles.
  • An update master module (update master, which can be regarded as an OTA master) is deployed in the GW of the vehicle 203
  • an update slave module (update slave, which can be regarded as an OTA slave) is deployed in multiple components of the vehicle 203.
  • the upgrade master module receives the upgrade package sent by the OTA cloud 202 and distributes it to the upgrade slave module, so that the upgrade slave module instructs the components in the vehicle to install and activate the upgrade package, and completes the upgrade of one or more components in the vehicle 203. upgrade.
  • the upgrade process is dominated by the OTA server.
  • the OTA server is maintained by the OEM, that is to say, the OEM is responsible for reviewing the software version and distributing the upgrade package.
  • the supplier server 201 needs to deliver the upgrade package to the OTA cloud 202 (OTA server), and the OTA cloud 202 distributes the upgrade package to the vehicle 203 that needs to be upgraded.
  • OTA server OTA cloud
  • the data of the upgrade package may be leaked, which may lead to component suppliers.
  • the core technology, key data is leaked or classified data is exposed.
  • FIG. 3 is a schematic flowchart of an OTA upgrade method provided by an embodiment of the present application. The method includes but is not limited to the following steps:
  • Step S301 The first server encrypts the upgrade data of the target component according to the first key to obtain the first ciphertext.
  • the target component is a component to be upgraded.
  • the target component can be deployed on one or more terminals.
  • the target component can be GW, Tbox, VIU, DC, ECU, etc. in the vehicle, or it can also be a vehicle
  • the media equipment in the vehicle is such as a camera, a radar, etc., or it can also be software in the vehicle, such as an operating system, navigation software, map software, monitoring software, and so on.
  • the ECU is composed of one or more of a processor, a memory, an input/output (I/O) interface, an analog-to-digital converter (A/D), and one or more large-scale integrated circuits such as shaping and driving. function.
  • the first server is a server for providing upgrade data of target parts. Further, the first server can be used by the supplier of the target component in the process of maintaining the target component.
  • the present application exemplifies a possible scenario: the first server may be a map update server belonging to a supplier of the target component, for the supplier to update the map data of the target component.
  • the server (for example, the first server, the OTA server, etc.) mentioned in the embodiments of this application may be one server or a server cluster composed of multiple servers.
  • the first server may be a server cluster deployed by multiple servers through a distributed architecture, and the cluster may include cloud computing servers, content delivery network (Content Delivery Network, CDN) servers, Network Time Protocol (Network Time Protocol, NTP), One or more of Domain Name System (DNS) servers, etc.
  • CDN Content Delivery Network
  • NTP Network Time Protocol
  • DNS Domain Name System
  • each server can coordinate with each other to jointly complete functions such as computing, data storage, and communication.
  • a single server, a distributed server, and a server cluster are collectively referred to as servers in the embodiments of the present application.
  • the first key may be a symmetric key or an asymmetric key.
  • the encryption key and the decryption key are usually different.
  • a ciphertext encrypted using a symmetric encryption algorithm, the encryption key and the decryption key are the same.
  • the upgrade data of the target component is used to upgrade the target component.
  • the upgrade data of the target components may be operating system updates, application software version updates, vulnerability patches, map data updates, calibration data updates, and the like.
  • the upgrade data of the target component may be reviewed by the supplier of the target component.
  • the first server may encrypt the upgrade data of the target component according to the first key by using an encryption algorithm.
  • encryption of the upgrade data of the multiple target components can be encrypted with the same key or with a different key.
  • multiple pieces of upgrade data may exist on the target component, and the first server may encrypt part of the multiple pieces of upgrade data to obtain the first ciphertext.
  • the first ciphertext can be packaged together with other unencrypted upgrade data to obtain an upgrade package, and the upgrade package is used for upgrading the target components.
  • This application exemplifies a possible scenario: the first server performs vulnerability patches and map data updates on the target components, at this time, the map data can be updated and encrypted to obtain the first ciphertext, and the vulnerability patch and the first ciphertext can be packaged to obtain upgrade package. In this way, the first server can only encrypt the data that needs to be protected by confidentiality, thereby reducing the computational pressure.
  • the first server may also package one or more pieces of upgrade data to obtain an upgrade package, and then encrypt the upgrade package.
  • the present application exemplifies another possible scenario: the first server performs vulnerability patches and map data updates on the target components, and at this time, the vulnerability patches and map data updates can be packaged to obtain an upgrade package, and the upgrade package can be encrypted to obtain the first encryption package. arts.
  • Step S302 The first server sends the first ciphertext to the OTA server.
  • the first server sends the first ciphertext to the OTA server, and correspondingly, the OTA server receives the first ciphertext from the first server.
  • the first server may send the upgrade package to the OTA server.
  • the OTA server receives the upgrade package from the first server, thereby receiving the first ciphertext in the upgrade package.
  • the first server may also send metadata of the first ciphertext or metadata (metadata) of an upgrade package where the first ciphertext is located to the OTA server.
  • the metadata is data used to describe the data attributes of the first ciphertext or the upgrade package, such as the file size of the first ciphertext, the version of the first ciphertext, and the like. This metadata can be used by the OTA server to determine upgrade strategies and the like.
  • step S303 to step S304 are as follows:
  • Step S303 The OTA server determines an upgrade strategy, where the upgrade strategy includes the first download address of the first ciphertext.
  • the first download address is used for downloading the first ciphertext or downloading an upgrade package including the first ciphertext.
  • the OTA server may allocate a first download address for the first ciphertext.
  • the first download address may be a uniform resource locator (uniform resource locator, URL).
  • the upgrade policy may further include one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the upgrade rules are used to define the upgrade order, whether to roll back and other rules.
  • the upgrade conditions can include whether the power supply is normal, storage space, network status, and the status of other devices with dependencies, etc.
  • the download rules are used to define the download rules. order, indicate which part to download, etc.
  • the OTA server determines an upgrade policy according to the information of the first terminal and/or the information of the first ciphertext (or the upgrade package in which the first ciphertext is located).
  • the information of the first terminal includes one or more items of an identification (identification, ID), model, version information, group information, address, and the like of the first terminal.
  • the information of the first ciphertext includes metadata (or attributes) of the first ciphertext, such as one or more items of a version of the first ciphertext, a file size, a storage address, and the like.
  • the information of the upgrade package where the first ciphertext is located includes one or more of the file size of the upgrade package, the storage address, the dependency of one or more pieces of data in the upgrade package, and the like.
  • the OTA server determines, according to the version information of the target component in the first terminal and the version information of the first ciphertext, that the target component on the first terminal needs to be upgraded, and then determines the first download according to the storage address of the first ciphertext address. For another example, the OTA server determines the download order of downloading the multiple upgrade data in the first terminal according to the dependencies of the multiple upgrade data in the upgrade package where the first ciphertext is located. For another example, the OTA server determines the size of the storage space required by the first terminal according to the file size of the first ciphertext.
  • the OTA server can determine the upgrade strategy, or can not determine the upgrade strategy, for example, the OTA server can send the metadata of the first ciphertext (or the upgrade package where the first ciphertext is located) For the first terminal, the first terminal determines the download strategy.
  • the specific situation depends on the implementation of the OTA server, the pre-convention or the definition of the standard.
  • Step S304 The OTA server sends the first download address to the first terminal.
  • the first download address may be used by the first terminal to download the first ciphertext from a device (for example, an OTA server, or a CDN server among multiple servers, or a NAS device, or a distributed database, etc.)
  • a device for example, an OTA server, or a CDN server among multiple servers, or a NAS device, or a distributed database, etc.
  • the OTA server may send the upgrade strategy to the first terminal, and accordingly, the first terminal receives the upgrade strategy from the OTA server, thereby obtaining the first download. address.
  • the OTA server may specifically send the upgrade strategy to the target component, and accordingly, the target component receives the upgrade strategy from the OTA upgrade master node, thereby obtaining the first download address.
  • the OTA server may specifically send the upgrade policy to the upgrade control component in the first terminal (the first download address may also be sent if the upgrade policy is not determined). Further, the upgrade control component in the first terminal may forward the upgrade policy to the target component in the first terminal.
  • the upgrade control component may be the GW
  • the target component may be the MDC
  • the OTA server may send the upgrade policy to the GW in the vehicle 203
  • the GW receives the upgrade policy
  • forwards the upgrade policy to the MDC so that the MDC can follow the Upgrade strategy to upgrade.
  • the upgrade control component may also be a component to be upgraded from other components to be upgraded in the component group for controlling the vehicle.
  • FIG. 4 is a possible vehicle architecture provided by an embodiment of the present application.
  • a vehicle integrated unit (VIU) and its connected components can be regarded as a component group, and the VIU can be regarded as an upgrade control component of a component group.
  • This application exemplifies a possible component group group1: VIU1, cockpit domain controller (CDC), ECU1.1, ECU1.2, ECU2.1, ECU2.2, Tbox, where VIU1 is the component group group1 the upgrade control part.
  • the target component is the CDC
  • the OTA server may send the first download address to the VIU1, and correspondingly, the VIU1 receives the first download address from the OTA server.
  • the component may be both the upgrade control component of the component group and the to-be-upgraded component of the component group.
  • the component group here is only an example, and the specific component group grouping depends on the specific implementation.
  • Step S305 The first terminal obtains the first ciphertext.
  • Case 1 The OTA server sends the first ciphertext to the first terminal, and accordingly, the first terminal receives the first ciphertext from the OTA server.
  • the OTA server may send the first ciphertext to the first terminal through a wired link, a wireless link, or the like.
  • the first terminal can download the first ciphertext from a device (for example, an OTA server, or a CDN server in multiple servers, or a NAS device, or a distributed database, etc.) that stores the first ciphertext through the first download address.
  • a device for example, an OTA server, or a CDN server in multiple servers, or a NAS device, or a distributed database, etc.
  • the first terminal may download the first ciphertext through a secure channel.
  • the secure channel may be a transmission channel based on a Secure Sockets Layer (SSL) protocol or a Transport Layer Security (Transport Layer Security, TLS) protocol, and is used for secure data transmission.
  • the secure channel may include one or more of a hypertext transport security protocol HTTPs secure channel, a transport layer security protocol TLS secure channel, or a datagram transport layer security (Datagram Transport Layer Security, DTLS) secure channel, and the like.
  • the first terminal when the first terminal establishes a secure channel with the device storing the first ciphertext, it may be necessary to perform relevant security configuration, so as to transmit information securely.
  • the first terminal and the device storing the first ciphertext can confirm one or more of the identity of the other party and the public-private key pair for encryption and decryption through a certificate.
  • the OTA server (or other device that stores the first ciphertext) does not modify or audit the content of the first ciphertext, which can be regarded as the OTA server (or other device that stores the first ciphertext) through transparent transmission. , and transparently transmit the first ciphertext from the first server to the first terminal.
  • Step S306 The first server sends the second key to the first terminal.
  • the second key is the decryption key of the first key.
  • the ciphertext encrypted by the first key can be decrypted by the second key to obtain the plaintext.
  • the second key and the aforementioned first key may be the same key (for example, the first key and the second key are symmetric keys), or they may be different keys (for example, the first key is a public key) , the second key is the private key).
  • the first server sends the second key to the first terminal, and accordingly, the first terminal receives the second key from the first server.
  • the second key can be used by the first terminal to decrypt the first ciphertext to obtain the upgrade data of the target component.
  • the first server may specifically send the second key to the target component in the first terminal, or may specifically send the second key to the upgrade control component in the first terminal.
  • the first server may send the second key to the first terminal in various implementation manners.
  • This embodiment exemplifies two possible implementation manners:
  • Implementation mode 1 the first server establishes a secure channel with the first terminal, and the first server sends the second key to the first terminal through the secure channel.
  • the secure channel includes one or more of an HTTPs secure channel, a TLS secure channel, or a DTLS secure channel, etc., and is used for secure data transmission.
  • the first server may distribute the address for obtaining the second key to the first terminal through the OTA server, and the first terminal may establish a secure channel with the first server according to the address of the second key.
  • the first terminal when the first terminal establishes a channel with the first server, it may be necessary to perform relevant security configuration, so as to transmit information securely.
  • the first terminal and the first server can confirm the identity of each other through the certificate, determine the public and private key pair for encryption and decryption, and so on.
  • the first server may also send data to the first terminal through other communication links that support encryption without transmitting data through a secure channel.
  • the first server may also send data to the first terminal through other communication links that support encryption without transmitting data through a secure channel.
  • it may depend on the implementation of the first server and the first terminal, a pre-agreed agreement, or the definition of a standard.
  • the security channel mentioned in the embodiments of the present application may specifically be one segment of security channel, or may be multiple segments of security channel.
  • the target component in the first terminal supports communication with the first server
  • the target component can directly establish a secure channel with the first server, so the target component can receive the first server sent by the first server through the secure channel.
  • Second key if the target component does not support establishing a secure channel directly with the first server, but supports establishing a secure channel with the upgrade control component in the first terminal.
  • the control component can establish a first section of safety channel with the first server and a second section of safety channel with the target component, so that the target component can communicate with the first server through the first section of safety channel and the second section of safety channel communication.
  • Implementation mode 2 The first server encrypts the second key by using the first security parameter to obtain the second ciphertext.
  • the first server sends the second ciphertext to the first terminal. Further, the first terminal decrypts the second ciphertext by using the second security parameter to obtain the second key.
  • the second security parameter can be used to decrypt the ciphertext encrypted by the first security parameter.
  • the first security parameter and the second security parameter may be the same parameter or different parameters.
  • the first security parameter may be a public key, a symmetric key, or a shared key negotiated between the first server and the first terminal.
  • the first terminal may determine a private key pair, and the public-private key pair includes a first public key and a first private key,
  • the first public key may be sent to the first server as the first security parameter, and the first private key may be used as the second security parameter.
  • the first security parameter (and the second security parameter) may belong to a temporary key or a one-time key.
  • a one-time key can be understood as a key that is only used once or that becomes invalid or deleted after being used once.
  • the first security parameter is deleted; after the first terminal decrypts the second ciphertext with the second security parameter, the second security parameter can be deleted.
  • the first security parameter is only used for encryption once and the second security parameter is used for decryption only once, so that the first security parameter and the second security parameter are not easily broken, and data security is improved.
  • a one-time pad may be used. That is to say, when the first server sends the second key to different terminals, the security parameters for encrypting the second key are different.
  • the first security parameter (and the subsequent second security parameter used for decrypting the second ciphertext) may be determined through negotiation between the first server and the first terminal.
  • this application exemplifies two types. Possible designs for determining the first safety parameter:
  • the first terminal determines a public and private key (including the first public key and the first private key), and the first digital certificate of the first terminal can be used to authenticate that the first public key originates from the first terminal.
  • the first terminal may send the first public key to the first server, and the first server authenticates the first public key through the first digital certificate.
  • the first public key is used as the first security parameter to encrypt the second key.
  • the above-mentioned public-private key pair may specifically be a target component or an upgrade control component in the first terminal
  • the above-mentioned first digital certificate may specifically be a digital certificate of a target component or an upgrade control component in the first terminal. .
  • the first digital certificate corresponds to the second public key and the second private key.
  • the CA can notarize the second public key of the first terminal, and encapsulate the second public key and the information of the first terminal to obtain the first digital certificate.
  • Other devices eg, the first server
  • FIG. 5 is a flowchart of a method for determining a first security parameter (and a second security parameter) provided by an embodiment of the present application, which may specifically include the following steps:
  • Step S511 The first terminal determines the first public key (PK1) and the first private key (SK1).
  • the first public key and the second private key may be specifically determined for the target component in the first terminal, or the first public key and the first private key may be determined for the upgrade control component in the first terminal.
  • Step S512 The first terminal obtains the first signature according to the second private key, the first public key and the first random number corresponding to the first digital certificate.
  • Step S513 The first terminal sends the first public key, the first random number and the first signature to the first server.
  • the first terminal may carry the first public key, the first random number and the first signature in the same message, or may carry the first public key, the first random number and the first signature in multiple messages respectively. sign.
  • the first terminal sends the first public key, the first random number and the first signature to the first server, and correspondingly, the first server receives the first public key, the first random number and the first signature from the first terminal.
  • Step S514 The first server authenticates the first public key according to the second public key corresponding to the first digital certificate.
  • the first digital certificate may be sent by the first terminal to the first server, may also be pre-configured in the first server, or may be obtained by the first server from a third-party device (such as a network-side device, a CA center, etc.) of.
  • a third-party device such as a network-side device, a CA center, etc.
  • the first server may de-sign the first signature according to the second public key corresponding to the first digital certificate, compare the de-signed result with the first public key, and if the comparison is consistent, the first public key is authenticated. Further, if the comparison is consistent, it means that the first public key really comes from the first terminal and has not been tampered with. If the comparison is inconsistent, it means that the first public key received by the first server may have been tampered with or the source is untrustworthy.
  • the first server may obtain a second digital certificate.
  • the second digital certificate can be used to authenticate the identity of the first server.
  • the second digital certificate may correspond to the third public key and the fourth public key.
  • the method shown in FIG. 5 may further include the following steps:
  • Step S515 The first server obtains the second signature according to the third private key, the first random number and the second random number corresponding to the second digital certificate.
  • Step S516 The first server sends the second random number and the second signature to the first terminal.
  • the first server may carry the second random number (NONCE2) and the second signature (S2) in the same message, or may carry the second random number and the second signature in multiple messages respectively.
  • the first server may carry the second ciphertext (C2) in the message that sends the second signature. Further optionally, the first server may also obtain a third signature (S3) according to the second signature, the second ciphertext, and the second random number, and the third signature is used for the first terminal to verify the second ciphertext.
  • Step S517 The first terminal authenticates the identity of the first server according to the second digital certificate.
  • the first terminal may de-sign the second signature according to the third public key corresponding to the second digital certificate, compare the de-signed result with the first random number and the second random number, and if the comparison is consistent, authenticate the first The identity of a server is passed.
  • the third signature when the third signature is included, the third signature may also be unsigned according to the third public key corresponding to the second digital certificate.
  • the first terminal may feed back an acknowledgement character (acknowledge character, ACK) or other acknowledgement indication information to the first server.
  • acknowledgement character acknowledgement character, ACK
  • the ACK or other confirmation indication information may be signed using the second private key.
  • the comparison is inconsistent, it means that the first random number, the second random number, or the second ciphertext has been tampered with or the source is unreliable.
  • Design 2 The first server and the first terminal determine a shared key through a key agreement algorithm, and the shared key is used as the first security parameter (second security parameter).
  • the first server may determine the identity of the other party through a pre-shared key (pre-shared key, PSK) with the first terminal.
  • PSK is a secret value shared between the first server and the first terminal.
  • the first server and the first terminal may obtain the PSK by pre-defining, pre-configuring, or generating through mutual negotiation.
  • FIG. 6 is a flowchart of another method for determining a first security parameter (and a second security parameter) provided by an embodiment of the present application, which may specifically include the following steps:
  • Step S6201 The first terminal determines the first key agreement parameter based on the key agreement algorithm.
  • the key agreement algorithm is a key agreement algorithm pre-agreed by the first terminal and the first server, or the first server may forward the identifier of the key agreement algorithm it supports to the first terminal through the OTA server for the first terminal.
  • the terminal chooses which key agreement algorithm to use.
  • Step S6202 The first terminal sends the first key negotiation parameter to the first server.
  • the first terminal may send a first message to the first server, where the first message includes the first key negotiation parameter.
  • the first message may further include a first freshness parameter (NONCE1) determined by the first terminal, an ID of the first terminal, and the like.
  • the first terminal sends the first key negotiation parameter to the first server, and correspondingly, the first server receives the first key negotiation parameter from the first terminal.
  • Step S6203 The first server obtains the shared key (the first security parameter) based on the key agreement algorithm.
  • the first server may perform deduction according to the shared key Kdh, and the deduced key may also be a shared key.
  • the shared key or other keys derived from the shared key can be used as the aforementioned first security parameter.
  • the first server may derive one or more of an encryption key, an identity authentication key, and an integrity protection key based on the shared key.
  • the encryption key Kenc determined by the first server may satisfy:
  • Kenc KDF(Kdh, NONCE1, NOCNE2, “enc")
  • NONCE1 is the first freshness parameter
  • NONCE1 is the second freshness parameter
  • NONCE1, NOCNE2, and “enc” are optional parameters, and may also include other optional parameters during specific implementation, such as the ID of the first terminal, the ID of the first server, and the like.
  • the integrity protection key Kint determined by the first server may satisfy:
  • Kenc KDF(Kdh, NONCE1, NOCNE2, “int")
  • NONCE1, NOCNE2, and “enc” are optional parameters, and may also include other optional parameters during specific implementation, such as the ID of the first terminal, the ID of the first server, and the like.
  • the integrity protection key can further be used to generate a message authentication code MAC for protecting the integrity of the message.
  • Step S6204 The first server determines the second key negotiation parameter.
  • the first server determines the calculated value B according to its own private key (b) and public key (p and g), and the calculated value B can be regarded as the second key negotiation parameter .
  • step S6205 is further included: the first server determines the first authentication parameter according to the PSK of the first server and the first terminal.
  • Step S6206 The first server sends the second key negotiation parameter to the first terminal.
  • the first terminal sends the first key negotiation parameter to the first server, and correspondingly, the first server receives the first key negotiation parameter from the first terminal.
  • the first server may send a second message to the first terminal, where the second message includes the second key negotiation parameter.
  • the second message may further include the second freshness parameter (NONCE2) determined by the first server, the first identity authentication information AUTH1, the first message authentication code MAC1, and the identification (identification, ID) of the first server. and many more.
  • the first message authentication code MAC1 is a MAC obtained through an integrity protection algorithm (or an integrity protection key) according to part or all of the data of the second message, and is used to protect the integrity of the second message.
  • Step S6207 Based on the key agreement algorithm, the first terminal determines the shared key (second security parameter) according to the second key agreement parameter.
  • Step S6208 The first terminal verifies the first authentication parameter according to the PSK of the first server and the first terminal.
  • the first terminal should also use the same parameters to generate the verification information, if the verification information is the same as the first authentication parameters , it is considered that the verification is passed.
  • the verification information check1 is the same as AUTH1
  • the first authentication parameter verification is passed.
  • the verification of the first authentication parameter it means that the PSK in the first server is consistent with the PSK in the first terminal (the identity of the first server is credible), and the first message and the second random number have not been tampered with.
  • Step S6209 The first terminal determines the second authentication parameter according to the PSK.
  • Step S6210 The first terminal sends the second authentication parameter to the first server.
  • the first server may send a third message to the first terminal, where the third message includes the second authentication parameter.
  • the third message may further include the second message authentication code MAC2 and so on determined by the first server.
  • the second message authentication code MAC2 is used to protect the integrity of the third message.
  • the second authentication parameter or the third message may also be encrypted by using an encryption key.
  • Step S6211 The first server verifies the first authentication parameter according to the PSK.
  • the first server may receive a key acquisition request from the first terminal (specifically, it may be a request message, information indicating that the second key is requested, and the application for information on name is not limited). Further, in response to the key acquisition request, the first server sends the second key to the first terminal or sends the second ciphertext to the second terminal.
  • the first server receives a key acquisition request from the first terminal, so as to obtain the first security parameter (second security parameter) through a key agreement algorithm. The first server encrypts the second key according to the first security parameter to obtain the second ciphertext, and sends the second ciphertext to the first terminal.
  • Step S307 The first terminal decrypts the first ciphertext through the second key to obtain the upgrade data of the target component.
  • the first terminal may decrypt the first ciphertext by using a decryption algorithm and a second key to obtain the upgrade data.
  • the first server may indicate the encryption algorithm to be used in the upgrade policy through the OTA server, so that the first terminal uses the corresponding decryption algorithm to decrypt.
  • the first server may send indication information when sending the second key, which is used to indicate the used encryption algorithm, so that the first terminal uses the corresponding decryption algorithm to decrypt.
  • Step S308 The first terminal upgrades the target component according to the upgrade data of the target component.
  • the first ciphertext can be decrypted specifically for the upgrade control component or the target component in the first terminal, and then the upgrade control component or the target component can be upgraded according to the upgrade data.
  • Case 1 The upgrade control component in the first terminal receives the first ciphertext sent by the OTA server, and the upgrade control component forwards the first ciphertext to the target component in the first terminal.
  • the upgrade control component in the first terminal receives the second key sent by the first server, and the upgrade control component forwards the second key to the target component in the first terminal.
  • the target component decrypts the first ciphertext according to the second key to obtain upgrade data.
  • the target component upgrades itself according to the upgrade data. It can be understood that the target component itself may not have the ability to transmit data with the OTA server or with the first server. Therefore, the first ciphertext and the second key can be forwarded through the upgrade control component, and the upgrade can be used after decrypting the first ciphertext. data is updated.
  • Case 2 The upgrade control component in the first terminal receives the first ciphertext sent by the OTA server.
  • the upgrade control component receives the second key sent by the first server.
  • the upgrade control component decrypts the first ciphertext according to the second key, obtains upgrade data, and upgrades the target components according to the upgrade data. It is understandable that the target component itself may not have the decryption capability, so the upgrade data can be obtained by decrypting the upgrade control component.
  • the upgrade control component can upgrade the target components by means of data flashing or the like.
  • Case 3 The target component in the first terminal receives the first ciphertext sent by the OTA server, and the target component receives the second key sent by the first server.
  • the target component decrypts the first ciphertext according to the second key to obtain upgrade data.
  • the target component upgrades the target component according to the upgrade data.
  • the target components can be upgraded using the method described in Case 3 under the condition that they have external communication capability and decryption capability.
  • the target component can be the VIU in the vehicle, and the VIU can perform data transmission with the OTA server and the first server, so the VIU can be upgraded by the method described in the third case.
  • FIG. 7 is a schematic diagram of the operation of a possible OTA upgrade method provided by an embodiment of the present application. It can be seen that the first server 701 encrypts the upgrade data of the target component with the first key to obtain the first key. The first ciphertext is transparently transmitted to the first terminal 703 (specifically, the target component 704 or the upgrade control component 705) through the OTA server 702. The second key is then sent to the first terminal 703 (specifically, the target component 704 or the upgrade control component 705).
  • the second key when sending the second key, it can be sent through a secure channel (as shown by the line 1 in the figure), or it can be obtained by encrypting the second key with the first security parameter, and then encrypting the obtained second key.
  • the text is sent to the first terminal (as shown by the line 2 in the figure, the first terminal 703 uses the second security parameter to decrypt the second cipher text to obtain the second key).
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • FIG. 8 is a schematic flowchart of another OTA upgrade method provided by an embodiment of the present application. The method includes but is not limited to the following steps:
  • Step S801 The first server sends the metadata of the upgrade data of the target component to the OTA server.
  • Metadata also known as intermediary data and relay data, is data about data, mainly information describing data properties.
  • the source of the upgrade data of the target component may include one or more of the first download address of the upgrade data, version information, file size, storage location, the identifier of the device providing the upgrade data, the identifier of the target component, and so on.
  • the metadata can be used by the OTA server to determine an upgrade strategy and the like.
  • step S301 For the relevant description of the first server and the target component, reference may be made to the relevant description in step S301 , which will not be repeated here.
  • the embodiment shown in FIG. 8 may include steps S802 to S803, as follows:
  • Step S802 The OTA server determines an upgrade strategy.
  • the upgrade policy may include the first download address of the first ciphertext.
  • the detailed description in step S303 which is not repeated here.
  • Step S803 The OTA server sends an upgrade policy to the first terminal.
  • the OTA server sends the upgrade policy to the first terminal, and accordingly, the first terminal receives the upgrade policy from the OTA server.
  • the OTA server sends the upgrade policy to the first terminal, and accordingly, the first terminal receives the upgrade policy from the OTA server.
  • Step S804 The first server sends the upgrade data of the target component to the first terminal.
  • the first server sends the upgrade data of the target component to the first terminal, and accordingly, the first terminal receives the upgrade data of the target component sent by the first server.
  • the first server may send the upgrade data of the target component to the first terminal through a wired link, a wireless link, or the like. It can be understood that the first server can send the upgrade data of the target component to the first terminal through the CDN.
  • the first terminal may acquire a first download address of the upgrade data of the target component, where the first download address is used for the first terminal to receive the upgrade data from the first server.
  • the first terminal may establish a secure channel with the first server through the download address of the upgrade data of the target component.
  • the first server sends the upgrade data of the target component to the first terminal through the safe channel, and correspondingly, the first terminal receives the upgrade data of the target component through the safe channel.
  • the secure channel may include one or more of the Hypertext Transport Security Protocol (HTTPs) secure channel, the Transport Layer Security (TLS) secure channel, or the Packet Transport Layer Security (DTLS) secure channel, etc., for secure data transmission.
  • HTTPs Hypertext Transport Security Protocol
  • TLS Transport Layer Security
  • DTLS Packet Transport Layer Security
  • Step S805 The first terminal upgrades the target component according to the upgrade data of the target component.
  • step S308 For details, reference may be made to the relevant description in step S308, which will not be repeated here.
  • FIG. 9 is a schematic diagram of the operation of another possible OTA upgrade method provided by the embodiment of the present application.
  • the first server 901 sends the metadata of the upgrade data of the target component to the OTA server 902, and the OTA
  • the server 902 sends the first download address to the first terminal 903 (specifically, the target component 904 or the upgrade control component 905).
  • the first terminal 902 (specifically, the target component 904 or the upgrade control component 905 ) downloads the upgrade data of the target component 904 from the first server through the first download address, thereby upgrading the target component 904 .
  • the first terminal downloads the upgrade data from the first server through the first download address, thereby preventing other intermediate devices (such as OTA servers) from acquiring the upgrade data of the target components, ensuring that Confidentiality of upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target component is directly obtained from the first server, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade efficiency is improved.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • FIG. 10 is a schematic flowchart of another OTA upgrade method provided by the embodiment of the application in FIG. 10. The method includes but is not limited to the following steps:
  • Step S1001 The first server encrypts the upgrade data of the target component according to the first key to obtain the first ciphertext.
  • step S301 For details, reference may be made to the relevant description in step S301, which will not be repeated here.
  • Step S1002 The first server encrypts the second key with the first security parameter to obtain the second ciphertext.
  • the first security parameter is the shared key between the first server and the first terminal (or specifically the first target component or upgrade control component in the first terminal) or the first terminal (or specifically the first terminal) the first public key of the first target component in the terminal or the upgrade control component).
  • the first target component is one of the target components.
  • the first security parameter may be preset in the first server.
  • the first target component is preconfigured with a first private key (or a first public key that also includes the first private key)
  • the first server may be preconfigured with a first public key
  • the first server uses the first public key key to encrypt the second key to obtain the second ciphertext.
  • the subsequent first target component can decrypt the second ciphertext by using the preconfigured first private key.
  • the first security parameter may also be predetermined by the first server and the first terminal through negotiation.
  • the first server and the first terminal determine the first security parameter (the second security parameter) in the manner shown in FIG. 5 or FIG. 6 .
  • the second key is the decryption key of the first key, and the ciphertext encrypted by the first key can be decrypted using the second key to obtain the plaintext.
  • the first key and the second key may be different keys (asymmetric key) or the same key (symmetric key), depending on the type of algorithm used to encrypt the first ciphertext.
  • a second target component is configured on the second terminal, and the second target component may be one of the target components.
  • the first server can encrypt the upgrade data of the target component through the third security parameter to obtain a third ciphertext, and the third ciphertext is used for the second terminal to upgrade the second target component.
  • the third security parameter may be the shared key between the first server and the second terminal (or specifically the target component in the second terminal), or the second terminal (or specifically the target in the second terminal) component) of the fourth public key.
  • the third security parameter is generally different from the first security parameter, but in some implementation situations, the third security parameter and the first security parameter may also be the same.
  • the same shared key or the same private key is preconfigured in a batch of target parts (including the first target part and the second target part) key, so that the first security parameter and the third security parameter used when encrypting the second key are the same.
  • Step S1003 The first server sends the first ciphertext and the second ciphertext to the OTA server.
  • the first server may carry the first ciphertext and the second ciphertext in the same message, or may carry the first ciphertext and the second ciphertext in multiple messages respectively.
  • An action is written here for the convenience of description, and is not intended to be limited to be sent in the same message.
  • the first server may also send the third ciphertext to the OTA server.
  • the first server may also send the indication information of the first terminal corresponding to the second ciphertext (or specifically the indication information of the first target component on the first terminal) to the OTA server, so that the first server can store the first terminal.
  • the second ciphertext is sent to the first terminal.
  • step S1004 to step S105 may include one or more steps from step S1004 to step S105, and step S1004 to step S1005 are as follows:
  • Step S1004 The OTA server determines an upgrade strategy, and the upgrade strategy includes the first download address of the first ciphertext and the second ciphertext.
  • the first download address is used to download the first ciphertext or an upgrade package containing the first ciphertext, and may also be used to download the second ciphertext.
  • the first download address may be a uniform resource locator (uniform resource locator, URL).
  • the first download address may specifically include two addresses, wherein one address is used for downloading the first ciphertext (or downloading an upgrade package including the first ciphertext), and the other address is used for downloading the second ciphertext.
  • step S303 For a detailed description of the upgrade strategy, reference may be made to the detailed description in step S303, which will not be repeated here.
  • the OTA server may determine that the second component needs to be upgraded according to the version information of the second component in the second terminal.
  • the OTA server sends the download address of the first ciphertext and the download address of the third ciphertext to the second terminal.
  • step S303 For other more contents, reference may be made to the relevant description in step S303, which will not be repeated here.
  • Step S1005 The OTA server sends the first download address to the first terminal.
  • the first download address may be used by the first terminal from a device that stores the first ciphertext (second ciphertext) (for example, an OTA server, or a CDN server among multiple servers, or a NAS device, or a distributed database, etc.) to download the first ciphertext (second ciphertext).
  • a device that stores the first ciphertext for example, an OTA server, or a CDN server among multiple servers, or a NAS device, or a distributed database, etc.
  • the OTA server may also send the second download address of the third ciphertext to the third terminal, where the second download address is used for the second terminal. Download the third ciphertext. Further optionally, the download address of the first ciphertext may be the same as the download address of the first ciphertext.
  • Step S1006 The first terminal acquires the first ciphertext and the second ciphertext.
  • This application exemplifies two possible cases where the first terminal obtains the first ciphertext and the second ciphertext:
  • Case 1 The OTA server sends the first ciphertext and the second ciphertext to the first terminal, and correspondingly, the first terminal receives the first ciphertext and the second ciphertext from the OTA server.
  • the first terminal may receive the first ciphertext and the second ciphertext sent by the first server through a wired link, a wireless link, or the like.
  • the first ciphertext and the second ciphertext may be carried in the same message, or may be carried separately in different messages.
  • the first terminal can download the first ciphertext from a device (for example, an OTA server, or a CDN server in multiple servers, or a NAS device, or a distributed database, etc.) that stores the first ciphertext through the first download address.
  • a device for example, an OTA server, or a CDN server in multiple servers, or a NAS device, or a distributed database, etc.
  • the first terminal may download the first ciphertext (the second ciphertext) through a secure channel.
  • the first terminal may download the first ciphertext (the second ciphertext) through a secure channel.
  • the first terminal may establishes a secure channel with the device storing the first ciphertext (the second ciphertext)
  • the OTA server (or other device that stores the first ciphertext) does not modify or audit the content of the first ciphertext, which can be regarded as the OTA server (or other device that stores the first ciphertext) through transparent transmission way, the first ciphertext (the second ciphertext) is transparently transmitted from the first server to the first terminal.
  • Step S1007 The first terminal decrypts the second ciphertext through the second security parameter to obtain the second key.
  • the second security parameter can decrypt the ciphertext encrypted by the first security parameter.
  • the second security parameter and the second security parameter may be the same (for example, a shared key) or different (for example, the first security parameter is a public key, and the second security parameter is a private key).
  • the first terminal can decrypt the second ciphertext by using the decryption algorithm and the second security parameter to obtain the second key.
  • Step S1008 The first terminal decrypts the first ciphertext through the second key to obtain the upgrade data of the first target component.
  • step S307 For details, refer to the relevant description in step S307, which is not repeated here.
  • Step S1009 The first terminal upgrades the first target component through the upgrade data of the first target component.
  • step S308 For details, refer to the relevant description in step S308, which is not repeated here.
  • the third terminal can obtain the first ciphertext and the third ciphertext, and use the fourth security parameter to decrypt the third ciphertext. , get the second key. Decrypt the first ciphertext through the second key to obtain the upgrade data of the second target component.
  • FIG. 11 is a schematic diagram of the operation of another possible OTA upgrade system provided by an embodiment of the present application.
  • the first server 1101 encrypts the target component (including the first target component 1104 and the The upgrade data of the second target component 1107) to obtain the first ciphertext.
  • the first server 1101 uses the first security parameter to encrypt the second key to obtain the second ciphertext, and uses the third security parameter to encrypt the second key to obtain the third ciphertext.
  • the first server 1101 sends the first ciphertext, the second ciphertext (as shown by the line of 1 in the figure), and the third ciphertext (as shown by the line of 2 in the figure) to the OTA server 1102 .
  • the OTA server 1101 sends the first ciphertext to the first terminal 1103 (specifically, the first target component 1104 or the first upgrade control component 1105) and the second terminal 1106 (specifically, the second target component 1107 or the second Upgrade control unit 1108).
  • the OTA server 1101 sends the second ciphertext to the first terminal 1103, so that the first terminal 1103 decrypts the second ciphertext using the second security parameter to obtain the second key.
  • the OTA server sends the third ciphertext to the second terminal 1106, so that the second terminal 1106 decrypts the third ciphertext using the fourth security parameter to obtain the second key.
  • the second key can be used by the first terminal and the second terminal to decrypt the first ciphertext to obtain the upgrade data of the upgrade target component.
  • the second key is encrypted by using the first security parameter, and the data size of the key is usually smaller than the data size of the upgrade data. Therefore, for a supplier who has multiple or multiple parts to be upgraded, considering the situation that the security parameters of the multiple parts may be different, compared with directly encrypting the upgrade data using the security parameters, this embodiment can significantly reduce the The amount of calculation and storage in the encryption process improves the efficiency of the upgrade.
  • Figure 12 is a schematic flowchart of another OTA upgrade method provided by an embodiment of the present application, and the method includes but is not limited to the following steps:
  • Step S1201 The first server encrypts the upgrade data of the target component by using the first security parameter to obtain the first ciphertext.
  • the first security parameter is the shared key between the first server and the first terminal (or specifically the target component in the first terminal) or the first terminal (or specifically the target component in the first terminal) ) of the first public key.
  • the first security parameter may be pre-configured, pre-defined in the first server, or generated through negotiation.
  • the supplier configures the target component with a shared key (first security parameter) with the first server when producing the target component, and the first server can use the preset shared secret when sending the upgrade data.
  • the key encrypts the upgrade data in the zero part of the target.
  • the first terminal is pre-configured with a first private key (or a first public key that also includes the first private key), the first server can obtain the first public key of the first terminal, and the first server can obtain the first public key of the first terminal through the first public key.
  • the public key encrypts the upgrade data of the target component to obtain the first ciphertext.
  • the first terminal may decrypt the first ciphertext by using the preconfigured first private key.
  • the safety parameters corresponding to the same type or the same batch of target parts may be the same.
  • the security parameters corresponding to different target components may also be different, depending on the implementation of the first server and the first terminal.
  • the target component is a component to be upgraded in the first terminal.
  • the target component is a component to be upgraded in the first terminal.
  • the first server may encrypt the upgrade data of the target component according to the first security parameter by using an encryption algorithm.
  • multiple pieces of upgrade data may exist on the target component, and the first server may encrypt part of the multiple pieces of upgrade data to obtain the first ciphertext.
  • the first ciphertext can be packaged together with other unencrypted upgrade data to obtain an upgrade package, and the upgrade package is used for upgrading the target components.
  • the first server can only encrypt the data that needs to be protected by confidentiality, thereby reducing the computing pressure of the server.
  • the first server may also package one or more pieces of upgrade data to obtain an upgrade package, and then encrypt the upgrade package.
  • Step S1202 The first server sends the first ciphertext to the OTA server.
  • step S302 For details, refer to the detailed description in step S302, which is not repeated here.
  • the embodiment shown in FIG. 12 may include one or more steps from step S1203 to step S1204, and the details of step S1203 to step S1204 are as follows:
  • Step S1203 The OTA server determines an upgrade strategy, and the upgrade strategy includes the first download address of the first ciphertext.
  • step S303 For details, refer to the detailed description in step S303, which is not repeated here.
  • Step S1204 The OTA server sends the first download address to the first terminal.
  • step S304 For details, refer to the detailed description in step S304, which is not repeated here.
  • Step S1205 The first terminal obtains the first ciphertext.
  • step S305 For details, refer to the detailed description in step S305, which is not repeated here.
  • Step S1206 The first terminal decrypts the first ciphertext through the second security parameter to obtain the upgrade data of the target component.
  • the second security parameter can decrypt the ciphertext encrypted by the first security parameter.
  • the second security parameter and the second security parameter may be the same value (for example, a shared key), or may be different values (for example, the first security parameter is a public key, and the second security parameter is a private key) .
  • the first terminal may decrypt the first ciphertext by using the second security parameter through a decryption algorithm to obtain the upgrade data.
  • the OTA server may indicate the encryption algorithm to be used in the upgrade policy, so that the first terminal uses the corresponding decryption algorithm to decrypt.
  • the first server may send indication information when sending the second key, which is used to indicate the used encryption algorithm, so that the first terminal uses the corresponding decryption algorithm to decrypt.
  • Step S1207 The first terminal upgrades the target component by using the upgrade data of the target component.
  • step S308 For details, refer to the detailed description in step S308, which is not repeated here.
  • the first security parameter and the second security parameter may be pre-configured or pre-acquired
  • the first server uses the first security parameter to encrypt the upgrade data of the target component
  • the first terminal uses the first security parameter to encrypt the upgrade data of the target component.
  • the second security parameter decrypts the first ciphertext to obtain the upgrade data of the target component. Since the upgrade data of the target parts and components are encrypted and transmitted, without obtaining the second security parameters, the second ciphertext cannot be decrypted to obtain the second key, and the first ciphertext cannot be decrypted to obtain the upgrade data of the target parts. Confidentiality of upgrade data. When the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • FIG. 13 is a schematic structural diagram of an OTA upgrade apparatus 130 provided by an embodiment of the present application.
  • the OTA upgrade apparatus 130 may include one or more of a processing unit 1301 , a sending unit 1302 , and a receiving unit.
  • the OTA upgrade device 130 is used to implement the aforementioned OTA method, for example, can be used to implement the OTA upgrade method shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the division of multiple units or modules is only a logical division based on functions, and is not a limitation on the specific structure of the apparatus.
  • some of the functional modules may be subdivided into more small functional modules, and some functional modules may also be combined into one functional module, but no matter whether these functional modules are subdivided or combined, in the implementation of the OTA upgrade method
  • the general process performed in the process is the same.
  • the sending unit 1302 and the receiving unit 1303 in the above-mentioned apparatus 130 may also be combined into a communication unit, and the communication unit is used to realize the function of receiving or sending data.
  • each unit corresponds to its own program code (or program instruction), and when the program code corresponding to each of these units is executed on at least one processor, the unit executes a corresponding process to realize a corresponding function.
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the first server in the embodiment shown in FIG. 3 , or a device in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 130 may include a processing unit 1301 and a sending unit 1302, wherein:
  • Described processing unit 1301 is used for encrypting the upgrade data of target parts and components according to the first key to obtain the first ciphertext, wherein, described first server is the server for providing the upgrade data of described target parts and components;
  • the sending unit 1302 is configured to send the first ciphertext to the OTA server;
  • the sending unit 1302 is further configured to send a second key to the first terminal on which the target component is deployed, where the second key is a decryption key corresponding to the first key.
  • the upgrade data of the target component is encrypted and transmitted, only the OTA upgrade device 130 and the first terminal can obtain the upgrade data through the second key, which avoids other intermediate devices from obtaining the upgrade data, and improves the performance of the upgrade data. Confidentiality of upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • the above-mentioned OTA upgrade device 130 belongs to a device used by the supplier of the target component to maintain the target component.
  • processing unit 1301 is further configured to establish a secure channel with the first terminal on which the target component is deployed;
  • the sending unit 1302 is further configured to send the second key to the first terminal through the secure channel.
  • the processing unit 1301 is further configured to encrypt the second key according to a first security parameter to obtain a second ciphertext, where the first security parameter is the first server and the The shared key between the first terminals or the first public key of the first terminal;
  • the sending unit 1302 is further configured to send the second ciphertext to the first terminal on which the target component is deployed.
  • the apparatus 130 further includes:
  • a receiving unit 1303, configured to receive a key acquisition request from the first terminal.
  • the first security parameter belongs to a temporary key or to a one-time key.
  • the first security parameter is the first public key of the first terminal; the receiving unit 1303 is further configured to receive the first terminal sent by the first terminal 's first public key;
  • the processing unit 1301 is further configured to authenticate the first public key of the first terminal through the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key;
  • the receiving unit 1303 is further configured to receive a first signature sent from the first terminal, so The first signature is obtained by using the second private key to sign the first public key;
  • the processing unit 1301 is further configured to determine that the first public key has passed the authentication according to the second public key, the first signature and the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the processing unit 1301 is further configured to:
  • the identity of the first terminal is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • the receiving unit 1303 is further configured to receive a first message sent by the first terminal, where the first information includes a first random number;
  • the sending unit 1302 is further configured to send a second message to the first terminal, where the second information includes a first authentication parameter and a second random number; the first authentication parameter is based on the first message, obtained from the second random number and the PSK;
  • the receiving unit 1303 is further configured to receive a third message sent by the first terminal, where the third message includes a second authentication parameter;
  • the processing unit 1301 is specifically configured to determine, according to the second message, the first random number and the PSK, that the identity authentication of the target component has passed.
  • the sending unit 1302 is specifically configured to:
  • the second key is sent to the target component of the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the first terminal in the embodiment shown in FIG. 3 , or a device in the first terminal, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 130 may include a receiving unit 1303 and a processing unit 1301, wherein:
  • the receiving unit 1303 is configured to receive the first ciphertext sent by the OTA server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key , the first server is a server for providing upgrade data of the target component;
  • the receiving unit 1303 is further configured to receive a second key from the first server, where the second key is a decryption key corresponding to the first key;
  • the processing unit 1301 is further configured to decrypt the first ciphertext through the second key to obtain the upgrade data of the target component;
  • the processing sheet 1301 is further configured to upgrade the target component through the upgrade data of the target component.
  • the upgrade data of the target component is encrypted and transmitted, only the first server and the OTA upgrade device 130 can obtain the upgrade data through the second key, which avoids other intermediate devices from obtaining the upgrade data, and improves the performance of the upgrade data. Confidentiality of upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • processing unit 1301 is further configured to establish a secure channel with the first server
  • the receiving unit 1303 is specifically configured to receive the second key of the first server through the secure channel.
  • the receiving unit 1303 is specifically configured to receive the second ciphertext from the first server; the second ciphertext is obtained by encrypting the second key according to the first security parameter;
  • the processing unit 1301 is further configured to decrypt the second ciphertext according to a second security parameter to obtain the second key, and the second security parameter is between the first server and the first terminal. the shared key or the first private key of the first terminal.
  • the apparatus 130 further includes:
  • the sending unit 1302 is configured to send a key acquisition request to the first server.
  • the second security parameter belongs to a temporary key or a one-time key.
  • the second security parameter is a first private key corresponding to the first public key
  • the first security parameter is a first public key of the first terminal
  • the first public key is authenticated by the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key
  • the processing unit 1301 is further configured to determine the first public key and the first private key
  • the processing unit 1301 is further configured to sign the first public key by using the second private key to obtain a first signature
  • the sending unit 1302 is further configured to send the first signature and the first public key to the first server; the first signature is used by the first server according to the second signature corresponding to the first signature certificate.
  • the public key authenticates the first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the processing unit 1301 is further configured to:
  • the identity of the first server is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • the sending unit 1302 is further configured to send a first message to the first server, where the first message includes a first random number;
  • the receiving unit 1303 is further configured to receive a second message sent by the first server, where the second message includes a first authentication parameter and a second random number;
  • the processing unit 1301 is specifically configured to determine that the identity authentication of the first server has passed according to the first authentication parameter, the first message, the second random number and the PSK;
  • the sending unit 1302 is further configured to send a third message to the first server, where the third message includes a second authentication parameter; the second authentication parameter is based on the first random number, the second message and the PSK obtained.
  • the second authentication parameter is used to authenticate the identity of the first terminal.
  • the OTA upgrade device 130 is specifically the target component in the first terminal
  • the OTA upgrade apparatus 130 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the OTA server in the embodiment shown in FIG. 3 , or a device in the OTA server, such as a chip or an integrated circuit.
  • the OTA upgrade device 130 may include a receiving unit 1303 and a sending unit 1302, wherein:
  • the receiving unit 1303 is configured to receive the first ciphertext from the first server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key.
  • the first server is a server for providing upgrade data of the target component;
  • the sending unit 1302 is configured to send an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the above-mentioned OTA upgrade device 130 can receive the ciphertext and forward the download address so that the first terminal obtains the first ciphertext, but the above-mentioned OTA upgrade device 130 Unable to obtain decryption key.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • the sending unit 1302 is specifically configured to send the first ciphertext to the first terminal through the secure channel, where the secure channel is the first terminal based on the The first download address is jointly established with the OTA server.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the upgrade rules are used to define the upgrade order, whether to roll back and other rules.
  • the upgrade conditions can include whether the power supply is normal, storage space, network status, and the status of other devices with dependencies, etc.
  • the download rules are used to define the download rules. order, indicate which part to download, etc.
  • the apparatus 130 further includes:
  • the processing unit 1301 is configured to determine the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • the OTA server determines the size of the storage space required by the first terminal according to the information of the first terminal and the file size of the first ciphertext.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • FIG. 14 is a schematic structural diagram of an OTA upgrade apparatus 140 provided by an embodiment of the present application.
  • the OTA upgrade apparatus 140 may include at least one of a sending unit 1401 and a processing unit 1402 .
  • the OTA upgrade device 140 is used to implement the aforementioned OTA method, for example, can be used to implement the OTA upgrade method shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the OTA upgrade apparatus 140 shown in FIG. 14 may be the first server in the embodiment shown in FIG. 8 , or a device in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 140 may include a sending unit 1401, wherein:
  • the sending unit 1401 is configured to send the metadata of the upgrade data of the target component to the OTA server, where the metadata of the upgrade data includes the first download address of the upgrade data and the version information of the upgrade data;
  • the sending unit 1401 is further configured to send the upgrade data of the target component to the first terminal on which the target component is deployed through a secure channel, where the secure channel is for the first terminal to download the target component according to the first download.
  • the address is jointly established with the first server.
  • the OTA upgrade apparatus 140 sends the metadata of the upgrade data to the OTA server, and the OTA server sends the first download address of the upgrade data to the first terminal.
  • the first terminal downloads the upgrade data through the first download address, which prevents other intermediate devices (eg, an OTA server) from acquiring the upgrade data of the target component, and ensures the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target parts and components are directly obtained from the storage device corresponding to the download address, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade process is improved. efficiency.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • the OTA upgrade device further includes:
  • the processing unit 1402 is configured to determine the metadata of the upgrade data of the target component.
  • the sending unit 1401 is specifically configured to:
  • the upgrade data of the target component is sent to the upgrade control component in the first terminal through the secure channel.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • FIG. 15 is a schematic structural diagram of an OTA upgrade apparatus 150 provided by an embodiment of the present application.
  • the OTA upgrade apparatus 150 may include a receiving unit 1501 and a processing unit 1502 .
  • the OTA upgrade device 140 is used to implement the aforementioned OTA method, for example, can be used to implement the OTA upgrade method shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the OTA upgrade apparatus 150 shown in FIG. 15 may be the first terminal in the embodiment shown in FIG. 8 , or a device in the first terminal, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 150 may include a receiving unit 1501 and a processing unit 1502, wherein:
  • the receiving unit 1501 is configured to receive a download strategy sent by the OTA server, where the download strategy includes the first download address of the upgrade data of the target component; the target component is deployed on the first terminal;
  • the processing unit 1502 is configured to jointly establish a secure channel with a first server based on the first download address, where the first server is a server for providing upgrade data of the target component;
  • the processing unit 1502 is further configured to receive, through the secure channel, the upgrade data of the target component sent by the first server;
  • the processing unit 1502 is further configured to upgrade the target component according to the upgrade data of the target component.
  • the above-mentioned OTA upgrade apparatus downloads the upgrade data through the first download address, which prevents other intermediate devices (eg, OTA server) from acquiring the upgrade data of the target components, and ensures the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target component is directly obtained from the first server, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade efficiency is improved.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the OTA upgrade apparatus 150 may specifically be the target component in the first terminal;
  • the OTA upgrade apparatus 150 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the OTA server in the embodiment shown in FIG. 8 , or a device in the OTA server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 130 may include a receiving unit 1303 and a sending unit 1302, wherein:
  • the receiving unit 1303 is configured to receive the metadata of the upgrade data of the target component sent by the first server, wherein the first server is a server for providing the upgrade data of the target component, and the upgrade data
  • the metadata contains the first download address of the upgrade data and the version information of the upgrade data
  • the sending unit 1302 is configured to send an upgrade policy to the first terminal, where the upgrade policy includes the first download address.
  • the OTA upgrade device 130 receives the metadata of the upgrade data and forwards the download address of the upgrade data to the upgrade policy, but cannot obtain the upgrade data, thereby ensuring the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the first terminal can download the upgrade data from the first server or other storage devices according to the first download address, thus avoiding operations such as dumping or auditing by intermediate devices, etc., reducing the complexity of the upgrade process and improving the performance of the upgrade process. Upgrade efficiency.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the apparatus 130 further includes:
  • the processing unit 1301 is configured to determine the upgrade strategy according to the information of the first terminal and/or the metadata of the upgrade data.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the metadata further includes the file size of the upgrade data of the target component.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • the OTA upgrade apparatus 140 shown in FIG. 14 may be the first server in the embodiment shown in FIG. 10 , or a device in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 140 may include a processing unit 1402 and a sending unit 1401, wherein:
  • the processing unit 1402 is configured to encrypt the upgrade data of the target component according to the first key to obtain a first ciphertext, wherein the first server is a server for providing the upgrade data of the target component;
  • the processing unit 1402 is configured to obtain a second ciphertext by encrypting a second key of a first security parameter, where the first security parameter is a shared secret between the first server and the first terminal.
  • the first security parameter is a shared secret between the first server and the first terminal.
  • key or the first public key of the first terminal the first terminal is a terminal on which a first target component is deployed, the first target component is one of the target components, and the first target component is one of the target components.
  • the second key is the decryption key of the first key;
  • the sending unit 1401 is configured to send the first ciphertext and the second ciphertext to an OTA server, where the second ciphertext is used by the first terminal to decrypt the first ciphertext.
  • the OTA upgrade device 140 belongs to a device used by the supplier of the target component to maintain the target component.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the OTA server in the embodiment shown in FIG. 10 , or a device in the OTA server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 130 may include a receiving unit 1303 and a sending unit 1302, wherein:
  • the receiving unit 1303 is configured to receive the first ciphertext and the second ciphertext sent by the first server, wherein the first ciphertext is obtained by encrypting the upgrade data of the target component according to the first key, so The second ciphertext is obtained by encrypting the second key according to the first security parameter, and the first security parameter is the shared key between the first server and the first terminal or the shared key of the first terminal.
  • a first public key, the first terminal is a terminal on which a first target component is deployed, the first target component is one of the target components, and the second key is the first encryption key. the decryption key of the key;
  • the sending unit 1302 is configured to send the first ciphertext and the second ciphertext to the first terminal, wherein the second ciphertext is used for the first terminal to decrypt the first ciphertext , to obtain the upgrade data of the target component.
  • the upgrade data is encrypted with the first key to obtain the first ciphertext
  • the second key is encrypted with the first security parameter to obtain the second ciphertext. Since the second ciphertext cannot be decrypted to obtain the second key without obtaining the second security parameter, the upgrade data of the target component cannot be obtained by decrypting the first ciphertext, thus ensuring the security of the upgrade data of the target component.
  • the second key is encrypted by using the first security parameter, and the data size of the key is usually smaller than the data size of the upgrade data. Therefore, for a supplier who has multiple or multiple parts to be upgraded, considering the situation that the security parameters of the multiple parts may be different, compared with directly encrypting the upgrade data using the security parameters, this embodiment can significantly reduce the The amount of calculation and storage in the encryption process improves the efficiency of the upgrade.
  • the apparatus 130 further includes:
  • the processing unit 1301 is configured to generate an upgrade policy according to the attribute of the upgrade package where the first ciphertext is located and the information of the first terminal; the upgrade policy includes the values of the first ciphertext and the second ciphertext.
  • the sending unit 1302 is further configured to send the upgrade policy to the first terminal;
  • the sending unit 1302 is further configured to send the first ciphertext and the second ciphertext to the first terminal through a secure channel, where the secure channel is for the first terminal to download the address according to the first download address jointly established with the OTA server.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 150 shown in FIG. 15 may be the first terminal in the embodiment shown in FIG. 10 , or a device in the first terminal, such as a chip or an integrated circuit.
  • a first target component is deployed in the OTA upgrade apparatus 150 (or in a device where the OTA upgrade apparatus 150 is located), and the first target component is one of the target components.
  • the OTA upgrade apparatus 150 may include a receiving unit 1501 and a processing unit 1502, wherein:
  • the receiving unit 1501 is configured to receive the first ciphertext and the second ciphertext sent by the OTA server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component according to the first key , wherein the first server is a server for providing upgrade data of the target component;
  • the processing unit 1502 is configured to decrypt the second ciphertext according to the second security parameter to obtain a second key, where the second key is the decryption key of the first key, and the second security parameter is the shared key between the first server and the first terminal or the first private key of the first terminal;
  • the processing unit 1502 is further configured to decrypt the first ciphertext according to the second key to obtain the upgrade data of the target component;
  • the processing unit 1502 is further configured to upgrade the first target component according to the upgrade data of the target component.
  • the OTA upgrade apparatus 150 is specifically the first target component in the first terminal;
  • the OTA upgrade apparatus 150 is specifically an upgrade control component in the first terminal.
  • processing unit 1502 is further configured to establish a secure channel with the OTA server through the first download address;
  • the receiving unit 1501 is specifically configured to receive the first ciphertext and the second ciphertext sent by the OTA server through the secure channel.
  • the receiving unit 1501 is further configured to receive a download policy from the OTA server, where the download policy includes the first download address.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 140 shown in FIG. 14 may be the first server in the embodiment shown in FIG. 12 , or a device in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade device may be a device for providing upgrade data of the target component.
  • the OTA upgrade apparatus 140 may include a processing unit 1402 and a sending unit 1401, wherein:
  • the processing unit 1402 is configured to encrypt the upgrade data of the target component according to a first security parameter to obtain a first ciphertext, and the first security parameter is the preset first server and the first ciphertext.
  • the sending unit 1401 is configured to send the first ciphertext to an OTA server; the first ciphertext is configured to be sent by the OTA server to a first terminal to zero the target in the first terminal. Parts are upgraded.
  • the first security parameter and the second security parameter may be pre-configured or pre-acquired
  • the first server uses the first security parameter to encrypt the upgrade data of the target component
  • the first terminal uses the second security parameter.
  • the security parameter decrypts the first ciphertext to obtain the upgrade data of the target component. Since the upgrade data of the target parts and components are encrypted and transmitted, without obtaining the second security parameters, the second ciphertext cannot be decrypted to obtain the second key, and the first ciphertext cannot be decrypted to obtain the upgrade data of the target parts. Confidentiality of upgrade data. When the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • the OTA upgrade apparatus 150 shown in FIG. 15 may be the first terminal in the embodiment shown in FIG. 10 , or a device in the first terminal, such as a chip or an integrated circuit.
  • a first target component is deployed in the OTA upgrade apparatus 150 (or in a device where the OTA upgrade apparatus 150 is located), and the first target component is one of the target components.
  • the OTA upgrade apparatus 150 may include a receiving unit 1501 and a processing unit 1502, wherein:
  • the receiving unit 1501 is configured to receive the first ciphertext sent by the OTA server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component according to the first security parameter.
  • the server is a server for providing upgrade data of the target component, and the first security parameter is a shared key between the first server and the first terminal or the first security parameter of the first terminal. public key;
  • the processing unit 1502 is configured to decrypt the first ciphertext in the upgrade package according to the second security parameter to obtain the upgrade data of the target component, and the second security parameter is the shared key or the the first private key of the first terminal;
  • the processing unit 1502 is further configured to upgrade the target component according to the upgrade data of the target component.
  • the OTA upgrade apparatus 150 is specifically the target component in the first terminal;
  • the OTA upgrade apparatus 150 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • the OTA upgrade apparatus 130 shown in FIG. 13 may be the OTA server in the embodiment shown in FIG. 10 , or a device in the OTA server, such as a chip or an integrated circuit.
  • the OTA upgrade apparatus 130 may include a receiving unit 1303 and a sending unit 1302, wherein:
  • the receiving unit 1303 is configured to receive the first ciphertext from the first server, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first security parameter.
  • the first server is a server for providing upgrade data of the target component;
  • the sending unit 1302 is configured to send an upgrade policy to the first terminal, where the upgrade policy includes a first download address of the first ciphertext.
  • the sending unit 1302 is specifically configured to send the first ciphertext to the first terminal through the secure channel, where the secure channel is the first terminal based on the The first download address is jointly established with the OTA server.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the apparatus 130 further includes:
  • the processing unit 1301 is configured to determine the upgrade policy according to the information of the first terminal and/or the information of the first ciphertext.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • FIG. 16 is a schematic structural diagram of an OTA upgrade apparatus 160 provided by an embodiment of the present application.
  • the apparatus 160 may include at least one memory 1601 and at least one processor 1602 .
  • a bus 1603 may also be included.
  • a communication interface 1604 may also be included, wherein the memory 1601 , the processor 1602 and the communication interface 1604 are connected through a bus 1603 .
  • the memory 1601 is used to provide a storage space, in which data such as an operating system and computer programs can be stored.
  • the memory 1601 may be random access memory (RAM), read-only memory (ROM), erasable programmable read only memory (EPROM), or portable read-only memory One or more combinations of memory (compact disc read-only memory, CD-ROM), etc.
  • the processor 1602 is a module that performs arithmetic operations and/or logical operations, and can specifically be a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (microprocessor unit, MPU), One or more of processing modules such as Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), and Complex Programmable Logic Device (CPLD) The combination.
  • CPU central processing unit
  • GPU graphics processing unit
  • MPU microprocessor
  • ASIC Application Specific Integrated Circuit
  • FPGA Field Programmable Gate Array
  • CPLD Complex Programmable Logic Device
  • the communication interface 1604 is used to receive and/or send data to the outside, and may be a wired link interface such as an Ethernet cable, or a wireless link (Wi-Fi, Bluetooth, general wireless transmission, etc.) interface.
  • the communication interface 1604 may further include a transmitter (eg, a radio frequency transmitter, an antenna, etc.), or a receiver, etc., coupled with the interface.
  • the processor 1602 in the device 160 is configured to read the computer program stored in the memory 1601, so as to execute the aforementioned OTA upgrade method, for example, as described in any one of the embodiments in FIG. 3, FIG. 8, FIG. 10 or FIG. 12 OTA upgrade method.
  • the OTA upgrade apparatus 160 may be the first server in the embodiment shown in FIG. 3 , or a module in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade device 160 may be a device for providing upgrade data of the target component.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext is obtained by encrypting the upgrade data of the target component according to the first key, wherein the first server is a server for providing the upgrade data of the target component;
  • a second key is sent to the first terminal on which the target component is deployed through the communication interface 1604, where the second key is a decryption key corresponding to the first key.
  • the upgrade data of the target components is encrypted and transmitted, only the OTA upgrade device 160 and the first terminal can obtain the upgrade data through the second key, which avoids other intermediate devices from obtaining the upgrade data, and improves the performance of the upgrade data. Confidentiality of upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • the above-mentioned OTA upgrade device 160 belongs to a device used by the supplier of the target component to maintain the target component.
  • processor 1602 is further configured to:
  • the second key is sent to the first terminal through the communication interface 1604 through the secure channel.
  • processor 1602 is further configured to:
  • the second ciphertext is sent to the first terminal on which the target component is deployed through the communication interface 1604 .
  • processor 1602 is further configured to:
  • a key acquisition request from the first terminal is received through the communication interface 1604 .
  • the first security parameter belongs to a temporary key or a one-time key.
  • the first security parameter is the first public key of the first terminal; the processor 1602 is further configured to authenticate the security authority through the first digital certificate of the first terminal. the first public key of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key; the processor 1602 is further configured to:
  • the second public key the first signature and the first public key, it is determined that the first public key is authenticated.
  • the first security parameter is a shared key between the first server and the first terminal; the processor 1602 is further configured to:
  • the identity of the first terminal is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • processor 1602 is further configured to:
  • the second information includes a first authentication parameter and a second random number; the first authentication parameter is based on the first message, the first Two random numbers and the PSK obtained;
  • the second message the first random number and the PSK, it is determined that the identity authentication of the target component is passed.
  • processor 1602 is further configured to:
  • the second key is sent to the target component of the first terminal through the communication interface 1604 .
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • the OTA upgrade device 160 may be the first terminal in the embodiment shown in FIG. 3 , or a module in the first terminal, such as a chip or an integrated circuit.
  • target components are deployed in the OTA upgrade apparatus 160 (or in the device where the OTA upgrade apparatus 160 is located).
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext sent by the OTA server is received through the communication interface 1604, and the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key.
  • a server is a server for providing upgrade data of the target component;
  • the target component is upgraded according to the upgrade data of the target component.
  • the upgrade data of the target component is encrypted and transmitted, only the first server and the OTA upgrade device 160 can obtain the upgrade data through the second key, which avoids other intermediate devices from obtaining the upgrade data, and improves the performance of the upgrade data. Confidentiality of upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • processor 1602 is further configured to:
  • the second key of the first server is received through the secure channel through the communication interface 1604 .
  • processor 1602 is further configured to:
  • the second ciphertext is obtained by encrypting the second key according to the first security parameter
  • processor 1602 is further configured to:
  • a key acquisition request is sent to the first server through the communication interface 1604 .
  • the second security parameter belongs to a temporary key or a one-time key.
  • the second security parameter is a first private key corresponding to the first public key
  • the first security parameter is a first public key of the first terminal
  • the first public key is authenticated by the first digital certificate of the first terminal.
  • the first digital certificate corresponds to a second public key and a second private key; the processor 1602 is further configured to:
  • the first public key is signed by the second private key to obtain the first signature
  • the first signature is used by the first server to authenticate the first signature certificate according to the second public key corresponding to the first signature certificate first public key.
  • the first security parameter is a shared key between the first server and the first terminal; the processor 1602 is further configured to:
  • the identity of the first server is authenticated through a pre-shared key PSK between the first server and the first terminal, where the PSK is a secret preset between the first server and the target component value.
  • processor 1602 is further configured to:
  • the third message includes a second authentication parameter; the second authentication parameter is based on the first random number, the second message and the PSK owned.
  • the second authentication parameter is used to authenticate the identity of the first terminal.
  • the OTA upgrade device 160 is specifically the target component in the first terminal
  • the OTA upgrade apparatus 160 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • the OTA upgrade apparatus 160 may be the OTA server in the embodiment shown in FIG. 3 , or a module in the OTA server, such as a chip or an integrated circuit.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext from the first server is received through the communication interface 1604, the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first key, the The first server is a server for providing upgrade data of the target component;
  • the above-mentioned OTA upgrade device 160 can receive the ciphertext and forward the download address so that the first terminal obtains the first ciphertext, but the above-mentioned OTA upgrade device 160 Unable to get decrypt key.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data is encrypted, it can prevent attackers from tampering with the upgrade data, which improves the security of the OTA upgrade.
  • processor 1602 is further configured to:
  • the first ciphertext is sent to the first terminal through the communication interface 1604 through the secure channel, where the secure channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the upgrade rules are used to define the upgrade order, whether to roll back and other rules.
  • the upgrade conditions can include whether the power supply is normal, storage space, network status, and the status of other devices with dependencies, etc.
  • the download rules are used to define the download rules. order, indicate which part to download, etc.
  • processor 1602 is further configured to:
  • the upgrade policy is determined according to the information of the first terminal and/or the information of the first ciphertext.
  • the OTA server determines the size of the storage space required by the first terminal according to the information of the first terminal and the file size of the first ciphertext.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 3 .
  • the OTA upgrade apparatus 160 may be the first server in the embodiment shown in FIG. 8 , or a module in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade device 160 may be a device for providing upgrade data of the target component.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the upgrade data of the target component is sent to the first terminal on which the target component is deployed through the communication interface 1604 through a secure channel, and the secure channel is the connection between the first terminal and the first terminal according to the first download address.
  • a server is jointly established.
  • the OTA upgrade device 160 sends the metadata of the upgrade data to the OTA server, and the OTA server sends the first download address of the upgrade data to the first terminal.
  • the first terminal downloads the upgrade data through the first download address, which prevents other intermediate devices (eg, an OTA server) from acquiring the upgrade data of the target component, and ensures the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target parts and components are directly obtained from the storage device corresponding to the download address, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade process is improved. efficiency.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the OTA upgrade device belongs to a device used by the supplier of the target component to maintain the target component.
  • processor 1602 is further configured to:
  • Metadata of upgrade data for the target component is determined.
  • processor 1602 is further configured to:
  • the upgrade data of the target component is sent to the upgrade control component in the first terminal through the communication interface 1604 through the secure channel.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • the OTA upgrade apparatus 160 may be the first terminal in the embodiment shown in FIG. 8 , or a module in the first terminal, such as a chip or an integrated circuit.
  • target components are deployed in the OTA upgrade apparatus 160 (or in the device where the OTA upgrade apparatus 160 is located).
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the download strategy includes the first download address of the upgrade data of the target component; the target component is deployed on the first terminal;
  • the first server is a server for providing upgrade data of the target component
  • the target component is upgraded according to the upgrade data of the target component.
  • the above-mentioned OTA upgrade apparatus downloads the upgrade data through the first download address, which prevents other intermediate devices (eg, OTA server) from acquiring the upgrade data of the target components, and ensures the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the upgrade data of the target component is directly obtained from the first server, operations such as dumping or auditing by intermediate devices are avoided, the complexity of the upgrade process is reduced, and the upgrade efficiency is improved.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • the OTA upgrade device 160 may specifically be the target component in the first terminal
  • the OTA upgrade apparatus 160 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • the OTA upgrade apparatus 160 may be the OTA server in the embodiment shown in FIG. 8 , or a module in the OTA server, such as a chip or an integrated circuit.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the metadata of the upgrade data of the target component sent by the first server is received through the communication interface 1604, wherein the first server is a server for providing the upgrade data of the target component, and the metadata of the upgrade data includes The first download address of the upgrade data and the version information of the upgrade data;
  • the OTA upgrade device 160 receives the metadata of the upgrade data and forwards the download address of the upgrade data to the upgrade policy, but cannot obtain the upgrade data, thereby ensuring the confidentiality of the upgrade data.
  • the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • the first terminal can download the upgrade data from the first server or other storage devices according to the first download address, thus avoiding operations such as dumping or auditing performed by intermediate devices, etc., reducing the complexity of the upgrade process and improving the performance of the upgrade process. Upgrade efficiency.
  • the embodiments of the present application can also meet the requirements of some parts that need to be quickly upgraded.
  • processor 1602 is further configured to:
  • the upgrade policy is determined according to the information of the first terminal and/or the metadata of the upgrade data.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • the metadata further includes the file size of the upgrade data of the target component.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 8 .
  • the OTA upgrade apparatus 160 may be the first server in the embodiment shown in FIG. 10 , or a module in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade device 160 may be a device for providing upgrade data of the target component.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext is obtained by encrypting the upgrade data of the target component according to the first key, wherein the first server is a server for providing the upgrade data of the target component;
  • the second ciphertext is obtained by encrypting the second key of the first security parameter, where the first security parameter is the shared key between the first server and the first terminal or the first terminal the first public key, the first terminal is a terminal deployed with a first target component, the first target component is one of the target components, and the second key is the first target component the decryption key for the key;
  • the OTA upgrade device 160 belongs to a device used by the supplier of the target component to maintain the target component.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 160 may be the OTA server in the embodiment shown in FIG. 10 , or a module in the OTA server, such as a chip or an integrated circuit.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext and the second ciphertext sent by the first server are received through the communication interface 1604, wherein the first ciphertext is obtained by encrypting the upgrade data of the target component according to the first key, and the second ciphertext is obtained by encrypting the upgrade data of the target component.
  • the text is obtained by encrypting the second key according to the first security parameter, and the first security parameter is the shared key between the first server and the first terminal or the first public key of the first terminal.
  • the first terminal is a terminal deployed with a first target component
  • the first target component is one of the target components
  • the second key is the decryption key of the first key key
  • the upgrade data is encrypted with the first key to obtain the first ciphertext
  • the second key is encrypted with the first security parameter to obtain the second ciphertext. Since the second ciphertext cannot be decrypted to obtain the second key without obtaining the second security parameter, the upgrade data of the target component cannot be obtained by decrypting the first ciphertext, thus ensuring the security of the upgrade data of the target component.
  • the second key is encrypted by using the first security parameter, and the data size of the key is usually smaller than the data size of the upgrade data. Therefore, for a supplier who has multiple or multiple parts to be upgraded, considering the situation that the security parameters of the multiple parts may be different, compared with directly encrypting the upgrade data using the security parameters, this embodiment can significantly reduce the The amount of calculation and storage in the encryption process improves the efficiency of the upgrade.
  • processor 1602 is further configured to:
  • the upgrade policy includes the first download address of the first ciphertext and the second ciphertext;
  • the first ciphertext and the second ciphertext are sent to the first terminal through the communication interface 1604 through a secure channel, where the secure channel is for the first terminal to communicate with the OTA server according to the first download address jointly established.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 160 may be the first terminal in the embodiment shown in FIG. 10 , or a module in the first terminal, such as a chip or an integrated circuit.
  • a first target component is deployed in the OTA upgrade apparatus 160 (or in a device where the OTA upgrade apparatus 160 is located), and the first target component is one of the target components.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the second key is the decryption key of the first key
  • the second security parameter is the first server and the shared key between the first terminals or the first private key of the first terminal;
  • the first target component is upgraded according to the upgrade data of the target component.
  • the OTA upgrade device 160 is specifically the first target component in the first terminal;
  • the OTA upgrade apparatus 160 is specifically an upgrade control component in the first terminal.
  • processor 1602 is further configured to:
  • the first ciphertext and the second ciphertext sent by the OTA server are received through the communication interface 1604 through the secure channel.
  • processor 1602 is further configured to:
  • a download policy from the OTA server is received through the communication interface 1604, and the download policy includes the first download address.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 10 .
  • the OTA upgrade apparatus 160 may be the first server in the embodiment shown in FIG. 12 , or a module in the first server, such as a chip or an integrated circuit.
  • the OTA upgrade device 160 may be a device for providing upgrade data of the target component.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • a first ciphertext is obtained by encrypting the upgrade data of the target component according to a first security parameter, where the first security parameter is a preset shared key between the first server and the first terminal or is the preset first public key of the first terminal, the first server is a server for providing the upgrade data of the target component; the first terminal is the terminal on which the target component is deployed ;
  • the first ciphertext is sent to the OTA server through the communication interface 1604; the first ciphertext is used for being sent by the OTA server to the first terminal to upgrade the target component in the first terminal.
  • the first security parameter and the second security parameter may be pre-configured or pre-acquired
  • the first server uses the first security parameter to encrypt the upgrade data of the target component
  • the first terminal uses the second security parameter.
  • the security parameter decrypts the first ciphertext to obtain the upgrade data of the target component. Since the upgrade data of the target parts and components are encrypted and transmitted, without obtaining the second security parameters, the second ciphertext cannot be decrypted to obtain the second key, and the first ciphertext cannot be decrypted to obtain the upgrade data of the target parts. Confidentiality of upgrade data. When the upgrade data contains core codes and key technology implementations, it can effectively protect core assets such as confidential data and key codes.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • the OTA upgrade apparatus 160 may be the first server in the embodiment shown in FIG. 12 , or a module in the first server, such as a chip or an integrated circuit.
  • target components are deployed in the OTA upgrade apparatus 160 (or in the device where the OTA upgrade apparatus 160 is located).
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext sent by the OTA server is received through the communication interface 1604, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component according to the first security parameter, and the first server is used for a server that provides upgrade data of the target component, and the first security parameter is a shared key between the first server and the first terminal or a first public key of the first terminal;
  • the target component is upgraded according to the upgrade data of the target component.
  • the OTA upgrade device 160 is specifically the target component in the first terminal
  • the OTA upgrade apparatus 160 is specifically an upgrade control component in the first terminal.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • the OTA upgrade apparatus 160 may be the OTA server in the embodiment shown in FIG. 12 , or a module in the OTA server, such as a chip or an integrated circuit.
  • the processor 1602 in the OTA upgrade device 160 is configured to read the computer program stored in the memory 1601, to perform the following operations:
  • the first ciphertext is received from the first server through the communication interface 1604, where the first ciphertext is obtained by the first server encrypting the upgrade data of the target component on the first terminal according to the first security parameter, the
  • the first server is a server for providing upgrade data of the target component;
  • processor 1602 is further configured to:
  • the first ciphertext is sent to the first terminal through the communication interface 1604 through the secure channel, where the secure channel is jointly established by the first terminal and the OTA server based on the first download address.
  • the upgrade policy includes one or more of upgrade rules, upgrade conditions, download rules, and the like.
  • processor 1602 is further configured to:
  • the upgrade policy is determined according to the information of the first terminal and/or the information of the first ciphertext.
  • each unit in the above design may also correspond to the corresponding description of the embodiment shown in FIG. 12 .
  • An embodiment of the present application further provides a chip system, where the chip system includes at least one processor and a communication interface, where the communication interface is used for sending and/or receiving data, and the at least one processor is used for calling at least one memory A stored computer program, so that the device where the chip system is located implements the method on the first server, the OTA server or the first terminal side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the at least one processor can be one or a combination of processing modules such as CPU, GPU, MPU, ASIC, FPGA, CPLD, co-processor (to assist the central processing unit to complete corresponding processing and application), MCU, etc. .
  • the embodiment of the present application also provides an OTA upgrade system, where the OTA upgrade system includes a first server and a target component.
  • the first server is used to implement the method on the first server side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 ;
  • the target component is used to implement the method on the first terminal side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the first server may belong to the server of the supplier of the target component.
  • the embodiment of the present application further provides an OTA upgrade system, where the OTA upgrade system includes an OTA server and a first terminal.
  • the OTA server is used to implement the method on the OTA server side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 ;
  • the first terminal is used to implement the method on the first terminal side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • the embodiment of the present application further provides an OTA upgrade system, where the OTA upgrade system includes a first server, an OTA server and a first terminal.
  • the first server is used to implement the method on the first server side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 ;
  • the OTA server is used to implement the method on the OTA server side in the embodiment shown in Fig. 3, Fig. 8, Fig. 10 or Fig. 12;
  • the first terminal is used to implement the method on the first terminal side in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 .
  • Embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is run on one or more processors, FIG. 3 and FIG. 8 are implemented. , the method described in the embodiment shown in FIG. 10 or FIG. 12 .
  • the embodiment of the present application also provides a computer program product, when the computer program product is executed on one or more processors, the computer program product described in the embodiment shown in FIG. 3 , FIG. 8 , FIG. 10 or FIG. 12 is implemented. method.
  • the computer may be a general purpose computer, special purpose computer, computer network, or other programmable device.
  • the computer instructions may be stored in or transmitted over a computer-readable storage medium.
  • the computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media integrated.
  • Useful media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, DVDs), or semiconductor media (eg, solid state disks (SSDs)), and the like.
  • the modules in the device embodiments of the present application may be combined, divided, and deleted according to actual needs.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Stored Programmes (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请实施例提供一种OTA升级方法及装置，应用于通信技术、车联网领域，该方法包括：第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，第一服务器为用于提供目标零部件的升级数据的服务器；第一服务器向OTA服务器发送第一密文；第一服务器向部署有目标零部件的第一终端发送第二密钥，该第二密钥为第一密钥对应的解密密钥。本申请实施例可以保护升级数据中的涉密数据、关键代码等核心资产，提高OTA升级的安全性。该方案进一步可用于提升自动驾驶或高级驾驶辅助系统ADAS能力，具体可以应用于车联网V2X、车间通信长期演进技术LTE-V、车辆-车辆V2V等领域。

Description

一种OTA升级方法及装置 技术领域
本申请涉及车联网、通信技术领域，尤其涉及一种OTA升级方法及装置。
背景技术
随着计算机技术、网络技术等不断发展，终端的数量越来越多，人们对于终端的智能化要求、安全要求等也越来越高，终端越来越智能化和多媒体化。当前的终端中往往部署了各种各样的硬件、软件(应用)，例如，车辆中配置有智能座舱、传感系统、自动驾驶系统，也安装有车载操作系统、导航应用、影音播放应用等等。这些硬件、软件虽然使得终端的功能更加丰富，但是也更容易出现漏洞、或者需要替换为更先进的版本等等。因此，需要对终端的硬件、软件(应用)进行升级更新。
空中下载技术(Over the Air，OΤΑ)是一种通过无线网络进行数据下载的技术，现已被广泛应用于车辆、电视、手机、平板电脑、机顶盒等设备的升级。OTA技术主要通过下载OTA升级包进行自动升级(也支持通过拷贝OTA升级包到SD卡来升级)，OTA升级速度快、对数据的影响小，因此OTA升级成为了终端功能升级的主要方式。例如，对于车辆来说，车辆厂商(Original Equipment Manufacturer，OEM，或者称为原始设备制造商)通过OTA技术升级车辆的相关硬件或软件，有利于厂商减少召回成本、快速响应需求、提升用户体验。
现有的OTA升级的模式是由OEM进行主导，OEM负责审核升级包的软件版本、分发升级包。但是随着智能网联汽车发展，部分敏感部件、特殊应用等需要升级时，若将升级包交给OEM审核后通过OTA服务器下载，则可能使得零件供应商的核心技术被泄露或者涉及数据遭到曝光。
因此，如何在OTA升级时保护升级数据中的机密性，成为了本领域技术人员亟待解决的技术问题。
发明内容
本申请实施例公开了一种OTA升级方法及装置，可以保护升级数据中的涉密数据、关键代码等核心资产，提高了OTA升级的安全性。
第一方面，本申请实施例公开了一种OTA升级方法，包括：
第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述第一服务器向OTA服务器发送所述第一密文；
所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
其中，第一服务器为用于提供目标零部件的升级数据的服务器，可以是一个单独的服务器，也可以是多个服务器组成的服务器集群。目标零部件是一个待升级部件。所述第一 密钥与所述第二密钥可以是相同的密钥(例如，第一密钥和所述第二密钥为对称密钥)，也可以是不同的密钥(例如第一密钥为公钥，第二密钥为私钥)。
可以看出，第一服务器提供目标零部件的升级数据时，可以将升级数据进行加密得到第一密文，第一终端可以通过OTA服务器获取第一密文。后续第一服务器可以将第二密钥发送给第一终端，以便于第一终端解密第一密文后进行升级。由于目标零部件的升级数据是经过加密传输的，只有第一服务器、第一终端可以通过第二密钥得到升级数据，避免了其他中间设备获取升级数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
结合第一方面，在第一方面的一种可能的实施方式中，上述第一服务器属于目标零部件的供应商用于维护目标零部件的服务器。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
所述第一服务器与部署有所述目标零部件的所述第一终端建立安全通道；
所述第一服务器通过所述安全通道向所述第一终端发送所述第二密钥。
其中，安全通道可以是基于安全套接字协议(Secure Sockets Layer，SSL)或者传输层安全(Transport Layer Security，TLS)的传输通道，用于数据安全传输。由于安全通道是安全可信的信道，第一服务器与第一终端通过安全通道传输第二密钥，可以保证第二密钥的安全性。
可选的，第一服务器具体可以与第一终端中的目标零部件建立安全通道，向第一终端中的目标零部件发送第二密钥。可替换的，第一服务器具体可以与第一终端中的升级控制部件建立安全通道，向第一终端中的升级控制部件发送第二密钥。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述第一服务器向部署有所述目标零部件的所述第一终端发送所述第二密文。
其中，第一安全参数可以是公钥、或者对称密钥或者第一服务器与第一终端(或者具体为第一终端中的目标零部件或者第一终端中的升级控制部件等)协商得到的共享密钥。例如，第一终端(具体还可以为第一终端中的目标零部件或者第一终端中的升级控制部件等)可以确定一个私钥对，该公私钥对包含第一公钥和第一私钥，该第一公钥可以发送给第一服务器作为第一安全参数，而第一私钥作为第二安全参数用于第一终端解密第二密文得到第二密钥。
可选的，第一服务器具体可以向第一终端中的目标零部件发送所述第二密文。可替换的，第一服务器具体可以向第一终端中的升级控制部件发送所述第二密文。
可以看出，通过安全参数将第二密钥加密后进行传输，可以提高第二密文的机密性，从而提高升级数据的机密性。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，所述方法还包括：
所述第一服务器接收来自所述第一终端的密钥获取请求。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一安全参数属于临时密钥或者属于一次性密钥。
其中，一次性密钥可以理解为只使用一次或者使用一次后即失效或被删除的密钥。例如，第一服务器使用第一安全参数加密第二密钥后，则将第一安全参数删除；第一终端使用第二安全参数解密第二密文后，可以将该第二安全参数删除。这样一来，只使用一次第一安全参数进行加密以及只使用一次第二安全参数进行解密，从而使得该第一安全参数和第二安全参数不容易被攻破，提高数据安全性。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一安全参数为所述第一终端的第一公钥；所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，还包括：
所述第一服务器接收所述第一终端发送的所述第一终端的第一公钥；
所述第一服务器通过所述第一终端的第一数字证书认证所述第一终端的第一公钥。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述第一服务器通过所述第一终端的第一数字证书认证所述第一终端的第一公钥，包括：
所述第一服务器接收来自所述第一终端发送的第一签名，所述第一签名为使用所述第二私钥对所述第一公钥签名得到的；
所述第一服务器根据所述第二公钥、所述第一签名和所述第一公钥确定所述第一公钥认证通过。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，还包括：
所述第一服务器通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
所述第一服务器通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
可以看出，该第一安全参数(以及后续用于解密第二密文的第二安全参数)可以是第一服务器与第一终端通过密钥协商算法确定的。这样一来，不同的终端与第一服务器可以协商得到不同的安全参数，从而使得该第一安全参数和第二安全参数不容易被攻破，提高数据安全性。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一服务器通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，包括：
所述第一终端接收所述第一终端发送的第一消息，所述第一信息包含第一随机数；
所述第一服务器向所述第一终端发送第二消息，所述第二信息包含第一认证参数和第二随机数；所述第一认证参数为根据所述第一消息、所述第二随机数和所述PSK得到的；
所述第一服务器接收所述第一终端发送的第三消息，所述第三信息包含第二认证参数；
所述第一服务器根据所述第二消息、所述第一随机数和所述PSK确定所述目标零部件的身份认证通过。
结合第一方面，在第一方面的又一种可能的实施方式中，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
所述第一服务器向所述第一终端的升级控制部件发送所述第二密钥；
或者，所述第一服务器向所述第一终端的所述目标零部件发送所述第二密钥。
第二方面，本申请实施例公开了一种OTA升级方法，包括：
第一终端接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述第一终端接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
所述第一终端通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
所述第一终端通过所述目标零部件的升级数据，升级所述目标零部件。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一终端接收来自所述第一服务器的第二密钥，包括：
所述第一终端与所述第一服务器建立安全通道；
所述第一终端通过所述安全通道接收所述第一服务器的所述第二密钥。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一终端接收来自所述第一服务器发送的第二密钥，包括：
所述第一终端接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
所述第一终端根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一终端接收来自所述第一服务器的第二密钥之前，所述方法还包括：
所述第一终端向所述第一服务器发送密钥获取请求。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第二安全参数属于临时密钥或者属于一次性密钥。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述目标零部件的第一公钥；
所述第一公钥通过所述目标零部件的第一数字证书进行认证。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述第一终端接收来自所述第一服务器的第二密文之前，还包括：
所述第一终端确定所述第一公钥和所述第一私钥；
所述第一终端通过所述第二私钥对所述第一公钥进行签名，得到第一签名，
所述第一终端向所述第一服务器发送第一签名和所述第一公钥；所述第一签名用于所 述第一服务器根据所述第一签名证书对应的第二公钥认证所述第一公钥。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述第一终端根据第二安全参数解密所述第二密文，得到所述第二密钥之前，还包括：
所述第一终端通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
所述第一终端通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述第一终端之间预设的秘密值。
结合第二方面，在第二方面的又一种可能的实施方式中，所述第一终端通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，包括：
所述第一终端向所述第一服务器发送第一消息，所述第一消息包含第一随机数；
所述第一终端接收所述第一服务器发送的第二消息，所述第二消息包含第一认证参数和第二随机数；
所述第一终端根据所述第一认证参数、所述第一消息、所述第二随机数和所述PSK确定所述第一服务器的身份认证通过；
所述第一终端向所述第一服务器发送第三消息，所述第三消息包含第二认证参数；所述第二认证参数为根据所述第一随机数、所述第二消息和所述PSK得到的。所述第二认证参数用于认证所述第一终端的身份。
结合第二方面，在第二方面的又一种可能的实施方式中，所述OTA升级方法具体应用于所述第一终端中的所述目标零部件；
或者，所述第一终端中还包括升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
需要说明的是，本申请第二方面的技术方案与第一方面的方案可能存在对应，相关的有益效果可以参考第一方面的有益效果，此处不再赘述。
第三方面，本申请实施例公开了一种OTA升级方法，包括：
OTA服务器接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述OTA服务器向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
结合第三方面，在第三方面的一种可能的实施方式中，所述方法还包括：
所述OTA服务器通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
结合第三方面，在第三方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
其中，升级规则用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态、有依赖关系的其他设备的状态等，下载规则用于定义下载的顺序、指示哪一个部件进行下载等等。
结合第三方面，在第三方面的又一种可能的实施方式中，所述方法还包括：
所述OTA服务器根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
例如，OTA服务器根据第一终端的信息和第一密文的文件大小，确定所述第一终端需要的存储空间大小。
第四方面，本申请实施例公开了一种OTA升级方法，包括：
第一服务器向OTA服务器发送目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述第一服务器通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与所述第一服务器共同建立的。
可以看出，第一服务器向OTA服务器发送升级数据的元数据，OTA服务器向第一终端发送升级数据的第一下载地址。第一终端通过第一下载地址从第一服务器下载升级数据，避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是在第一服务器直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
结合第四方面，在第四方面的一种可能的实施方式中，所述第一服务器属于所述目标零部件的供应商用于维护所述目标零部件的服务器。
结合第四方面，在第四方面的又一种可能的实施方式中，所述第一服务器通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，具体可以为：
所述第一服务器通过所述安全通道向所述第一终端中的所述目标零部件发送所述目标零部件的升级数据；
或者，所述第一服务器通过所述安全通道向所述第一终端中的升级控制部件发送所述目标零部件的升级数据。
第五方面，本申请实施例公开了一种OTA升级方法，包括：
第一终端接收OTA服务器发送的下载策略，所述下载策略中包含目标零部件的升级数据的第一下载地址；所述目标零部件部署在所述第一终端上；
所述第一终端基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述第一终端通过所述安全通道接收所述第一服务器发送的所述目标零部件的升级数据；
所述第一终端根据所述目标零部件的升级数据升级所述目标零部件。
结合第五方面，在第五方面的一种可能的实施方式中，所述OTA升级方法具体应用于所述目标零部件。
结合第五方面，在第五方面的又一种可能的实施方式中，所述第一终端中还包括升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
第五方面的技术方案可能与第四方面的技术方案对应，相关的有益效果可以参考第四方面的有益效果，此处不再赘述。
第六方面，本申请实施例公开了一种OTA升级方法，包括：
OTA服务器接收第一服务器发送的目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述OTA服务器向所述第一终端发送升级策略，所述升级策略包含所述第一下载地址。
结合第六方面，在第六方面的又一种可能的实施方式中，所述方法还包括：
所述OTA服务器根据所述第一终端的信息和/或升级数据的元数据，确定所述升级策略。
结合第六方面，在第六方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
结合第六方面，在第六方面的又一种可能的实施方式中，所述元数据中还包括所述目标零部件的升级数据的文件大小。
第七方面，本申请实施例公开了一种OTA升级方法，包括：
第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述第一服务器通过第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述第一服务器向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于所述第一终端解密所述第一密文。
可以看出，由于没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了目标零部件的升级数据的安全性。
进一步的，由于没有直接对目标零部件的升级数据进行加密，而是使用第一安全参数加密第二密钥，而密钥的数据大小通常小于升级数据的数据大小。因此，对于存在有多个、多种零部件需要升级的供应商来说，考虑多个零部件的安全参数可能不同的情况，相比于直接使用安全参数加密升级数据，本实施例可以显著减少加密过程中的计算量、存储量，提高升级的效率。
结合第七方面，在第七方面的一种可能的实施方式中，所述第一服务器属于所述目标零部件的供应商用于维护所述目标零部件的服务器。
第八方面，本申请实施例公开了一种OTA升级方法，包括：
OTA服务器接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述OTA服务器向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
结合第八方面，在第八方面的一种可能的实施方式中，所述OTA服务器向所述第一终端发送所述第一密文和所述第二密文，包括：
所述OTA服务器根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
所述OTA服务器向所述第一终端发送所述升级策略；
所述OTA服务器通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
第八方面的技术方案可能与第七方面的技术方案对应，相关的有益效果可以参考第七方面的有益效果，此处不再赘述。
第九方面，本申请实施例公开了一种OTA升级方法，应用于部署有第一目标零部件的第一终端，所述第一目标零部件为目标零部件中的一个，所述方法包括：
所述第一终端接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述第一终端根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
所述第一终端根据所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
所述第一终端根据所述目标零部件的升级数据升级所述第一目标零部件。
结合第九方面，在第九方面的一种可能的实施方式中，所述OTA升级方法具体应用于所述第一终端中的所述第一目标零部件；
或者，所述OTA升级系统中的第一终端中还包括升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
进一步的，所述升级控制部件用于控制所述第一目标零部件的升级。
结合第九方面，在第九方面的又一种可能的实施方式中，所述第一终端接收OTA服务器发送的第一密文和第二密文，包括：
所述第一终端通过第一下载地址与所述OTA服务器建立安全通道；
所述第一终端通过所述安全通道接收所述OTA服务器发送的第一密文和第二密文。
结合第九方面，在第九方面的又一种可能的实施方式中，所述方法还包括：
所述第一终端接收来自所述OTA服务器的下载策略，所述下载策略中包含所述第一下载地址。
第十方面，本申请实施例公开了一种OTA升级方法，包括：
第一服务器根据第一安全参数对所述目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的所述第一服务器与所述第一终端之间的共享密钥或者为预置的所述第一终端的第一公钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；所述第一终端为部署有所述目标零部件的终端；
所述第一服务器向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
可以看出，第一安全参数和第二安全参数可以是预先配置或者预先获取的，第一服务器使用第一安全参数对目标零部件的升级数据进行加密，第一终端使用第二安全参数对第一密文解密从而获取目标零部件的升级数据。由于目标零部件的升级数据是经过加密传输的，没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
结合第十方面，在第十方面的一种可能的实施方式中，上述第一服务器属于目标零部件的供应商用于维护目标零部件的服务器。
第十一方面，本申请实施例公开了一种OTA升级方法，应用于部署有第一目标零部件的第一终端，所述第一目标零部件为目标零部件中的一个，所述方法包括：
第一终端接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述第一终端根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
所述第一终端根据所述目标零部件的升级数据升级所述目标零部件。
结合第十一方面，在第十一方面的一种可能的实现方式中，所述OTA升级方法具体应用于所述目标零部件。
结合第十一方面，在第十一方面的一种可能的实现方式中，所述第一终端上还部署有升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
第十一方面的技术方案可能与第十方面的技术方案对应，相关的有益效果可以参考第十方面的有益效果，此处不再赘述。
第十二方面，本申请实施例公开了一种OTA升级方法，包括：
OTA服务器接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一安全参数对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提 供所述目标零部件的升级数据的服务器；
所述OTA服务器向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
结合第十二方面，在第十二方面的一种可能的实施方式中，所述方法还包括：
所述OTA服务器通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
结合第十二方面，在第十二方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
结合第十二方面，在第十二方面的又一种可能的实施方式中，所述方法还包括：
所述OTA服务器根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
第十三方面，本申请实施例公开了一种OTA升级装置，所述OTA升级装置可以包括处理单元、发送单元，该OTA升级装置用于实现第一方面或者第一方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方案中，所述处理单元，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元，用于向OTA服务器发送所述第一密文；
所述发送单元，还用于向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
结合第十三方面，在第十三方面的一种可能的实施方式中，上述OTA升级装置属于目标零部件的供应商用于维护目标零部件的装置。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述处理单元，还用于与部署有所述目标零部件的所述第一终端建立安全通道；
所述发送单元，还用于通过所述安全通道向所述第一终端发送所述第二密钥。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述处理单元，还用于根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述发送单元，还用于向部署有所述目标零部件的所述第一终端发送所述第二密文。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述装置还包括：
接收单元，用于接收来自所述第一终端的密钥获取请求。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述第一安全参数属于临时密钥或者属于一次性密钥。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述第一安全参数为所述第一终端的第一公钥；所述接收单元，还用于接收所述第一终端发送的所述第一终端的第一公钥；
所述处理单元，还用于通过所述第一终端的第一数字证书认证所述第一终端的第一公 钥。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述接收单元，还用于接收来自所述第一终端发送的第一签名，所述第一签名为使用所述第二私钥对所述第一公钥签名得到的；
所述处理单元，还用于根据所述第二公钥、所述第一签名和所述第一公钥确定所述第一公钥认证通过。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元，还用于：
通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述接收单元，还用于接收所述第一终端发送的第一消息，所述第一信息包含第一随机数；
所述发送单元，还用于向所述第一终端发送第二消息，所述第二信息包含第一认证参数和第二随机数；所述第一认证参数为根据所述第一消息、所述第二随机数和所述PSK得到的；
所述接收单元，还用于接收所述第一终端发送的第三消息，所述第三信息包含第二认证参数；
所述处理单元，具体用于根据所述第二消息、所述第一随机数和所述PSK确定所述目标零部件的身份认证通过。
结合第十三方面，在第十三方面的又一种可能的实施方式中，所述发送单元，具体用于：
向所述第一终端的升级控制部件发送所述第二密钥；
或者，向所述第一终端的所述目标零部件发送所述第二密钥。
第十四方面，本申请实施例公开了一种OTA升级装置，包括接收单元、处理单元，所述OTA升级装置用于实现第二方面或者第二方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方式中，所述接收单元，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述接收单元，还用于接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
所述处理单元，还用于通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
所述处理单元，还用于通过所述目标零部件的升级数据，升级所述目标零部件。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述处理单元，还用于与所述第一服务器建立安全通道；
所述接收单元，具体用于通过所述安全通道接收所述第一服务器的所述第二密钥。
结合第十四方面，在第十四方面的又一种可能的实施方式中，
所述接收单元，具体用于接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
所述处理单元，还用于根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述装置还包括：
发送单元，用于向所述第一服务器发送密钥获取请求。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述第二安全参数属于临时密钥或者属于一次性密钥。
结合第十四方面，在第十四方面的又一种可能的实施方式中，
所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述第一终端的第一公钥；
所述第一公钥通过所述第一终端的第一数字证书进行认证。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；
所述处理单元，还用于确定所述第一公钥和所述第一私钥；
所述处理单元，还用于通过所述第二私钥对所述第一公钥进行签名，得到第一签名，
所述发送单元，还用于向所述第一服务器发送第一签名和所述第一公钥；所述第一签名用于所述第一服务器根据所述第一签名证书对应的第二公钥认证所述第一公钥。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元，还用于：
通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述发送单元，还用于向所述第一服务器发送第一消息，所述第一消息包含第一随机数；
所述接收单元，还用于接收所述第一服务器发送的第二消息，所述第二消息包含第一认证参数和第二随机数；
所述处理单元，具体用于根据所述第一认证参数、所述第一消息、所述第二随机数和所述PSK确定所述第一服务器的身份认证通过；
所述发送单元，还用于向所述第一服务器发送第三消息，所述第三消息包含第二认证参数；所述第二认证参数为根据所述第一随机数、所述第二消息和所述PSK得到的。所述第二认证参数用于认证所述第一终端的身份。
结合第十四方面，在第十四方面的又一种可能的实施方式中，所述OTA升级装置具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置具体为所述第一终端中的升级控制部件。
第十五方面，本申请实施例公开了一种OTA升级装置，包括接收单元和发送单元，所述OTA升级装置用于实现第三方面或者第三方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方式中，所述接收单元，用于接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元，用于向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
结合第十五方面，在第十五方面的一种可能的实施方式中，所述发送单元，具体用于通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
结合第十五方面，在第十五方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
其中，升级规则用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态、有依赖关系的其他设备的状态等，下载规则用于定义下载的顺序、指示哪一个部件进行下载等等。
结合第十五方面，在第十五方面的又一种可能的实施方式中，所述装置还包括：
处理单元1503，用于根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
例如，OTA服务器根据第一终端的信息和第一密文的文件大小，确定所述第一终端需要的存储空间大小。
第十六方面，本申请实施例公开了一种OTA升级装置，包括发送单元，所述OTA升级装置用于实现第四方面或者第四方面的任意一种可能的实施方式所描述的方法。所述OTA升级装置为用于提供所述目标零部件的升级数据的装置，
在一种可能的实施方式中，所述发送单元，用于向OTA服务器发送目标零部件的升级数据的元数据，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述发送单元，还用于通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与所述第一服务器共同建立的。
结合第十六方面，在第十六方面的一种可能的实施方式中，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
结合第十六方面，在第十六方面的又一种可能的实施方式中，所述OTA升级装置还包括：
处理单元，用于确定所述目标零部件的升级数据的元数据。
结合第十六方面，在第十六方面的又一种可能的实施方式中，所述发送单元，具体用于：
通过所述安全通道向所述第一终端中的所述目标零部件发送所述目标零部件的升级数 据；
或者，通过所述安全通道向所述第一终端中的升级控制部件发送所述目标零部件的升级数据。
第十七方面，本申请实施例公开了一种OTA升级装置，所述OTA升级装置包括接收单元、处理单元，所述OTA升级装置用于实现第五方面或者第五方面的任意一种可能的实施方式所描述的方法。所述OTA升级装置中部署有目标零部件。
在一种可能的实现方式中，所述接收单元，用于接收OTA服务器发送的下载策略，所述下载策略中包含目标零部件的升级数据的第一下载地址；所述目标零部件部署在所述第一终端上；
所述处理单元，用于基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述处理单元，还用于通过所述安全通道接收所述第一服务器发送的所述目标零部件的升级数据；
所述处理单元，还用于根据所述目标零部件的升级数据升级所述目标零部件。
结合第十七方面，在第十七方面的又一种可能的实施方式中，所述OTA升级装置具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置具体为所述第一终端中的升级控制部件。
第十八方面，本申请实施例公开了一种OTA升级装置，包括接收单元、发送单元，所述OTA升级装置用于实现第六方面或者第六方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方式中，所述接收单元，用于接收第一服务器发送的目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述发送单元，用于向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
结合第十八方面，在第十八方面的又一种可能的实施方式中，所述装置还包括：
处理单元，用于根据所述第一终端的信息和/或升级数据的元数据，确定所述升级策略。
结合第十八方面，在第十八方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
结合第十八方面，在第十八方面的又一种可能的实施方式中，所述元数据中还包括所述目标零部件的升级数据的文件大小。
第十九方面，本申请实施例公开了一种OTA升级装置，包括处理单元、发送单元，所述OTA装置用于实现第七方面或者第七方面的任意一种可能的实施方式所描述的方法。所述OTA升级装置可以为用于提供所述目标零部件的升级数据的装置。
在一种可能的实施方案中，所述处理单元，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据 的服务器；
所述处理单元，用于通过第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述发送单元，用于向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于所述第一终端解密所述第一密文。
结合第十九方面，在第十九方面的一种可能的实施方式中，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
第二十方面，本申请实施例公开了一种OTA升级装置，包括接收单元、发送单元，所述OTA升级装置用于实现第八方面或者第八方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方式中，所述接收单元，用于接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述发送单元，用于向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
结合第二十方面，在第二十方面的一种可能的实施方式中，所述装置，还包括：
处理单元，用于根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
所述发送单元，还用于向所述第一终端发送所述升级策略；
所述发送单元，还用于通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
第二十一方面，本申请实施例公开了一种OTA升级装置，包括接收单元、处理单元，所述OTA升级装置用于实现第九方面或者第九方面的任意一种可能的实施方式所描述的方法。其中，所述OTA升级装置中(或者OTA升级装置所在的设备中)部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个。
在一种可能的实施方式中，所述接收单元，用于接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述处理单元，用于根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
所述处理单元，还用于根据所述第二密钥解密所述第一密文，得到所述目标零部件的 升级数据；
所述处理单元，还用于根据所述目标零部件的升级数据升级所述第一目标零部件。
结合第二十一方面，在第二十一方面的一种可能的实施方式中，所述OTA升级装置具体为所述第一终端中的所述第一目标零部件；
或者，所述OTA升级装置具体为所述第一终端中的升级控制部件。
结合第二十一方面，在第二十一方面的又一种可能的实施方式中，所述处理单元，还用于通过第一下载地址与所述OTA服务器建立安全通道；
所述接收单元，具体用于通过所述安全通道接收所述OTA服务器发送的第一密文和第二密文。
结合第二十一方面，在第二十一方面的又一种可能的实施方式中，所述接收单元，还用于接收来自所述OTA服务器的下载策略，所述下载策略中包含所述第一下载地址。
第二十二方面，本申请实施例公开了一种OTA升级装置，包括处理单元、发送单元，所述OTA升级装置用于实现第十方面或者第十方面的任意一种可能的实施方式所描述的方法。所述OTA升级装置可以为用于提供所述目标零部件的升级数据的装置。
在一种可能的实施方案中，所述处理单元，用于根据第一安全参数对所述目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的所述第一服务器与所述第一终端之间的共享密钥或者为预置的所述第一终端的第一公钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；所述第一终端为部署有所述目标零部件的终端；
所述发送单元，用于向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
结合第二十二方面，在第二十二方面的一种可能的实施方式中，上述OTA升级装置属于目标零部件的供应商用于维护目标零部件的装置。
第二十三方面，本申请实施例公开了一种OTA升级装置，包括接收单元、处理单元，所述OTA升级装置用于实现第十一方面或者第十一方面的任意一种可能的实施方式所描述的方法。其中，所述OTA升级装置中部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个。
在一种可能的实现方式中，所述接收单元，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述处理单元，用于根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
所述处理单元，还用于根据所述目标零部件的升级数据升级所述目标零部件。
结合第二十三方面，在第二十三方面的又一种可能的实施方式中，所述OTA升级装置具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置具体为所述第一终端中的升级控制部件。
第二十四方面，本申请实施例公开了一种OTA升级装置，包括接收单元、发送单元，所述OTA升级装置用于实现第十二方面或者第十二方面的任意一种可能的实施方式所描述的方法。
在一种可能的实施方式中，所述接收单元，用于接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一安全参数对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元，用于向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
结合第二十四方面，在第二十四方面的一种可能的实施方式中，所述发送单元，具体用于通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
结合第二十四方面，在第二十四方面的又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
结合第二十四方面，在第二十四方面的又一种可能的实施方式中，所述装置还包括：
处理单元，用于根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
第二十五方面，本申请实施例还提供一种第一服务器，所述服务器包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述第一服务器实现第一方面或第一方面任意一种可能的实施方式所描述的方法；又或者实现第四方面或第四方面的任意一种可能的实施方式所描述的方法；又或者实现第七方面或第七方面的任意一种可能的实施方式所描述的方法；又或者实现第十一方面或第十一方面的任意一种可能的实施方式所描述的方法。
第二十六方面，本申请实施例还提供一种第一终端，所述第一终端包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述第一终端实现第二方面或第二方面任意一种可能的实施方式所描述的方法；又或者实现第五方面或第五方面的任意一种可能的实施方式所描述的方法；又或者实现第九方面或第九方面的任意一种可能的实施方式所描述的方法；又或者实现第十一方面或第十一方面的任意一种可能的实施方式所描述的方法。
可选的，所述第一终端可以为网关、整车集成单元、T-box等装置，也可以为车辆、机器人或者无人机等智能设备或者运输终端。
第二十七方面，本申请实施例还提供一种OTA服务器，所述OTA服务器包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述OTA服务器实现第三方面或第三方面任意一种可能的实施方式所描述的方法；又或者实现第六方面或第六方面的任意一种可能的实施方式所描述的方法；又或者实现第八方面或第八方面的任意一种可能的实施方式所描述的方法；又或者实现第十二方面或第十二方面的任意一种可能的实施方式所描述的方法。
第二十八方面，本申请实施例还提供一种OTA升级系统，该OTA升级系统包括第一服务器和目标零部件。其中，该第一服务器用于实现上述第一方面或者第一方面的又一种可能的实现方式所描述的方法，该目标零部件用于实现上述第二方面或者第二方面的一种可能的实现方式所描述的方法；
或者，该第一服务器用于实现上述第四方面或者第四方面的又一种可能的实现方式所描述的方法，该目标零部件用于实现上述第五方面或者第五方面的一种可能的实现方式所描述的方法；
或者，该第一服务器用于实现上述第七方面或者第七方面的又一种可能的实现方式所描述的方法，该目标零部件用于实现上述第九方面或者第九方面的一种可能的实现方式所描述的方法；
或者，该第一服务器用于实现上述第十方面或者第十方面的又一种可能的实现方式所描述的方法，该目标零部件用于实现上述第十一方面或者第十一方面的一种可能的实现方式所描述的方法。
第二十九方面，本申请实施例还提供一种OTA升级系统，该OTA升级系统包括OTA服务器和第一终端。其中，该OTA服务器用于实现上述第三方面或者第三方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第二方面或者第二方面的一种可能的实现方式所描述的方法；
或者，该OTA服务器用于实现上述第六方面或者第六方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第五方面或者第五方面的一种可能的实现方式所描述的方法；
或者，该OTA服务器用于实现上述第八方面或者第八方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第九方面或者第九方面的一种可能的实现方式所描述的方法；
或者，该OTA服务器用于实现上述第十二方面或者第十二方面的又一种可能的实现方式所描述的方法，该第一终端用于实现上述第十一方面或者第十一方面的又一种可能的实现方式所描述的方法。
第三十方面，本申请实施例公开了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现第一方面至第十二方面(或者还包括其可能的实施方式)所描述的方法。
第三十一方面，本申请实施例公开了一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现第一方面至第十二方面(或者还包括其可能的实施方式)所描述的方法。
可以理解的，本申请实施例装置侧的有益效果可以参考对应的方法侧，此处不再赘述。
附图说明
以下对本申请实施例用到的附图进行介绍。
图1是本申请实施例的一种OTA升级系统的架构示意图；
图2是本申请实施例提供的一种车辆升级系统的架构示意图；
图3是本申请实施例提供的一种OTA升级方法的流程示意图；
图4是本申请实施例提供的一种车辆的架构示意图；
图5是本申请实施例提供的一种确定第一安全参数的方法的流程示意图；
图6是本申请实施例提供的又一种确定第一安全参数的方法的流程示意图；
图7是本申请实施例提供的又一种OTA升级系统的架构示意图；
图8是本申请实施例提供的又一种OTA升级方法的流程示意图；
图9是本申请实施例提供的再一种OTA升级系统的架构示意图；
图10是本申请实施例提供的再一种OTA升级方法的流程示意图；
图11是本申请实施例提供的再一种OTA升级系统的架构示意图；
图12是本申请实施例提供的再一种OTA升级方法的流程示意图；
图13是本申请实施例提供的一种OTA升级装置的结构示意图；
图14是本申请实施例提供的又一种OTA升级装置的结构示意图；
图15是本申请实施例提供的再一种OTA升级装置的结构示意图；
图16是本申请实施例提供的再一种OTA升级装置的结构示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。需要说明的是，本申请中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其他实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
本申请中实施例提到的“至少一个”是指一个或者多个，“多个”是指两个或两个以上。“以下至少一项(个)”或其类似表达，是指的这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a、b、或c中的至少一项(个)，可以表示：a、b、c、(a和b)、(a和c)、(b和c)、或(a和b和c)，其中a、b、c可以是单个，也可以是多个。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A、同时存在A和B、单独存在B这三种情况，其中A、B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。
以及，除非有相反的说明，本申请实施例使用“第一”、“第二”等序数词是用于对多个对象进行区分，不用于限定多个对象的顺序、时序、优先级或者重要程度。例如，第一探测装置和第二探测装置，只是为了区分不同的探测装置，而并不是表示这两种装置的结构、探测原理、重要程度等的不同。
为了便于理解，下面先对本申请实施例中的部分用语进行解释说明。
一、安全算法(密码算法)
(1)散列算法
散列算法又称为哈希(hash)函数、哈希算法，散列算法可以将一段数据(例如字符串、数字、文件等)输出为一段预设长度(例如80位、或者128位等等)的散列值(散列值也可以称为哈希值、摘要值等)，且很难找到逆向规律。常见的散列算法主要有安全散列 算法(secure hash algorithm 1，SHA-1)、信息摘要(message digest，MD)算法(如MD2、MD4或MD5等)等。
(2)加密(encryption)算法
加密算法用于保护数据的机密性(confidentiality)，通常表现为对明文加密得到密文。加密算法既可以包括加密运算(例如椭圆点加运算、异或运算等)，也可以包括安全性较高的各种算法。常见的加密算法主要有异或运算、数据加密标准(data encryption standard，DES)、三重数据加密算法(triple data encryption algorithm，3DES)、高级加密标准(advanced encryption standard，AES)、RSA加密算法、数据结构分析算法(data structure analysis，DSA)等。
(3)完整性保护算法
完整性保护算法是用于保护数据完整性(data integrity)的算法，也可以称为完保算法。在一些具体实现中，完整性保护算法通常会输出消息认证码(message authentication code，MAC)，某些场景中也将完整性保护算法称为MAC算法。完整性保护算法可以通过多种哈希算法来实现，通过哈希算法来实现的完整性保护算法称为基于哈希的消息认证码(hash-based message authentication code，HMAC)算法，其中的哈希算法可以为MD5、SHA-1、SHA-256等等中的一个，这些不同的HMAC实现通常标记为：HMAC-MD5，HMAC-SHA1，HMAC-SHA256等等。
在一些具体场景中，通过认证加密算法，对与给定的原文既可以加密数据也可以生成消息认证码，因此认证加密算法既可以作为加密算法也可以作为完保算法。例如，基于GMAC和计数加密模式的AES算法(AES-Galois/counter mode，AES-GCM)和基于CMAC和计数加密模式的AES算法(AES-CMAC/counter Mode，AES-CCM)等，既可以对消息进行认证加密，认证加密的过程中也能够保护消息的完整性。
(4)密钥派生算法
密钥派生算法用于从一个秘密值中派生出一个或多个秘密值，又称为密钥导出算法。例如，通过秘密值Key派生的新的秘密值DK可以表示为：DK＝KDF(Key)。常用的密钥派生算法有基于密码的密钥派生函数(password-based key derivation function，PBKDF)、斯克里普特(scrypt)算法等，其中PBKDF算法又包括第一代PBKDF1和第二代PBKDF2。可选的，一些KDF算法在派生密钥过程中，使用哈希算法对输入的秘密值进行哈希变化，因此KDF函数还可以接收算法标识作为输入，用于指示使用何种哈希算法。
需要说明的是，KDF不仅应用于派生得到秘密值得过程，也可以应用在生成认证信息、身份信息等场景中。
(5)密钥协商算法
密钥协商是通信双方通过交互一部分参数，从而协商得到密钥的过程。用于密钥协商的算法称为密钥协商算法，也可以称为密钥交换算法。常用的密钥协商算法有迪菲赫尔曼(Diffie-Hellman，DH)算法、基于椭圆曲线密码(Elliptic Curve Cryptosystems，ECC)的迪菲赫尔曼(ECDH)算法、奥克利(Oakley)算法、国密算法(如SM1、SM2、SM3和SM4)等。
其中，以DH算法为例，两个装置使用两个数值较大的素数p和随机数g，各自产生的随机数a和b。第二装置将g的a次方mod P产生的数值A(A＝ga mod p)发送给第一装置， 第一装置将g的b次方mod p产生的数值B(B＝gb mod p)发送给第二装置，第二装置再对接收的结果做a次方运算(K＝Ba mod p)，第一装置对接收的结果做b次方运算(K＝Abmod p)，由于K＝Ab mod p＝(ga mod p)b mod p＝gab mod p＝(gb mod p)a mod p＝Ba mod p，因此第一装置和第二装置计算出的密钥K是相同的。
在这种情况下，若攻击者通过A、g、p，计算得到a的公式为：a＝loggAmodp，由于对数运算没有一个快速计算的算法，而且素数p和随机数g通常数值较大，因此攻击者很难通过A、素数p和随机数g通过对数运算和模运算得到a。因此通过DH算法得到的密钥K是具有安全性的。
其中，ECDH算法主要基于如下等式来实现：K＝k×G，其中K、G为椭圆曲线Ep(a,b)上的点，n为G的阶(nG＝O∞，O∞指无穷远点)，k为小于n的整数。在K＝kG中，对于给定的k和G，根据加法法则，计算K很容易(例如使用点加运算进行累加)。但反过来，对于给定的K和G，求k就非常困难。因为实际使用中的椭圆曲线算法原则上把p取得相当大，n也相当大，要把k个点逐一算出来与K进行比较是数学难题。
可以理解的，前述的关于算法的解释只是用于简单叙述实现的原理，并不限定使用时一定使用相同的参数进行实现。算法具体实现过程中还可以有其他的改进和变体，本申请中提到算法可以为经过改进和变体后的算法，例如ECC可以结合在DSA算法中，称为ECDSA算法。
二、新鲜性参数
新鲜性参数用于生成密钥和认证参数等，也可以称为新鲜度或新鲜参数，可以包括随机数(number once，NONCE)、计数值(counter)、序列号(serial number)、顺序号(sequence number)等等中的至少一个。其中，NONCE是一个只被使用一次的(或者说非重复的)随机数值。不同时刻生成的新鲜性参数通常不同，即新鲜性参数的具体取值，在每生成一次新鲜性参数时会发生变化，从而使得这一次生成密钥(或者认证参数等)所使用的新鲜性参数与上一次生成密钥(或者认证参数等)时所使用的新鲜性参数不同的，可以提高生成的密钥(或者认证参数等)的安全性。
例如，新鲜性参数可以是节点通过随机数发生器(random number generator)获取的随机数。
三、数字证书
数字证书(也可以称为安全证书)是标志身份的一个数字认证，通常是由证书授权(Certificate Authority，CA)中心或者受信任的第三方设备所颁发的一种较为权威与公正的证书。
例如，第一终端中存在一个长期密钥对(长期公钥PK和长期私钥SK)，CA中心为长期公钥PK做认证，CA中心用自己的私钥cpk，对该长期公钥PK和一些相关信息(例如对第二节点的描述信息)一起加密生成DC。第一终端使用证书对应的私钥生成第一公钥的签名(即“私钥签名”)，将第一公钥、第一公钥的签名以及DC发送给第一服务器，第一服务器使用CA中心的公钥csk解密证书，可以确定该DC为CA颁发的，以及确定该DC中的长期公钥PK来自第一终端，从而认证了长期公钥PK的来源。第一服务器使用长期公钥PK对第一公钥的签名进行验签(即“公钥验签”)，从而确定第一公钥来自第一终端。
下面对本申请实施例的系统架构和业务场景进行描述。需要说明的是，本申请描述的系统架构及业务场景是为了更加清楚的说明本申请的技术方案，并不构成对于本申请提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请提供的技术方案对于类似的技术问题，同样适用。
请参见图1，图1是本申请实施例提供的一种OTA升级系统的示意图，包括第一服务器101、OTA服务器(server)102、终端103，其中：
第一服务器101是具有数据处理能力的设备，可以是实体设备如主机、服务器等，也可以是虚拟设备如虚拟机、容器等。需要说明的是，此处为了便于描述称为服务器，具体实现过程中可以是服务器，也可以是其他具有数据处理能力的设备。第一服务器101为提供目标零部件的升级数据的服务器。例如，第一服务器可以属于目标零部件的供应商维护目标零部件的服务器。
OTA服务器102是OTA升级过程中，与终端进行信息交互的服务器。通常来说，OTA服务器可以指示终端需要进行某一零部件的升级，可选的，OTA服务器还可以将零部件的升级数据发送给终端。在一些具体的实施场景中，也将OTA服务器称为OTA云端。
第一终端103为部署有目标零部件104的终端。第一终端103可以通过OTA服务器102获取升级数据，从而进行升级目标零部件104。
在一种可能的设计中，目标零部件104具有数据收发能力，从而可以从OTA服务器102中获取升级数据从而进行升级。
在又一种可能的设计中，第一终端103上可以部署有升级控制部件105，该第一终端103可以通过升级控制部件105从OTA服务器102中获取升级数据。进一步的，第一终端103可以通过升级控制部件105对目标零部件104进行升级，或者通过升级控制部件105控制目标零部件104进行升级。例如，升级控制部件105用于接收升级数据、指挥升级的次序、检查升级状态、刷写升级数据等等中的一项或者多项都可以看作升级控制部件105控制目标零部件104进行升级。
在一些具体实施场景中，第一终端103的升级控制部件105具体又可以包括OTA主模块(Master)和OTA从模块(slave)，OTA主模块将从OTA服务器获取的升级包分发给终端中的一个或者多个OTA从模块，该一个或者多个OTA从模块指挥终端内的零部件安装和激活升级包，完成升级。以第一终端为车辆为例，请参见图2，图2是本申请实施例例举的一种可能的车辆升级系统的示意图，包括供应商服务器201、OTA云端202和车辆203。车辆203是基于车辆电子电气(Electrical/Electronic Architecture，E/E)架构的车辆，参见区域204，车辆203可以包括以下部件：移动数据中心(Mobile Data Center，MDC)、人机交互(Human–Machine Interaction，HMI)、网关(gateway，GW)、汽车盒子(Telematics BOX，Tbox或者称为TCU)、电子控制单元(Electronic Control Unit，ECU)等模块。其中，GW是整车电子电气架构中的核心部件，其作为整车网络的数据交互枢纽，可将控制区域网络(Controller Area Network，CAN)、局域互联网络(Local Interconnect Network，LIN)、多媒体数据传输(Media Oriented System Transport，MOST)、FlexRay等网络数据在不同网络中进行路由。MDC是汽车的智能车载计算平台。T-BOX主要用于和汽车外部、后台系 统和手机应用(application，APP)通信。HMI是汽车的信息娱乐系统。ECU是汽车专用微机控制器。在车辆203的GW中部署有升级主模块(update master，可以看作是OTA master)，车辆203的多个零部件中部署有升级从模块(update slave，可以看作是OTA slave)，GW中的升级主模块接收OTA云端202发送的升级包，将其分发给升级从模块，使得升级从模块指挥车辆内的零部件安装和激活升级包，完成对车辆203中的一个或者多个零部件的升级。
但是，现有的OTA升级时，升级的过程是由OTA服务器进行主导。该OTA服务器由OEM负责维护，也即是说，OEM负责审核软件版本、分发升级包。例如，在图2所示的架构中，供应商服务器201需要将升级包交由OTA云端202(OTA服务器)，由OTA云端202将升级包分发给需要升级的车辆203。但是随着智能网联汽车发展，部分敏感部件、特殊应用等需要升级时，若将升级包交给OEM审核后通过OTA服务器下载，则可能使得升级包的数据被泄露，可能导致零部件供应商的核心技术、关键数据被泄露或者涉密数据遭到曝光。
为了解决上述问题，本申请提出如下实施例。
请参见图3，图3是本申请实施例提供的一种OTA升级方法的流程示意图，该方法包括但不限于如下步骤：
步骤S301：第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文。
其中，目标零部件是一个待升级的部件。该目标零部件可以部署在一个或者多个终端上，例如，以终端为某一车辆为例，目标零部件可以为车辆中的GW、Tbox、VIU、DC、ECU等等，或者还可以为车辆中的媒体设备如摄像头、雷达等等，或者还可以为车辆中的软件，例如操作系统、导航软件、地图软件、监控软件等等。其中，ECU由处理器、存储器、输入/输出(I/O)接口、模数转换器(A/D)以及整形、驱动等大规模集成电路中的一个或者多个组成，可以完成多种多样的功能。
第一服务器为用于提供目标零部件的升级数据的服务器。进一步的，第一服务器可以用于目标零部件的供应商在维护目标零部件的过程中使用。本申请例举一种可能的场景：第一服务器可以是属于目标零部件的供应商的地图更新服务器，用于该供应商更新目标零部件的地图数据。
需要说明的是，本申请各实施例中提到的服务器(例如第一服务器、OTA服务器等)，可以是一个服务器、也可以是多个服务器组成的服务器集群。例如，第一服务器可以为多个服务器通过分布式架构部署的服务器集群，集群中可以包括云计算服务器、内容分发网络(Content Delivery Network，CDN)服务器、网络时间协议(Network Time Protocol，NTP)、域名解析系统(Domain Name System，DNS)服务器等等中的一个或者多个。其中，各个服务器之间可以相互协调，共同完成计算、数据存储、通信等功能，为了方便描述，本申请实施例中将单个服务器、分布式服务器、服务器集群等统称为服务器。
第一密钥可以是对称密钥，也可以是非对称密钥。具体的，通过非对称密钥加密算法进行加密的密文，加密密钥和解密的密钥通常不同。使用对称加密算法进行加密的密文，加密密钥和解密密钥相同。
目标零部件的升级数据用于对目标零部件进行升级。例如，目标零部件的升级数据可以为操作系统更新、应用软件版本更新、漏洞补丁、对地图数据的更新、标定数据更新等等。可选的，该目标零部件的升级数据可以经过目标零部件的供应商的审核。
第一服务器可以通过加密算法，根据第一密钥对目标零部件的升级数据进行加密。例如，得到的第一密文满足如下式子：第一密文＝Enc(升级数据，第一密钥)，其中，Enc为加密算法，具体可以为DES算法、AES算法等等中的一个或者多个的组合。
可选的，对于存在多个目标零部件时(例如第一终端上部署了第一目标零部件，第二终端上部署了第二目标零部件)，对多个目标零部件的升级数据的加密可以使用相同的密钥进行加密，也可以使用不同的密钥进行加密。
可选的，目标零部件可能存在多项升级数据，第一服务器可以将多项升级数据中的部分升级数据进行加密，得到第一密文。该第一密文可以与其他未加密的升级数据一同打包得到升级包，该升级包用于目标零部件的升级。本申请例举一种可能的场景：第一服务器对目标零部件进行漏洞补丁和地图数据更新，此时可以将地图数据更新加密得到第一密文，而将漏洞补丁和第一密文打包得到升级包。这样一来，第一服务器可以只加密需要进行机密性保护的数据，减轻计算压力。
当然，第一服务器也可以将一项或者多项升级数据先打包得到升级包，然后将升级包进行加密。本申请再例举一种可能的场景：第一服务器对目标零部件进行漏洞补丁和地图数据更新，此时可以将漏洞补丁和地图数据更新打包得到升级包，对升级包进行加密得到第一密文。
步骤S302：第一服务器向OTA服务器发送第一密文。
可以理解的，第一服务器向OTA服务器发送第一密文，相应的，OTA服务器则接收来自第一服务器的第一密文。
在具体实施过程中，若第一密文包含在升级包中，第一服务器可以向OTA服务器发送升级包。OTA服务器接收来自第一服务器的升级包，从而接收到升级包中第一密文。
可选的，第一服务器还可以向OTA服务器发送第一密文的元数据或者第一密文所在的升级包的元数据(metadata)。其中，元数据是用于描述第一密文或者升级包的数据属性的数据，例如第一密文的文件大小、第一密文的版本等等。该元数据可以用于OTA服务器确定升级策略等。
可选的，图3所示的实施例可以包括步骤S303-步骤S304中的一个或者多个步骤，步骤S303-步骤S304具体如下：
步骤S303：OTA服务器确定升级策略，该升级策略中包含第一密文的第一下载地址。
具体地，第一下载地址用于下载第一密文或者下载包含第一密文的升级包。可选的，OTA服务器接收第一密文后，可以为第一密文分配第一下载地址。可选的，第一下载地址可以为统一资源定位符(uniform resource locator，URL)。
可选的，升级策略还可以包括升级规则、升级条件、下载规则等等中的一项或者多项。其中，升级规则用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态、有依赖关系的其他设备的状态等，下载规则用于定义下载的顺序、指示哪一个部件进行下载等等。
可选的，OTA服务器根据第一终端的信息和/或所述第一密文(或者所述第一密文所在的升级包)的信息，确定升级策略。其中，第一终端的信息包含第一终端的身份标识(identification，ID)、型号、版本信息、分组信息、地址等等中的一项或者多项。第一密文的信息包含第一密文的元数据(或者说属性)，例如所述第一密文的版本、文件大小、存储地址等等中的一项或者多项。第一密文所在的升级包的信息包含升级包的文件大小、存储地址、升级包中一项或者多项数据的依赖关系等等中的一项或者多项。
例如，OTA服务器根据第一终端中的目标零部件的版本信息以及第一密文的版本信息，确定第一终端上的目标零部件需要升级，进而根据第一密文的存储地址确定第一下载地址。再如，OTA服务器根据第一密文所在的升级包中的多项升级数据的依赖关系，确定第一终端中的下载多项升级数据的下载次序。再如，OTA服务器根据第一密文的文件大小，确定所述第一终端需要的存储空间大小。
可以理解的，在实际的处理过程中，OTA服务器可以确定升级策略，也可以不确定升级策略，例如，OTA服务器可以将第一密文(或者第一密文所在的升级包)的元数据发送给第一终端，由第一终端确定下载策略。具体情况取决于OTA服务器的实现、预先的约定或者标准的定义。
步骤S304：OTA服务器向第一终端发送第一下载地址。
其中，第一下载地址可以用于第一终端从存储该第一密文的设备(例如，OTA服务器、或者多个服务器中的CDN服务器、或者NAS设备、又或者分布式数据库等)中下载该第一密文。
可选的，在第一下载地址包含在升级策略中的情况下，OTA服务器可以向第一终端发送升级策略，相应的，第一终端就接收到来自OTA服务器的升级策略，从而获取第一下载地址。
进一步的可选的，OTA服务器具体可以向目标零部件发送升级策略，相应的，目标零部件则接收来自OTA升级主节点的升级策略，从而获取第一下载地址。
可替代的，OTA服务器具体可以向第一终端中的升级控制部件发送升级策略(没有确定升级策略的情况下也可以是发送第一下载地址)。进一步的，第一终端中的升级控制部件可以将升级策略转发给第一终端中的目标零部件。例如，参见图2，升级控制部件可以是GW，目标零部件可以为MDC，OTA服务器可以向车辆203中的GW发送升级策略，GW接收升级策略，并将升级策略转发给MDC，以便于MDC按照升级策略进行升级。
在一种可能的设计中，升级控制部件也可以是其他用于控制车辆的部件组中的待升级部件进行升级的部件。请参见图4，图4是本申请实施例提供的一种可能的车辆的架构，车辆40存在多个部件组，每个部件组中包括一个用于升级控制部件组内的待升级部件进行OTA升级的升级控制部件。例如，可以将一个整车集成单元(vehicle integrated/integration unit，VIU)及其连接的部件作为一个部件组，将VIU作为一个部件组的升级控制部件。本申请例举一个可能的部件组group1：VIU1、座舱域控制器(cockpit domain controller，CDC)、ECU1.1、ECU1.2、ECU2.1、ECU2.2、Tbox，其中VIU1为该部件组group1的升级控制部件。若目标零部件为CDC，则OTA服务器可以将第一下载地址发送给VIU1，相应的，VIU1接收来自OTA服务器的第一下载地址。需要说明的是，当部件组内仅包括一个部件时，该 部件可以既是该部件组的升级控制部件，也是该部件组的待升级部件。此处的部件组仅为示例，具体的部件组分组情况取决于具体的实现。
步骤S305：第一终端获取第一密文。
本申请例举两种可能的第一终端获取第一密文的可能情况：
情况一：OTA服务器向第一终端发送第一密文，相应的，第一终端则接收来自OTA服务器的第一密文。具体的，OTA服务器可以通过有线链路、无线链路等向第一终端发送第一密文。
情况二：第一终端可以通过第一下载地址，从存储第一密文的设备(例如，OTA服务器、或者多个服务器中的CDN服务器、或者NAS设备、又或者分布式数据库等)下载第一密文。
进一步的可选的，第一终端可以通过安全通道下载第一密文。其中，安全通道可以是基于安全套接字(Secure Sockets Layer，SSL)协议或者传输层安全(Transport Layer Security，TLS)协议的传输通道，用于数据安全传输。具体的，安全通道可以包括超文本传输安全协议HTTPs安全通道、传输层安全协议TLS安全通道或数据包传输层安全协议(Datagram Transport Layer Security，DTLS)安全通道等等中的一个或者多个。
可选的，第一终端与存储第一密文的设备建立安全通道时，可能需要执行相关安全配置，以便于安全的传输信息。例如，第一终端与存储第一密文的设备可以通过证书确认对方的身份、确定进行加解密的公私钥对等等中的一项或者多项。
可选的，OTA服务器(或者其他存储第一密文的设备)对第一密文的内容不进行修改或审核，可以看作OTA服务器(或者其他存储第一密文的设备)通过透传方式，将第一密文从第一服务器处透传给第一终端。
步骤S306：第一服务器向第一终端发送第二密钥。
具体的，第二密钥为第一密钥的解密密钥。经过第一密钥加密的密文，可以通过该第二密钥解密得到明文。第二密钥与前述第一密钥可能是相同的密钥(例如，第一密钥和第二密钥为对称密钥)，也可能是不同的密钥(例如第一密钥为公钥，第二密钥为私钥)。
可以理解的，第一服务器向第一终端发送第二密钥，相应的，第一终端则接收来自第一服务器的第二密钥。该第二密钥可以用于第一终端解密第一密文，得到目标零部件的升级数据。可选的，第一服务器具体可以向第一终端中的目标零部件发送第二密钥，或者具体可以向第一终端中的升级控制部件发送第二密钥。
可选的，第一服务器可以通过各种实现方式向第一终端发送第二密钥，本实施例例举两种可能的实现方式：
实现方式一：第一服务器与第一终端建立安全通道，第一服务器通过安全通道向第一终端发送第二密钥。具体的，安全通道包括HTTPs安全通道、TLS安全通道或DTLS安全通道等等中的一个或者多个，用于安全数据传输。可选的，第一服务器可以通过OTA服务器向第一终端分发用于获取第二密钥的地址，第一终端根据该第二密钥的地址，可以与第一服务器建立安全通道。
进一步可选的，第一终端与第一服务器建立通道时，可能需要执行相关安全配置，以便于安全的传输信息。例如，第一终端与第一服务器可以通过证书确认对方的身份、确定 进行加解密的公私钥对等等。
可选的，在实际的处理过程中，第一服务器还可以通过其他支持加密的通信链路向第一终端发送数据，而无需通过安全通道传输数据。具体可以取决于第一服务器与第一终端的实现、预先的约定或者标准的定义。
需要说明的是，本申请实施例中提到的安全通道具体可以为一段安全通道，也可以为多段安全通道。例如，在第一终端中的目标零部件支持与第一服务器进行通信的情况下，目标零部件可以直接与第一服务器建立安全通道，因此目标零部件可以通过安全通道接收第一服务器发送的第二密钥。在一些具体实施场景中，若目标零部件不支持与第一服务器直接建立安全通道，但是支持与第一终端中的升级控制部件建立安全通道。该控制部件可以与第一服务器建立第一段安全通道，与目标零部件建立第二段安全通道，从而使得目标零部件可以通过第一段安全通道和第二段安全通道，与第一服务器进行通信。
实现方式二：第一服务器通过第一安全参数加密第二密钥，得到第二密文。第一服务器向第一终端发送第二密文。进一步的，第一终端使用第二安全参数解密第二密文，得到第二密钥。具体的，第二安全参数可以用于解密经过第一安全参数加密得到的密文。第一安全参数与第二安全参数可以是相同的参数也可以是不同的参数。可选的，第一安全参数可以是公钥、或者对称密钥或者第一服务器与第一终端协商得到的共享密钥。例如，第一终端(具体可以为第一终端中的目标零部件或者第一终端中的升级控制部件等)可以确定一个私钥对，该公私钥对包含第一公钥和第一私钥，该第一公钥可以发送给第一服务器作为第一安全参数，而第一私钥作为第二安全参数。
可选的，第一安全参数(以及第二安全参数)可以属于临时密钥或者一次性密钥(one time key)。其中，一次性密钥可以理解为只使用一次或者使用一次后即失效或被删除的密钥。例如，第一服务器使用第一安全参数加密第二密钥后，则将第一安全参数删除；第一终端使用第二安全参数解密第二密文后，可以将该第二安全参数删除。这样一来，只使用一次第一安全参数进行加密以及只使用一次第二安全参数进行解密，从而使得该第一安全参数和第二安全参数不容易被攻破，提高数据安全性。
可选的，为了提高安全性，第一服务器加密第二密钥时，可以使用一次一密的形式。也即是说，第一服务器向不同的终端发送第二密钥时，对第二密钥进行加密的安全参数是不同的。
进一步可选的，该第一安全参数(以及后续用于解密第二密文的第二安全参数)可以是第一服务器与第一终端通过协商确定的，为了方便理解，本申请例举两种可能的确定第一安全参数的设计：
设计1：第一终端确定一个公私钥(包含第一公钥和第一私钥)，第一终端的第一数字证书可以用于认证第一公钥来源于第一终端。具体的，第一终端可以将第一公钥发送给第一服务器，第一服务器通过第一数字证书认证第一公钥。该第一公钥即作为第一安全参数，用于加密第二密钥。可选的，确定上述公私钥对的具体可以为第一终端中的目标零部件或者升级控制部件等，上述第一数字证书具体可以为第一终端中的目标零部件或者升级控制部件的数字证书。
在一种可能的实施场景中，第一数字证书对应第二公钥和第二私钥。例如，CA可以为 第一终端的第二公钥作公证，将第二公钥和第一终端的信息等封装得到第一数字证书。其他设备(例如第一服务器)可以通过第一数字证书和CA确定第二公钥确实来自第一终端。从而使得其他设备(例如第一服务器)通过第一数字证书对应的第二公钥和第二私钥可以认证第一公钥。请参见图5，图5是本申请实施例提供的一种确定第一安全参数(以及第二安全参数)的方法流程图，具体可以包括以下步骤：
步骤S511：第一终端确定第一公钥(PK1)和第一私钥(SK1)。
可选的，具体可以为第一终端中的目标零部件确定第一公钥和第二私钥，也可以为第一终端中的升级控制部件确定第一公钥和第一私钥。
步骤S512：第一终端根据第一数字证书对应的第二私钥、第一公钥和第一随机数，得到第一签名。
例如，得到的第一签名S1满足如下式子：S1＝sign(SK2，PK1，NONCE1)，其中，sign为签名算法，SK2为第一数字证书对应的第二私钥，PK1为第一公钥，NONCE1为第一随机数(可选的)。
步骤S513：第一终端向第一服务器发送第一公钥、第一随机数和第一签名。
需要说明的是，第一终端可以在同一条消息中携带第一公钥、第一随机数和第一签名，也可以在多条消息中分别携带第一公钥、第一随机数和第一签名。
第一终端向第一服务器发送第一公钥、第一随机数和第一签名，相应的，第一服务器则接收来自第一终端的第一公钥、第一随机数和第一签名。
步骤S514：第一服务器根据第一数字证书对应的第二公钥认证第一公钥。
其中，第一数字证书可以是第一终端发送给第一服务器的，也可以是第一服务器中预先配置的，还可以是第一服务器从第三方设备(例如网络侧设备、CA中心等)获取的。
具体的，第一服务器可以根据第一数字证书对应的第二公钥解签第一签名，将解签后的结果与第一公钥比对，若比对一致则认证第一公钥通过。进一步的，若对比一致，则说明第一公钥确实来源于第一终端，没有被篡改。若比对不一致，则说明第一服务器收到第一公钥可能被篡改或者来源不可信。
可选的，第一服务器可以获取有第二数字证书。第二数字证书可以用于认证第一服务器的身份。例如，第二数字证书可以对应第三公钥和第四公钥。图5所示的方法还可以包括如下步骤：
步骤S515：第一服务器根据第二数字证书对应的第三私钥、第一随机数和第二随机数，得到第二签名。
例如，得到的第二签名S2满足如下式子：S2＝sign(SK3，NONCE1，NONCE2)，其中，sign用于指示签名算法，SK3为第三数字证书对应的第三私钥，NONCE1为第一随机数(可选的)，NONCE2为第二随机数(可选的)。
步骤S516：第一服务器向第一终端发送第二随机数和第二签名。
需要说明的是，第一服务器可以在同一条消息中携带第二随机数(NONCE2)和第二签名(S2)，也可以在多条消息中分别携带第二随机数和第二签名。
可选的，第一服务器可以在发送第二签名的消息中携带第二密文(C2)。进一步的可选的，第一服务器还可以根据第二签名、第二密文、第二随机数得到第三签名(S3)，该第三 签名用于第一终端验证第二密文。例如，第三签名S3满足：S3＝Sign(SK3，S2||C2||NONCE2)，其中“||”可以为字符串连接符号，各项参数的含义可以参考前述的描述。
步骤S517：第一终端根据第二数字证书认证第一服务器的身份。
具体的，第一终端可以根据第二数字证书对应的第三公钥解签第二签名，将解签后的结果与第一随机数、第二随机数比对，若比对一致则认证第一服务器的身份通过。
可选的，在包含第三签名时，还可以根据第二数字证书对应的第三公钥解签第三签名。
可选的，若认证第一服务器的身份通过，第一终端可以向第一服务器反馈确认字符(acknowledge character，ACK)或其他确认指示信息。可选的，该ACK或其他确认指示信息可以使用第二私钥进行签名。
进一步的，若比对不一致，则说明第一随机数、第二随机数、或者第二密文已经被篡改或者来源不可信。
设计2：第一服务器与第一终端通过密钥协商算法确定共享密钥，该共享密钥作为第一安全参数(第二安全参数)。
进一步的，在确定共享密钥的过程中，第一服务器可以通过与第一终端之间的预共享密钥(pre-shared key，PSK)确定对方的身份。其中，PSK是第一服务器与第一终端之间共享的一个秘密值。第一服务器与第一终端可以通过预先定义、预先配置或者通过互相协商生成等方式得到PSK。
请参见图6，图6是本申请实施例提供的又一种确定第一安全参数(以及第二安全参数)的方法流程图，具体可以包括以下步骤：
步骤S6201：第一终端基于密钥协商算法，确定第一密钥协商参数。
其中，密钥协商算法为第一终端与第一服务器预先约定的密钥协商算法，或者，第一服务器可以通过OTA服务器向第一终端转发其支持的密钥协商算法的标识，用于第一终端选择使用何种密钥协商算法。
例如，以密钥协商算法为DH算法为例，第一终端与第一服务器可以将较大的素数p和随机数g作为公钥，第一终端根据自己的私钥(a)和公钥(p和g)确定计算值A(例如：A＝g amod p)，该计算值A可以看做第一密钥协商参数。
再如，以密钥协商算法为ECDH算法、以确定的椭圆曲线为Ep、基点为G为例，第一终端根据自己的私钥(a)和基点G得到计算值A(例如:A＝a×G)发送给第一服务器，则该计算值A可以看做第一密钥协商参数。
步骤S6202：第一终端向第一服务器发送第一密钥协商参数。
具体的，第一终端可以向第一服务器发送第一消息，第一消息中包含第一密钥协商参数。可选的，第一消息中还可以包括第一终端确定的第一新鲜性参数(NONCE1)、第一终端的ID等等。
第一终端向第一服务器发送第一密钥协商参数，相应的，第一服务器则接收来自第一终端的第一密钥协商参数。
步骤S6203：第一服务器基于密钥协商算法，得到共享密钥(第一安全参数)。
例如，以DH算法为例，共享密钥可以满足：Kdh＝KEe bmod p，其中，KEe为第一密钥协商参数(例如，满足：KEe＝g amod p)，p为DH密钥交换过程中的公钥。
例如，以ECDH算法为例，共享密钥可以满足：Kdh＝b×KEe，其中，KEe为第一密钥协商参数(例如，满足：KEe＝a×G)，G为椭圆曲线的基点。
可选的，第一服务器可以根据共享密钥Kdh进行推演，推演出的密钥也可以为共享密钥。例如，共享密钥Kgt可以满足：Kgt＝KDF(Kdh，NONCE1，NOCNE2)。其中，NONCE1为第一新鲜性参数，NOCNE2为第二新鲜性参数。该共享密钥或者通过共享密钥派生得到的其他密钥可以作为前述第一安全参数。
进一步的可选的，第一服务器可以基于共享密钥推演得到加密密钥、身份认证密钥、完整性保护密钥中的一个或者多个。例如，第一服务器确定的加密密钥Kenc可以满足：
Kenc＝KDF(Kdh，NONCE1，NOCNE2，“enc”)
其中，“enc”为一种可选的密钥标识，具体实施时可以预先配置或者协议规定一段字符串作为密钥标识，NONCE1为第一新鲜性参数，NONCE1为第二新鲜性参数。NONCE1，NOCNE2，“enc”为可选参数，具体实施时还可以包括其他可选参数，例如第一终端的ID、第一服务器的ID等等。再如，第一服务器确定的完整性保护密钥Kint可以满足：
Kenc＝KDF(Kdh，NONCE1，NOCNE2，“int”)
其中，“int”为一种可选的密钥标识，具体实施时可以预先配置或者协议规定一段字符串作为密钥标识。NONCE1，NOCNE2，“enc”为可选参数，具体实施时还可以包括其他可选参数，例如第一终端的ID、第一服务器的ID等等。该完整性保护密钥进一步可以用于生成消息认证码MAC，用于保护消息的完整性。
步骤S6204：第一服务器确定第二密钥协商参数。
例如，以密钥协商算法为DH算法为例，第一服务器根据自己的私钥(b)和公钥(p和g)确定计算值B，该计算值B可以看做第二密钥协商参数。
再如，以密钥协商算法为ECDH算法、以确定的椭圆曲线为Ep、基点为G为例，第一服务器根据自己的私钥(b)和基点G得到计算值B(例如:B＝b×G)发送给第一终端，则该计算值B可以看做第二密钥协商参数。
可选的，还包括步骤S6205：第一服务器根据第一服务器与第一终端的PSK确定第一认证参数。
可选的，第一认证参数AUTH1可以满足如下式子：AUTH1＝(PSK，NONCE2，第一消息)。进一步的，参与生成第一认证参数的数据还可以有共享密钥、第一终端的ID、第二终端的ID、第二消息等等中的一项或者多项。
步骤S6206：第一服务器向第一终端发送第二密钥协商参数。
具体的，第一终端向第一服务器发送第一密钥协商参数，相应的，第一服务器则接收来自第一终端的第一密钥协商参数。
可选的，第一服务器可以向第一终端发送第二消息，该第二消息中即包含第二密钥协商参数。可选的，第二消息中还可以包括第一服务器确定的第二新鲜性参数(NONCE2)、第一身份认证信息AUTH1、第一消息认证码MAC1、第一服务器的身份标识(identification，ID)等等。其中，第一消息认证码MAC1为根据第二消息的部分或者全部数据，通过完整性保护算法(或者还包括完整性保护密钥)得到的MAC，用于保护第二消息的完整性。
步骤S6207：第一终端基于密钥协商算法，根据第二密钥协商参数确定共享密钥(第 二安全参数)。
具体描述可以参考步骤S6203中第一服务器侧的详细描述。
步骤S6208：第一终端根据第一服务器与第一终端的PSK，校验第一认证参数。
在一种可选的方案中，根据协议规定，第一服务器使用什么参数生成第一认证参数，则第一终端也应当使用相同的参数生成校验信息，如果校验信息与第一认证参数相同，则认为验证通过。
例如，若第一认证参数AUTH1满足：AUTH1＝KDF(PSK，NONCE2，第一消息)，则第一终端根据PSK，则第二节点生成校验信息check1＝KDF(PSK，NONCE2，第一消息)，若校验信息check1与AUTH1相同，则第一认证参数校验通过。进一步的，若第一认证参数校验通过，说明第一服务器中的PSK与第一终端中的PSK一致(第一服务器的身份可信)，且第一消息、第二随机数没有被篡改。
步骤S6209：第一终端根据PSK确定第二认证参数。
可选的，第二认证参数AUTH2可以满足如下式子：AUTH2＝(PSK，NONCE1，第二消息)。进一步的，参与生成第一认证参数的数据还可以有共享密钥、第一终端的ID、第二终端的ID、第二消息等等中的一项或者多项。
步骤S6210：第一终端向第一服务器发送第二认证参数。
可选的，第一服务器可以向第一终端发送第三消息，该第三消息中即包含第二认证参数。可选的，第三消息中还可以包括第一服务器确定的第二消息认证码MAC2等等。其中，第二消息认证码MAC2用于保护第三消息的完整性。
可选的，该第二认证参数或者第三消息还可以通过加密密钥进行加密。
步骤S6211：第一服务器根据PSK，校验第一认证参数。
具体描述可以参考步骤S6208中第一终端侧的详细描述。
可选的，第一服务器向第一终端发送第二密钥之前，可以接收来自第一终端的密钥获取请求(具体可以是请求消息、指示请求第二密钥的信息，本申请对信息的名称不作限定)。进一步的，第一服务器响应于该密钥获取请求，向第一终端发送第二密钥或者向第二终端发送第二密文。在一种可能的设计中，第一服务器接收来自第一终端的密钥获取请求，从而通过密钥协商算法得到第一安全参数(第二安全参数)。第一服务器根据第一安全参数加密第二密钥得到第二密文，向第一终端发送第二密文。
步骤S307：第一终端通过第二密钥解密第一密文，得到目标零部件的升级数据。
可选的，第一终端可以通过解密算法，通过第二密钥对第一密文进行解密，得到升级数据。例如，得到的升级数据的过程满足如下式子：升级数据＝Dec(升级数据，第二密钥)，其中，Dec为加密算法Enc对应的解密算法(通常来说，加密算法与解密算法为同一种算法，或者具体可以为算法中的不同计算流程，此处为了便于描述使用不同的名称)。
可选的，第一服务器可以通过OTA服务器在升级策略中指示使用的加密算法，从而使得第一终端使用对应的解密算法进行解密。可替换的，第一服务器可以在发送第二密钥时发送指示信息，用于指示使用的加密算法，从而使得第一终端使用对应的解密算法进行解密。
步骤S308：第一终端通过所述目标零部件的升级数据，升级所述目标零部件。
在具体实施过程中，具体可以为第一终端中的升级控制部件或者目标零部件对第一密文进行解密，然后通过升级控制部件或者目标零部件根据升级数据进行升级。本申请例举几种可能的实施情况：
情况一：第一终端中的升级控制部件接收OTA服务器发送的第一密文，该升级控制部件将第一密文转发给第一终端中的目标零部件。第一终端中的升级控制部件接收第一服务器发送的第二密钥，该升级控制部件将第二密钥转发给第一终端中的目标零部件。目标零部件根据第二密钥解密第一密文，得到升级数据。目标零部件根据升级数据，对自身进行升级。可以理解的，目标零部件自身可能不具备与OTA服务器或者与第一服务器进行数据传输的能力，因此可以通过升级控制部件转发第一密文和第二密钥，解密第一密文后使用升级数据进行升级。
情况二：第一终端中的升级控制部件接收OTA服务器发送的第一密文。该升级控制部件接收第一服务器发送的第二密钥。该升级控制部件根据第二密钥解密第一密文，得到升级数据，根据升级数据对目标零部件进行升级。可以理解的，目标零部件自身可能不具备解密能力，因此可以通过升级控制部件解密得到升级数据。可选的，升级时，升级控制部件可以通过数据刷写等方式，对目标零部件进行升级。
情况三：第一终端中的目标零部件接收OTA服务器发送的第一密文，该目标零部件接收第一服务器发送的第二密钥。该目标零部件根据第二密钥解密第一密文，得到升级数据。该目标零部件根据升级数据，对目标零部件进行升级。可以理解的，目标零部件在具有外部通信能力和解密能力的条件下，可以使用情况三中描述的方法进行升级。例如，参见图4，目标零部件可以为车辆中的VIU，该VIU可以与OTA服务器和第一服务器进行数据传输，因此VIU可以通过情况三中描述的方法进行升级。
请参见图7，图7是本申请实施例提供的一种可能的OTA升级方法的运行示意图，可以看出，第一服务器701将目标零部件的升级数据通过第一密钥加密得到第一密文，将第一密文通过OTA服务器702透传给第一终端703(具体可以是目标零部件704或者升级控制部件705)。然后将第二密钥发送给第一终端703(具体可以是目标零部件704或者升级控制部件705)。其中，发送第二密钥时，具体可以是通过安全通道发送(如图中①所在的线条所示)，也可以是将第二密钥使用第一安全参数加密后，将得到的第二密文发送给第一终端(如图中②所在的线条所示，后续第一终端703使用第二安全参数解密第二密文得到第二密钥)。
可以看出，在图3所示的实施例中，由于目标零部件的升级数据是经过加密传输的，只有第一服务器、第一终端可以通过第二密钥得到升级数据，避免了其他中间设备获取升级数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
请参见图8，图8是本申请实施例提供的又一种OTA升级方法的流程示意图，该方法包括但不限于如下步骤：
步骤S801：第一服务器向OTA服务器发送目标零部件的升级数据的元数据。
其中，元数据，又称中介数据、中继数据，为描述数据的数据(data about data)，主要是描述数据属性(property)的信息。目标零部件的升级数据的袁术可以包含升级数据的第一下载地址、版本信息、文件大小、存储位置、提供升级数据的设备的标识、目标零部件的标识等等中的一项或者多项。
进一步的，该元数据可以用于OTA服务器确定升级策略等。
第一服务器以及目标零部件的相关描述可以参考步骤S301中的相关说明，此处不再赘述。
可选的，图8所示的实施例可以包括步骤S802-步骤S803，具体如下：
步骤S802：OTA服务器确定升级策略。
具体的，该升级策略中可以包含第一密文的第一下载地址。相关描述可以参考步骤S303中的详细描述，此处不再赘述。
步骤S803：OTA服务器向第一终端发送升级策略。
具体的，OTA服务器向第一终端发送升级策略，相应的，第一终端就接收到来自OTA服务器的升级策略。相关描述可以参考步骤S304中的详细描述，此处不再赘述。
步骤S804：第一服务器向第一终端发送目标零部件的升级数据。
具体的，第一服务器向第一终端发送目标零部件的升级数据，相应的，第一终端则接收第一服务器发送的目标零部件的升级数据。具体的，第一服务器可以通过有线链路、无线链路等向第一终端发送目标零部件的升级数据。可以理解的，该第一服务器可以通过CDN向第一终端发送目标零部件的升级数据。
进一步的，第一终端可以获取目标零部件的升级数据的第一下载地址，该第一下载地址用于第一终端从第一服务器上接收升级数据。
具体的，第一终端可以通目标零部件的升级数据的下载地址，与第一服务器建立安全通道。第一服务器通过该安全通道向第一终端发送目标零部件的升级数据，相应的，第一终端通过安全通道接收目标零部件的升级数据。其中，安全通道可以包括超文本传输安全协议HTTPs安全通道、传输层安全协议TLS安全通道或数据包传输层安全性协议DTLS安全通道等等中的一个或者多个，用于数据安全传输。
步骤S805：第一终端通过所述目标零部件的升级数据，升级所述目标零部件。
具体可以参考步骤S308中的相关描述，此处不再赘述。
请参见图9，图9是本申请实施例提供的又一种可能的OTA升级方法的运行示意图，可以看出，第一服务器901向OTA服务器902发送目标零部件的升级数据的元数据，OTA服务器902向第一终端903(具体可以是目标零部件904或者升级控制部件905)发送第一下载地址。第一终端902(具体可以是目标零部件904或者升级控制部件905)通过第一下载地址从第一服务器处下载目标零部件904的升级数据，从而对目标零部件904进行升级。
可以看出，在图8所示的方法中，第一终端通过第一下载地址从第一服务器下载升级数据，从而避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是在第一服务器直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
请参见图10，图10申请实施例提供的又一种OTA升级方法的流程示意图，方法包括但不限于如下步骤：
步骤S1001：第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文。
具体可以参考步骤S301中的相关描述，此处不再赘述。
步骤S1002：第一服务器通过第一安全参数加密第二密钥得到第二密文。
其中，第一安全参数为第一服务器与第一终端(或者具体为第一终端中的第一目标零部件或者升级控制部件)之间的共享密钥或者为第一终端(或者具体为第一终端中的第一目标零部件或者升级控制部件)的第一公钥。其中，第一目标零部件为目标零部件中的一个。
可选的，第一安全参数可以在是第一服务器中预置的。例如，第一目标零部件中预先配置有第一私钥(或者还包含第一私钥的第一公钥)，第一服务器可以预先配置有第一公钥，第一服务器通过该第一公钥加密第二密钥，得到第二密文。后续第一目标零部件可以通过预先配置的第一私钥解密第二密文。
可替代的，第一安全参数还可以是第一服务器与第一终端通过协商的方式预先确定的。例如，第一服务器与第一终端通过图5或者图6所示的方式确定第一安全参数(第二安全参数)。
第二密钥为第一密钥的解密密钥，经过第一密钥加密的密文，可以使用第二密钥解密得到明文。第一密钥与第二密钥可能是不同的密钥(非对称密钥)，也可以是同一个密钥(对称密钥)，具体取决于加密第一密文时使用的算法的类型。
可选的，考虑一种可能的情况，第二终端上配置有第二目标零部件，该第二目标零件可以为目标零部件中的其中一个。第一服务器可以通过第三安全参数加密所述目标零部件的升级数据得到第三密文，该第三密文用于该第二终端升级该第二目标零部件。其中，第三安全参数可以为第一服务器与第二终端(或者具体为第二终端中的目标零部件)之间的共享密钥，或者为第二终端(或者具体为第二终端中的目标零部件)的第四公钥。
需要说明的是，第三安全参数一般与第一安全参数不同，但是在一些实施情况中，第三安全参数与第一安全参数也可以是相同的。例如，供应商在生产目标零部件时，在某一批次的目标零部件(包含第一目标零部件和第二目标零部件)中预先配置了相同的共享密钥或者预先配置了相同的私钥，从而使得加密第二密钥时使用的第一安全参数与第三安全参数是相同的。
步骤S1003：第一服务器向OTA服务器发送第一密文、第二密文。
需要说明的是，第一服务器可以在同一条消息中携带第一密文和第二密文，也可以在多条消息中分别携带第一密文和第二密文。此处为了便于描述故写作一个动作，并不旨在限定一定是在同一条消息中发送的。
可选的，考虑前述的第二终端配置有第二目标零部件的情况，第一服务器还可以OTA服务器发送第三密文。
可选的，第一服务器还可以向OTA服务器发送第二密文对应的第一终端的指示信息(或者具体为第一终端上的第一目标零部件的指示信息)，便于第一服务器将第二密文发送给第一终端。
可选的，图10所示的实施例可以包括步骤S1004-步骤S105中的一个或者多个步骤，步骤S1004-步骤S1005具体如下：
步骤S1004：OTA服务器确定升级策略，升级策略中包含第一密文和第二密文的第一下载地址。
具体地，第一下载地址用于下载第一密文或者下载包含第一密文的升级包，还可以用于下载第二密文。可选的，第一下载地址可以为统一资源定位符(uniform resource locator，URL)。
可选的，第一下载地址具体可以包含两个地址，其中一个地址用于下载第一密文(或者下载包含第一密文的升级包)，另一个地址用于下载第二密文。
关于升级策略的详细描述可以参考步骤S303中的详细描述，此处不再赘述。
可选的，考虑前述的第二终端配置有第二目标零部件的情况，OTA服务器可以根据第二终端中的第二零部件的版本信息，确定第二零部件需要升级。OTA服务器则向第二终端发送第一密文的下载地址以及第三密文的下载地址。
其他更多内容可以参考步骤S303中相关描述，此处不再赘述。
步骤S1005：OTA服务器向第一终端发送第一下载地址。
其中，第一下载地址可以用于第一终端从存储该第一密文(第二密文)的设备(例如，OTA服务器、或者多个服务器中的CDN服务器、或者NAS设备、又或者分布式数据库等)中下载该第一密文(第二密文)。
可选的，考虑前述的第二终端上配置有第二目标零部件的情况，OTA服务器还可以向第三终端发送第三密文的第二下载地址，该第二下载地址用于第二终端下载第三密文。进一步的可选的，第一密文的下载地址可以与第一密文的下载地址相同。
步骤S1006：第一终端获取第一密文和第二密文。
本申请例举两种可能的第一终端获取第一密文和第二密文的＝情况：
情况一：OTA服务器向第一终端发送第一密文和第二密文，相应的，第一终端则接收来自OTA服务器的第一密文和第二密文。具体的，第一终端可以通过有线链路、无线链路等接收第一服务器发送的第一密文和第二密文。可选的，第一密文和第二密文可以是在同一条消息中携带的，也可以是通过不同的消息分别携带的。
情况二：第一终端可以通过第一下载地址，从存储第一密文的设备(例如，OTA服务器、或者多个服务器中的CDN服务器、或者NAS设备、又或者分布式数据库等)下载第一密文和第二密文。
进一步的可选的，第一终端可以通过安全通道下载第一密文(第二密文)。可选的，第一终端与存储第一密文(第二密文)的设备建立安全通道时，可能需要执行相关安全配置，以便于安全的传输信息。
需要说明的是，OTA服务器(或者其他存储第一密文的设备)对第一密文的内容不进行修改或审核，可以看作OTA服务器(或者其他存储第一密文的设备)通过透传方式，将第一密文(第二密文)从第一服务器处透传给第一终端。
具体的描述还可以参考步骤S306中的描述，此处不再赘述。
步骤S1007：第一终端通过第二安全参数解密第二密文，得到第二密钥。
其中，第二安全参数可以解密经过第一安全参数加密的密文。可选的，该第二安全参数与第二安全参数可以是相同的(例如共享密钥)，也可以是不同的(例如第一安全参数为公钥，第二安全参数为私钥)。
第一终端可以通过解密算法，通过第二安全参数对第二密文进行解密，得到第二密钥。
步骤S1008：第一终端通过第二密钥解密第一密文，得到第一目标零部件的升级数据。
具体可以参见步骤S307中的相关描述，此处不再赘述。
步骤S1009：第一终端通过第一目标零部件的升级数据，升级第一目标零部件。
具体可以参见步骤S308中的相关描述，此处不再赘述。
可以理解的，可选的，考虑前述的第二终端上配置有第二目标零部件的情况，第三终端可以获取第一密文和第三密文，使用第四安全参数解密第三密文，得到第二密钥。通过第二密钥解密第一密文，得到第二目标零部件的升级数据。
例如，请参见图11，图11是本申请实施例提供的又一种可能的OTA升级系统的运行示意图，第一服务器1101根据第一密钥加密目标零部件(包含第一目标零部件1104和第二目标零部件1107)的升级数据，得到第一密文。第一服务器1101使用第一安全参数加密第二密钥得到第二密文，使用第三安全参数加密第二密钥得到第三密文。第一服务器1101向OTA服务器1102发送第一密文、第二密文(如图中①所在的线条所示)、第三密文(如图中②所在的线条所示)。OTA服务器1101将第一密文发送给第一终端1103(具体可以是第一目标零部件1104或者第一升级控制部件1105)和第二终端1106(具体可以是第二目标零部件1107或者第二升级控制部件1108)。OTA服务器1101将第二密文发送给第一终端1103，以便于第一终端1103使用第二安全参数解密第二密文，得到第二密钥。OTA服务器将第三密文发送给第二终端1106，以便于第二终端1106使用第四安全参数解密第三密文，得到第二密钥。该第二密钥可以用于第一终端和第二终端解密第一密文，以得到升级目标零部件的升级数据。
可以看出，在图10所示的方法中，由于没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了目标零部件的升级数据的安全性。
进一步的，由于没有直接对目标零部件的升级数据进行加密，而是使用第一安全参数加密第二密钥，而密钥的数据大小通常小于升级数据的数据大小。因此，对于存在有多个、多种零部件需要升级的供应商来说，考虑多个零部件的安全参数可能不同的情况，相比于直接使用安全参数加密升级数据，本实施例可以显著减少加密过程中的计算量、存储量，提高升级的效率。
请参见图12，图12是本申请实施例提供的又一种OTA升级方法的流程示意图，该方 法包括但不限于如下步骤：
步骤S1201：第一服务器使用第一安全参数对目标零部件的升级数据进行加密得到第一密文。
其中，第一安全参数为第一服务器与第一终端(或者具体为第一终端中的目标零部件)之间的共享密钥或者为第一终端(或者具体为第一终端中的目标零部件)的第一公钥。可选的，第一安全参数可以为第一服务器中预先配置、预先定义或者通过协商的方式生成的。
例如，供应商在生产目标零部件时在目标零部件中配置了与第一服务器之间的共享密钥(第一安全参数)，第一服务器在发送升级数据时，可以使用预置的共享密钥加密目标零部的升级数据。
再如，第一终端中预先配置有第一私钥(或者还包含第一私钥的第一公钥)，第一服务器可以获取第一终端的第一公钥，第一服务器通过该第一公钥加密目标零部件的升级数据，得到第一密文。后续第一终端可以通过预先配置的第一私钥解密第一密文。
需要说明的是，为了减少计算量，同一种或者同一批次的目标零部件对应的安全参数可以是相同的。但是不同的目标零部件对应的安全参数也可以不同，具体取决于第一服务器、第一终端的实现。
目标零部件是第一终端中一个待升级的部件。第一服务器、目标零部件的升级数据等相关描述可以参见步骤S301中的描述，此处不再赘述。
第一服务器可以通过加密算法，根据第一安全参数对目标零部件的升级数据进行加密。例如，得到的第一密文满足如下式子：第一密文＝Enc(升级数据，第一安全参数)，其中，Enc为加密算法，具体可以为DES算法、AES算法等等中的一个或者多个的组合。
可选的，目标零部件可能存在多项升级数据，第一服务器可以将多项升级数据中的部分升级数据进行加密，得到第一密文。该第一密文可以与其他未加密的升级数据一同打包得到升级包，该升级包用于目标零部件的升级。这样一来，第一服务器可以只加密需要进行机密性保护的数据，减轻服务器的计算压力。
当然，第一服务器也可以将一项或者多项升级数据先打包得到升级包，然后将升级包进行加密。
步骤S1202：第一服务器向OTA服务器发送第一密文。
具体可以参见步骤S302中的详细描述，此处不再赘述。
可选的，图12所示的实施例可以包括步骤S1203-步骤S1204中的一个或者多个步骤，步骤S1203-步骤S1204具体如下：
步骤S1203：OTA服务器确定升级策略，升级策略中包含第一密文的第一下载地址。
具体可以参见步骤S303中的详细描述，此处不再赘述。
步骤S1204：OTA服务器向第一终端发送第一下载地址。
具体可以参见步骤S304中的详细描述，此处不再赘述。
步骤S1205：第一终端获取第一密文。
具体可以参见步骤S305中的详细描述，此处不再赘述。
步骤S1206：第一终端通过第二安全参数解密第一密文，得到目标零部件的升级数据。
其中，第二安全参数可以解密经过第一安全参数加密的密文。可选的，该第二安全参 数与第二安全参数可以是相同的值(例如共享密钥)，也可以是不同的值(例如第一安全参数为公钥，第二安全参数为私钥)。
可选的，第一终端可以通过解密算法，使用第二安全参数对第一密文进行解密，得到升级数据。例如，得到的升级数据的过程满足如下式子：升级数据＝Dec(升级数据，第二安全参数)，其中，Dec为加密算法Enc对应的解密算法(通常来说，加密算法与解密算法为同一种算法，或者具体可以为算法中的不同计算流程，此处为了便于描述使用不同的名称)。
可选的，OTA服务器可以在升级策略中指示使用的加密算法，从而使得第一终端使用对应的解密算法进行解密。可替换的，第一服务器可以在发送第二密钥时发送指示信息，用于指示使用的加密算法，从而使得第一终端使用对应的解密算法进行解密。
步骤S1207：第一终端通过目标零部件的升级数据，升级目标零部件。
具体可以参见步骤S308中的详细描述，此处不再赘述。
在图12所示的方法中，第一安全参数和第二安全参数可以是预先配置或者预先获取的，第一服务器使用第一安全参数对目标零部件的升级数据进行加密，第一终端使用第二安全参数对第一密文解密从而获取目标零部件的升级数据。由于目标零部件的升级数据是经过加密传输的，没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
上述详细阐述了本申请实施例的方法，下面提供了本申请实施例的装置。
请参见图13，图13是本申请实施例提供的一种OTA升级装置130的结构示意图，该OTA升级装置130可以包括处理单元1301、发送单元1302、接收单元中的一个或者多个。该OTA升级装置130用于实现前述的OTA方法，例如可以用于实现图3、图8、图10或者图12所示的OTA升级方法。
可以理解的，本申请各个装置实施例中，对多个单元或者模块的划分仅是一种根据功能进行的逻辑划分，不作为对装置具体的结构的限定。在具体实现中，其中部分功能模块可能被细分为更多细小的功能模块，部分功能模块也可能组合成一个功能模块，但无论这些功能模块是进行了细分还是组合，在实现OTA升级方法的过程中所执行的大致流程是相同的。例如，上述装置130中的发送单元1302、接收单元1303也可以合并为通信单元，该通信单元用于实现接收、或者发送数据的功能。通常，每个单元都对应有各自的程序代码(或者说程序指令)，这些单元各自对应的程序代码在至少一个处理器上运行时，使得该单元执行相应的流程从而实现相应功能。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图3所示实施例中的第一服务器，或者为第一服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括处理单元1301和发送单元1302，其中：
所述处理单元1301，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密 文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元1302，用于向OTA服务器发送所述第一密文；
所述发送单元1302，还用于向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，只有OTA升级装置130、第一终端可以通过第二密钥得到升级数据，避免了其他中间设备获取升级数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，上述OTA升级装置130属于目标零部件的供应商用于维护目标零部件的装置。
在又一种可能的实施方式中，所述处理单元1301，还用于与部署有所述目标零部件的所述第一终端建立安全通道；
所述发送单元1302，还用于通过所述安全通道向所述第一终端发送所述第二密钥。
在又一种可能的实施方式中，所述处理单元1301，还用于根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述发送单元1302，还用于向部署有所述目标零部件的所述第一终端发送所述第二密文。
在又一种可能的实施方式中，所述装置130还包括：
接收单元1303，用于接收来自所述第一终端的密钥获取请求。
在又一种可能的实施方式中，所述第一安全参数属于临时密钥或者属于一次性密钥。
在又一种可能的实施方式中，所述第一安全参数为所述第一终端的第一公钥；所述接收单元1303，还用于接收所述第一终端发送的所述第一终端的第一公钥；
所述处理单元1301，还用于通过所述第一终端的第一数字证书认证所述第一终端的第一公钥。
在又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述接收单元1303，还用于接收来自所述第一终端发送的第一签名，所述第一签名为使用所述第二私钥对所述第一公钥签名得到的；
所述处理单元1301，还用于根据所述第二公钥、所述第一签名和所述第一公钥确定所述第一公钥认证通过。
在又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元1301，还用于：
通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
在的又一种可能的实施方式中，所述接收单元1303，还用于接收所述第一终端发送的 第一消息，所述第一信息包含第一随机数；
所述发送单元1302，还用于向所述第一终端发送第二消息，所述第二信息包含第一认证参数和第二随机数；所述第一认证参数为根据所述第一消息、所述第二随机数和所述PSK得到的；
所述接收单元1303，还用于接收所述第一终端发送的第三消息，所述第三信息包含第二认证参数；
所述处理单元1301，具体用于根据所述第二消息、所述第一随机数和所述PSK确定所述目标零部件的身份认证通过。
在又一种可能的实施方式中，所述发送单元1302，具体用于：
向所述第一终端的升级控制部件发送所述第二密钥；
或者，向所述第一终端的所述目标零部件发送所述第二密钥。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图3所示实施例中的第一终端，或者为第一终端中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括接收单元1303和处理单元1301，其中：
所述接收单元1303，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述接收单元1303，还用于接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
所述处理单元1301，还用于通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
所述处理单1301，还用于通过所述目标零部件的升级数据，升级所述目标零部件。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，只有第一服务器、OTA升级装置130可以通过第二密钥得到升级数据，避免了其他中间设备获取升级数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，所述处理单元1301，还用于与所述第一服务器建立安全通道；
所述接收单元1303，具体用于通过所述安全通道接收所述第一服务器的所述第二密钥。
在又一种可能的实施方式中，
所述接收单元1303，具体用于接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
所述处理单元1301，还用于根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
在又一种可能的实施方式中，所述装置130还包括：
发送单元1302，用于向所述第一服务器发送密钥获取请求。
在又一种可能的实施方式中，所述第二安全参数属于临时密钥或者属于一次性密钥。
在又一种可能的实施方式中，所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述第一终端的第一公钥；
所述第一公钥通过所述第一终端的第一数字证书进行认证。
在又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；
所述处理单元1301，还用于确定所述第一公钥和所述第一私钥；
所述处理单元1301，还用于通过所述第二私钥对所述第一公钥进行签名，得到第一签名，
所述发送单元1302，还用于向所述第一服务器发送第一签名和所述第一公钥；所述第一签名用于所述第一服务器根据所述第一签名证书对应的第二公钥认证所述第一公钥。
在又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元1301，还用于：
通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
在又一种可能的实施方式中，所述发送单元1302，还用于向所述第一服务器发送第一消息，所述第一消息包含第一随机数；
所述接收单元1303，还用于接收所述第一服务器发送的第二消息，所述第二消息包含第一认证参数和第二随机数；
所述处理单元1301，具体用于根据所述第一认证参数、所述第一消息、所述第二随机数和所述PSK确定所述第一服务器的身份认证通过；
所述发送单元1302，还用于向所述第一服务器发送第三消息，所述第三消息包含第二认证参数；所述第二认证参数为根据所述第一随机数、所述第二消息和所述PSK得到的。所述第二认证参数用于认证所述第一终端的身份。
在又一种可能的实施方式中，所述OTA升级装置130具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置130具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图3所示实施例中的OTA服务器，或者为OTA服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括接收单元1303和发送单元 1302，其中：
所述接收单元1303，用于接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元1302，用于向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，上述OTA升级装置130可以接收密文、转发下载地址以使得第一终端获取第一密文，但是上述OTA升级装置130无法获取解密的密钥。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，所述发送单元1302，具体用于通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
其中，升级规则用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态、有依赖关系的其他设备的状态等，下载规则用于定义下载的顺序、指示哪一个部件进行下载等等。
在又一种可能的实施方式中，所述装置130还包括：
处理单元1301，用于根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
例如，OTA服务器根据第一终端的信息和第一密文的文件大小，确定所述第一终端需要的存储空间大小。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
请参见图14，图14是本申请实施例提供的一种OTA升级装置140的结构示意图，该OTA升级装置140可以包括发送单元1401、处理单元1402中的至少一个。该OTA升级装置140用于实现前述的OTA方法，例如可以用于实现图3、图8、图10或者图12所示的OTA升级方法。
在一种可能的设计中，图14中所示的OTA升级装置140可以为图8所示实施例中的第一服务器，或者为第一服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置140可以包括发送单元1401，其中：
所述发送单元1401，用于向OTA服务器发送目标零部件的升级数据的元数据，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述发送单元1401，还用于通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与所述第一服务器共同建立的。
可以看出，上述设计中，OTA升级装置140向OTA服务器发送升级数据的元数据，OTA服务器向第一终端发送升级数据的第一下载地址。第一终端通过第一下载地址下载升级数据，避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是直接从下载地址对应的存储设备上直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
在又一种可能的实施方式中，所述OTA升级装置还包括：
处理单元1402，用于确定所述目标零部件的升级数据的元数据。
在又一种可能的实施方式中，所述发送单元1401，具体用于：
通过所述安全通道向所述第一终端中的所述目标零部件发送所述目标零部件的升级数据；
或者，通过所述安全通道向所述第一终端中的升级控制部件发送所述目标零部件的升级数据。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
请参见图15，图15是本申请实施例提供的一种OTA升级装置150的结构示意图，该OTA升级装置150可以包括接收单元1501、处理单元1502。该OTA升级装置140用于实现前述的OTA方法，例如可以用于实现图3、图8、图10或者图12所示的OTA升级方法。
在一种可能的设计中，图15中所示的OTA升级装置150可以为图8所示实施例中的第一终端，或者为第一终端中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置150可以包括接收单元1501和处理单元1502，其中：
所述接收单元1501，用于接收OTA服务器发送的下载策略，所述下载策略中包含目标零部件的升级数据的第一下载地址；所述目标零部件部署在所述第一终端上；
所述处理单元1502，用于基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述处理单元1502，还用于通过所述安全通道接收所述第一服务器发送的所述目标零部件的升级数据；
所述处理单元1502，还用于根据所述目标零部件的升级数据升级所述目标零部件。
可以看出，上述OTA升级装置通过第一下载地址下载升级数据，避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是在第一服务器直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述OTA升级装置150具体可以为第一终端中的所述目标零部件；
或者，所述OTA升级装置150具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图8所示实施例中的OTA服务器，或者为OTA服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括接收单元1303和发送单元1302，其中：
所述接收单元1303，用于接收第一服务器发送的目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
所述发送单元1302，用于向所述第一终端发送升级策略，所述升级策略包含所述第一下载地址。
可以看出，上述设计中，上述OTA升级装置130接收升级数据的元数据，向升级策略转发升级数据的下载地址，而无法获取到升级数据，从而保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，第一终端可以根据第一下载地址从第一服务器或者其他存储设备上下载升级数据，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述装置130还包括：
处理单元1301，用于根据所述第一终端的信息和/或升级数据的元数据，确定所述升级策略。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
在又一种可能的实施方式中，所述元数据中还包括所述目标零部件的升级数据的文件大小。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
在一种可能的设计中，图14中所示的OTA升级装置140可以为图10所示实施例中的第一服务器，或者为第一服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置140可以包括处理单元1402和发送单元1401，其中：
所述处理单元1402，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述处理单元1402，用于通过第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述发送单元1401，用于向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于所述第一终端解密所述第一密文。
在又一种可能的实施方式中，所述OTA升级装置140属于所述目标零部件的供应商用于维护所述目标零部件的装置。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图10所示实施例中的OTA服务器，或者为OTA服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括接收单元1303和发送单元1302，其中：
所述接收单元1303，用于接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
所述发送单元1302，用于向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
可以看出，上述设计中，将升级数据通过第一密钥进行加密得到第一密文，将第二密钥进行使用第一安全参数进行加密得到第二密文。由于没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了目标零部件的升级数据的安全性。
进一步的，由于没有直接对目标零部件的升级数据进行加密，而是使用第一安全参数加密第二密钥，而密钥的数据大小通常小于升级数据的数据大小。因此，对于存在有多个、多种零部件需要升级的供应商来说，考虑多个零部件的安全参数可能不同的情况，相比于直接使用安全参数加密升级数据，本实施例可以显著减少加密过程中的计算量、存储量，提高升级的效率。
在又一种可能的实施方式中，所述装置130，还包括：
处理单元1301，用于根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
所述发送单元1302，还用于向所述第一终端发送所述升级策略；
所述发送单元1302，还用于通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，图15中所示的OTA升级装置150可以为图10所示实施例中的第一终端，或者为第一终端中的一个器件，例如芯片或者集成电路等。其中，所述OTA升级装置150中(或者OTA升级装置150所在的设备中)部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个。
在一种可能的实施方案中，该OTA升级装置150可以包括接收单元1501和处理单元1502，其中：
所述接收单元1501，用于接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述处理单元1502，用于根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
所述处理单元1502，还用于根据所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
所述处理单元1502，还用于根据所述目标零部件的升级数据升级所述第一目标零部件。
在又一种可能的实施方式中，所述OTA升级装置150具体为所述第一终端中的所述第一目标零部件；
或者，所述OTA升级装置150具体为所述第一终端中的升级控制部件。
在又一种可能的实施方式中，所述处理单元1502，还用于通过第一下载地址与所述OTA服务器建立安全通道；
所述接收单元1501，具体用于通过所述安全通道接收所述OTA服务器发送的第一密文和第二密文。
在又一种可能的实施方式中，所述接收单元1501，还用于接收来自所述OTA服务器的下载策略，所述下载策略中包含所述第一下载地址。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，图14中所示的OTA升级装置140可以为图12所示实施例中的第一服务器，或者为第一服务器中的一个器件，例如芯片或者集成电路等。所述OTA升级装置可以为用于提供所述目标零部件的升级数据的装置。
在一种可能的实施方案中，该OTA升级装置140可以包括处理单元1402和发送单元1401，其中：
所述处理单元1402，用于根据第一安全参数对所述目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的所述第一服务器与所述第一终端之间的共享密钥或者为预置的所述第一终端的第一公钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；所述第一终端为部署有所述目标零部件的终端；
所述发送单元1401，用于向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
可以看出，上述设计中，第一安全参数和第二安全参数可以是预先配置或者预先获取的，第一服务器使用第一安全参数对目标零部件的升级数据进行加密，第一终端使用第二安全参数对第一密文解密从而获取目标零部件的升级数据。由于目标零部件的升级数据是经过加密传输的，没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
在一种可能的设计中，图15中所示的OTA升级装置150可以为图10所示实施例中的第一终端，或者为第一终端中的一个器件，例如芯片或者集成电路等。其中，所述OTA升级装置150中(或者OTA升级装置150所在的设备中)部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个。
在一种可能的实施方案中，该OTA升级装置150可以包括接收单元1501和处理单元1502，其中：
所述接收单元1501，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
所述处理单元1502，用于根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
所述处理单元1502，还用于根据所述目标零部件的升级数据升级所述目标零部件。
在又一种可能的实施方式中，所述OTA升级装置150具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置150具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
在一种可能的设计中，图13中所示的OTA升级装置130可以为图10所示实施例中的OTA服务器，或者为OTA服务器中的一个器件，例如芯片或者集成电路等。
在一种可能的实施方案中，该OTA升级装置130可以包括接收单元1303和发送单元1302，其中：
所述接收单元1303，用于接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一安全参数对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
所述发送单元1302，用于向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
在又一种可能的实施方式中，所述发送单元1302，具体用于通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
在又一种可能的实施方式中，所述装置130还包括：
处理单元1301，用于根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
请参见图16，图16是本申请实施例提供的一种OTA升级装置160的结构示意图，该装置160可以包括至少一个存储器1601和至少一个处理器1602。可选的，还可以包含总线1603。进一步可选的，还可以包括通信接口1604，其中，存储器1601、处理器1602和通信接口1604通过总线1603相连。
其中，存储器1601用于提供存储空间，存储空间中可以存储操作系统和计算机程序等数据。存储器1601可以是随机存储记忆体(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read only memory，EPROM)、或便携式只读存储器(compact disc read-only memory，CD-ROM)等等中的一种或者多种的组合。
处理器1602是进行算术运算和/或逻辑运算的模块，具体可以是中央处理器(central processing unit，CPU)、图片处理器(graphics processing unit，GPU)、微处理器(microprocessor unit，MPU)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程逻辑门阵列(Field Programmable Gate Array，FPGA)、复杂可编程逻辑器件(Complex programmable logic device，CPLD)等处理模块中的一种或者多种的组合。
通信接口1604用于接收外部发送的数据和/或向外部发送数据，可以为包括诸如以太 网电缆等的有线链路接口，也可以是无线链路(Wi-Fi、蓝牙、通用无线传输等)接口。可选的，通信接口1604还可以包括与接口耦合的发射器(如射频发射器、天线等)，或者接收器等。
该装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行前述的OTA升级方法，例如图3、图8、图10或者图12中任意一个实施例所描述的OTA升级方法。
在一种可能的设计中，该OTA升级装置160可以为图3所示实施例中的第一服务器，或者第一服务器中的一个模块，例如芯片或者集成电路等。其中，所述OTA升级装置160可以为用于提供所述目标零部件的升级数据的装置。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过通信接口1604向OTA服务器发送所述第一密文；
通过通信接口1604向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，只有OTA升级装置160、第一终端可以通过第二密钥得到升级数据，避免了其他中间设备获取升级数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，上述OTA升级装置160属于目标零部件的供应商用于维护目标零部件的装置。
在又一种可能的实施方式中，所述处理器1602，还用于：
与部署有所述目标零部件的所述第一终端建立安全通道；
通过所述通信接口1604通过所述安全通道向所述第一终端发送所述第二密钥。
在又一种可能的实施方式中，所述处理器1602，还用于：
根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
通过所述通信接口1604向部署有所述目标零部件的所述第一终端发送所述第二密文。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过所述通信接口1604接收来自所述第一终端的密钥获取请求。
在又一种可能的实施方式中，所述第一安全参数属于临时密钥或者属于一次性密钥。
在又一种可能的实施方式中，所述第一安全参数为所述第一终端的第一公钥；所述处理器1602，还用于通过所述第一终端的第一数字证书认证所述第一终端的第一公钥。
在又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述处理 器1602，还用于：
通过所述通信接口1604接收来自所述第一终端发送的第一签名，所述第一签名为使用所述第二私钥对所述第一公钥签名得到的；
根据所述第二公钥、所述第一签名和所述第一公钥确定所述第一公钥认证通过。
在又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理器1602，还用于：
通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
在的又一种可能的实施方式中，所述处理器1602，还用于：
通过所述通信接口1604接收所述第一终端发送的第一消息，所述第一信息包含第一随机数；
通过所述通信接口1604向所述第一终端发送第二消息，所述第二信息包含第一认证参数和第二随机数；所述第一认证参数为根据所述第一消息、所述第二随机数和所述PSK得到的；
通过所述通信接口1604接收所述第一终端发送的第三消息，所述第三信息包含第二认证参数；
根据所述第二消息、所述第一随机数和所述PSK确定所述目标零部件的身份认证通过。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过所述通信接口1604向所述第一终端的升级控制部件发送所述第二密钥；
或者，通过所述通信接口1604向所述第一终端的所述目标零部件发送所述第二密钥。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图3所示实施例中的第一终端，或者第一终端中的一个模块，例如芯片或者集成电路等。可选的，所述OTA升级装置160中(或者OTA升级装置160所在的设备中)部署有目标零部件。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过通信接口1604接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
通过所述目标零部件的升级数据，升级所述目标零部件。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，只有第一服务器、OTA升级装置160可以通过第二密钥得到升级数据，避免了其他中间设备获取升级 数据，提高了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，所述处理器1602，还用于：
与所述第一服务器建立安全通道；
通过通信接口1604通过所述安全通道接收所述第一服务器的所述第二密钥。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604向所述第一服务器发送密钥获取请求。
在又一种可能的实施方式中，所述第二安全参数属于临时密钥或者属于一次性密钥。
在又一种可能的实施方式中，所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述第一终端的第一公钥；
所述第一公钥通过所述第一终端的第一数字证书进行认证。
在又一种可能的实施方式中，所述第一数字证书对应第二公钥和第二私钥；所述处理器1602，还用于：
确定所述第一公钥和所述第一私钥；
通过所述第二私钥对所述第一公钥进行签名，得到第一签名，
通过通信接口1604向所述第一服务器发送第一签名和所述第一公钥；所述第一签名用于所述第一服务器根据所述第一签名证书对应的第二公钥认证所述第一公钥。
在又一种可能的实施方式中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理器1602，还用于：
通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604向所述第一服务器发送第一消息，所述第一消息包含第一随机数；
通过通信接口1604接收所述第一服务器发送的第二消息，所述第二消息包含第一认证参数和第二随机数；
根据所述第一认证参数、所述第一消息、所述第二随机数和所述PSK确定所述第一服务器的身份认证通过；
通过通信接口1604向所述第一服务器发送第三消息，所述第三消息包含第二认证参数；所述第二认证参数为根据所述第一随机数、所述第二消息和所述PSK得到的。所述第二认证参数用于认证所述第一终端的身份。
在又一种可能的实施方式中，所述OTA升级装置160具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置160具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图3所示实施例中的OTA服务器，或者OTA服务器中的一个模块，例如芯片或者集成电路等。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过通信接口1604向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
可以看出，上述设计中，由于目标零部件的升级数据是经过加密传输的，上述OTA升级装置160可以接收密文、转发下载地址以使得第一终端获取第一密文，但是上述OTA升级装置160无法获取解密的密钥。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于升级数据是经过加密的，可以避免攻击者篡改升级数据，提高了OTA升级的安全性。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
其中，升级规则用于定义升级的次序、是否需要进行回滚等规则，升级条件可以包含是否供电正常、存储空间、网络状态、有依赖关系的其他设备的状态等，下载规则用于定义下载的顺序、指示哪一个部件进行下载等等。
在又一种可能的实施方式中，所述处理器1602，还用于：
根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
例如，OTA服务器根据第一终端的信息和第一密文的文件大小，确定所述第一终端需要的存储空间大小。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图3所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图8所示实施例中的第一服务器，或者第一服务器中的一个模块，例如芯片或者集成电路等。其中，所述OTA升级装置160 可以为用于提供所述目标零部件的升级数据的装置。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604向OTA服务器发送目标零部件的升级数据的元数据，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
通过通信接口1604通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与所述第一服务器共同建立的。
可以看出，上述设计中，OTA升级装置160向OTA服务器发送升级数据的元数据，OTA服务器向第一终端发送升级数据的第一下载地址。第一终端通过第一下载地址下载升级数据，避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是直接从下载地址对应的存储设备上直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
在又一种可能的实施方式中，所述处理器1602，还用于：
确定所述目标零部件的升级数据的元数据。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604通过所述安全通道向所述第一终端中的所述目标零部件发送所述目标零部件的升级数据；
或者，通过通信接口1604通过所述安全通道向所述第一终端中的升级控制部件发送所述目标零部件的升级数据。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图8所示实施例中的第一终端，或者第一终端中的一个模块，例如芯片或者集成电路等。可选的，所述OTA升级装置160中(或者OTA升级装置160所在的设备中)部署有目标零部件。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收OTA服务器发送的下载策略，所述下载策略中包含目标零部件的升级数据的第一下载地址；所述目标零部件部署在所述第一终端上；
基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过通信接口1604通过所述安全通道接收所述第一服务器发送的所述目标零部件的 升级数据；
根据所述目标零部件的升级数据升级所述目标零部件。
可以看出，上述OTA升级装置通过第一下载地址下载升级数据，避免了其他中间设备(例如OTA服务器)获取目标零部件的升级数据，保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，由于目标零部件的升级数据是在第一服务器直接获取的，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述OTA升级装置160具体可以为第一终端中的所述目标零部件；
或者，所述OTA升级装置160具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图8所示实施例中的OTA服务器，或者OTA服务器中的一个模块，例如芯片或者集成电路等。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收第一服务器发送的目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
通过通信接口1604向所述第一终端发送升级策略，所述升级策略包含所述第一下载地址。
可以看出，上述设计中，上述OTA升级装置160接收升级数据的元数据，向升级策略转发升级数据的下载地址，而无法获取到升级数据，从而保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
进一步的，第一终端可以根据第一下载地址从第一服务器或者其他存储设备上下载升级数据，因此避免了中间设备等进行转存、或者审核等操作，减少了升级流程的复杂度，提高了升级效率。通过本申请实施例还可以满足某一些需要快速升级的零部件的需求。
在又一种可能的实施方式中，所述处理器1602，还用于：
根据所述第一终端的信息和/或升级数据的元数据，确定所述升级策略。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
在又一种可能的实施方式中，所述元数据中还包括所述目标零部件的升级数据的文件大小。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图8所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图10所示实施例中的第一服务器，或者第一服务器中的一个模块，例如芯片或者集成电路等。其中，所述OTA升级装置160可以为用于提供所述目标零部件的升级数据的装置。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
通过通信接口1604向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于所述第一终端解密所述第一密文。
在又一种可能的实施方式中，所述OTA升级装置160属于所述目标零部件的供应商用于维护所述目标零部件的装置。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图10所示实施例中的OTA服务器，或者OTA服务器中的一个模块，例如芯片或者集成电路等。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
通过通信接口1604向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
可以看出，上述设计中，将升级数据通过第一密钥进行加密得到第一密文，将第二密钥进行使用第一安全参数进行加密得到第二密文。由于没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了目标零部件的升级数据的安全性。
进一步的，由于没有直接对目标零部件的升级数据进行加密，而是使用第一安全参数加密第二密钥，而密钥的数据大小通常小于升级数据的数据大小。因此，对于存在有多个、多种零部件需要升级的供应商来说，考虑多个零部件的安全参数可能不同的情况，相比于直接使用安全参数加密升级数据，本实施例可以显著减少加密过程中的计算量、存储量， 提高升级的效率。
在又一种可能的实施方式中，所述处理器1602，还用于：
根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
通过通信接口1604向所述第一终端发送所述升级策略；
通过通信接口1604通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图10所示实施例中的第一终端，或者第一终端中的一个模块，例如芯片或者集成电路等。其中，所述OTA升级装置160中(或者OTA升级装置160所在的设备中)部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
根据所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
根据所述目标零部件的升级数据升级所述第一目标零部件。
在又一种可能的实施方式中，所述OTA升级装置160具体为所述第一终端中的所述第一目标零部件；
或者，所述OTA升级装置160具体为所述第一终端中的升级控制部件。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过第一下载地址与所述OTA服务器建立安全通道；
通过通信接口1604通过所述安全通道接收所述OTA服务器发送的第一密文和第二密文。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604接收来自所述OTA服务器的下载策略，所述下载策略中包含所述第一下载地址。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图10所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图12所示实施例中的第一服务器，或者第一服务器中的一个模块，例如芯片或者集成电路等。其中，所述OTA升级装置160可以为用于提供所述目标零部件的升级数据的装置。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
根据第一安全参数对所述目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的所述第一服务器与所述第一终端之间的共享密钥或者为预置的所述第一终端的第一公钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；所述第一终端为部署有所述目标零部件的终端；
通过通信接口1604向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
可以看出，上述设计中，第一安全参数和第二安全参数可以是预先配置或者预先获取的，第一服务器使用第一安全参数对目标零部件的升级数据进行加密，第一终端使用第二安全参数对第一密文解密从而获取目标零部件的升级数据。由于目标零部件的升级数据是经过加密传输的，没有获取第二安全参数则无法解密第二密文得到第二密钥，从而无法解密第一密文得到目标零部件的升级数据，因此保证了升级数据的机密性。当升级数据中包含核心代码、关键技术实现的情况下，可以有效保护涉密数据、关键代码等核心资产。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图12所示实施例中的第一服务器，或者第一服务器中的一个模块，例如芯片或者集成电路等。可选的，所述OTA升级装置160中(或者OTA升级装置160所在的设备中)部署有目标零部件。
该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
根据所述目标零部件的升级数据升级所述目标零部件。
在又一种可能的实施方式中，所述OTA升级装置160具体为第一终端中的所述目标零部件；
或者，所述OTA升级装置160具体为所述第一终端中的升级控制部件。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
在一种可能的设计中，该OTA升级装置160可以为图12所示实施例中的OTA服务器，或者OTA服务器中的一个模块，例如芯片或者集成电路等。该OTA升级装置160中的处理器1602用于读取所述存储器1601中存储的计算机程序，用于执行以下操作：
通过通信接口1604接收来自第一服务器的第一密文，所述第一密文为第一服务器根据第一安全参数对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
通过通信接口1604向所述第一终端发送升级策略，所述升级策略包含所述第一密文的第一下载地址。
在又一种可能的实施方式中，所述处理器1602，还用于：
通过通信接口1604通过所述安全通道向所述第一终端发送所述第一密文，所述安全通道为所述第一终端基于所述第一下载地址与所述OTA服务器共同建立的。
在又一种可能的实施方式中，所述升级策略中包括升级规则、升级条件、下载规则等等中的一项或者多项。
在又一种可能的实施方式中，所述处理器1602，还用于：
根据所述第一终端的信息和/或所述第一密文的信息，确定所述升级策略。
需要说明的是，上述设计中的各个单元的具体实现还可以对应参照图12所示的实施例的相应描述。
本申请实施例还提供了一种芯片系统，所述芯片系统包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述芯片系统所在的装置实现图3、图8、图10或者图12所示的实施例中第一服务器、OTA服务器或者第一终端侧的方法。
进一步，所述至少一个处理器可以为CPU、GPU、MPU、ASIC、FPGA、CPLD、协处理器(协助中央处理器完成相应处理和应用)、MCU等处理模块中的一种或者多种的组合。
本申请实施例还提供了一种OTA升级系统，该OTA升级系统包括第一服务器和目标零部件。其中，所述第一服务器用于实现图3、图8、图10或者图12所示的实施例中第一服务器侧的方法；
所述目标零部件用于实现图3、图8、图10或者图12所示的实施例中第一终端侧的方法。进一步的，所述第一服务器可以属于所述目标零部件的供应商的服务器。
本申请实施例还提供了一种OTA升级系统，该OTA升级系统包括OTA服务器和第一终端。其中，所述OTA服务器用于实现图3、图8、图10或者图12所示的实施例中OTA服务器侧的方法；
所述第一终端用于实现图3、图8、图10或者图12所示的实施例中第一终端侧的方法。
本申请实施例还提供了一种OTA升级系统，该OTA升级系统包括第一服务器、OTA服务器和第一终端。其中，所述第一服务器用于实现图3、图8、图10或者图12所示的实施例中第一服务器侧的方法；
所述OTA服务器用于实现图3、图8、图10或者图12所示的实施例中OTA服务器侧 的方法；
所述第一终端用于实现图3、图8、图10或者图12所示的实施例中第一终端侧的方法。
本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，实现图3、图8、图10或者图12所示的实施例所描述的方法。
本申请实施例还提供了一种计算机程序产品，当所述计算机程序产品在一个或多个处理器上运行时，实现图3、图8、图10或者图12所示的实施例所描述的方法。
在计算机上加载和执行该计算机指令时，可以全部或部分地实现本申请实施例所描述的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其它可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者通过计算机可读存储介质进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如，固态硬盘(solid state disk，SSD))等。
本申请方法实施例中的步骤可以根据实际需要进行顺序调整、合并和删减。
本申请装置实施例中的模块可以根据实际需要进行合并、划分和删减。

Claims (61)

  1. 一种空中下载技术OTA升级方法，其特征在于，包括：
    第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述第一服务器向OTA服务器发送所述第一密文；
    所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
  2. 根据权利要求1中所述的方法，其特征在于，所述第一服务器属于所述目标零部件的供应商用于维护所述目标零部件的服务器。
  3. 根据权利要求1或2中所述的方法，其特征在于，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
    所述第一服务器与部署有所述目标零部件的所述第一终端建立安全通道；
    所述第一服务器通过所述安全通道向所述第一终端发送所述第二密钥。
  4. 根据权利要求1或2中所述的方法，其特征在于，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
    所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
    所述第一服务器向部署有所述目标零部件的所述第一终端发送所述第二密文。
  5. 根据权利要求4中所述的方法，其特征在于，所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，所述方法还包括：
    所述第一服务器接收来自所述第一终端的密钥获取请求。
  6. 根据权利要求4或5中所述的方法，其特征在于，所述第一安全参数属于临时密钥或者属于一次性密钥。
  7. 根据权利要求4-6任一项中所述的方法，其特征在于，所述第一安全参数为所述目标零部件的第一公钥；所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，还包括：
    所述第一服务器接收所述第一终端发送的所述目标零部件的第一公钥；
    所述第一服务器通过所述目标零部件的第一数字证书认证所述目标零部件的第一公钥。
  8. 根据权利要求4-6任一项中所述的方法，其特征在于，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述第一服务器根据第一安全参数加密所述第二密钥得到第二密文之前，还包括：
    所述第一服务器通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
    所述第一服务器通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
  9. 根据权利要求1-8任一项中所述的方法，其特征在于，所述第一服务器向部署有所述目标零部件的第一终端发送第二密钥，包括：
    所述第一服务器向所述第一终端的升级控制部件发送所述第二密钥；
    或者，所述第一服务器向所述第一终端的所述目标零部件发送所述第二密钥。
  10. 一种空中下载技术OTA升级方法，其特征在于，包括：
    第一终端接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对所述第一终端上的目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述第一终端接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
    所述第一终端通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
    所述第一终端通过所述目标零部件的升级数据，升级所述目标零部件。
  11. 根据权利要求10中所述的方法，其特征在于，所述第一终端接收来自所述第一服务器的第二密钥，包括：
    所述第一终端与所述第一服务器建立安全通道；
    所述第一终端通过所述安全通道接收所述第一服务器的所述第二密钥。
  12. 根据权利要求10中所述的方法，其特征在于，所述第一终端接收来自所述第一服务器发送的第二密钥，包括：
    所述第一终端接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
    所述第一终端根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
  13. 根据权利要求12中所述的方法，其特征在于，所述第一终端接收来自所述第一服务器的第二密钥之前，所述方法还包括：
    所述第一终端向所述第一服务器发送密钥获取请求。
  14. 根据权利要求12或13中所述的方法，其特征在于，所述第二安全参数属于临时 密钥或者属于一次性密钥。
  15. 根据权利要求12-14任一项中所述的方法，其特征在于，
    所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述目标零部件的第一公钥；
    所述第一公钥通过所述目标零部件的第一数字证书进行认证。
  16. 根据权利要求12-14任一项中所述的方法，其特征在于，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述第一终端根据第二安全参数解密所述第二密文，得到所述第二密钥之前，还包括：
    所述第一终端通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
    所述第一终端通过所述第一服务器和所述目标零部件之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
  17. 根据权利要求10-16中任一项所述的方法，其特征在于，
    所述OTA升级方法具体应用于所述第一终端中的所述目标零部件；
    或者，所述第一终端中还包括升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
  18. 一种OTA升级方法，其特征在于，包括：
    第一服务器向OTA服务器发送目标零部件的升级数据的元数据，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述升级数据的元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
    所述第一服务器通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与所述第一服务器共同建立的。
  19. 根据权利要求18中所述的方法，其特征在于，所述第一服务器属于所述目标零部件的供应商用于维护所述目标零部件的服务器。
  20. 一种空中下载技术OTA升级方法，其特征在于，应用于部署有目标零部件的第一终端，所述方法包括：
    所述第一终端接收OTA服务器发送的下载策略，所述下载策略中包含所述目标零部件的升级数据的第一下载地址；
    所述第一终端基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述第一终端通过所述安全通道接收所述第一服务器发送的所述目标零部件的升级数据；
    所述第一终端根据所述目标零部件的升级数据升级所述目标零部件。
  21. 一种空中下载技术OTA升级方法，其特征在于，包括：
    第一服务器根据第一密钥对目标零部件的升级数据进行加密得到第一密文，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述第一服务器通过第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
    所述第一服务器向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于所述第一终端解密所述第一密文。
  22. 根据权利要求21中所述的方法，其特征在于，所述第一服务器属于所述目标零部件的供应商用于维护所述目标零部件的服务器。
  23. 一种空中下载技术OTA升级方法，其特征在于，包括：
    OTA服务器接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
    所述OTA服务器向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
  24. 根据权利要求23中所述的方法，其特征在于，所述OTA服务器向所述第一终端发送所述第一密文和所述第二密文，包括：
    所述OTA服务器根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
    所述OTA服务器向所述第一终端发送所述升级策略；
    所述OTA服务器通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
  25. 一种空中下载技术OTA升级方法，其特征在于，应用于部署有第一目标零部件的第一终端，所述第一目标零部件为目标零部件中的一个，所述方法包括：
    所述第一终端接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述第一终端根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所 述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
    所述第一终端根据所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
    所述第一终端根据所述目标零部件的升级数据升级所述第一目标零部件。
  26. 根据权利要求25中所述的方法，其特征在于，
    所述OTA升级方法具体应用于所述第一终端中的所述第一目标零部件；
    或者，所述OTA升级系统中的第一终端中还包括升级控制部件，所述OTA升级方法具体应用于所述升级控制部件。
  27. 一种OTA升级方法，其特征在于，包括：
    第一服务器根据第一安全参数对所述目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的所述第一服务器与所述第一终端之间的共享密钥或者为预置的所述第一终端的第一公钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；所述第一终端为部署有所述目标零部件的终端；
    所述第一服务器向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
  28. 一种空中下载技术OTA升级方法，其特征在于，应用于部署有第一目标零部件的第一终端，所述第一目标零部件为目标零部件中的一个，所述方法包括：
    第一终端接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
    所述第一终端根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
    所述第一终端根据所述目标零部件的升级数据升级所述目标零部件。
  29. 一种空中下载技术OTA升级装置，其特征在于，所述OTA升级装置用于提供所述目标零部件的升级数据的装置，所述OTA升级装置包括：
    处理单元，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密文；
    发送单元，用于向OTA服务器发送所述第一密文；
    所述发送单元，还用于向部署有所述目标零部件的第一终端发送第二密钥，所述第二密钥为所述第一密钥对应的解密密钥。
  30. 根据权利要求29中所述的装置，其特征在于，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
  31. 根据权利要求29或30中所述的装置，其特征在于，所述发送单元，具体用于：
    与部署有所述目标零部件的所述第一终端建立安全通道；
    通过所述安全通道向所述第一终端发送所述第二密钥。
  32. 根据权利要求29或30中所述的装置，其特征在于，所述处理单元，还用于根据第一安全参数加密所述第二密钥得到第二密文，所述第一安全参数为第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
    所述发送单元，具体用于向部署有所述目标零部件的所述第一终端发送所述第二密文。
  33. 根据权利要求32中所述的装置，其特征在于，所述装置还包括：
    接收单元，用于接收来自所述第一终端的密钥获取请求。
  34. 根据权利要求32或33中所述的装置，其特征在于，所述第一安全参数属于临时密钥或者属于一次性密钥。
  35. 根据权利要求32-34任一项中所述的装置，其特征在于，所述第一安全参数为所述第一终端的第一公钥；所述接收单元，还用于接收所述第一终端发送的所述目标零部件的第一公钥；
    所述处理单元，还用于通过所述第一终端的第一数字证书认证所述第一公钥。
  36. 根据权利要求32-34任一项中所述的装置，其特征在于，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元，还用于：
    通过密钥协商算法，与所述第一终端协商得到所述共享密钥；
    通过第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一终端的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
  37. 根据权利要求30-36任一项中所述的装置，其特征在于，所述发送单元，具体用于：
    向所述第一终端的升级控制部件发送所述第二密钥；
    或者，向所述第一终端的所述目标零部件发送所述第二密钥。
  38. 一种空中下载技术OTA升级装置，其特征在于，包括：
    接收单元，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一密钥对目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    所述接收单元，还用于接收来自所述第一服务器的第二密钥，所述第二密钥为所述第一密钥对应的解密密钥；
    处理单元，用于通过所述第二密钥解密所述第一密文，得到所述目标零部件的升级数 据；
    所述处理单元，还用于通过所述目标零部件的升级数据，升级所述目标零部件。
  39. 根据权利要求38中所述的装置，其特征在于，所述处理单元，还用于与所述第一服务器建立安全通道；
    所述接收单元，具体用于通过所述安全通道接收所述第一服务器的所述第二密钥。
  40. 根据权利要求38中所述的装置，其特征在于，
    所述接收单元，具体用于接收来自所述第一服务器的第二密文；所述第二密文为根据第一安全参数加密第二密钥得到的；
    所述处理单元，还用于根据第二安全参数解密所述第二密文，得到所述第二密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥。
  41. 根据权利要求40中所述的装置，其特征在于，所述装置还包括：
    发送单元，用于向所述第一服务器发送密钥获取请求。
  42. 根据权利要求40或41中所述的装置，其特征在于，所述第二安全参数属于临时密钥或者属于一次性密钥。
  43. 根据权利要求41-42任一项中所述的装置，其特征在于，
    所述第二安全参数为所述第一公钥对应的第一私钥，所述第一安全参数为所述第一终端的第一公钥；
    所述第一公钥通过所述第一终端的第一数字证书进行认证。
  44. 根据权利要求41-42任一项中所述的装置，其特征在于，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥；所述处理单元，还用于：
    通过密钥协商算法，与所述第一服务器协商得到所述共享密钥；
    通过所述第一服务器和所述第一终端之间的预共享密钥PSK认证所述第一服务器的身份，所述PSK为所述第一服务器与所述目标零部件之间预设的秘密值。
  45. 根据权利要求38-44中任一项所述的装置，其特征在于，所述OTA升级装置具体为第一终端中的所述目标零部件；
    或者，所述OTA升级装置具体为所述第一终端中的升级控制部件。
  46. 一种OTA升级装置，其特征在于，所述OTA升级装置为用于提供所述目标零部件的升级数据的装置，所述OTA升级装置包括：
    发送单元，用于向OTA服务器发送目标零部件的升级数据的元数据，所述升级数据的 元数据包含所述升级数据的第一下载地址和所述升级数据的版本信息；
    所述发送单元，还用于通过安全通道向部署有所述目标零部件的第一终端发送所述目标零部件的升级数据，所述安全通道为所述第一终端根据所述第一下载地址与第一服务器共同建立的。
  47. 根据权利要求46中所述的装置，其特征在于，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
  48. 一种空中下载技术OTA升级装置，其特征在于，所述OTA升级装置中部署有目标零部件，所述OTA升级装置包括：
    接收单元，用于接收OTA服务器发送的下载策略，所述下载策略中包含所述目标零部件的升级数据的第一下载地址；
    所述处理单元，还用于基于所述第一下载地址，与第一服务器共同建立安全通道，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    接收单元，用于通过所述安全通道接收所述第一服务器发送的所述目标零部件的升级数据；
    所述处理单元，还用于根据所述目标零部件的升级数据升级所述目标零部件。
  49. 一种空中下载技术OTA升级装置，其特征在于，所述OTA升级装置用于提供所述目标零部件的升级数据的装置，所述OTA升级装置包括：
    处理单元，用于根据第一密钥对目标零部件的升级数据进行加密得到第一密文；
    所述处理单元，还用于根据第一安全参数的加密第二密钥得到第二密文，其中，所述第一安全参数为第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥；
    发送单元，用于向OTA服务器发送所述第一密文和所述第二密文，所述第二密文用于部署有所述第一目标零部件的第一终端解密所述第一密文。
  50. 根据权利要求49中所述的装置，其特征在于，所述OTA升级装置属于所述目标零部件的供应商用于维护所述目标零部件的装置。
  51. 一种空中下载技术OTA升级装置，其特征在于，包括：
    接收单元，用于接收第一服务器发送的第一密文和第二密文，其中，所述第一密文为根据第一密钥对目标零部件的升级数据加密得到的，所述第二密文为根据第一安全参数对第二密钥加密得到的，所述第一安全参数为所述第一服务器与第一终端之间的共享密钥或者为所述第一终端部件的第一公钥，所述第一终端为部署有第一目标零部件的终端，所述第一目标零部件为所述目标零部件中的一个，所述第二密钥为所述第一密钥的解密密钥，所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    发送单元，用于向所述第一终端发送所述第一密文和所述第二密文，其中所述第二密文用于所述第一终端解密所述第一密文，以得到所述目标零部件的升级数据。
  52. 根据权利要求51中所述的装置，其特征在于，所述装置，还包括：
    处理单元，用于根据所述第一密文所在的升级包的属性和所述第一终端的信息生成升级策略；所述升级策略包括所述第一密文和所述第二密文的第一下载地址；
    所述发送单元，还用于向所述第一终端发送所述升级策略；
    所述发送单元，还用于通过安全通道向所述第一终端发送所述第一密文和所述第二密文，所述安全通道为所述第一终端根据所述第一下载地址与所述OTA服务器共同建立的。
  53. 一种空中下载技术OTA升级装置，其特征在于，所述OTA升级装置中部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个，所述OTA升级装置包括：
    接收单元，用于接收OTA服务器发送的第一密文和第二密文，所述第一密文为第一服务器根据第一密钥对所述目标零部件的升级数据加密得到的，其中所述第一服务器为用于提供所述目标零部件的升级数据的服务器；
    处理单元，用于根据第二安全参数解密所述第二密文得到第二密钥，所述第二密钥为所述第一密钥的解密密钥，所述第二安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一私钥；
    所述处理单元，还用于根据所述第二密钥解密所述第一密文，得到所述目标零部件的升级数据；
    所述处理单元，还用于根据所述目标零部件的升级数据升级所述第一目标零部件。
  54. 根据权利要求53中所述的装置，其特征在于，
    所述OTA升级装置具体为所述第一终端中的所述目标零部件；
    或者，所述OTA升级装置具体为所述第一终端中的所述升级控制部件。
  55. 一种OTA升级装置，其特征在于，所述OTA升级装置为用于提供所述目标零部件的升级数据的装置，所述OTA升级装置包括：
    处理单元，用于根据第一安全参数对目标零部件的升级数据进行加密得到第一密文，所述第一安全参数为预置的第一服务器与部署有所述目标零部件的第一终端之间的共享密钥或者为预置的部署有所述目标零部件的第一终端的第一公钥；
    发送单元，用于向OTA服务器发送所述第一密文；所述第一密文用于由所述OTA服务器发送给第一终端以对所述第一终端中的所述目标零部件进行升级。
  56. 一种空中下载技术OTA升级装置，其特征在于，所述OTA升级装置中部署有第一目标零部件，所述第一目标零部件为目标零部件中的一个，所述OTA升级装置包括：
    接收单元，用于接收OTA服务器发送的第一密文，所述第一密文为第一服务器根据第一安全参数对所述目标零部件的升级数据加密得到的，所述第一服务器为用于提供所述目 标零部件的升级数据的服务器，所述第一安全参数为所述第一服务器与所述第一终端之间的共享密钥或者为所述第一终端的第一公钥；
    所述接收单元，还用于根据第二安全参数解密所述升级包中的第一密文，得到所述目标零部件的升级数据，所述第二安全参数为所述共享密钥或者为所述第一终端的第一私钥；
    所述处理单元，还用于根据所述目标零部件的升级数据升级所述目标零部件。
  57. 一种空中下载技术OTA升级装置，其特征在于，所述装置包括至少一个处理器和通信接口，所述通信接口用于发送和/或接收数据，所述至少一个处理器用于调用至少一个存储器中存储的计算机程序，以使得所述装置实现如权利要求1-28中任一项所述的方法。
  58. 一种空中下载技术OTA升级系统，其特征在于，所述系统包括第一服务器和目标零部件，其中：
    所述第一服务器用于实现如权利要求1-9中任一项所述的OTA升级方法，所述目标零部件用于实现包含权利要求10-17中任一项所述的OTA升级方法；
    或者，第一服务器用于实现如权利要求18或者19中所述的OTA升级方法，所述目标零部件用于实现如权利要求20所述的OTA升级方法；
    或者，第一服务器用于实现如权利要求21或者22中任一项所述的OTA升级方法，所述目标零部件用于实现如权利要求25或者26中任一项所述的OTA升级方法；
    或者，第一服务器用于实现如权利要求27中所述的OTA升级方法，所述目标零部件用于实现如包含权利要求28中所述的OTA升级方法。
  59. 一种空中下载技术OTA升级系统，其特征在于，所述系统包括OTA服务器和第一终端，其中：
    所述OTA服务器用于实现如权利要求23或者24中所述的OTA升级方法，所述第一终端包含权利要求25或者26中所述的OTA升级方法。
  60. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当所述计算机程序在一个或多个处理器上运行时，执行如权利要求1-28中任一项所述的方法。
  61. 一种计算机产品，其特征在于，当所述计算机产品在一个或多个处理器上运行时，执行如权利要求1-28中任一项所述的方法。
PCT/CN2020/140094 2020-12-28 2020-12-28 一种ota升级方法及装置 Ceased WO2022140903A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202080004762.2A CN112913189B (zh) 2020-12-28 2020-12-28 一种ota升级方法及装置
PCT/CN2020/140094 WO2022140903A1 (zh) 2020-12-28 2020-12-28 一种ota升级方法及装置
EP20967255.9A EP4258593A4 (en) 2020-12-28 2020-12-28 OTA UPDATE METHOD AND APPARATUS

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/140094 WO2022140903A1 (zh) 2020-12-28 2020-12-28 一种ota升级方法及装置

Publications (1)

Publication Number Publication Date
WO2022140903A1 true WO2022140903A1 (zh) 2022-07-07

Family

ID=76112904

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/140094 Ceased WO2022140903A1 (zh) 2020-12-28 2020-12-28 一种ota升级方法及装置

Country Status (3)

Country Link
EP (1) EP4258593A4 (zh)
CN (1) CN112913189B (zh)
WO (1) WO2022140903A1 (zh)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115250174A (zh) * 2022-07-26 2022-10-28 深圳微言科技有限责任公司 一种行为数据的隐私保护系统
CN115529138A (zh) * 2022-08-29 2022-12-27 中国南方电网有限责任公司 一种基于数字认证技术的变电站安全通信方法及系统
CN115883174A (zh) * 2022-11-28 2023-03-31 北京国家新能源汽车技术创新中心有限公司 一种适用于汽车ecu ota升级的国密混合加密算法、装置及存储介质
CN116193436A (zh) * 2023-02-28 2023-05-30 东风汽车集团股份有限公司 一种车机设备ota升级包下发方法及系统
CN116566824A (zh) * 2023-05-23 2023-08-08 济南量子技术研究院 一种量子安全的ota升级方法及系统
CN117435226A (zh) * 2023-12-22 2024-01-23 深圳市法本信息技术股份有限公司 车载电子控制单元的数据刷写方法、设备及存储介质
CN119892496A (zh) * 2025-03-25 2025-04-25 麒麟软件有限公司 一种升级包加密分发方法及系统
CN121509122A (zh) * 2026-01-14 2026-02-10 质子汽车科技有限公司 一种域控电气架构车辆ota信息安全防护方法和系统

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113687848A (zh) * 2021-08-13 2021-11-23 泰安北航科技园信息科技有限公司 一种针对物流车队管理场景的高可靠性车辆ota升级方法
CN113849213B (zh) * 2021-10-15 2024-05-14 四川启睿克科技有限公司 一种边缘设备的ota升级系统及方法
CN114286318B (zh) * 2021-12-28 2024-06-14 合众新能源汽车股份有限公司 一种基于一机一密的ota升级包传输方法
WO2023230929A1 (zh) * 2022-05-31 2023-12-07 华为技术有限公司 通信方法及相关装置
WO2024138547A1 (zh) * 2022-12-29 2024-07-04 华为技术有限公司 车载设备的升级方法及设备
CN116166765B (zh) * 2023-04-23 2023-08-01 国家基础地理信息中心 一种矢量数据的更新方法、装置、电子设备及存储介质
CN118659909B (zh) * 2024-06-28 2025-11-28 岚图汽车科技股份有限公司 升级包的传输方法、装置、设备及存储介质
CN119583061B (zh) * 2025-02-07 2025-04-15 中信建投证券股份有限公司 后量子密钥协商方法和设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019083440A2 (zh) * 2017-10-24 2019-05-02 华为国际有限公司 一种车载设备升级方法及相关设备
CN110597538A (zh) * 2019-09-03 2019-12-20 广州小鹏汽车科技有限公司 一种基于ota升级系统的软件升级方法和ota升级系统
CN111079163A (zh) * 2019-12-16 2020-04-28 国网山东省电力公司威海市文登区供电公司 加解密信息系统
WO2020101936A1 (en) * 2018-11-12 2020-05-22 Thirdwayv, Inc. Secure over-the-air firmware upgrade

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5390844B2 (ja) * 2008-12-05 2014-01-15 パナソニック株式会社 鍵配布システム、鍵配布方法
US20110173457A1 (en) * 2009-08-14 2011-07-14 Jeffrey Reh Enhanced security for over the air (ota) firmware changes
EP2750065A1 (en) * 2012-12-27 2014-07-02 Telefonica S.A. Method, system and computer program product for managing operations of service terminals
CN109561118B (zh) * 2017-09-26 2020-12-25 比亚迪股份有限公司 软件升级方法、装置、系统、存储介质、电子设备及车辆
CN109862099B (zh) * 2019-01-15 2022-07-12 浙江吉利汽车研究院有限公司 一种升级校验方法、装置、终端及系统
CN110378105B (zh) * 2019-07-02 2021-06-04 广州小鹏汽车科技有限公司 安全升级方法、系统、服务器及车载终端
CN110378153A (zh) * 2019-07-18 2019-10-25 上海擎感智能科技有限公司 一种升级包安全下载方法及系统
CN111263352B (zh) * 2020-01-08 2023-07-04 上海博泰悦臻网络技术服务有限公司 车载设备的ota升级方法、系统、存储介质及车载设备
CN111510485B (zh) * 2020-04-10 2022-09-09 东风小康汽车有限公司重庆分公司 一种ota升级包下载方法、装置、车辆端以及服务器

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019083440A2 (zh) * 2017-10-24 2019-05-02 华为国际有限公司 一种车载设备升级方法及相关设备
WO2020101936A1 (en) * 2018-11-12 2020-05-22 Thirdwayv, Inc. Secure over-the-air firmware upgrade
CN110597538A (zh) * 2019-09-03 2019-12-20 广州小鹏汽车科技有限公司 一种基于ota升级系统的软件升级方法和ota升级系统
CN111079163A (zh) * 2019-12-16 2020-04-28 国网山东省电力公司威海市文登区供电公司 加解密信息系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4258593A4 *

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115250174A (zh) * 2022-07-26 2022-10-28 深圳微言科技有限责任公司 一种行为数据的隐私保护系统
CN115529138A (zh) * 2022-08-29 2022-12-27 中国南方电网有限责任公司 一种基于数字认证技术的变电站安全通信方法及系统
CN115883174A (zh) * 2022-11-28 2023-03-31 北京国家新能源汽车技术创新中心有限公司 一种适用于汽车ecu ota升级的国密混合加密算法、装置及存储介质
CN116193436A (zh) * 2023-02-28 2023-05-30 东风汽车集团股份有限公司 一种车机设备ota升级包下发方法及系统
CN116566824A (zh) * 2023-05-23 2023-08-08 济南量子技术研究院 一种量子安全的ota升级方法及系统
CN117435226A (zh) * 2023-12-22 2024-01-23 深圳市法本信息技术股份有限公司 车载电子控制单元的数据刷写方法、设备及存储介质
CN117435226B (zh) * 2023-12-22 2024-04-16 深圳市法本信息技术股份有限公司 车载电子控制单元的数据刷写方法、设备及存储介质
CN119892496A (zh) * 2025-03-25 2025-04-25 麒麟软件有限公司 一种升级包加密分发方法及系统
CN121509122A (zh) * 2026-01-14 2026-02-10 质子汽车科技有限公司 一种域控电气架构车辆ota信息安全防护方法和系统

Also Published As

Publication number Publication date
CN112913189A (zh) 2021-06-04
CN112913189B (zh) 2022-08-26
EP4258593A1 (en) 2023-10-11
EP4258593A4 (en) 2024-03-20

Similar Documents

Publication Publication Date Title
CN112913189B (zh) 一种ota升级方法及装置
US11321074B2 (en) Vehicle-mounted device upgrade method and related apparatus
JP7619746B2 (ja) セキュアアクセス方法および装置
AU2013230989B2 (en) Policy for secure packet transmission using required node paths and cryptographic signatures
CN110050437B (zh) 分布式证书注册的装置和方法
EP2917867B1 (en) An improved implementation of robust and secure content protection in a system-on-a-chip apparatus
JP7760025B2 (ja) Ｂｌｕｅｔｏｏｔｈノードペアリング方法及び関連する装置
WO2021147100A1 (zh) 报文传输方法及装置
CN116599772B (zh) 一种数据处理方法及相关设备
US11153344B2 (en) Establishing a protected communication channel
CN113556230B (zh) 数据安全传输方法、证书相关方法、服务端、系统及介质
CN110213039A (zh) 一种管理方法、终端和服务器
WO2022171177A1 (zh) 通信密钥配置方法及装置
CN112449323A (zh) 一种通信方法、装置和系统
WO2021022406A1 (zh) 一种身份验证方法及装置
WO2021082222A1 (zh) 通信方法、存储方法、运算方法及装置
US11637704B2 (en) Method and apparatus for determining trust status of TPM, and storage medium
US12010247B2 (en) Implementation of a butterfly key expansion scheme
US20250226974A1 (en) Method and apparatus for distributing encrypted device unique credentials
US20240311129A1 (en) Distribution server
CN112929871A (zh) Ota升级包的获取方法、电子设备以及存储介质
CN113422753A (zh) 数据处理方法、装置、电子设备及计算机存储介质
HK40059898A (zh) 数据处理方法、装置、电子设备及计算机存储介质
CN120528588A (zh) 一种密钥迁移的方法及相关设备
CN121792150A (zh) 基于工业通信的数据加密方法、装置、设备及介质

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: 20967255

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020967255

Country of ref document: EP

Effective date: 20230705

NENP Non-entry into the national phase

Ref country code: DE