Vehicle gateway flashing method, device and equipment and storage medium

Abstract

The invention discloses a vehicle gateway flashing method, device and equipment and a storage medium, and belongs to the technical field of vehicle gateways, and the method comprises the following steps: S1, receiving a flashing request: receiving the flashing request from an upper computer, the flashing request comprising a target firmware version number, a firmware data index, a digital signature and firmware hash information; s2, legality verification: performing security verification on the flash request, including S3, security communication establishment: after verification is passed, establishing a security communication channel between a gateway and a target vehicle electronic control unit, the channel adopting a TLS1.3 protocol, and negotiating through an elliptic curve Diffie-Hellman to generate a dynamic session key; s4, firmware fragmentation transmission is carried out; s5, firmware writing: after the target ECU receives the complete firmware fragment, executing firmware writing operation, and returning a writing completion state to the gateway; the flash security is greatly improved, and replay attacks and man-in-the-middle attacks are prevented.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle gateway, more particularly, to a vehicle gateway flashing method, device, equipment and storage medium. BACKGROUND

[0002] Vehicle electronic systems are increasingly complex, and modern cars are usually equipped with multiple electronic control units (ECUs), such as power system control units, body control units, in-vehicle information entertainment systems, etc. With the upgrading of car functions and the improvement of safety requirements, the update and maintenance of ECU firmware have become an important link to ensure vehicle performance and safety. The traditional firmware update method mainly relies on vehicle repair stations or diagnostic equipment to perform firmware flashing through physical connection (such as OBD interface).

[0003] The prior art has the following disadvantages: the traditional flashing process mainly uses plaintext transmission or simple verification, which is vulnerable to data tampering, man-in-the-middle attacks or replay attacks; the identity verification, integrity verification, signature mechanism and other measures of the flashing request are not perfect, and the credibility of the flashing source and content is low; the firmware file is usually transmitted once, and lacks fragmentation, sliding window or retransmission mechanism, and network fluctuations or packet loss can easily cause flashing failure; the writing process lacks real-time verification and exception handling mechanism, and once failure occurs, it may cause ECU firmware damage or vehicle function abnormality; the traditional flashing method does not fully disclose the links of exception handling, rollback mechanism, write completion confirmation and function self-checking, making it difficult to ensure the traceability and controllability of the flashing process; the demand for OTA (Over-The-Air) remote flashing is increasing, and the existing technology still has technical bottlenecks in safe and reliable flashing in a remote environment. SUMMARY

[0004] The present application aims to provide a vehicle gateway flashing method, device, equipment and storage medium to solve the problems raised in the background art: the traditional flashing process mainly uses plaintext transmission or simple verification, which is vulnerable to data tampering, man-in-the-middle attacks or replay attacks; the identity verification, integrity verification, signature mechanism and other measures of the flashing request are not perfect, and the credibility of the flashing source and content is low; the firmware file is usually transmitted once, and lacks fragmentation, sliding window or retransmission mechanism, and network fluctuations or packet loss can easily cause flashing failure; the writing process lacks real-time verification and exception handling mechanism, and once failure occurs, it may cause ECU firmware damage or vehicle function abnormality; the traditional flashing method does not fully disclose the links of exception handling, rollback mechanism, write completion confirmation and function self-checking, making it difficult to ensure the traceability and controllability of the flashing process; the demand for OTA (Over-The-Air) remote flashing is increasing, and the existing technology still has technical bottlenecks in safe and reliable flashing in a remote environment.

[0005] Technical solution: A vehicle gateway flashing method, comprising the following steps: S1, receiving flashing request: receiving the flashing request from the host computer, the flashing request including target firmware version number, firmware data index, digital signature and firmware hash information; S2, legality verification: performing security verification on the flashing request, including: S21, verifying the identity of the host computer based on X.509 certificate chain, and confirming that the certificate is not expired and is not included in the revocation list (CRL / OCSP); S22, verifying the joint signature of the request header and the firmware hash using elliptic curve digital signature algorithm (ECDSA) to confirm that the flashing instruction has not been tampered with; S3, secure communication establishment: after verification, a secure communication channel is established between the gateway and the target vehicle electronic control unit (ECU), the channel uses TLS1.3 protocol, and a dynamic session key is generated through elliptic curve Diffie-Hellman (ECDH) negotiation; S4, firmware fragment transmission: the target firmware data is fragmented according to 1KB-8KB size, each piece of data includes fragment number, SHA256 checksum and data length, and is transmitted through an adaptive sliding window mechanism, the specific steps including: S41, after sending each piece of firmware data, waiting for ECU verification feedback; S42, if ECU verification fails or exceeds the preset number of times, retransmit the fragment; S43, until all fragments are successfully transmitted; S5, firmware writing: after the target ECU receives the complete firmware fragment, it performs firmware writing operation and returns the writing completion status to the gateway; S6, exception handling and rollback: if verification fails, writing timeout or ECU exception occurs during writing, the gateway triggers the rollback mechanism, including: S61, load the old firmware image stored in the ECU security partition; S62, overwrite the failed new firmware; S63, verify the integrity of the old firmware through SHA256, and confirm that the ECU starts normally; S64, return the status to the host computer after rollback is completed; S7, flashing result feedback and function self-check: based on ECU feedback, generate the final flashing result, including success, flashing failure, partial failure and rollback completion, and perform function self-check, the self-check including key register state reading, communication interface detection and running log reporting, if abnormal, trigger alarm and record log; S8, application scenarios and interface applicability: the method is applicable to OTA remote flashing and local diagnostic flashing, supports CAN, Ethernet and LIN interfaces, and can perform AES encryption transmission on firmware data.

[0006] Preferably, the sliding window mechanism in S4 can dynamically adjust the window size according to the network packet loss rate, so as to improve the transmission efficiency and ensure the transmission reliability.

[0007] Preferably, the firmware writing operation in S5 includes segmented writing, segment-by-segment verification and final integrity confirmation, so as to ensure that the written firmware is consistent with the upper computer firmware hash.

[0008] Preferably, the rollback mechanism triggering condition includes: CRC check failure, writing timeout, running exception or function self-check failure of ECU in the writing process.

[0009] Preferably, the function self-check result in S7 is returned to the upper computer together with the flashing log, which is used for flashing audit and remote troubleshooting.

[0010] A vehicle gateway flashing device, comprising: a request receiving module, configured to receive a flashing request from an upper computer; a verification module, configured to verify the legality of the flashing request; a communication module, configured to establish a secure communication channel between the gateway and a target ECU after verification; a transmission module, configured to perform fragmented transmission and buffer verification on firmware data, and transmit the firmware data to the target ECU piece by piece; and a result processing module, configured to receive the flashing state feedback of the target ECU, and generate a flashing result and return it to the upper computer.

[0011] Preferably, the verification module uses a digital signature algorithm to verify the integrity of the flashing request.

[0012] Preferably, the communication module establishes an encrypted channel based on the TLS protocol.

[0013] A vehicle gateway flashing device, comprising a processor, a memory and a communication interface, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor implements the method of any one of claims 1 to 5.

[0014] A computer readable storage medium, having a computer program stored thereon, wherein the computer program is executed by a processor to implement the method of any one of claims 1 to 5.

[0015] Compared with the prior art, the advantages of the present application are: (1) The application strictly verifies the identity and digital signature of the flashing request, and combines X.509 certificate chain and elliptic curve encryption technology to establish a secure communication channel, so that the source of the flashing data is reliable and has not been tampered with, the flashing security is greatly improved, and the replay attack and man-in-the-middle attack are prevented.

[0016] (2) The application transmits the firmware in pieces (1KB-8KB per piece), adopts an adaptive sliding window mechanism and a piece retransmission strategy, ensures that each piece of data is written after being verified, and performs segment verification when writing, thereby enhancing the reliability of the flashing process, the integrity and controllability of the firmware.

[0017] (3) The application implements rollback of the firmware with writing failure or verification anomaly, and provides complete state feedback and abnormal log recording, thereby improving the controllability of flashing, ensuring the safety of ECU, and achieving traceability of operation and maintenance.

[0018] (4) The application supports multiple network interfaces (CAN, Ethernet, LIN), remote OTA and local flashing, and combines session maintenance, heartbeat detection and abnormal alarm mechanism, thereby improving the flashing efficiency, enhancing the long-time flashing stability, and being widely applicable.

[0019] (5) The application combines the multi-layer security mechanism with reliable transmission, segmented writing and rollback measures, thereby significantly improving the overall safety, reliability and controllability of vehicle firmware upgrade. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 The figure is a flowchart of the vehicle gateway flashing method of the application. DETAILED DESCRIPTION

[0021] Embodiment, please refer to Figure 1 A vehicle gateway flashing method, comprising the following steps: S1, receiving a flashing request: receiving a flashing request from a host computer, the flashing request including target firmware version number, firmware data index, digital signature and firmware hash information; S21 identity verification When the host computer initiates a flashing request, it sends its X.509 digital certificate with the request, the certificate including public key, serial number, issuing authority information and validity period.

[0022] The gateway receives the certificate and performs the following operations: Validity period check: verify that the current system time is between the start date and the end date of the certificate, and refuse the flashing request if the certificate is expired; Revocation status check: query whether the certificate is revoked through CRL or OCSP, and refuse the request if it is revoked; Certificate chain verification: Verify the certificate from the host computer to the trusted root certificate, and verify the signature correctness level by level; Certificate blacklist check: Add historical abnormal certificates or high-risk certificates to the gateway local blacklist to further improve security; S22 digital signature verification The host computer signs the flashing request data, including: Request header information (vehicle ID, target ECU number, timestamp, etc.) Firmware data hash value (SHA256 or SHA512) Use the host computer private key to generate ECDSA signature data and send it with the request; The gateway receives the request and performs verification: Recalculate the request header and firmware hash value; Use the host computer public key to verify the signature match; If the verification fails, reject the request and record the exception log; And take the following enhanced measures: Timestamp verification: Only accept requests within the last N seconds to prevent replay attacks; One-time random number (Nonce): The request carries a random number to ensure that each flashing request is unique and prevent replay; Request frequency limit: Limit the number of flashing requests initiated by the same certificate within a unit of time to prevent flashing storms or DoS attacks; Multi-factor authentication: For high-privilege flashing operations, the gateway can require the host computer to provide additional identity credentials, such as one-time passwords or hardware key verification; Exception alarm mechanism: When the number of consecutive failures exceeds the threshold, the gateway triggers an alarm and suspends the flashing operation to ensure the safety of the vehicle's ECU.

[0023] Ensure the identity of the flashing request is trusted, complete and tamper-proof; prevent replay attacks, malicious flashing, flashing storms, and improve system security and reliability; provide multi-layer security protection and can be applied in OTA remote flashing or local flashing scenarios.

[0024] S3, secure communication establishment: After verification, establish a secure communication channel between the gateway and the target vehicle electronic control unit (ECU), which uses the TLS1.3 protocol and generates a dynamic session key through elliptic curve Diffie-Hellman (ECDH) negotiation; After completing the legality verification in S2, the gateway confirms that the host computer's identity is trusted and the flashing request has not been tampered with; the gateway and the target ECU have a physical or logical communication channel (such as CAN, Ethernet or LIN interface); Gateway as a client or server, ECU as the corresponding end, according to the system configuration to select the role; Both sides start the TLS1.3 handshake, including the following processes: ClientHello / ServerHello: Gateway and ECU exchange the supported encryption suite, random number, protocol version and other information; Certificate exchange: Gateway and ECU verify each other's certificates to ensure that the identity of the opposite end is trusted; Key negotiation: Use Elliptic Curve Diffie-Hellman (ECDH) to generate a temporary session key; Finished message verification: Both sides confirm that the handshake is complete and there is no tampering; The dynamic session key generated by ECDH negotiation is used to encrypt the flashing data channel; the data encryption algorithm can use AES-256-GCM or ChaCha20-Poly1305 to ensure the confidentiality and integrity of the data during transmission; a new session key is generated for each flashing session, which is destroyed after the flashing is completed, preventing key reuse risk; Session random number (Nonce): used to generate dynamic keys to prevent replay attacks; Handshake message integrity check: verify each handshake message has not been tampered with through a hash algorithm and MAC; Handshake timeout and retry mechanism: if the handshake is not completed within the preset time (such as 5 seconds), it will automatically retry to prevent network jitter from causing failure; Handshake exception alarm: when the number of handshake failures exceeds the threshold, the gateway triggers a security alarm and suspends the flashing operation; After the TLS encrypted channel is established, all flashing data (firmware fragments, checksums, control commands) are transmitted through the channel; each data packet is checked for integrity during transmission to ensure that the data has not been tampered with or lost; for long-time flashing operations, session maintenance and heartbeat detection are supported to prevent unexpected connection interruption.

[0025] Ensure the confidentiality, integrity and identity trust of communication between gateway and ECU; prevent man-in-the-middle attacks, replay attacks or data tampering during flashing; support multiple network interfaces and OTA flashing scenarios to improve flashing security and reliability.

[0026] S4, the firmware fragment transmission divides the target firmware file into fragments according to a fixed size, which can be adaptively adjusted within the range of 1KB-8KB; Each piece of data contains the following information: Fragment number: identifies the position of the fragment in the firmware file, ensuring that the data order can be recombined; Fragment hash value: calculate the hash value of each piece of data using SHA256, which is used to check the integrity; Data length: record the actual number of bytes of this fragment; Random nonce: used to prevent replay attacks; The gateway dynamically adjusts the window size according to the network bandwidth and packet loss rate, and multiple pieces of data can be sent simultaneously in the window to improve transmission efficiency; The gateway records the sent fragment sequence number and state after sending a batch of fragments, and waits for ECU feedback; S41, the gateway sends the fragment data to the target ECU through the secure communication channel established in S3; After receiving each piece of data, the ECU performs the following operations: Check if the fragment length and sequence number match; Calculate the SHA256 hash value of the fragment and compare it with the received value; Return the verification result (success or failure) to the gateway; S42, when the gateway receives a verification failure or does not receive feedback within the timeout time (such as 500ms-2s, which can be adjusted according to the network situation), mark the fragment as pending retransmission; Set a maximum number of retransmissions (such as 3 times) for each fragment, and if the number of retransmissions exceeds the maximum number, trigger an exception handling (see S6 rollback or alarm mechanism); Support priority retransmission mechanism: preferentially send failed fragments to ensure firmware transmission integrity; S43, after all fragments are successfully transmitted and verified, the gateway sends a firmware transmission completion notification to the ECU; The ECU confirms that all fragments have been completely received and prepares to perform a write operation; Use TLS channel encryption for each batch of fragment transmission to prevent data from being stolen or tampered with during transmission; support heartbeat detection mechanism for long-time flashing session, and automatically resume transmission if communication is interrupted; the gateway records fragment transmission logs, including fragment sequence number, sending time, and verification result, for exception troubleshooting and auditing; combined with the digital signature and timestamp mechanism of S2, prevent replay attacks or illegal flashing requests; Ensure the integrity and order of firmware data; support high packet loss network environment to ensure flashing reliability; improve flashing efficiency while ensuring security and exception traceability; provide a reliable foundation for subsequent firmware writing, reducing the probability of writing failure and rollback.

[0027] S5, firmware writing: after the target ECU receives the complete firmware fragments, it performs firmware writing operation and returns the writing completion status to the gateway; After receiving all the firmware fragments transmitted in S4 and verifying them, the ECU reassembles the fragment data into a complete firmware image; During the assembly process, the ECU rechecks the order of the fragments, the total length, and the SHA256 hash value to ensure the integrity of the firmware. Before performing the write, the ECU performs the following preprocessing: Write area check: Confirm that the Flash or EEPROM area used to store the new firmware is available and undamaged; Backup old firmware: Copy the current firmware to the secure partition to ensure that it can be rolled back in case of write failure; Stop non-critical tasks: Suspend background tasks or communication that may interfere with the write operation to ensure write stability; The firmware is written in segments, and the size of each segment can be adjusted according to the ECU Flash page size; Immediately after writing each segment of data, a write verification is performed: Read the written segment data and calculate the hash value for comparison with the original data; Only when the verification is passed will the next segment be written, and if the verification fails, the rewrite mechanism will be triggered; After the write is complete, the ECU performs integrity verification on the entire firmware, including: SHA256 hash comparison; CRC or ECC (Error Detection / Correction Code) verification; If the verification fails, trigger the S6 rollback mechanism to restore the old firmware; After the ECU successfully writes the firmware and passes the integrity verification, it returns the write completion status to the gateway, including: Firmware version number; Write result status (success, partial failure, failure); Verification result; After receiving the status, the gateway can proceed to the next step of function self-check or write result feedback; S6, exception handling and rollback: If a verification failure, write timeout, or ECU exception occurs during the write process, the gateway triggers the rollback mechanism, including: S61, Load the old firmware image stored in the ECU secure partition; S62, Overwrite the failed new firmware; S63, Verify the integrity of the old firmware through SHA256 and confirm that the ECU starts normally; S64, Return the status to the host computer after the rollback is complete; S7, Write result feedback and function self-check: Based on the ECU feedback, generate the final write result, including success, write failure, partial failure, and rollback completion, and perform a function self-check, which includes key register state reading, communication interface detection, and running log reporting. If an exception occurs, trigger an alarm and record the log; S8, application scenario and interface applicability: the method is applicable to OTA remote flashing and local diagnostic flashing, supports CAN, Ethernet and LIN interfaces, and can perform AES encryption transmission on firmware data.

[0028] The sliding window mechanism in S4 can dynamically adjust the window size according to the network packet loss rate, so as to improve the transmission efficiency and guarantee the transmission reliability.

[0029] The firmware writing operation in S5 includes segmented writing, segment-by-segment verification and final integrity confirmation, so as to ensure that the written firmware is consistent with the upper computer firmware hash.

[0030] The rollback mechanism triggering conditions include: ECU CRC check failure, write timeout, running exception or function self-check failure in the writing process.

[0031] The function self-check result in S7 is returned to the upper computer together with the flashing log, which is used for flashing audit and remote troubleshooting.

[0032] A vehicle gateway flashing device, comprising: a request receiving module for receiving a flashing request from an upper computer; a verification module for verifying the legality of the flashing request; a communication module for establishing a secure communication channel between the gateway and the target ECU after verification; a transmission module for fragmenting and transmitting the firmware data and performing buffer verification, and transmitting the firmware data to the target ECU piece by piece; a result processing module for receiving the flashing state feedback of the target ECU and generating the flashing result and returning it to the upper computer.

[0033] The verification module uses a digital signature algorithm to verify the integrity of the flashing request.

[0034] The communication module establishes an encrypted channel based on the TLS protocol.

[0035] The above shows and describes the basic principles, main features and advantages of the present application; those skilled in the art should understand that the present application is not limited to the above embodiments, the above embodiments and descriptions in the specification are only preferred examples of the present application, and are not intended to limit the present application, various changes and improvements can be made to the present application without departing from the spirit and scope of the present application, and these changes and improvements all fall within the scope of the claimed present application; the scope of protection of the present application is defined by the appended claims and their equivalents.

Claims

1. A vehicle gateway flashing method, characterized in that, The method comprises the following steps: S1, receiving a flashing request: receiving a flashing request from a host computer, the flashing request comprising a target firmware version number, a firmware data index, a digital signature, and firmware hash information; S2, legality verification: performing security verification on the flashing request, comprising: S21, verifying the identity of the host computer based on an X.509 certificate chain, and confirming that the certificate has not expired and is not included in a revocation list; S22, verifying the joint signature of the request header and the firmware hash using an elliptic curve digital signature algorithm to confirm that the flashing instruction has not been tampered with; S3, establishing a secure communication channel: after verification, a secure communication channel is established between the gateway and the target vehicle electronic control unit, the channel uses the TLS1.3 protocol, and a dynamic session key is generated through elliptic curve Diffie-Hellman negotiation; S4, firmware fragment transmission: the target firmware data is fragmented according to a size of 1KB-8KB, each piece of data comprising a fragment number, a SHA256 checksum, and a data length, and the transmission is performed through an adaptive sliding window mechanism, the specific steps comprising: S41, after sending each piece of firmware data, waiting for ECU verification feedback; S42, if the ECU verification fails or times out for more than a preset number of times, retransmitting the fragment; S43, until all fragments are successfully transmitted; S5, firmware writing: after the target ECU receives the complete firmware fragments, performing a firmware writing operation and returning a writing completion status to the gateway; S6, exception handling and rollback: if a verification failure, a writing timeout, or an ECU exception occurs during the writing process, the gateway triggers a rollback mechanism, comprising: S61, loading the old firmware image stored in the ECU secure partition; S62, covering the new firmware that fails to write; S63, verifying the integrity of the old firmware through SHA256, and confirming that the ECU starts normally; S64, returning a status to the host computer after the rollback is completed; S7, flashing result feedback and function self-check: generating a final flashing result based on ECU feedback, including success, flashing failure, partial failure, and rollback completion, and performing a function self-check, the self-check comprising key register state reading, communication interface detection, and running log reporting, if an exception occurs, triggering an alarm and recording a log; S8, application scenario and interface applicability: the method is applicable to OTA remote flashing and local diagnostic flashing, supports CAN, Ethernet, and LIN interfaces, and can perform AES encryption transmission on firmware data.

2. The vehicle gateway flashing method of claim 1, wherein, The sliding window mechanism in S4 can dynamically adjust the window size according to the network packet loss rate to improve transmission efficiency and ensure transmission reliability.

3. The vehicle gateway flashing method of claim 1, wherein, The firmware writing operation in S5 comprises segmented writing, segment-by-segment verification, and final integrity confirmation, ensuring that the written firmware is consistent with the host computer firmware hash.

4. The vehicle gateway flashing method of claim 1, wherein, The rollback mechanism triggering conditions include: ECU CRC verification failure, writing timeout, running exception, or function self-check failure during the writing process.

5. The vehicle gateway flashing method of claim 1, wherein, The function self-check result in S7 is returned to the host computer together with the flashing log, which is used for flashing audit and remote troubleshooting.

6. A vehicle gateway flashing device, characterized by: The method comprises: a request receiving module for receiving a flashing request from a host computer; a verification module for verifying the legality of the flashing request; a communication module, configured to establish a secure communication channel between the gateway and the target ECU after verification; a transmission module, configured to perform fragmented transmission and cache verification on the firmware data, and transmit the firmware data to the target ECU in fragments; a result processing module, configured to receive a flashing state feedback from the target ECU, and generate a flashing result and return the flashing result to the host computer.

7. A vehicle gateway flashing device according to claim 6, wherein, The verification module verifies the integrity of the flashing request by using a digital signature algorithm.

8. The vehicle gateway flasher of claim 6, wherein, The communication module establishes an encrypted channel based on a TLS protocol. 9.A vehicle gateway flashing device, comprising a processor, a memory and a communication interface, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor implements the method in any one of claims 1 to 5. 10.A computer readable storage medium, storing a computer program, and when the computer program is executed by a processor, the method in any one of claims 1 to 5 is implemented.

Images