An OTA upgrading method and device, a VBOX and a readable storage medium

Abstract

The application relates to the field of new energy vehicles, and provides an OTA upgrading method and device, a VBOX and a readable storage medium. The method comprises the following steps: if it is determined that a current to-be-accessed cloud is a legal cloud, a file download address corresponding to a target upgrading file version is acquired; the file download address and transparent transmission flag information are encapsulated and then are transparently transmitted to a target ECU via a vehicle gateway; a first and a second security tunnel between an upgrading master control end and the legal cloud and the vehicle gateway are respectively established, the vehicle gateway is notified, so that the vehicle gateway establishes a third security tunnel between the vehicle gateway and the target ECU; after the first, second and third security tunnels are successfully established, the target ECU is notified to download a target upgrading file package corresponding to the file download address from the legal cloud through the third, second and first security tunnels. The application can not only improve the OTA upgrading efficiency of an intelligent ECU, but also can guarantee the security of each transmission node in the OTA upgrading process.

Description

Technical Field

[0001] This application relates to the field of new energy vehicles, and in particular to an OTA upgrade method, device, VBOX, and readable storage medium. Background Technology

[0002] As vehicle components become increasingly intelligent, the variety of software and hardware integrated into vehicles is also growing, leading to greater vehicle complexity. This increased complexity inevitably brings maintenance difficulties, and the demand for software and firmware upgrades is growing stronger. Because OTA (Over-The-Air Technology) not only provides a more convenient way to upgrade vehicles but also allows consumers to experience a more intelligent and convenient driving experience, most automakers are now using OTA to upgrade vehicle software and firmware. This allows for rapid repair of system defects, rapid iteration, improvement of products and user experience, and saves time and money for both suppliers and customers.

[0003] While OTA (Over-The-Air) updates bring convenience to upgrading automotive software and firmware, they also harbor some hidden risks. For example, tempted by huge illicit profits, connected vehicles are vulnerable to hacker attacks, threatening the security of data transmission during the OTA upgrade process. Furthermore, current OTA processes, regardless of whether the ECU being updated is intelligent or non-intelligent, require the upgrade file to be transmitted to the vehicle gateway first. The gateway then decrypts the file, locates the target ECU address, and re-encapsulates and forwards the file based on that address. This undoubtedly reduces the efficiency of OTA upgrades for intelligent ECUs.

[0004] Therefore, ensuring data transmission security during OTA upgrades while improving the efficiency of OTA upgrades for intelligent ECUs will be a current research hotspot and focus for improving OTA upgrade services. Summary of the Invention

[0005] In view of this, embodiments of this application provide an OTA upgrade method, apparatus, VBOX, and readable storage medium to solve the problem of how to ensure the security of data transmission during the OTA upgrade process, while improving the OTA upgrade efficiency of intelligent ECUs.

[0006] A first aspect of this application provides an OTA upgrade method, applied to an upgrade master control terminal, including:

[0007] After determining the target ECU and the target upgrade file version, verify the legitimacy of the current cloud connection.

[0008] If the cloud to be connected is a legitimate cloud, then obtain the file download address corresponding to the target upgrade file version from the legitimate cloud.

[0009] If the forwarding flag information corresponding to the target ECU is determined to be the transparent transmission flag information, the file download address and the forwarding flag information are encapsulated to obtain an encapsulated message, and the encapsulated message is transmitted to the target ECU through the vehicle gateway.

[0010] Upon receiving a file download request from the target ECU based on the encapsulated message, a first secure tunnel is established between the upgrade master control terminal and the legitimate cloud, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway, and a secure tunnel establishment command is sent to the vehicle gateway so that the vehicle gateway can establish a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command.

[0011] After the first, second, and third secure tunnels are successfully established, a download permission response is returned to the target ECU, enabling the target ECU to download the target upgrade file package corresponding to the file download address from a legitimate cloud location through the third, second, and first secure tunnels based on the download permission response.

[0012] A second aspect of this application provides an OTA upgrade device, comprising:

[0013] The verification module is configured to verify the legitimacy of the current cloud access after determining the target ECU and the target upgrade file version.

[0014] The acquisition module is configured to obtain the file download address corresponding to the target upgrade file version from a legitimate cloud if the current cloud to be connected is a legitimate cloud.

[0015] The encapsulation module is configured to encapsulate the file download address and the forwarding flag information into an encapsulated message if it is determined that the forwarding flag information corresponding to the target ECU is transparent transmission flag information, and then transmit the encapsulated message to the target ECU through the vehicle gateway.

[0016] The module is configured to establish a first secure tunnel between the upgrade master control terminal and the legitimate cloud when it receives a file download request based on the encapsulated message from the target ECU, establish a second secure tunnel between the upgrade master control terminal and the vehicle gateway, and send a secure tunnel establishment command to the vehicle gateway so that the vehicle gateway can establish a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command.

[0017] The download module is configured to return a download permission response to the target ECU after the first, second, and third secure tunnels are successfully established. This allows the target ECU to download the target upgrade file package corresponding to the file download address from a legitimate cloud location via the third, second, and first secure tunnels based on the download permission response.

[0018] A third aspect of the embodiments of this application provides a VBOX that includes the OTA upgrade device of the second aspect.

[0019] A fourth aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method described above.

[0020] A fifth aspect of this application provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0021] Compared with the prior art, the beneficial effects of this application embodiment include at least the following: First, when the target ECU and the target upgrade file version are determined, and it is verified that the cloud to be accessed is a legitimate cloud, the file download address corresponding to the target upgrade file version is obtained from the legitimate cloud; then, the file download address and the forwarding flag information corresponding to the target ECU are encapsulated into an encapsulated message, and transmitted to the target ECU through the vehicle gateway. The forwarding flag information eliminates the need for the vehicle gateway to decapsulate the encapsulated message after receiving it, find the target ECU address, and then re-encapsulate and forward it based on the target ECU address, which helps to improve the efficiency of data transmission and thus improve the efficiency of subsequent OTA upgrades of intelligent ECUs; Second, when the file download request is received from the target ECU based on the encapsulated message, a first secure tunnel is established between the upgrade master control terminal and the legitimate cloud, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway, and a secure tunnel is sent to the vehicle gateway. The system establishes a secure tunnel, enabling the vehicle gateway to create a third secure tunnel between itself and the target ECU. The target ECU can then directly download the target upgrade file package from a legitimate cloud source via the first, second, and third secure tunnels. This effectively defends against malicious attacks on any transmission node during the download process, significantly improving the security of each transmission node and ensuring data transmission security during OTA upgrades. Simultaneously, the target ECU can directly download the required upgrade file package for upgrade flashing via the first, second, and third secure tunnels, eliminating the need for VBOX downloading and caching, and the vehicle gateway forwarding the upgrade file package. This further improves OTA upgrade efficiency and avoids consuming VBOX's cache space, alleviating resource storage pressure on the VBOX. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic diagram illustrating one application scenario of this application.

[0024] Figure 2 This is a schematic diagram of the UMC / UA / US structure based on a hardware / software layered design provided in an embodiment of this application;

[0025] Figure 3 This is a flowchart illustrating an OTA upgrade method provided in an embodiment of this application;

[0026] Figure 4 This is a schematic diagram of an encapsulated data structure in the OTA upgrade method provided in this application embodiment;

[0027] Figure 5 This is a flowchart illustrating a method for establishing a first secure tunnel in the OTA upgrade method provided in this application embodiment;

[0028] Figure 6 This is a schematic diagram of the structure of an OTA upgrade device provided in an embodiment of this application;

[0029] Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0030] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0031] The following will describe in detail, with reference to the accompanying drawings, an OTA upgrade method, apparatus, and VBOX according to embodiments of this application.

[0032] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application. The application scenario may include a cloud platform 101, a VBOX 102, a vehicle gateway (VGW) 103, and ECU1, ECU2...ECUm, ECUm+1, ECUm+2...ECUn. The cloud platform 101 and VBOX 102 can communicate via a 4G / 5G communication network; VBOX 102 and the vehicle gateway (VGW) 103 can communicate via Ethernet (ETH); the vehicle gateway (VGW) 103 can connect to ECU1, ECU2...ECUm via a CAN bus; and the vehicle gateway (VGW) 103 can connect to ECUm, ECUm+1, ECUm+2...ECUn via Ethernet.

[0033] Cloud 101 typically refers to cloud computing platforms, including cloud-based data processing and analysis platforms, as well as platforms that provide cloud storage services.

[0034] VBOX 102 typically refers to a network device installed in a vehicle for communication with external devices (such as cloud 101). VBOX 102 contains an OTA upgrade controller (UMC), which can also be called an upgrade controller terminal.

[0035] ECUm, ECUm+1, ECUm+2...ECUn support Ethernet (DOIP) communication and are intelligent ECUs. ECU1, ECU2...ECUm support CAN communication and are non-intelligent ECUs. Each ECU carries an OTA upgrade slave controller (referred to as "US").

[0036] The vehicle gateway (VGW) 103 carries an OTA upgrade agent (referred to as "UA").

[0037] like Figure 2 As shown, UMC / UA / US is based on a layered hardware and software design, which enables hardware and software decoupling, facilitating functional expansion and portability. Please refer to [link / reference]. Figure 2 UMC includes OTA master control service, DOIP client (i.e., tunnel client), APN blacklist / whitelist, access authentication (mainly for authentication of the vehicle's internal sub-IP network address), network security protocols (such as TLS protocol), DOIP protocol stack, TCP / IP protocol stack, hardware layer, and physical layer (PHY). UA includes DOIP server (i.e., first tunnel server), network security protocols (such as TLS protocol), DOIP protocol stack, UDS protocol stack, TCP / IP layer, DOCAN, hardware layer, and physical layer (PHY). US includes OTA upgrade flashing service, DOIP server application layer, network security protocols (such as TLS protocol), access authentication (mainly for access authentication of the source port number of the target upgrade file packet), DOIP protocol stack, TCP / IP layer, hardware layer, and physical layer (PHY).

[0038] The DOIP server in the UA has termination, data forwarding, and pass-through functions, making it suitable for various communication application scenarios. When the upgrade message transmitted from VBOX is for the UA's own upgrade, the DOIP server enables the termination function. In this case, the upgrade message is intercepted within the UA and is not forwarded or pass-through to its connected ECUs. When the upgrade file transmitted from VBOX is to be sent to another connected ECU, and that ECU is a non-intelligent device supporting the CAN protocol, the forwarding function is enabled, and the upgrade file is forwarded to the other connected ECU after protocol conversion. When the upgrade file transmitted from VBOX is to be sent to another connected ECU, and that ECU is an intelligent device supporting the Ethernet protocol, the pass-through function is enabled, and the upgrade file is pass-through to the other connected ECU.

[0039] Figure 3 This is a flowchart illustrating an OTA upgrade method provided in an embodiment of this application. Figure 3 OTA upgrade methods can be provided by Figure 1 It is executed using UMC carried in VBOX 102. Figure 3 As shown, the OTA upgrade method may specifically include the following steps:

[0040] Step S301: After determining the target ECU and the target upgrade file version, verify the legitimacy of the current cloud connection.

[0041] In one embodiment, the upgrade master control terminal can periodically or irregularly query the cloud 101 to obtain the latest released upgrade file information (including upgrade file version number, ECU ID, ECU address, etc.), thereby identifying the target ECU. Then, the upgrade file message can be sent to the target ECU via the vehicle gateway 103. If the ECU determines that an upgrade is needed, it sends a confirmation message to the upgrade master control terminal via the vehicle gateway 103. This confirmation message includes the currently used upgrade file version number and the desired upgrade file version number. Upon receiving the confirmation message, the upgrade master control terminal determines the desired upgrade file version number as the target upgrade file version.

[0042] In another embodiment, the upgrade master control terminal can periodically or irregularly obtain the latest released upgrade file information from the cloud 101, determine the target ECU based on the upgrade file information, and determine the latest upgrade file version corresponding to the target ECU as the target upgrade file version.

[0043] After determining the target ECU and the target upgrade file version, the main control unit continues to obtain the pre-set APN blacklist and whitelist. This APN blacklist and whitelist can be provided by a service provider that specializes in managing cloud websites. It also obtains the URL information of the website to be connected to the cloud and checks whether the URL information is in the whitelist of the APN blacklist and whitelist.

[0044] Step S302: If the cloud to be accessed is a legitimate cloud, then obtain the file download address corresponding to the target upgrade file version from the legitimate cloud.

[0045] Following the example above, if the URL of the cloud to be accessed is in the whitelist of the APN blacklist / whitelist, then the cloud to be accessed can be confirmed as legitimate. The upgrade control unit then sends a request to this legitimate cloud to obtain the file download address corresponding to the target upgrade file version. Upon receiving this request, the legitimate cloud sends the corresponding file download address to the upgrade control unit.

[0046] In some cases, if the file download address is published directly, the upgrade master control unit can directly obtain the corresponding file download address from the published information after determining the target ECU and the target upgrade file version.

[0047] Step S303: If it is determined that the forwarding flag information corresponding to the target ECU is transparent flag information, the file download address and the forwarding flag information are encapsulated to obtain an encapsulated message, and the encapsulated message is transparently transmitted to the target ECU through the vehicle gateway.

[0048] Forwarding flag information includes termination flag, forwarding flag, and pass-through flag. For example, the number 0 can be used as the termination flag, 1 as the forwarding flag, and 2 as the pass-through flag.

[0049] After identifying the target ECU, the upgrade master control unit obtains the ECU source address and ECU destination address of the target ECU, and then follows the steps as follows: Figure 4 The encapsulated data structure shown is used to encapsulate data into an encapsulated message. The flashing upgrade data in the encapsulated message is the download address of the file corresponding to the target upgrade file version. Then, the upgrade master control terminal sends the encapsulated message to the vehicle gateway 102. Upon receiving the encapsulated message, the vehicle gateway 102 reads the forwarding flag in the encapsulated message to determine its recipient, eliminating the need for decapsulation and recapsulation, thus improving data / message transmission efficiency and enhancing OTA upgrade efficiency. If the vehicle gateway 102 reads a forwarding flag of "2", it does not perform any processing on the encapsulated message, which can be directly passed to the target ECU. Here, the upgrade master control terminal directly passes the encapsulated message to the target ECU through the vehicle gateway 102 (from the perspective of external users, the VGW is transparent, and it appears as if there is a direct connection between the OTA master control terminal and the target ECU).

[0050] Step S304: Upon receiving a file download request from the target ECU based on the encapsulated message, a first secure tunnel is established between the upgrade master control terminal and the legitimate cloud, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway, and a secure tunnel establishment command is sent to the vehicle gateway so that the vehicle gateway establishes a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command.

[0051] When the target ECU receives the packaged file directly transmitted from the upgrade master control terminal via VGW and confirms that it needs to download the target upgrade file, it can directly transmit a file download request via VGW.

[0052] Step S305: After the first, second, and third secure tunnels are successfully established, a download permission response is returned to the target ECU, so that the target ECU can download the target upgrade file package corresponding to the file download address from the legitimate cloud location through the third, second, and first secure tunnels based on the download permission response.

[0053] The technical solution provided in this application embodiment, on the one hand, firstly, upon determining the target ECU and the target upgrade file version, and verifying that the cloud to be accessed is a legitimate cloud, obtains the file download address corresponding to the target upgrade file version from the legitimate cloud; then, encapsulates the file download address and the forwarding flag information corresponding to the target ECU into an encapsulated message, and transmits it to the target ECU via the vehicle gateway. The aforementioned forwarding flag information eliminates the need for the vehicle gateway to decapsulate the encapsulated message after receiving it, search for the target ECU address, and then re-encapsulate and forward it based on the target ECU address, thus improving data transmission efficiency and consequently increasing the OTA upgrade efficiency of the subsequent intelligent ECU; on the other hand, upon receiving a file download request from the target ECU based on the aforementioned encapsulated message, establishes a first secure tunnel between the upgrade master control terminal and the legitimate cloud, establishes a second secure tunnel between the upgrade master control terminal and the vehicle gateway, and sends a secure tunnel establishment command to the vehicle gateway. This allows the vehicle gateway to establish a third secure tunnel between itself and the target ECU based on the secure tunnel establishment command. Subsequently, the target ECU can directly download the target upgrade file package corresponding to the download address from a legitimate cloud source through the first, second, and third secure tunnels. This effectively defends against malicious attacks by intruders on any transmission node during the download process, significantly improving the security of each transmission node in the download chain and ensuring data transmission security during OTA upgrades. Simultaneously, the target ECU can directly download the required target upgrade file package for upgrade flashing through the first, second, and third secure tunnels, eliminating the need for VBOX downloading and caching, and the vehicle gateway forwarding the target upgrade file package to the target ECU. This further improves OTA upgrade efficiency and avoids occupying the VBOX's cache space used for caching target upgrade file packages, thus alleviating the resource storage pressure on the VBOX.

[0054] In some embodiments, the upgrade master terminal includes a tunnel client, and the legitimate cloud includes a first tunnel server. Establishing a first secure tunnel between the upgrade master terminal and the legitimate cloud includes:

[0055] The control tunnel client sends a first negotiation message to the first tunnel server. The first negotiation message includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a first random number generated by the tunnel client.

[0056] If the first tunnel server detects that the second negotiation information fed back to the tunnel client based on the first negotiation information, it sends a verification command to the tunnel client to enable the tunnel client to verify the first server certificate chain. If the verification is successful, the tunnel client sends the first client certificate chain and a request to obtain the server shared key to the first tunnel server. The second negotiation information includes a first confirmation information confirming the network security protocol version used by both parties, a second confirmation information confirming the data encryption suite used by both parties, the first server certificate chain, a request to obtain the first client certificate chain of the tunnel client, and a second random number generated by the first tunnel server.

[0057] When the server-side shared key returned by the first tunnel server after verifying the certificate chain of the first client is detected, the control tunnel client generates a first session key using a first random number, a second random number, and a data encryption suite. Then, the first session key is encrypted using the server-side shared key to obtain a first encryption key. The first encryption key is then encrypted using the client-side private key to obtain a second encryption key. The second encryption key and the client-side shared key are then sent to the first tunnel server. The client-side private key and the client-side shared key are a pair of asymmetric keys.

[0058] When the tunnel client detects that it has received a ciphertext of the negotiation end message encrypted by the first tunnel server using the first session key, it confirms that the first secure tunnel between the upgrade master control terminal and the legitimate cloud has been successfully established.

[0059] As an example, please refer to Figure 5First, the upgrade master terminal of VBOX 102 sends a control command to the tunnel client (DOIP client). After receiving the control command, the tunnel client sends the first negotiation information to the first tunnel server (DOIP server) in the cloud 101. The first negotiation information includes the network security protocol version supported by the tunnel client (e.g., TLS1.2 or TLS1.3), the data encryption suite supported by the tunnel client (including one or more sets of data encryption algorithms, data compression algorithms, etc.), and the first random number generated by the tunnel client based on the random number generator. After receiving the first negotiation information sent by the tunnel client, the first tunnel server of Cloud 101 sends a second negotiation information back to the tunnel client. This second negotiation information includes: selecting a network security protocol version from the network security protocol versions supported by the tunnel client; selecting a data encryption suite from the data encryption suites supported by the tunnel client; the first server certificate chain registered and authenticated by the first tunnel server (this first server certificate chain includes a root certificate, secondary certificates, and terminal certificates, where the root certificate is the root of trust for Cloud 101 and the starting point of the trust chain; the secondary certificate is a certificate issued by the private key of the root certificate; the terminal certificate is a certificate issued by the secondary certificate based on its private key and is used for registration with Cloud); a request to obtain the tunnel client's first client certificate chain (this first client certificate chain includes a root certificate, secondary certificates, and terminal certificates, where the root certificate is the root of trust for VBOX and the starting point of the trust chain; the secondary certificate is a certificate issued by the private key of the root certificate; the terminal certificate is a certificate issued by the secondary certificate based on its private key and is registered by VBOX and assigned to the tunnel client); and a second random number generated by the first tunnel server based on a random number generator. Next, the upgrade master control terminal sends a verification command to the tunnel client. Upon receiving this command, the tunnel client verifies the first server certificate chain provided by the first tunnel server. During verification, the tunnel client first finds the corresponding secondary certificate based on the terminal certificate of the first tunnel server, and then searches for the root certificate corresponding to that secondary certificate. If the root certificate is confirmed to be trustworthy, the tunnel client confirms that the first server certificate chain of the first tunnel server has passed verification. Then, the tunnel client sends a request to the first tunnel server to retrieve its first client certificate chain and the server's shared key (i.e., the first tunnel server's own public key). If the tunnel client fails to verify the first server certificate chain, the subsequent process terminates. Upon receiving the request from the tunnel client to retrieve the server's shared key, the first tunnel server first verifies the first client certificate chain (the verification method is the same as described above regarding the tunnel client's verification of the first server certificate chain). After successful verification, the first tunnel server returns its server shared key to the tunnel client.When the upgraded master control terminal detects that the first tunnel server has returned the server-side shared key to the tunnel client, it controls the tunnel client to generate a first session key using a first random number, a second random number, and a data encryption suite. The client then encrypts this first session key using the server-side shared key to obtain a first encryption key. Next, the tunnel client encrypts this first encryption key using its own client-side private key to obtain a second encryption key. The tunnel client then sends the second encryption key and its own client-side shared key to the first tunnel server. The generation methods for the first session key, first encryption key, and second encryption key are as follows: The tunnel client performs a hash operation on the first random number, the second random number, and the data encryption suite to obtain the first session key. It then encrypts this first session key using the server-side shared key to obtain the first encryption key. Finally, the tunnel client encrypts this first encryption key using its own client-side private key to obtain the second encryption key. Upon receiving the second encryption key and the client-side shared key, the first tunnel server first decrypts the second encryption key using the client-side shared key to obtain the first encryption key. Then, it decrypts the first encryption key using its own server-side private key to obtain the first session key. The server-side private key and the server-side shared key are an asymmetric key pair. After obtaining the first session key using the aforementioned method, the first tunnel server encrypts the negotiation end message using the first session key, obtaining the ciphertext of the negotiation end message, and returns it to the tunnel client. When the upgrade master control terminal detects that the tunnel client has received the ciphertext of the negotiation end message, it confirms that the first secure tunnel between the upgrade master control terminal and the legitimate cloud has been successfully established.

[0060] By using the above methods, a secure data transmission channel can be established between the upgrade master control terminal and the legitimate cloud. This can effectively prevent third parties from illegally intercepting and maliciously tampering with the data transmitted through the secure data transmission channel between the upgrade master control terminal and the legitimate cloud. This helps to ensure the data transmission security of the transmission link between the vehicle and the cloud during the OTA upgrade process.

[0061] In some embodiments, the vehicle gateway includes a second tunnel server. Establishing a second secure tunnel between the upgrade master control unit and the vehicle gateway includes:

[0062] If the vehicle gateway is verified to be a legitimate gateway, the control tunnel client sends a third negotiation message to the second tunnel server. The third negotiation message includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a third random number generated by the tunnel client.

[0063] When the tunnel client detects that it has received the fourth negotiation information from the second tunnel server, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway based on the third and fourth negotiation information. The fourth negotiation information includes the third confirmation information confirming the network security protocol version used by both parties, the fourth confirmation information confirming the data encryption suite used by both parties, the second server certificate chain, the request to obtain the second client certificate chain of the tunnel client, and the fourth random number generated by the first tunnel server.

[0064] As an example, the upgrade master control terminal first obtains the subnet IP address information of the vehicle gateway, and then queries whether the subnet IP address information is in the preset whitelist of legal access subnet IP addresses. If it is, the vehicle gateway is confirmed as a legal gateway; otherwise, the vehicle gateway is confirmed as an illegal gateway.

[0065] After confirming that the vehicle gateway is a legitimate gateway, the steps for establishing a second secure tunnel between the upgrade master control terminal and the vehicle gateway based on the third and fourth negotiation information can refer to the steps for establishing the first secure tunnel between the upgrade master control terminal and the legitimate cloud, and will not be repeated here.

[0066] By using the above methods, a secure data transmission channel can be established between the upgrade master control terminal and the legitimate gateway. This can effectively prevent third parties from illegally intercepting and maliciously tampering with the data transmitted through the secure data transmission channel between the upgrade master control terminal and the legitimate gateway, and help ensure the data transmission security of the transmission link between the upgrade master control terminal and the legitimate gateway during the OTA upgrade process.

[0067] In some embodiments, establishing a third secure tunnel between itself and the target ECU according to a secure tunnel establishment instruction includes:

[0068] Send legitimate source address information from the cloud to the target ECU;

[0069] Upon receiving confirmation access information regarding the source address from the target ECU, the fifth negotiation information is sent to the target ECU. The fifth negotiation information includes the network security protocol version supported by the vehicle gateway, the data encryption suite supported by the vehicle gateway, and a fifth random number generated by the vehicle gateway.

[0070] Upon receiving the sixth negotiation information from the target ECU based on the fifth negotiation information, a third secure tunnel is established between the vehicle gateway and the target ECU based on the fifth and sixth negotiation information. The sixth negotiation information includes the fifth confirmation information confirming the network security protocol version used by both parties, the sixth confirmation information confirming the data encryption suite used by both parties, the third server certificate chain, the request to obtain the gateway certificate chain of the vehicle gateway, and the sixth random number generated by the target ECU.

[0071] As an example, when the vehicle gateway 102 receives a secure tunnel establishment command from the upgrade master control terminal (the command includes the source address information from the legitimate cloud, the ECU ID of the target ECU, and the ECU address information), it locates the target ECU based on the ECU ID and ECU address information in the command and sends the source address information from the legitimate cloud (the source port number of the legitimate cloud) to the target ECU. After receiving the source address information, the target ECU can confirm whether the source address information is legitimate by checking whether it is included in the preset source address whitelist; if the source address information is confirmed to be legitimate, it sends a confirmation access message back to the legitimate gateway. After receiving the confirmation access message from the target ECU, the steps for establishing the third secure tunnel between the vehicle gateway and the target ECU based on the fifth and sixth negotiation information can refer to the steps for establishing the first secure tunnel between the upgrade master control terminal and the legitimate cloud, and will not be repeated here.

[0072] By using the above methods, a secure data transmission channel can be established between the legitimate gateway and the target ECU. This can effectively prevent third parties from illegally intercepting and maliciously tampering with the data transmitted through the secure data transmission channel between the legitimate gateway and the target ECU, and help ensure the data transmission security of the transmission link between the legitimate gateway and the target ECU during OTA upgrades.

[0073] In some embodiments, downloading the target upgrade file package corresponding to the file download address from a legitimate cloud location via a third secure tunnel, a second secure tunnel, or a first secure tunnel based on a download permission response information includes:

[0074] Obtain the first session key of the first secure tunnel, the second session key of the second secure tunnel, and the third session key of the third secure tunnel;

[0075] Determine the validity of the first session key, the second session key, and the third session key;

[0076] If the first session key, the second session key, and the third session key are all valid keys to be activated, then the upgrade file interface corresponding to the file download address in the legitimate cloud will be accessed sequentially through the third secure tunnel, the second secure tunnel, and the first secure tunnel to download the target upgrade file package from the upgrade file interface.

[0077] As an example, after successfully establishing a third secure tunnel between the vehicle gateway and the target ECU, it sends the third session key to the upgrade master control unit. The upgrade master control unit then creates a logical relationship table for the session key association, corresponding to the ECU ID of the target ECU and its upgrade file version. In one example, the logical relationship table for the session key association is shown in Table 1.

[0078] Table 1. Logical Relationships Between Session Keys

[0079]

[0080] When the upgrade master control receives a file download request from the target ECU, it first reads the ECUID of the target ECU and uses the ECU ID to query Table 1 above to determine whether there is a logical relationship of session key association with the ECUID. If there is, it can be determined that the first security tunnel, the second security tunnel and the third security tunnel have been successfully established, and then the download permission response information is returned to the target ECU in sequence through the second security tunnel and the third security tunnel. The download permission response information includes the first, second and third session keys corresponding to the ECU ID of the target ECU.

[0081] It should be noted that the session key association logic is different for different ECU IDs, and the session key association logic is also different for the same ECU ID for different upgrade file versions.

[0082] After receiving the download permission response, the target ECU extracts the first, second, and third session keys, and further extracts the number of times each key has been used and its expiration date. If the number of uses is 0, and the current system time is within the valid usage period (i.e., the current system time is less than the expiration date), then the session key is a valid key to be activated. Subsequently, the target ECU accesses the upgrade file interface corresponding to the file download address in the legitimate cloud environment through the third, second, and first security tunnels in sequence, directly downloading the required target upgrade file package for upgrade flashing.

[0083] In some embodiments, when accessing the upgrade file interface corresponding to the file download address in the legitimate cloud, the first session key, the second session key, and the third session key are all modified to secondary activation keys, and the key activation usage duration of the first session key, the second session key, and the third session key is calculated; if the key activation usage duration of the first session key, the second session key, and the third session key all reach the first set duration, then the first session key, the second session key, and the third session key are all modified to invalid keys.

[0084] When the target ECU successfully accesses the upgrade file interface corresponding to the download address in the legitimate cloud and begins downloading the target upgrade file package, the first, second, and third session keys are all modified to secondary activation keys. Specifically, the "number of times used" for each session key is changed to 1. Simultaneously, the activation duration for each session key is calculated from the time it is activated. Afterward, it is calculated whether the activation durations of the first, second, and third session keys have all reached a pre-set duration (which can be flexibly set according to actual conditions, for example, 5 minutes, 10 minutes, etc.).

[0085] In one example, the time when the target ECU successfully accesses the upgrade file interface corresponding to the file download address in the legitimate cloud can be uniformly recorded as the time when the first, second, and third session keys are activated and used. Then, by calculating whether the activation and usage duration of the first session key has reached the first preset duration, it is possible to simultaneously determine whether the activation and usage duration of the second and third session keys have also reached the first preset duration. This reduces the amount of computation and improves computational efficiency.

[0086] Once the first, second, and third session keys are activated, their originally set expiration dates will be automatically modified to the date after activation plus the first set duration. Taking the first session key as an example, after activation, its expiration date will be automatically modified to the date of activation plus the first set duration. For instance, assuming the original expiration date for the first session key was 2:02:30 PM on January 10, 2023, and the first set duration was 10 minutes, and the activation date was 2:03:10 PM on January 3, 2023, then the expiration date will be automatically modified to 2:13:10 PM on January 3, 2023.

[0087] By using the above method, after the first, second, and third session keys are activated and used, the original expiration time of the first, second, and third session keys is automatically modified. This can prevent unauthorized third parties from obtaining the session keys through illegal means and disrupting or damaging the OTA upgrade flashing of the target ECU by limiting the effective use period of the session keys, thereby ensuring the security of OTA upgrades.

[0088] In other embodiments, when accessing the upgrade file interface corresponding to the file download address in the legitimate cloud, the first session key, the second session key, and the third session key are all modified to secondary activation keys, and the key activation usage duration of the first session key, the second session key, and the third session key are calculated respectively; the file download progress of the target upgrade file package is determined; if the file download progress is incomplete and the key activation usage duration has reached the first set duration, the minimum time required to complete the download of the target upgrade file package is estimated; based on the minimum required time, the first set duration is extended to the second set duration, and the key activation usage duration continues to accumulate; if the continued accumulation of the key activation usage duration reaches the second set duration, the first session key, the second session key, and the third session key are all modified to invalid keys.

[0089] As an example, assuming the original expiration time for the first session key was 2:02:30 PM on January 10, 2023, and the first set duration was 10 minutes, and the activation time for the first session key was 2:03:10 PM on January 3, 2023, then the expiration time will be automatically changed to 2:13:10 PM on January 3, 2023 after the first session key is activated. During the download of the target upgrade package from a legitimate cloud source, the target ECU will monitor the download progress in real time. If the activation duration of the first, second, and third session keys has reached the first set duration, i.e., 2:13:10 PM on January 3, 2023, and the download progress of the target upgrade package has not yet reached 100% (i.e., incomplete), the shortest time required to complete the download of the target upgrade package can be estimated based on the current ECU load, network speed, etc. If the estimated minimum required time is 15 minutes, then the first set time will be extended to the second set time (i.e., 25 minutes), and the new deadline will be automatically changed from 14:13:10 on January 3, 2023 to 14:28:10 on January 3, 2023. If the accumulated key activation time reaches the second set time, then the "number of times used" for the first, second, and third session keys will be changed to >1, at which point the first, second, and third session keys will all be invalid keys.

[0090] By appropriately extending the first set time to the second set time using the above method, it can be ensured that the target ECU can download the complete target upgrade file package within the valid usage period of the session key, thereby improving the efficiency of OTA upgrade and effectively ensuring the data transmission security during the OTA upgrade process.

[0091] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0092] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0093] Figure 6 This is a schematic diagram of an OTA upgrade device provided in an embodiment of this application. Figure 6 As shown, the OTA upgrade device includes:

[0094] Verification module 601 is configured to verify the legitimacy of the current cloud access after determining the target ECU and the target upgrade file version;

[0095] The acquisition module 602 is configured to obtain the file download address corresponding to the target upgrade file version from the legitimate cloud if the current cloud to be accessed is a legitimate cloud.

[0096] The encapsulation module 603 is configured to encapsulate the file download address and the forwarding flag information into an encapsulated message if it is determined that the forwarding flag information corresponding to the target ECU is transparent transmission flag information, and then transmit the encapsulated message to the target ECU through the vehicle gateway.

[0097] The module 604 is configured to establish a first secure tunnel between the upgrade master control terminal and the legitimate cloud when it receives a file download request based on the encapsulated message from the target ECU, establish a second secure tunnel between the upgrade master control terminal and the vehicle gateway, and send a secure tunnel establishment command to the vehicle gateway so that the vehicle gateway establishes a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command.

[0098] Download module 605 is configured to return a download permission response to the target ECU after the first, second, and third secure tunnels are successfully established, so that the target ECU can download the target upgrade file package corresponding to the file download address from the legitimate cloud through the third, second, and first secure tunnels based on the download permission response.

[0099] In some embodiments, the upgrade master control terminal includes a tunnel client, and the legitimate cloud includes a first tunnel server. The aforementioned establishment module 604 includes a first establishment unit, configured to establish a first secure tunnel between the upgrade master control terminal and the legitimate cloud.

[0100] The first establishment unit includes:

[0101] The first control component is configured to control the tunnel client to send first negotiation information to the first tunnel server. The first negotiation information includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a first random number generated by the tunnel client.

[0102] The distribution component is configured to, upon detecting that the first tunnel server has fed back second negotiation information to the tunnel client based on the first negotiation information, issue a verification command to the tunnel client, enabling the tunnel client to verify the first server's certificate chain. If the verification passes, the tunnel client sends the first client's certificate chain and a request to obtain the server's shared key and a second random number to the first tunnel server. The second negotiation information includes first confirmation information confirming the network security protocol version used by both parties, second confirmation information confirming the data encryption suite used by both parties, the first server's certificate chain, a request to obtain the tunnel client's first client's certificate chain, and a second random number generated by the first tunnel server.

[0103] The second control component is configured to, upon detecting that the first tunnel server returns a server-side shared key and a second random number after verifying the first client's certificate chain, control the tunnel client to generate a first session key using the first random number, the second random number, and a data encryption suite; then encrypt the first session key using the server-side shared key to obtain a first encryption key; then encrypt the first encryption key using the client's private key to obtain a second encryption key; and finally send the second encryption key and the client-side shared key to the first tunnel server, wherein the client-side private key and the client-side shared key are a pair of asymmetric keys.

[0104] The acknowledgment component is configured to confirm the successful establishment of the first secure tunnel between the upgrade master and the legitimate cloud when it detects that the tunnel client has received a ciphertext of the negotiation end message encrypted by the first tunnel server using the first session key.

[0105] In some embodiments, the vehicle gateway includes a second tunnel server. The establishment module 604 includes a second establishment unit configured to establish a second secure tunnel between the upgrade master control terminal and the vehicle gateway.

[0106] The second establishment unit includes:

[0107] The verification component is configured to, if verified and confirmed that the vehicle gateway is a legitimate gateway, control the tunnel client to send third negotiation information to the second tunnel server. The third negotiation information includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a third random number generated by the tunnel client.

[0108] The component is configured to establish a second secure tunnel between the upgrade master control terminal and the vehicle gateway based on the third and fourth negotiation information when the tunnel client receives the fourth negotiation information fed back by the second tunnel server. The fourth negotiation information includes a third confirmation information confirming the network security protocol version used by both parties, a fourth confirmation information confirming the data encryption suite used by both parties, a second server certificate chain, a request to obtain the second client certificate chain of the tunnel client, and a fourth random number generated by the first tunnel server.

[0109] In some embodiments, the vehicle gateway includes a second tunnel client configured to establish a third secure tunnel between itself and a target ECU according to a secure tunnel establishment instruction.

[0110] The second tunnel client includes:

[0111] The first sending module is configured to send legitimate source address information from the cloud to the target ECU;

[0112] The second sending module is configured to send a fifth negotiation message to the target ECU when it receives the confirmation access information for the source address information from the target ECU. The fifth negotiation message includes the network security protocol version supported by the vehicle gateway, the data encryption suite supported by the vehicle gateway, and a fifth random number generated by the vehicle gateway.

[0113] The tunnel establishment module is configured to establish a third secure tunnel between the vehicle gateway and the target ECU based on the fifth negotiation information and the sixth negotiation information when it receives the sixth negotiation information fed back by the target ECU based on the fifth negotiation information. The sixth negotiation information includes the fifth confirmation information confirming the network security protocol version used by both parties, the sixth confirmation information confirming the data encryption suite used by both parties, the third server certificate chain, the request to obtain the gateway certificate chain of the vehicle gateway, and the sixth random number generated by the target ECU.

[0114] In some embodiments, the target ECU is configured to download a target upgrade file package corresponding to a file download address from a legitimate cloud location via a third secure tunnel, a second secure tunnel, and a first secure tunnel based on a download permission response information.

[0115] The target ECU includes:

[0116] The key acquisition module is configured to acquire the first session key of the first secure tunnel, the second session key of the second secure tunnel, and the third session key of the third secure tunnel;

[0117] The judgment module is configured to judge the validity of the first session key, the second session key, and the third session key;

[0118] The file download module is configured to access the upgrade file interface corresponding to the file download address in the legitimate cloud through the third secure tunnel, the second secure tunnel, and the first secure tunnel in sequence if the first session key, the second session key, and the third session key are all valid keys to be activated, so as to download the target upgrade file package from the upgrade file interface.

[0119] In some embodiments, the target ECU further includes:

[0120] The first modification module is configured to modify the first session key, the second session key, and the third session key to the secondary activation key when accessing the upgrade file interface corresponding to the file download address in the legitimate cloud, and to start calculating the key activation usage duration of the first session key, the second session key, and the third session key respectively;

[0121] The second modification module is configured to modify the first session key, the second session key, and the third session key to invalid keys if the key activation and usage time reaches the first set time.

[0122] In some embodiments, the second modification module includes:

[0123] The progress determination unit is configured to determine the download progress of the target upgrade file package.

[0124] The estimation unit is configured to estimate the minimum time required to complete the download of the target upgrade file package if the file download progress is incomplete and the key activation usage time has reached a first set time.

[0125] The extension unit is configured to extend the first preset duration to the second preset duration based on the shortest required duration, and continue to accumulate the key activation usage duration;

[0126] The key modification unit is configured to modify the first session key, the second session key, and the third session key to invalid keys if the accumulated key activation time reaches a second set time.

[0127] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0128] This application also provides a VBOX, which includes as follows: Figure 6 The OTA upgrade device shown is housed within a UMC.

[0129] Figure 7 This is a schematic diagram of the electronic device 7 provided in an embodiment of this application. Figure 7As shown, the electronic device 7 of this embodiment includes a processor 701, a memory 702, and a computer program 703 stored in the memory 702 and executable on the processor 701. When the processor 701 executes the computer program 703, it implements the steps in the various method embodiments described above. Alternatively, when the processor 701 executes the computer program 703, it implements the functions of each module / unit in the various device embodiments described above.

[0130] Electronic device 7 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 7 may include, but is not limited to, processor 701 and memory 702. Those skilled in the art will understand that... Figure 7 This is merely an example of electronic device 7 and does not constitute a limitation on electronic device 7. It may include more or fewer components than shown, or different components.

[0131] The processor 701 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0132] The memory 702 can be an internal storage unit of the electronic device 7, such as a hard disk or RAM of the electronic device 7. The memory 702 can also be an external storage device of the electronic device 7, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc., equipped on the electronic device 7. The memory 702 can also include both internal and external storage units of the electronic device 7. The memory 702 is used to store computer programs and other programs and data required by the electronic device.

[0133] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0134] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a readable storage medium (e.g., a computer-readable storage medium). Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable storage medium may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0135] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An OTA upgrade method, characterized in that, Applications include upgrading the main control unit, including: After determining the target ECU and the target upgrade file version, verify the legitimacy of the current cloud connection. If the cloud to be accessed is a legitimate cloud, then obtain the file download address corresponding to the target upgrade file version from the legitimate cloud. If the forwarding flag information corresponding to the target ECU is determined to be transparent flag information, the file download address and the forwarding flag information are encapsulated to obtain an encapsulated message, and the encapsulated message is transparently transmitted to the target ECU via the vehicle gateway. Upon receiving a file download request from the target ECU based on the encapsulated message, a first secure tunnel is established between the upgrade master control terminal and the legitimate cloud, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway, and a secure tunnel establishment command is sent to the vehicle gateway so that the vehicle gateway establishes a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command. After the first, second, and third secure tunnels are successfully established, a download permission response is returned to the target ECU, so that the target ECU can download the target upgrade file package corresponding to the file download address from the legitimate cloud location through the third, second, and first secure tunnels based on the download permission response.

2. The method according to claim 1, characterized in that, The upgraded master control terminal includes a tunnel client, and the legitimate cloud includes a first tunnel server; Establishing a first secure tunnel between the upgraded main control terminal and the legitimate cloud, including: The tunnel client is controlled to send a first negotiation message to the first tunnel server. The first negotiation message includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a first random number generated by the tunnel client. If the first tunnel server detects that the tunnel client receives second negotiation information based on the first negotiation information, and sends a verification command to the tunnel client to verify the first server certificate chain, and if the verification passes, the tunnel client sends the first client certificate chain and a request to obtain the server shared key and a second random number to the first tunnel server. The second negotiation information includes first confirmation information confirming the network security protocol version used by both parties, second confirmation information confirming the data encryption suite used by both parties, the first server certificate chain, the request to obtain the first client certificate chain of the tunnel client, and a second random number generated by the first tunnel server. When the first tunnel server detects the server-side shared key and the second random number returned after verifying the first client certificate chain, it controls the tunnel client to generate a first session key using the first random number, the second random number, and the data encryption suite. Then, it encrypts the first session key using the server-side shared key to obtain a first encryption key. Finally, it encrypts the first encryption key using the client's private key to obtain a second encryption key. The second encryption key and the client's shared key are then sent to the first tunnel server. The client's private key and the client's shared key are a pair of asymmetric keys. When the tunnel client detects that it has received a negotiation end message encrypted by the first tunnel server using the first session key, it confirms that the first secure tunnel between the upgrade master control terminal and the legitimate cloud has been successfully established.

3. The method according to claim 2, characterized in that, The vehicle gateway includes a second tunnel server; Establishing a second secure tunnel between the upgrade master control terminal and the vehicle gateway includes: If the vehicle gateway is verified to be a legitimate gateway, the tunnel client is controlled to send a third negotiation message to the second tunnel server. The third negotiation message includes the network security protocol version supported by the tunnel client, the data encryption suite supported by the tunnel client, and a third random number generated by the tunnel client. When the tunnel client detects that it has received the fourth negotiation information from the second tunnel server, a second secure tunnel is established between the upgrade master control terminal and the vehicle gateway based on the third and fourth negotiation information. The fourth negotiation information includes a third confirmation information confirming the network security protocol version used by both parties, a fourth confirmation information confirming the data encryption suite used by both parties, a second server certificate chain, a request to obtain the second client certificate chain of the tunnel client, and a fourth random number generated by the first tunnel server.

4. The method according to claim 1 or 3, characterized in that, A third secure tunnel is established between the ECU and the target ECU according to the secure tunnel establishment command, including: Send the legitimate cloud source address information to the target ECU; Upon receiving confirmation access information regarding the source address information from the target ECU, a fifth negotiation message is sent to the target ECU. The fifth negotiation message includes the network security protocol version supported by the vehicle gateway, the data encryption suite supported by the vehicle gateway, and a fifth random number generated by the vehicle gateway. Upon receiving the sixth negotiation information fed back by the target ECU based on the fifth negotiation information, a third secure tunnel is established between the vehicle gateway and the target ECU based on the fifth and sixth negotiation information. The sixth negotiation information includes a fifth confirmation information confirming the network security protocol version used by both parties, a sixth confirmation information confirming the data encryption suite used by both parties, a third server certificate chain, a request to obtain the gateway certificate chain of the vehicle gateway, and a sixth random number generated by the target ECU.

5. The method according to claim 1, characterized in that, Based on the download permission response information, the target upgrade file package corresponding to the file download address is downloaded from the legitimate cloud location through the third security tunnel, the second security tunnel, and the first security tunnel, including: Obtain the first session key of the first secure tunnel, the second session key of the second secure tunnel, and the third session key of the third secure tunnel; Determine the validity of the first session key, the second session key, and the third session key; If the first session key, the second session key, and the third session key are all valid keys to be activated, then the upgrade file interface corresponding to the file download address in the legitimate cloud is accessed sequentially through the third secure tunnel, the second secure tunnel, and the first secure tunnel to download the target upgrade file package from the upgrade file interface.

6. The method according to claim 5, characterized in that, The method further includes: When accessing the upgrade file interface corresponding to the file download address in the legitimate cloud, the first session key, the second session key, and the third session key are all modified to secondary activation keys, and the key activation usage duration of the first session key, the second session key, and the third session key is calculated respectively. If the activation and usage time of the key reaches the first set time, then the first session key, the second session key, and the third session key will all be modified to invalid keys.

7. The method according to claim 6, characterized in that, If the key activation duration reaches a first preset duration, then the first session key, the second session key, and the third session key will all be modified to expired keys, including: Determine the download progress of the target upgrade package; If the file download progress is incomplete and the key activation usage time has reached the first set time, then estimate the shortest time required to complete the download of the target upgrade file package; Based on the minimum required duration, the first set duration is extended to the second set duration, and the key activation usage duration continues to accumulate; If the accumulated key activation time reaches the second set time, the first session key, the second session key, and the third session key will all be changed to invalid keys.

8. An OTA upgrade device, characterized in that, include: The verification module is configured to verify the legitimacy of the current cloud access after determining the target ECU and the target upgrade file version. The acquisition module is configured to, if the cloud to be accessed is a legitimate cloud, obtain the file download address corresponding to the target upgrade file version from the legitimate cloud; The encapsulation module is configured to encapsulate the file download address and the forwarding flag information into an encapsulated message if it is determined that the forwarding flag information corresponding to the target ECU is transparent transmission flag information, and then transmit the encapsulated message to the target ECU through the vehicle gateway. The module is configured to, upon receiving a file download request from the target ECU based on the encapsulated message, establish a first secure tunnel between the upgrade master control terminal and the legitimate cloud, establish a second secure tunnel between the upgrade master control terminal and the vehicle gateway, and send a secure tunnel establishment command to the vehicle gateway so that the vehicle gateway establishes a third secure tunnel between itself and the target ECU according to the secure tunnel establishment command. The download module is configured to return a download permission response to the target ECU after the first, second, and third secure tunnels have been successfully established, so that the target ECU can download the target upgrade file package corresponding to the file download address from the legitimate cloud location through the third, second, and first secure tunnels based on the download permission response.

9. A VBOX, characterized in that, The VBOX includes the OTA upgrade device as described in claim 8; The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor, when executing the computer program, implements the steps of the method as described in any one of claims 1 to 7.

10. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images