A signature and verification method of automobile ECU firmware

Abstract

The application provides a signature and verification method of automobile ECU firmware, and belongs to the technical field of automobile electronic safety upgrade. The method divides the firmware into multiple data code segments, calculates the hash of each segment and generates a root hash signature; during upgrade, ECU_MASTER sends data and hash segment by segment, ECU_SLAVE verifies and stores segment by segment, and after the completion of the whole transmission, the root hash is recalculated and compared with the decrypted root hash to complete the overall verification. The application executes the verification process locally on the small-capacity target ECU, solves the problem that small storage space ECU cannot be verified as a whole, eliminates the security risk that the data in the transmission process is tampered with but not detected in the verification scheme, significantly improves the safety and reliability of automobile ECU remote upgrade, and is suitable for the safety upgrade of various small-capacity vehicle ECU firmware.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic control unit firmware upgrade technology, specifically to a method for firmware signing and verification of an automotive ECU. Background Technology

[0002] Many ECUs in intelligent connected vehicles support remote firmware upgrades. To ensure the firmware is legitimate and has not been tampered with, verification is necessary. High-capacity ECUs can download the complete upgrade package first and then verify the firmware; however, low-capacity ECUs cannot cache the complete firmware and must have the high-capacity ECU_MASTER verify the firmware before transmission and flashing.

[0003] The existing verification process is as follows: First, ECU_MASTER receives the complete upgrade package and verifies its signature; second, ECU_MASTER transmits the firmware to ECU_SLAVE via the CAN bus and flashes it. The existing solution has a flaw: after ECU_MASTER's signature verification is successful, the data may be corrupted or tampered with during transmission, making it impossible for ECU_SLAVE to verify again. This can lead to the flashing of unauthorized firmware, seriously threatening vehicle safety. Summary of the Invention

[0004] To address the issues in existing technologies where small-capacity ECUs cannot undergo local whole-process signing and where proxy signing carries the risk of tampering after transmission, this invention provides an ECU firmware signing and verification method that involves segmented signing, segment-by-segment verification, and local final comparison. This method completely moves the verification process to the target ECU_SLAVE, eliminating the risk of undetected tampering during transmission.

[0005] To achieve the above technical effects, the present invention employs a signing and verification method for automotive ECU firmware, characterized by comprising:

[0006] S1 firmware segmentation: The compiled ECU binary firmware is divided into multiple data code segments according to address and data code;

[0007] S2 segmented hash calculation and signing: The hash value is calculated independently for each data code segment, and then the hash values ​​of all segments are hashed to generate an overall root hash value HASHroot. The root hash value HASHroot is signed using the private key to obtain the signature information.

[0008] S3 segmented transmission and local signature verification: ECU_MASTER sends data code segments and corresponding hash values ​​to ECU_SLAVE segment by segment. After receiving each data code segment, ECU_SLAVE immediately recalculates the hash value of each segment and compares it with the received original root hash value. If they match, the signature verification is successful. ECU_SLAVE writes the data code segment to the specified address and saves its corresponding hash value.

[0009] S4 ECU_SLAVE root hash value recalculation and verification: After all data segments have been transmitted and locally verified, ECU_SLAVE recalculates a root hash value (HASHCal) using all locally stored independent hash values. ECU_MASTER sends the signature information, and ECU_SLAVE decrypts it using the public key to obtain the original root hash value (HASHroot). ECU_SLAVE compares HASHCal with HASHroot. If they match, the signature verification passes and the upgrade is successful; otherwise, the signature verification fails.

[0010] Furthermore, in firmware segmentation, data from consecutive addresses are merged into a single data code segment, and the size of the data code segment does not exceed the processing and storage capacity of ECU_SLAVE.

[0011] Furthermore, the segmented transmission and local signature verification use the SHA256 algorithm to calculate the hash value of each data segment and the root hash value.

[0012] Furthermore, the root hash value is signed using the RSA2048 algorithm for segmented transmission and local signature verification.

[0013] Furthermore, ECU_MASTER and ECU_SLAVE communicate via CAN, CANFD, or LIN bus.

[0014] Furthermore, ECU_SLAVE is a small storage space ECU, and the entire signature verification process is executed locally in ECU_SLAVE.

[0015] Compared with the prior art, the present invention has the following beneficial effects:

[0016] 1. Adapts to ECUs with small storage space, allowing signature verification to be completed without caching the complete firmware;

[0017] 2. Verification is completed locally on the target ECU, completely eliminating the risk of data tampering going undetected during transmission;

[0018] 3. The combination of segmented transmission and segment-by-segment verification enhances the stability and security of upgrades. Attached Figure Description

[0019] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0020] Figure 1 This is a flowchart illustrating the ECU firmware signing process according to an embodiment of this application.

[0021] Figure 2 This is a flowchart illustrating the ECU firmware verification process according to an embodiment of this application.

[0022] Figure 3 This is a step diagram illustrating the signing and verification method for the automotive ECU firmware in this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0024] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, all directional indications (such as up, down, left, right, front, back, bottom, etc.) in this application are only used to explain the relative positional relationships and movements between components in a specific orientation (as shown in the figures). If the specific orientation changes, the directional indication will also change accordingly. Furthermore, descriptions involving "first," "second," etc., in this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated.

[0026] The present invention provides a method for signing and verifying automotive ECU firmware, the working principle of which is as follows:

[0027] First, during the firmware generation phase, in offline mode, the entire firmware is broken down into multiple small data code segments, and an independent hash value is generated for each segment. These independent hash values ​​are then aggregated to generate an overall root hash value, which is then digitally signed. This preprocessing mechanism provides a verifiable "fingerprint" for each part of the firmware and the firmware as a whole.

[0028] During the online upgrade transmission phase, ECU_MASTER no longer transmits the entire firmware package at once, but instead transmits it in segments. For each data segment transmitted, ECU_MASTER simultaneously sends its corresponding independent hash value. ECU_SLAVE, due to limited storage space, cannot store the entire firmware, but it can receive and process individual data segments. When ECU_SLAVE receives each data segment, it immediately calculates its hash value and compares it with the received independent hash value. This "instant verification" mechanism ensures that each data segment is intact and undisturbed before being written to ECU_SLAVE memory, and also guarantees that any tampering of a data segment can be detected before the upgrade. After successful verification, ECU_SLAVE writes the segment to memory and saves its corresponding independent hash value.

[0029] After all data segments have been transmitted and locally verified, ECU_SLAVE uses all the individual hash values ​​it stores to recalculate a new root hash value (HASHCal). Simultaneously, ECU_SLAVE receives the digital signature sent by ECU_MASTER and decrypts it using the public key to obtain the original root hash value (HASHroot). Finally, ECU_SLAVE compares the locally calculated HASHCal with the decrypted HASHroot. If they match, it proves that throughout the entire process from firmware generation to transmission and local assembly by ECU_SLAVE, every byte of the firmware has maintained its original integrity and legitimacy, without any tampering or damage.

[0030] This layered verification (verifying each segment first, then verifying the sum of all segments) enables ECU_SLAVE to perform final and reliable verification of the integrity of the entire firmware even with limited storage space, thus effectively avoiding transmission risks.

[0031] This invention provides a method for signing and verifying automotive ECU firmware, comprising the following steps:

[0032] like Figure 1 As shown, the ECU firmware signing process can be carried out in the following steps:

[0033] 1. The newly compiled firmware file for ECU_SLAVE is divided into N (e.g., 10) smaller data code segments (Data Block 1, Data Block 2, ..., Data Block N) based on its address and data code information. The size of each data code segment is controlled within the processing capacity of ECU_SLAVE.

[0034] 2. Calculate the SHA256 hash value of each data code segment independently to obtain HASH1, HASH2, ..., HASHN respectively.

[0035] 3. Perform SHA256 hash calculation on these individual hash values ​​(HASH1 to HASHN) again to generate an overall root hash value (HASHroot).

[0036] 4. Use a preset private key to perform an RSA digital signature on this HASHroot, generating a 2048-bit RSA signature.

[0037] 5. Finally, the upgrade package is packaged, which contains all data code segments, the independent hash value corresponding to each data code segment, and the signed HASHroot (this information constitutes the "verification structure").

[0038] like Figure 2 As shown, ECU firmware verification involves segmented transmission and local verification, occurring between ECU_MASTER and ECU_SLAVE.

[0039] 1. ECU_MASTER receives the upgrade package. The remote upgrade system sends the complete upgrade package to ECU_MASTER (an ECU with a large storage capacity).

[0040] 2. Segmented Transmission and Local Verification. ECU_MASTER begins sending data to ECU_SLAVE. It first sends "Data Segment 1" and its corresponding "HASH1" (extracted from the verification structure of the upgrade package). Upon receiving "Data Segment 1," ECU_SLAVE immediately calculates its SHA256 hash value. ECU_SLAVE compares its calculated hash value with the "HASH1" received from ECU_MASTER. If they match, ECU_SLAVE confirms the data segment is complete and writes it to the specified address in its own memory, saving the verified "HASH1." If they do not match, ECU_SLAVE immediately determines that the data has been corrupted or tampered with during transmission, the upgrade fails, and the process is aborted.

[0041] ECU_MASTER and ECU_SLAVE repeatedly perform segmented transmission and local verification, transmitting and verifying "data code segment 2" and "HASH2" one by one, until all N data code segments and their corresponding hash values ​​have been successfully transmitted, verified and written to ECU_SLAVE, and all independent hash values ​​(HASH1 to HASHN) are saved by ECU_SLAVE.

[0042] 3. The SLAVE calculates the root hash. After all the individual hash values ​​(HASH1 to HASHN) have been stored locally in the ECU_SLAVE, the ECU_SLAVE performs SHA256 hash calculation on these stored hash values ​​again to generate a locally calculated root hash value (HASHCal).

[0043] 4. Slave-side signature verification. ECU_MASTER sends the previously generated digital signature information (including the signature's hashroot) to ECU_SLAVE. ECU_SLAVE decrypts this signature information using a pre-stored public key to obtain the original hashroot. ECU_SLAVE then performs a final comparison between its locally calculated "HASHCal" and the "HASHroot" obtained through public key decryption. If the "HASHCal" and "HASHroot" are completely identical, it indicates that the entire firmware package, from generation and transmission to local assembly by ECU_SLAVE, has not been tampered with, and the firmware is legitimate and complete. Signature verification passes, and the firmware upgrade by ECU_SLAVE is successful. If the two are inconsistent, it indicates that an error or tampering occurred in the firmware at some stage (transmission, writing, or local hash value storage), signature verification fails, and the upgrade is aborted.

[0044] The specific embodiments of the present invention have been described above. Based on the above description, those skilled in the art can make various changes and modifications without departing from the technical concept of the present invention.

Claims

1. A method for signing and verifying automotive ECU firmware, characterized in that, include: S1 firmware segmentation: The compiled ECU binary firmware is divided into multiple data code segments according to address and data code; S2 segmented hash calculation and signing: The hash value is calculated independently for each data code segment, and then the hash values ​​of all segments are hashed to generate an overall root hash value HASHroot. The root hash value HASHroot is signed using the private key to obtain the signature information. S3 segmented transmission and local signature verification: ECU_MASTER sends data code segments and corresponding hash values ​​to ECU_SLAVE segment by segment. After receiving each data code segment, ECU_SLAVE immediately recalculates the hash value of each segment and compares it with the received original root hash value. If they match, the signature verification is successful. ECU_SLAVE writes the data code segment to the specified address and saves its corresponding hash value. S4 ECU_SLAVE root hash value recalculation and verification: After all data code segments are transmitted and verified locally, ECU_SLAVE uses all the independent hash values ​​stored locally to recalculate a root hash value HASHCal. ECU_MASTER sends the signature information, and ECU_SLAVE uses the public key to decrypt and obtain the original root hash value HASHroot. ECU_SLAVE compares HASHCal with HASHroot; if they match, the signature verification passes and the upgrade is successful; otherwise, the signature verification fails.

2. The method for signing and verifying automotive ECU firmware according to claim 1, characterized in that, In the firmware segmentation process, data from consecutive addresses are merged into a single data code segment, and the size of the data code segment does not exceed the processing and storage capacity of ECU_SLAVE.

3. The method for signing and verifying automotive ECU firmware according to claim 1, characterized in that, The segmented transmission and local signature verification use the SHA256 algorithm to calculate the hash value of each data segment and the root hash value.

4. The method for signing and verifying automotive ECU firmware according to claim 1, characterized in that, The segmented transmission and local signature verification use the RSA2048 algorithm to sign the root hash value.

5. The method for signing and verifying automotive ECU firmware according to claim 1, characterized in that, ECU_MASTER and ECU_SLAVE communicate via CAN, CANFD, or LIN bus.

6. The signing and verification method for automotive ECU firmware according to claim 1, characterized in that, The ECU_SLAVE is a small storage space ECU, and the entire signature verification process is executed locally in the ECU_SLAVE.

Images