OTA security upgrade flashing method and device and VBOX

Abstract

The application relates to the technical field of intelligent automobiles, and provides an OTA safe upgrade flashing method and device and a VBOX. The method comprises the following steps: assembling an upgrade message, wherein the upgrade message comprises a message header and original upgrade data; determining a data transmission channel, starting a timer to record a first cumulative time, and monitoring a current system load state of the data transmission channel in real time; extracting and verifying header information in the message header; if it is determined that the header information passes the verification, and it is determined that an encryption algorithm needs to be replaced according to the first cumulative time and the current system load state, then the first encryption algorithm is replaced by a second encryption algorithm; the original upgrade data is encrypted by using the second encryption algorithm to obtain ciphertext upgrade data, and ciphertext of the upgrade message is assembled; and the ciphertext of the upgrade message is transmitted to a transit gateway or a target ECU. The application can reduce the risk that the upgrade flashing data is attacked, tampered with or cracked by a third party, and effectively improve the safety of OTA upgrade flashing.

Description

Technical Field

[0001] This application relates to the field of intelligent vehicle technology, and in particular to an OTA security upgrade flashing method, device and VBOX. Background Technology

[0002] Over-the-Air (OTA) technology in automobiles refers to upgrading vehicle firmware and software using over-the-air (OTA) technology. OTA not only provides a more convenient way to upgrade vehicles but also allows consumers to experience a more intelligent and convenient car ownership experience.

[0003] Currently, smart cars are becoming increasingly feature-rich, and the interaction between the vehicle and the outside world is becoming more and more frequent. At the same time, the risks of attack and data tampering during the data interaction process are also increasing.

[0004] Current automotive OTA upgrades primarily use a single security verification method, the UDS 0x27 service, for upgrade flashing. The data flashed during upgrades is easily cracked, tampered with, or attacked by third parties, resulting in poor security. Summary of the Invention

[0005] In view of this, the present application provides an OTA secure upgrade flashing method, device and VBOX to solve the problem that the data flashed during the existing automotive OTA upgrade flashing process is easily cracked, tampered with or attacked by third parties, resulting in poor security.

[0006] A first aspect of this application provides an OTA security upgrade flashing method, including:

[0007] Assemble the upgrade message, which includes a message header and the original upgrade data;

[0008] Identify the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time;

[0009] Extract the header information from the message header and verify the header information;

[0010] If the header information is verified and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is changed to the second encryption algorithm.

[0011] The original upgrade data is encrypted using the second encryption algorithm to obtain ciphertext upgrade data, and the ciphertext upgrade data and message header are assembled into ciphertext upgrade message;

[0012] The upgrade message is transmitted in ciphertext to the relay gateway, which then decrypts it to obtain plaintext upgrade data and writes it to the target ECU, enabling the target ECU to perform an upgrade flash using the plaintext upgrade data; alternatively, the upgrade message is transmitted in ciphertext to the target ECU, which then decrypts it to obtain plaintext upgrade data and performs an upgrade flash using the plaintext upgrade data.

[0013] A second aspect of this application provides another OTA security upgrade flashing method, including:

[0014] Assemble the upgrade message, which includes a message header and the original upgrade data;

[0015] The original upgrade data is encrypted using the first encryption algorithm to obtain the first ciphertext data;

[0016] Identify the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time;

[0017] Extract the header information from the message header and verify the header information;

[0018] If the header information is verified and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is changed to the second encryption algorithm.

[0019] The first ciphertext data is encrypted using the second encryption algorithm to obtain the second ciphertext data, and the second ciphertext data and the message header are assembled into the ciphertext of the transmission message.

[0020] The encrypted transmission message is transmitted to the relay gateway, which decrypts the encrypted transmission message to obtain plaintext upgrade data and writes the plaintext upgrade data to the target ECU, so that the target ECU can use the plaintext upgrade data to perform the upgrade flashing; or, the encrypted transmission message is transmitted to the target ECU, which decrypts the encrypted transmission message to obtain plaintext upgrade data and uses the plaintext upgrade data to perform the upgrade flashing.

[0021] A third aspect of this application provides an OTA security upgrade flashing device, comprising:

[0022] The assembly module is configured to assemble upgrade messages, which include a message header and raw upgrade data.

[0023] The module is configured to determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time.

[0024] The extraction module is configured to extract header information from the message header and verify the header information;

[0025] The replacement module is configured to, if it is determined that the header information passes verification and the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0026] The encryption module is configured to encrypt the original upgrade data using a second encryption algorithm to obtain ciphertext upgrade data, and to assemble the ciphertext upgrade data and the message header into ciphertext upgrade message;

[0027] The transmission module is configured to transmit the ciphertext of the upgrade message to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, to transmit the ciphertext of the upgrade message to the target ECU, so that the target ECU can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0028] A fourth aspect of this application provides another OTA security upgrade flashing device, including:

[0029] The assembly module is configured to assemble upgrade messages, which include a message header and raw upgrade data.

[0030] A first encryption module is configured to encrypt the original upgrade data using a first encryption algorithm to obtain the first ciphertext data;

[0031] The module is configured to determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time.

[0032] The extraction module is configured to extract header information from the message header and verify the header information;

[0033] The replacement module is configured to, if it is determined that the header information passes verification and the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0034] The secondary encryption module is configured to encrypt the first ciphertext data using a second encryption algorithm to obtain the second ciphertext data, and then assemble the second ciphertext data and the message header into a transmission message ciphertext.

[0035] The data transmission module is configured to transmit the encrypted transmission message to the relay gateway, so that the relay gateway can decrypt the encrypted transmission message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, to transmit the encrypted transmission message to the target ECU, so that the target ECU can decrypt the encrypted transmission message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0036] A fifth aspect of the embodiments of this application provides a VBOX, including an OTA upgrade main controller;

[0037] The OTA upgrade controller includes the OTA security upgrade flashing device mentioned in the third or fourth aspect above.

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

[0039] Compared with the prior art, the beneficial effects of the embodiments of this application include at least the following: The technical solution provided in this application, during the OTA upgrade flashing process, involves assembling an upgrade message, which includes a message header and original upgrade data; determining the data transmission channel and starting a timer to record a first cumulative time, while monitoring the current system load status of the data transmission channel in real time; extracting header information from the message header and verifying the header information; if the header information passes verification, and based on the first cumulative time and the current system load status, determining that the encryption algorithm needs to be changed, then obtaining the first encryption algorithm and replacing it with a second encryption algorithm; and using the second encryption algorithm to encrypt the original upgrade data to obtain ciphertext upgrade data. The encrypted upgrade data and message header are assembled into an encrypted upgrade message. This encrypted upgrade message is then transmitted to a relay gateway, which decrypts it to obtain plaintext upgrade data. The plaintext upgrade data is then written to the target ECU, enabling the target ECU to perform an upgrade flashing using the plaintext upgrade data. Alternatively, the encrypted upgrade message can be transmitted to the target ECU, which decrypts it to obtain plaintext upgrade data and performs an upgrade flashing using the plaintext upgrade data. This allows for periodic or irregular changes to the encryption algorithm used to encrypt the original upgrade data, significantly reducing the risk of third-party attacks, tampering, or cracking of the upgrade flashing data during OTA upgrade flashing and substantially improving the security of upgrade flashing. Attached Figure Description

[0040] 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.

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

[0042] Figure 2 This is a flowchart illustrating an OTA security upgrade flashing method provided in an embodiment of this application;

[0043] Figure 3 This is a schematic diagram illustrating the overall process of a UMC transmitting ciphertext of an upgrade message and a transmission message to a target ECU / transfer gateway, as provided in an embodiment of this application.

[0044] Figure 4 This is a schematic diagram of a process provided in this application embodiment for a UA to decrypt the ciphertext of an upgrade message based on a transmission message;

[0045] Figure 5 This is a flowchart illustrating another OTA security upgrade flashing method provided in an embodiment of this application;

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

[0047] Figure 7 This is a schematic diagram of another OTA security upgrade flashing device provided in an embodiment of this application;

[0048] Figure 8 This is a schematic diagram of the structure of a VBOX provided in an embodiment of this application;

[0049] Figure 9 This is a schematic diagram of another VBOX structure provided in an embodiment of this application;

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

[0051] 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.

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

[0053] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this application. The application scenario may include VBOX101, VGW102, and ECU103.

[0054] VBOX (Vehicle BOX) can be the vehicle's TBOX (Telematics Control Unit). VBOX 101 contains the OTA upgrade master controller (abbreviated as "UMC").

[0055] VGW (Vehicle Gateway) is a gateway. VGW 102 carries an OTA upgrade agent (UA).

[0056] ECU (Electronic Control Unit), also known as "vehicle computer" or "on-board computer," etc. ECU 103 carries the OTA upgrade slave controller (abbreviated as "US").

[0057] The UMC and UA are connected via Ethernet (ETH), and the UA and US are connected via CAN / CANFD / ETH bus. The UMC and US are connected via CAN / CANFD / ETH bus. The UMC and the cloud server can be connected via wired network (such as a wired network using coaxial cable, twisted pair, or fiber optic connection) or wireless network (such as Bluetooth).

[0058] In this embodiment of the application, during the OTA upgrade flashing process, VBOX 101 can first download the original upgrade data from the cloud server and assemble it with the message header to form an upgrade message. Then, it determines the data transmission channel and starts a timer to record the first cumulative time, monitoring the current system load status of the data transmission channel in real time. Next, it extracts the header information from the message header and verifies it. If the header information passes verification, and based on the first cumulative time and the current system load status, it determines that the encryption algorithm needs to be changed, so it obtains the first encryption algorithm and replaces it with the second encryption algorithm. Then, it uses the second encryption algorithm to encrypt the original upgrade data to obtain ciphertext upgrade data, and assembles the ciphertext upgrade data and message header to form an upgrade message ciphertext. Finally, it transmits the upgrade message ciphertext to the relay gateway so that the relay gateway can decrypt the upgrade message ciphertext to obtain plaintext upgrade data, and writes the plaintext upgrade data to the target ECU so that the target ECU can use the plaintext upgrade data for upgrade flashing; or, it transmits the upgrade message ciphertext to the target ECU so that the target ECU can decrypt the upgrade message ciphertext to obtain plaintext upgrade data, and uses the plaintext upgrade data for upgrade flashing. The above method allows for the timely or unscheduled replacement of the encryption algorithm used for encrypted transmission, greatly reducing the risk of third-party attacks, tampering, or cracking of upgrade data during OTA upgrade flashing, and significantly improving the security of upgrade flashing.

[0059] It should be noted that the specific types and quantities of VBOX 101, VGW 102, ECU 103, and cloud server 104 can be set according to the actual situation, and are not specifically limited here. For example, the number of VGW 102 can be one or more, such as VGW1, VGW2...VGWn, and the number of ECU 103 can also be one or more, such as ECU1, ECU2...ECUz.

[0060] Figure 2 This is a flowchart illustrating an OTA security upgrade flashing method provided in an embodiment of this application. Figure 2 The OTA security upgrade flashing method can be provided by Figure 1 Execution of UMC in VBOX 101. (e.g.) Figure 2 As shown, the OTA security upgrade flashing method includes:

[0061] Step S201: Assemble the upgrade message, which includes a message header and the original upgrade data.

[0062] Raw upgrade data refers to the software data used to upgrade and rewrite the current software version of ECU 103. Raw upgrade data is unencrypted plaintext data.

[0063] The message header can be either the CAN bus protocol header or the ETH (Ethernet) bus protocol header.

[0064] In one implementation, the UMC can download the original upgrade data from the cloud server and temporarily store it locally. When an OTA upgrade is required, the UMC reads the original upgrade data from the VBOX 101 locally and assembles the original upgrade data and the message header into an upgrade message.

[0065] Step S202: Determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time.

[0066] The data transmission channel can be a CAN channel or an Ethernet (ETH) channel.

[0067] In one implementation, the data transmission channel can be determined based on the header of the upgrade message. For example, if the header is a CAN bus protocol header, the CAN channel is used as the data transmission channel. If the header is an ETH (Ethernet) bus protocol header, the Ethernet (ETH) channel is used as the data transmission channel.

[0068] The current system load status refers to the data transmission load rate of the data transmission channel currently in use.

[0069] In one implementation, if the data transmission channel is a CAN channel, the bus load rate from the UMC to the target ECU being flashed can be monitored in real time using canbusload. canbusload is one of the programs in the Linux CAN utility canutils. It can easily calculate and refresh the current load rate information on the CAN bus and provides the three software algorithms mentioned above for statistical analysis (i.e., ignoring padding bits, calculating maximum padding bits, and calculating precise padding bits).

[0070] Step S203: Extract the header information from the message header and verify the header information.

[0071] When the message header is a CAN bus protocol message header, the header information mainly includes the CAD ID, the message transmission frequency of the CAD ID, and other information.

[0072] When the message header is an ETH bus protocol header, the header information mainly includes the source and destination "five-tuple" and ACL configuration information such as VLANs. An Access Control List (ACL) consists of a series of rules (i.e., judgment statements describing the matching conditions of a message). A Virtual Local Area Network (VLAN) is a logical group of devices and users that are not restricted by physical location and can be organized according to factors such as function or department, allowing them to communicate as if they were in the same network segment. The "five-tuple" includes the message's source address, destination address, source port, destination port, and port number.

[0073] As an example, when the message header is a CAN bus protocol header, its header information is verified, mainly checking whether the CAD ID is in the whitelist and whether the transmission frequency of the message for that CAD ID is normal. Generally, a current transmission frequency of the message for that CAD ID within ±10% of the set transmission frequency for that CAD ID is considered normal; otherwise, it is considered abnormal. For example, if the transmission frequency of the message for CAD ID1 is set to 100MHz, a current transmission frequency between 90MHz and 110MHz is considered normal; if the current transmission frequency is less than 90MHz or greater than 110MHz, it is considered abnormal.

[0074] As another example, when the message header is an ETH bus protocol message header, its header information is verified, mainly to check whether the source and destination "five-tuple" and VLAN all meet the ACL configuration information.

[0075] Step S204: If it is determined that the header information has passed verification, and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is changed to the second encryption algorithm.

[0076] Step S205: Encrypt the original upgrade data using the second encryption algorithm to obtain ciphertext upgrade data, and assemble the ciphertext upgrade data and message header into ciphertext upgrade message.

[0077] Step S206: The ciphertext of the upgrade message is transmitted to the relay gateway so that the relay gateway can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, the ciphertext of the upgrade message is transmitted to the target ECU so that the target ECU can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0078] A relay gateway can be Figure 1 One of the VGW 102.

[0079] The target ECU can be Figure 1 One of the ECUs, 103.

[0080] The technical solution provided in this application embodiment, during the OTA upgrade flashing process, on the one hand, UMC verifies the header information of the message header to ensure that the upgrade message is a normal message; on the other hand, when determining the data transmission channel, a timer is started to record the first cumulative time and the current system load status of the data transmission channel is monitored in real time. Then, under the premise that the header information verification is passed, it is further determined whether the encryption algorithm needs to be changed according to the first cumulative time and the current system load status. This allows for the periodic or irregular replacement of the encryption algorithm, thereby increasing the difficulty for the upgrade flashing data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, and thus effectively improving the security of OTA upgrade flashing.

[0081] In some embodiments, determining that the header information has passed verification in step S204 above includes:

[0082] Obtain the data filtering rules corresponding to the data transmission channel;

[0083] Determine whether the header information matches each filtering rule in the data filtering rules;

[0084] If the header information matches each filtering rule in the data filtering rules, then the identification information of the target ECU is obtained;

[0085] If the identification information passes verification, then the header information is confirmed to have passed verification.

[0086] As an example, when the data transmission channel is a CAN channel, the data filtering rule is that the CAD ID is a CAD ID in a pre-defined whitelist, and the message transmission frequency of that CAD ID is a normal transmission frequency. The process of determining whether the header information conforms to each filtering rule specifically involves checking whether the CAD ID in the header information is a CAD ID in the pre-defined whitelist, and whether the message transmission frequency of that CAD ID is a normal transmission frequency. For example, assuming the header information extracted from the message header includes CAD ID1, and the message transmission frequency of CAD ID1 is 105MHz, then it checks whether the pre-defined whitelist contains CAD ID1. If CAD ID1 exists in the whitelist, it further determines whether the message transmission frequency of CAD ID1 is a normal transmission frequency. If the set message transmission frequency corresponding to CAD ID1 is 100MHz, and the message transmission frequency of CAD ID1 is 95MHz, then the message transmission frequency of CAD ID1 is within ±10% of the set message transmission frequency corresponding to CAD ID1 (i.e., 90MHz to 110MHz), which is considered a normal message transmission frequency. Therefore, it can be determined that the header information conforms to each filtering rule in the data filtering rules. At this point, the identification information of the target ECU (such as ECU ID) can be further obtained; assuming the obtained identification information of the target ECU is ECU ID1. Simultaneously, UMC can read the ECU identification information list and query whether the list contains ECU ID1. If the list contains ECU ID1, then the header information is deemed to have passed verification.

[0087] As another example, when the data transmission channel is an Ethernet (ETH) channel, the data filtering rule is that both the source and target "five-tuple" and VLAN must conform to the ACL configuration information. Determining whether the header information conforms to each filtering rule in the data filtering rules means determining whether the source and target "five-tuple" and VLAN conform to the ACL configuration information. If the source and target "five-tuple" and VLAN conform to the ACL configuration information, the target ECU's identification information is further obtained; let's assume the obtained target ECU's identification information is ECU ID2. Simultaneously, UMC can read the ECU's identification information list and query whether the list contains ECU ID2. If the list contains ECU ID2, the header information is deemed to have passed verification.

[0088] In this embodiment of the application, if the verification of the header information fails, the subsequent process of OTA upgrade flashing will be exited, and alarm information (such as alarm text, alarm beep, etc.) will be output.

[0089] In some embodiments, if the first cumulative time reaches the set replacement time interval and the current system load status is normal load status, it is determined that the encryption algorithm needs to be replaced; the first encryption algorithm is obtained and the first encryption algorithm is replaced with the second encryption algorithm.

[0090] Setting the replacement time interval refers to the time interval between replacements. This replacement time interval can be flexibly set according to the actual situation. For example, the replacement time interval can be 120 seconds, 150 seconds, 180 seconds, etc.

[0091] Normal load status typically refers to the total load rate of the data transmission channel not exceeding a preset threshold (for example, the preset threshold can be set to 50%, 80%, 90%, 100%, etc.).

[0092] As an example, assuming the set replacement interval is 120 seconds and the first cumulative time is 120 seconds, it can be determined that the first cumulative time has reached the set replacement interval. If the current total load rate of the data transmission channel is 40%, and the preset threshold is 80%, meaning the total load rate is less than the preset threshold, then it is determined that the encryption algorithm needs to be changed.

[0093] At this point, we can obtain KEY1, the key of the currently used encryption algorithm, then retrieve the first encryption algorithm based on KEY1, and finally replace KEY1 with KEY2, which corresponds to the second encryption algorithm. This will replace the first encryption algorithm with the second encryption algorithm.

[0094] The first encryption algorithm can be a symmetric encryption algorithm (such as DES, 3DES, TDEA, Blowfish, etc.) or an asymmetric encryption algorithm (such as RSA). The first encryption algorithm and the second encryption algorithm are different. For example, when the first encryption algorithm is DES, the second encryption algorithm can be any of the following: 3DES, TDEA, Blowfish, RSA, etc. Conversely, when the second encryption algorithm is DES, the first encryption algorithm can be any of the following: 3DES, TDEA, Blowfish, RSA, etc.

[0095] In one implementation, an algorithm replacement sequence table can be pre-defined, for example, Algorithm 1 (corresponding to KEY1) → Algorithm 2 (corresponding to KEY2) → Algorithm 3 (corresponding to KEY3) → Algorithm 4 (corresponding to KEY4) → Algorithm 1 → Algorithm 2... That is, "Algorithm 1 → Algorithm 2 → Algorithm 3 → Algorithm 4" is a cyclic replacement unit. The initial default encryption algorithm (i.e., the initial encryption algorithm negotiated in advance between UMC and ECU) is Algorithm 1 (the first encryption algorithm, corresponding to KEY1). When the first accumulated time reaches the set replacement time interval, and the current system load is normal, it is determined that the encryption algorithm needs to be replaced. At this time, the KEY corresponding to the second encryption algorithm can be determined first according to the algorithm replacement sequence table. If the KEY of the second encryption algorithm is KEY2, then Algorithm 1 (the first encryption algorithm, corresponding to KEY1) can be replaced with Algorithm 2 (the second encryption algorithm, corresponding to KEY2). When the first accumulated time reaches the next set replacement time interval, and the current system load is normal, it is determined that the encryption algorithm needs to be replaced. At this point, if the KEY corresponding to the second encryption algorithm is determined to be KEY3 according to the algorithm replacement order table, then the algorithm 2 (first encryption algorithm) corresponding to KEY2 is replaced with the algorithm 3 (second encryption algorithm) corresponding to KEY3. This process continues, with the encryption algorithm being changed periodically according to the algorithm replacement order table.

[0096] In this embodiment of the application, when the first cumulative time reaches the set replacement time interval and the current system load status is normal load status, the first encryption algorithm is periodically replaced with the second encryption algorithm. This can increase the difficulty for the upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

[0097] In other embodiments, if the first cumulative time has not reached the set replacement time interval and the current system load state is a load mutation state or a load abnormal state; or, if the first cumulative time has reached the set replacement time interval and the current system load state is a load mutation state or a load abnormal state, then it is determined that the encryption algorithm needs to be replaced; the first encryption algorithm is obtained and replaced with the second encryption algorithm; the first cumulative time recorded by the timer is cleared and the timer is restarted to record the second cumulative time.

[0098] A load surge typically refers to a situation where the total load rate of a data transmission channel changes significantly within a short period of time. Generally, a load surge is defined as a sudden increase in the total load rate from 25% to over 50% within a unit of time (e.g., within 30 seconds) (i.e., an increase of more than 100% in load rate).

[0099] An abnormal load condition typically refers to a situation where the load rate exceeds a preset threshold (which can be flexibly set according to actual conditions, for example, the preset threshold is 80%, 100%, etc.).

[0100] To facilitate understanding, let's continue with the example above. Set the replacement interval to 120 seconds, the first accumulated time recorded by the timer to 50 seconds, and if the current system load jumps from 25% to over 50% within 30 seconds, then it's determined that the encryption algorithm needs to be changed. At this point, we can first obtain the key for the first encryption algorithm (let's say KEY1). Then, if the key for the second encryption algorithm is determined to be KEY2 according to the algorithm replacement order table, we replace Algorithm 1 (the first encryption algorithm) corresponding to KEY1 with Algorithm 2 (the second encryption algorithm) corresponding to KEY2. Simultaneously, we clear the first accumulated time recorded by the timer (reset to zero) and restart the timer to record the second accumulated time from zero.

[0101] The technical solution provided in this application embodiment can, when a sudden change or abnormal situation is detected in the current system load (which may be due to a sudden change or abnormal situation caused by a third-party attack on the system), eliminate the need to wait for the first cumulative time to reach the set replacement time interval before executing the step of changing the encryption algorithm. This increases the difficulty for the upgrade and flashing data to be attacked, tampered with, or cracked by a third party during the OTA upgrade and flashing process, thereby effectively improving the security of OTA upgrade and flashing.

[0102] In some embodiments, in step S206 above, the ciphertext of the upgrade message is transmitted to the relay gateway so that the relay gateway can decrypt the ciphertext of the upgrade message, specifically including:

[0103] Perform a hash operation on the original upgrade data to obtain a hash value;

[0104] Obtain the algorithm identifier code of the second encryption algorithm;

[0105] The hash value and algorithm identifier are assembled into a transmission message;

[0106] The ciphertext of the upgrade message and the transmission message are transmitted to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message based on the transmission message.

[0107] Algorithm identifier code can be an identifier code (such as KEY), ID, etc., used to uniquely identify the second encryption algorithm.

[0108] As an example, UMC can perform a hash operation on the original upgrade data to obtain a hash value that is unidirectional, unique, and irreversible.

[0109] For example, the hash value and algorithm identifier can be assembled into a transmission message of the corresponding protocol format, depending on the data transmission channel used. For instance, if the data transmission channel is a CAN channel, the hash value and algorithm identifier can be filled into the data portion of the CAN message, and the message header of the CAN message can be the same as the message header used to assemble the upgrade message.

[0110] In one embodiment, combined with Figure 3 The overall process of UMC transmitting the ciphertext of the upgrade message and the transmission message to the target ECU / transfer gateway is as follows:

[0111] Step 1: UMC obtains the original upgrade data from the source (VBOX local or cloud server);

[0112] Step 2: UMC determines whether it is a UDS upgrade or an ETH upgrade, that is, determines the data transmission channel; at this time, a timer is started to record the first cumulative time, and the current system load status of the data transmission channel is monitored in real time.

[0113] Step 3: If the CAN channel is used as the data transmission channel, extract the message header information in the CAD message and check whether the CAD ID is in the whitelist and whether the message transmission frequency corresponding to the CAD ID meets the predefined specifications (i.e., determine whether the message transmission frequency corresponding to the CAD ID is normal).

[0114] Step 4: If the Ethernet (ETH) channel is used as the data transmission channel, extract the header information of the ETH message and check whether the source and destination "five-tuple" and VLAN meet the ACL configuration.

[0115] Step 5: If the CAD ID in Step 3 is in the whitelist and the packet transmission frequency corresponding to the CAD ID meets the predefined specifications; or if the source and destination "five-tuple" and VLAN in Step 4 both meet the ACL configuration, then perform ECU identity authentication and determine whether the ECU identity authentication is successful.

[0116] Step 6: If the ECU identity authentication is successful, the header information is confirmed to have been verified. Based on the first cumulative time and the current system load status, determine whether the encryption algorithm needs to be changed.

[0117] Step 7: If ECU authentication fails, exit the OTA upgrade process and issue an alarm;

[0118] Step 8: If the first cumulative time reaches the set replacement time interval and the current system load status is normal load status, then it is determined that the encryption algorithm needs to be replaced.

[0119] Step 9: Obtain the second encryption algorithm corresponding to the KEY that updates the encryption algorithm (e.g., algorithm 2 corresponding to KEY2), replace the original encryption algorithm (first encryption algorithm, e.g., algorithm 1 corresponding to KEY1) with the second encryption algorithm, and use the second encryption algorithm to encrypt the original upgrade data to obtain the ciphertext of the upgrade message, and transmit the ciphertext of the upgrade message to the transit gateway or the target ECU.

[0120] Step 10: Perform a hash operation on the original upgrade data to obtain a hash value, and assemble the hash value with the KEY of the second encryption algorithm to form a transmission message, and transmit the transmission message to the relay gateway or target ECU.

[0121] After receiving the ciphertext of the upgrade message and the transmission message from the UMC, the relay gateway or target ECU decrypts the ciphertext of the upgrade message based on the transmission message.

[0122] The following is a detailed explanation using the example of UMC transmitting both the ciphertext of the upgrade message and the transmission message obtained according to the above steps to the relay gateway (VGW 102), and then the UA in VGW 102 decrypting the ciphertext of the upgrade message based on the transmission message.

[0123] In one embodiment, combined with Figure 4 The process by which the UA decrypts the ciphertext of the upgrade message based on this transmission message is as follows:

[0124] Step (1): The UA receives the ciphertext of the upgrade message and the transmission message transmitted from the UMC;

[0125] Step (2): Determine whether it is a UDS upgrade or an ETH upgrade, that is, determine the data transmission channel;

[0126] Step (3): If the CAN channel is used as the data transmission channel, extract the header information of the message header from the upgrade message ciphertext (CAN message) (in the upgrade message ciphertext, the header information of the message header can be transmitted in plaintext), and check whether the CAD ID is in the whitelist and whether the message transmission frequency corresponding to the CAD ID meets the predefined specifications (i.e., determine whether the message transmission frequency corresponding to the CAD ID is normal).

[0127] Step (4): If the Ethernet (ETH) channel is used as the data transmission channel, extract the header information of the message header from the upgrade message ciphertext (ETH message), and check whether the source and destination "five-tuple" and VLAN meet the ACL configuration.

[0128] Step (5): If the CAD ID in step (3) is in the whitelist and the packet transmission frequency corresponding to the CAD ID meets the predefined specifications; or if the source and target "five-tuple" and VLAN in step (4) both meet the ACL configuration, then perform ECU identity authentication and determine whether the ECU identity authentication is successful.

[0129] Step (6): If the ECU identity authentication is successful, the header information is verified. The KEY of the second encryption algorithm (e.g., KEY2) is extracted from the transmission message. The second encryption algorithm (i.e., Algorithm 2) corresponding to KEY2 is found. Algorithm 2 is used to decrypt the ciphertext upgrade data in the ciphertext of the upgrade message (the decryption process is the reverse process of encrypting the original upgrade data using Algorithm 2) to obtain the plaintext upgrade data.

[0130] Step (7): If ECU identity authentication fails, exit the OTA upgrade process and issue an alarm;

[0131] Step (8): UA performs a hash operation on the plaintext upgrade data to obtain the hash value; extracts the hash value from the transmitted message and compares whether the hash value and the hash value are consistent.

[0132] Step (9): If the hash value is consistent with the hash value, it is confirmed that the plaintext upgrade data has not been tampered with and was released by UMC. The plaintext upgrade data is written to the target ECU so that the target ECU can use the plaintext upgrade data to perform upgrade flashing.

[0133] Step (10): If the hash value is inconsistent with the hash value, it is confirmed that the plaintext upgrade data has been tampered with or was not issued by UMC. The plaintext upgrade data is discarded, the OTA upgrade process is exited and an alarm is issued.

[0134] In another implementation, after receiving the ciphertext of the upgrade message and the transmission message from the UMC, the target ECU decrypts the ciphertext of the upgrade message based on the transmission message. The specific decryption process is basically the same as the process described above where the UA decrypts the ciphertext of the upgrade message based on the transmission message, and will not be repeated here.

[0135] The technical solution provided in this application, by adding a hash algorithm mechanism to the data sender (UMC) and data receiver (UA / US), helps to ensure the integrity and authenticity of the upgrade data during the entire OTA upgrade flashing process, and improves the security and upgrade quality of OTA upgrade flashing.

[0136] In some embodiments, the above-described OTA security upgrade flashing method further includes:

[0137] If the header information is verified and it is determined that the encryption algorithm does not need to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained.

[0138] The original upgrade data is encrypted using the first encryption algorithm to obtain the third ciphertext data;

[0139] The third ciphertext data is assembled with the message header into an encrypted message and transmitted to the relay gateway or target ECU.

[0140] As an example, if the replacement interval is set to 120 seconds, and the normal load condition is a total load rate not exceeding 80%, if it is determined that the upgrade message, including the header information, passes verification, and the first cumulative time is 100 seconds, and the current system load rate is 20% (<80%), which is a normal load condition, then it can be determined that there is no need to change the encryption algorithm, and the first encryption algorithm (assuming it is Algorithm 1 corresponding to KEY1) is obtained. Next, Algorithm 1 is used to encrypt the original upgrade data to obtain the third ciphertext data; then, the third ciphertext data and the message header are assembled into an encrypted message, and the encrypted message is transmitted to the relay gateway or the target ECU.

[0141] The technical solution provided in this application can dynamically adjust the encryption algorithm currently used based on the first cumulative time and the current system load status. This helps to increase the difficulty for upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby improving the security of OTA upgrade flashing.

[0142] Figure 5 This is a flowchart illustrating another OTA security upgrade flashing method provided in an embodiment of this application. Figure 5 As shown, the OTA security upgrade flashing method includes the following steps:

[0143] Step S501: Assemble the upgrade message, which includes a message header and the original upgrade data;

[0144] Step S502: Encrypt the original upgrade data using the first encryption algorithm to obtain the first ciphertext data;

[0145] Step S503: Determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time;

[0146] Step S504: Extract the header information from the message header and verify the header information;

[0147] Step S505: If it is determined that the header information has passed the verification, and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is changed to the second encryption algorithm.

[0148] Step S506: Encrypt the first ciphertext data using the second encryption algorithm to obtain the second ciphertext data, and assemble the second ciphertext data and the message header into a transmission message ciphertext;

[0149] Step S507: The encrypted transmission message is transmitted to the relay gateway so that the relay gateway can decrypt the encrypted transmission message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, the encrypted transmission message is transmitted to the target ECU so that the target ECU can decrypt the encrypted transmission message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0150] As an example, assuming the first encryption algorithm is Algorithm 1 (corresponding KEY 1), Algorithm 1 is used to encrypt the original upgrade data to obtain the first ciphertext data. Next, the data transmission channel is determined, and a timer is started to record the first cumulative time, monitoring the current system load status of the data transmission channel in real time. The header information in the message header is extracted and verified. If the header information passes verification, and based on the first cumulative time and the current system load status, it is determined that the encryption algorithm needs to be changed. Then, the second encryption algorithm (assumed to be Algorithm 2, corresponding KEY 2) is determined according to the algorithm replacement order table, and Algorithm 1 is replaced with Algorithm 2. That is, the first encryption algorithm has now been updated to Algorithm 2. Next, Algorithm 2 is used to encrypt the first ciphertext data to obtain the second ciphertext data. This second ciphertext data and the aforementioned message header are then assembled into a transmission message ciphertext. Finally, this transmission message ciphertext is transmitted to the relay gateway or the target ECU.

[0151] When the relay gateway or target ECU receives the encrypted transmission message from the UMC, it can refer to the above. Figure 4 Steps (1) to (6) verify the header information of the transmitted message ciphertext. After the header information is verified, Algorithm 2 is obtained according to KEY2. Algorithm 2 is used to decrypt the second ciphertext data in the transmitted message ciphertext to obtain the first decrypted data. Then, Algorithm 1 is obtained according to KEY1. Algorithm 1 is used to decrypt the first decrypted data to obtain the plaintext upgrade data.

[0152] The technical solution provided in this application has three aspects: First, by encrypting the original upgrade data once to obtain first ciphertext data, the difficulty of the upgrade data being attacked, tampered with, or cracked by a third party during the OTA upgrade flashing process can be increased. Second, by verifying whether the header information of the message header is legitimate, it can be ensured that the message to be transmitted is a normal message, which is conducive to improving the security of OTA upgrade flashing. Third, based on the successful verification of the header information, it can be determined whether the encryption algorithm needs to be changed according to the first cumulative time and the current system load status, so as to realize the periodic or irregular change of the encryption algorithm, further increasing the difficulty of the upgrade data being attacked, tampered with, or cracked by a third party during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

[0153] 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.

[0154] 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.

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

[0156] Assembly module 601 is configured to assemble upgrade messages, which include message headers and original upgrade data.

[0157] The determination module 602 is configured to determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time;

[0158] The extraction module 603 is configured to extract header information from the message header and verify the header information;

[0159] The replacement module 604 is configured to, if it is determined that the header information passes the verification and the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0160] The encryption module 605 is configured to encrypt the original upgrade data using a second encryption algorithm to obtain ciphertext upgrade data, and to assemble the ciphertext upgrade data and the message header into ciphertext upgrade message;

[0161] The transmission module 606 is configured to transmit the ciphertext of the upgrade message to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, to transmit the ciphertext of the upgrade message to the target ECU, so that the target ECU can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0162] The technical solution provided in this application embodiment, during the OTA upgrade flashing process, on the one hand, UMC verifies the header information of the message header to ensure that the upgrade message is a normal message; on the other hand, when determining the data transmission channel, a timer is started to record the first cumulative time and the current system load status of the data transmission channel is monitored in real time. Then, under the premise that the header information verification is passed, it is further determined whether the encryption algorithm needs to be changed according to the first cumulative time and the current system load status. This allows for the periodic or irregular replacement of the encryption algorithm, thereby increasing the difficulty for the upgrade flashing data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, and thus effectively improving the security of OTA upgrade flashing.

[0163] In some embodiments, the replacement module 604 includes:

[0164] The rule acquisition unit is configured to acquire data filtering rules corresponding to the data transmission channel;

[0165] The judgment unit is configured to determine whether the header information conforms to each filtering rule in the data filtering rules;

[0166] The information acquisition unit is configured to acquire the identification information of the target ECU if the header information matches each filtering rule in the data filtering rules.

[0167] The verification unit is configured to determine that the header information has passed verification if the identification information has passed verification.

[0168] In some embodiments, the replacement module 604 includes:

[0169] The first determining unit is configured to determine that the encryption algorithm needs to be changed if the first cumulative time reaches the set replacement time interval and the current system load status is normal load status.

[0170] The first acquisition unit is configured to acquire the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0171] In this embodiment of the application, when the first cumulative time reaches the set replacement time interval and the current system load status is normal load status, the first encryption algorithm is periodically replaced with the second encryption algorithm. This can increase the difficulty for the upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

[0172] In other embodiments, the replacement module 604 described above includes:

[0173] The second determining unit is configured to determine that the encryption algorithm needs to be replaced if the first cumulative time has not reached the set replacement time interval and the current system load state is a load change state or a load abnormal state; or if the first cumulative time has reached the set replacement time interval and the current system load state is a load change state or a load abnormal state.

[0174] The second acquisition unit is configured to acquire the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0175] The clearing unit is configured to clear the first cumulative time recorded by the timer and restart the timer to record the second cumulative time.

[0176] The technical solution provided in this application embodiment can, when a sudden change or abnormal situation is detected in the current system load (which may be due to a sudden change or abnormal situation caused by a third-party attack on the system), eliminate the need to wait for the first cumulative time to reach the set replacement time interval before executing the step of changing the encryption algorithm. This increases the difficulty for the upgrade and flashing data to be attacked, tampered with, or cracked by a third party during the OTA upgrade and flashing process, thereby effectively improving the security of OTA upgrade and flashing.

[0177] In some embodiments, the transmission module 606 includes:

[0178] The processing unit is configured to perform a hash operation on the original upgrade data to obtain a hash value;

[0179] The identifier acquisition unit is configured to acquire the algorithm identifier code of the second encryption algorithm;

[0180] The assembly unit is configured to assemble hash values ​​and algorithm identifiers into a transmission message;

[0181] The transmission unit is configured to transmit the ciphertext of the upgrade message and the transmission message to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message based on the transmission message.

[0182] The technical solution provided in this application, by adding a hash algorithm mechanism to the data sender (UMC) and data receiver (UA / US), helps to ensure the integrity and authenticity of the upgrade data during the entire OTA upgrade flashing process, and improves the security and upgrade quality of OTA upgrade flashing.

[0183] In some embodiments, the above-mentioned OTA security upgrade flashing device further includes:

[0184] The algorithm acquisition module is configured to acquire the first encryption algorithm if it is determined that the header information has passed verification and that the encryption algorithm does not need to be changed based on the first cumulative time and the current system load status.

[0185] The data encryption module is configured to encrypt the original upgrade data using a first encryption algorithm to obtain third ciphertext data;

[0186] The message assembly module is configured to assemble the third ciphertext data and the message header into an encrypted message and transmit it to the relay gateway or the target ECU.

[0187] The technical solution provided in this application can dynamically adjust the encryption algorithm currently used based on the first cumulative time and the current system load status. This helps to increase the difficulty for upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby improving the security of OTA upgrade flashing.

[0188] Figure 7 This is a schematic diagram of another OTA security upgrade flashing device provided in an embodiment of this application. Figure 7 As shown, the OTA security upgrade flashing device includes:

[0189] Assembly module 701 is configured to assemble upgrade messages, which include message headers and original upgrade data.

[0190] The encryption module 702 is configured to encrypt the original upgrade data using a first encryption algorithm to obtain the first ciphertext data;

[0191] The determination module 703 is configured to determine the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time;

[0192] Extraction module 704 is configured to extract header information from the message header and verify the header information;

[0193] The replacement module 705 is configured to, if it is determined that the header information passes verification and the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

[0194] The secondary encryption module 706 is configured to encrypt the first ciphertext data using a second encryption algorithm to obtain the second ciphertext data, and assemble the second ciphertext data and the message header into a transmission message ciphertext;

[0195] The data transmission module 707 is configured to transmit the encrypted transmission message to the relay gateway, so that the relay gateway can decrypt the encrypted transmission message to obtain plaintext upgrade data, and write the plaintext upgrade data to the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; or, to transmit the encrypted transmission message to the target ECU, so that the target ECU can decrypt the encrypted transmission message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing.

[0196] The technical solution provided in this application has three aspects: First, by encrypting the original upgrade data once to obtain first ciphertext data, the difficulty of the upgrade data being attacked, tampered with, or cracked by a third party during the OTA upgrade flashing process can be increased. Second, by verifying whether the header information of the message header is legitimate, it can be ensured that the message to be transmitted is a normal message, which is conducive to improving the security of OTA upgrade flashing. Third, based on the successful verification of the header information, it can be determined whether the encryption algorithm needs to be changed according to the first cumulative time and the current system load status, so as to realize the periodic or irregular change of the encryption algorithm, further increasing the difficulty of the upgrade data being attacked, tampered with, or cracked by a third party during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

[0197] 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.

[0198] Figure 8 This is a schematic diagram of the structure of a VBOX provided in an embodiment of this application. Figure 8 As shown, the VBOX includes an OTA upgrade main controller 801; the OTA upgrade main controller 801 includes as follows Figure 6 The OTA security upgrade flashing device shown.

[0199] The VBOX provided in this application embodiment, during the OTA upgrade flashing process, on the one hand, verifies the header information of the message to ensure that the upgrade message is a normal message; on the other hand, when determining the data transmission channel, a timer is started to record the first cumulative time and monitors the current system load status of the data transmission channel in real time. Then, provided that the header information verification is successful, it is further determined whether the encryption algorithm needs to be changed based on the first cumulative time and the current system load status. This allows for the periodic or irregular replacement of the encryption algorithm, increasing the difficulty for the upgrade flashing data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

[0200] Figure 9 This is a schematic diagram of the structure of a VBOX provided in an embodiment of this application. Figure 9 As shown, the VBOX includes an OTA upgrade main controller 901; the OTA upgrade main controller 901 includes as follows Figure 7 The OTA security upgrade flashing device shown.

[0201] The VBOX provided in this application has the following advantages: First, by encrypting the original upgrade data once to obtain first ciphertext data, it increases the difficulty for the upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process. Second, by verifying whether the header information of the message header is legitimate, it ensures that the message to be transmitted is a normal message, which helps to improve the security of OTA upgrade flashing. Third, based on the successful verification of the header information, it determines whether the encryption algorithm needs to be changed according to the first cumulative time and the current system load status, which can realize the periodic or irregular change of the encryption algorithm, further increasing the difficulty for the upgrade data to be attacked, tampered with, or cracked by third parties during the OTA upgrade flashing process, thereby effectively improving the security of OTA upgrade flashing.

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

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

[0204] The processor 1001 may 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.

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

[0206] 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.

[0207] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in 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 medium may include: any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), or a random access memory (RAM). The content contained in a computer-readable medium can be appropriately added to or subtracted according to the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, a computer-readable medium may not include electrical carrier signals and telecommunication signals.

[0208] 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 security upgrade flashing method, characterized in that, include: Assemble an upgrade message, the upgrade message including a message header and original upgrade data; Identify the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time; Extract the header information from the message header and verify the header information; If it is determined that the header information passes verification, and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is replaced with the second encryption algorithm. The original upgrade data is encrypted using the second encryption algorithm to obtain ciphertext upgrade data, and the ciphertext upgrade data and the message header are assembled into an upgrade message ciphertext. The ciphertext of the upgrade message is transmitted to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and write the plaintext upgrade data into the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; Alternatively, the ciphertext of the upgrade message can be transmitted to the target ECU, so that the target ECU can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform the upgrade flashing; Determining that the header information passes verification includes: Obtain the data filtering rules corresponding to the data transmission channel; Determine whether the header information conforms to each filtering rule in the data filtering rules; If the header information matches each of the filtering rules in the data filtering rules, then the identification information of the target ECU is obtained; If the identification information passes verification, then the header information is determined to have passed verification.

2. The method according to claim 1, characterized in that, Based on the first accumulated time and the current system load status, if it is determined that the encryption algorithm needs to be changed, then the first encryption algorithm is obtained, and the first encryption algorithm is replaced with the second encryption algorithm, including: If the first cumulative time reaches the set replacement time interval, and the current system load status is normal load status, then it is determined that the encryption algorithm needs to be replaced. Obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm.

3. The method according to claim 1, characterized in that, Based on the first accumulated time and the current system load status, if it is determined that the encryption algorithm needs to be changed, then the first encryption algorithm is obtained, and the first encryption algorithm is replaced with the second encryption algorithm, including: If the first accumulated time has not reached the set replacement time interval, and the current system load status is a load change state or a load abnormal state; or, if the first accumulated time has reached the set replacement time interval, and the current system load status is a load change state or a load abnormal state, then it is determined that the encryption algorithm needs to be replaced. Obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm; Clear the first cumulative time recorded by the timer and restart the timer to record the second cumulative time.

4. The method according to claim 1, characterized in that, The ciphertext of the upgrade message is transmitted to the relay gateway so that the relay gateway can decrypt the ciphertext of the upgrade message, including: Perform a hash operation on the original upgrade data to obtain a hash value; Obtain the algorithm identifier code of the second encryption algorithm; The hash value and algorithm identifier are assembled into a transmission message; The ciphertext of the upgrade message and the transmission message are transmitted to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message based on the transmission message.

5. The method according to claim 1, characterized in that, The method further includes: If it is determined that the header information passes verification, and it is determined that no change of encryption algorithm is required based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained; The original upgrade data is encrypted using the first encryption algorithm to obtain the third ciphertext data; The third ciphertext data is assembled with the message header into an encrypted message and transmitted to the relay gateway or target ECU.

6. An OTA security upgrade flashing method, characterized in that, include: Assemble an upgrade message, the upgrade message including a message header and original upgrade data; The original upgrade data is encrypted using the first encryption algorithm to obtain the first ciphertext data; Identify the data transmission channel and start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time; Extract the header information from the message header and verify the header information; If it is determined that the header information passes verification, and it is determined that the encryption algorithm needs to be changed based on the first cumulative time and the current system load status, then the first encryption algorithm is obtained and the first encryption algorithm is replaced with the second encryption algorithm. The first ciphertext data is encrypted using the second encryption algorithm to obtain the second ciphertext data, and the second ciphertext data and the message header are assembled into a transmission message ciphertext. The encrypted transmission message is transmitted to the relay gateway, so that the relay gateway can decrypt the encrypted transmission message to obtain plaintext upgrade data, and write the plaintext upgrade data into the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; Alternatively, the encrypted transmission message can be transmitted to the target ECU, so that the target ECU can decrypt the encrypted transmission message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing; Determining that the header information passes verification includes: Obtain the data filtering rules corresponding to the data transmission channel; Determine whether the header information conforms to each filtering rule in the data filtering rules; If the header information matches each of the filtering rules in the data filtering rules, then the identification information of the target ECU is obtained; If the identification information passes verification, then the header information is determined to have passed verification.

7. An OTA security upgrade flashing device, characterized in that, include: An assembly module is configured to assemble an upgrade message, the upgrade message including a message header and original upgrade data; The determination module is configured to determine the data transmission channel, start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time; The extraction module is configured to extract header information from the message header and verify the header information; The replacement module is configured to, if it is determined that the header information passes verification and, based on the first cumulative time and the current system load status, it is determined that the encryption algorithm needs to be replaced, then obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm; The encryption module is configured to encrypt the original upgrade data using the second encryption algorithm to obtain ciphertext upgrade data, and to assemble the ciphertext upgrade data and the message header into an upgrade message ciphertext; The transmission module is configured to transmit the ciphertext of the upgrade message to the relay gateway, so that the relay gateway can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and write the plaintext upgrade data into the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; Alternatively, the ciphertext of the upgrade message can be transmitted to the target ECU, so that the target ECU can decrypt the ciphertext of the upgrade message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform the upgrade flashing; Determining that the header information passes verification includes: Obtain the data filtering rules corresponding to the data transmission channel; Determine whether the header information conforms to each filtering rule in the data filtering rules; If the header information matches each of the filtering rules in the data filtering rules, then the identification information of the target ECU is obtained; If the identification information passes verification, then the header information is determined to have passed verification.

8. An OTA security upgrade flashing device, characterized in that, include: An assembly module is configured to assemble an upgrade message, the upgrade message including a message header and original upgrade data; A primary encryption module is configured to encrypt the original upgrade data using a first encryption algorithm to obtain first ciphertext data; The determination module is configured to determine the data transmission channel, start a timer to record the first cumulative time, and monitor the current system load status of the data transmission channel in real time; The extraction module is configured to extract header information from the message header and verify the header information; The replacement module is configured to, if it is determined that the header information passes verification and, based on the first cumulative time and the current system load status, it is determined that the encryption algorithm needs to be replaced, then obtain the first encryption algorithm and replace the first encryption algorithm with the second encryption algorithm; The secondary encryption module is configured to encrypt the first ciphertext data using the second encryption algorithm to obtain the second ciphertext data, and assemble the second ciphertext data and the message header into a transmission message ciphertext; The data transmission module is configured to transmit the encrypted transmission message to a relay gateway, so that the relay gateway can decrypt the encrypted transmission message to obtain plaintext upgrade data, and write the plaintext upgrade data into the target ECU, so that the target ECU can use the plaintext upgrade data to perform upgrade flashing; Alternatively, the encrypted transmission message can be transmitted to the target ECU, so that the target ECU can decrypt the encrypted transmission message to obtain plaintext upgrade data, and use the plaintext upgrade data to perform upgrade flashing; Determining that the header information passes verification includes: Obtain the data filtering rules corresponding to the data transmission channel; Determine whether the header information conforms to each filtering rule in the data filtering rules; If the header information matches each of the filtering rules in the data filtering rules, then the identification information of the target ECU is obtained; If the identification information passes verification, then the header information is determined to have passed verification.

9. A VBOX, characterized in that, Including OTA upgrades for the main control unit; The OTA upgrade controller includes the OTA security upgrade flashing device as described in claim 7 or claim 8.

Images