Vehicle-mounted controller firmware authentication information generation method, startup verification method and device

Abstract

The application provides a vehicle-mounted controller firmware authentication information generation method, a starting verification method and device, and the generation method comprises the following steps: dividing a binary data stream of a to-be-authenticated firmware, calculating block hash values of each block; sequentially splicing the physical starting address, block length and block hash value of the block to obtain a flattened block directory; obtaining the starting physical storage address and physical storage length of the flattened block directory, and obtaining a combined byte stream based on the same, and calculating a global root hash value of the combined byte stream; writing the starting physical storage address, physical storage length and global root hash value into the first area of the firmware header in the ASCII format; and generating a double signature based on the global root hash value and a development private key and a mass production private key respectively, and writing the double signature into an independent area of the firmware header. The application improves the security and productization efficiency of the vehicle-mounted controller firmware.

Description

Technical Field

[0001] This invention relates to the field of firmware verification technology, specifically to a method for generating firmware authentication information for an on-board controller, a startup verification method, and an apparatus. Background Technology

[0002] As the core control unit of a vehicle, the firmware security of the in-vehicle controller is directly related to vehicle driving safety and the safety of users' lives and property. With the continuous improvement of vehicle intelligence and connectivity, the attack surface faced by in-vehicle controller firmware is expanding, and the security authentication issues during firmware storage and loading have become a key research focus in the field of vehicle security.

[0003] Existing firmware authentication schemes for vehicle controllers, such as the Chinese invention patent CN120491895A, perform hierarchical verification by constructing a hash tree after dividing the firmware into blocks and distributing each block across multiple nodes. Verification is then performed by aggregating the hash values ​​calculated by each node. While this scheme achieves firmware block verification, its hash tree structure requires hierarchical aggregation and recursive operations across multiple distributed nodes, resulting in significant hierarchical parsing overhead. Furthermore, it primarily targets multi-device networking scenarios and is difficult to directly adapt to the resource-constrained embedded environment of a single vehicle controller node. In addition, this scheme does not address the binding of firmware blocks to physical storage addresses, making it unable to defend against substitution attacks targeting specific storage addresses. Moreover, existing firmware authentication schemes for vehicle controllers do not consider the key isolation and independent signing requirements during the firmware development and mass production stages. This necessitates recompiling or resigning the entire firmware when transitioning from the development stage to the mass production stage, hindering development version traceability and mass production switchover efficiency.

[0004] Therefore, there is an urgent need to provide a method for generating firmware authentication information and a startup verification method for vehicle controllers. This method can construct a flat firmware directory bound to the physical storage address to reduce the parsing overhead of the vehicle controller and defend against address substitution attacks. Furthermore, by having R&D signatures and mass production signatures that coexist independently and do not overlap in the same firmware, a seamless and secure transition between the R&D and mass production stages can be achieved. Summary of the Invention

[0005] In view of this, it is necessary to provide a method for generating firmware authentication information for vehicle controllers, a startup verification method and device, to solve the technical problems in the prior art, such as high overhead of firmware verification level parsing, inability to defend against address substitution attacks due to the lack of binding between firmware content and storage address, and the need to recompile firmware for key switching during the R&D and mass production stages.

[0006] To address the aforementioned technical problems, in a first aspect, the present invention provides a method for generating firmware authentication information for an onboard controller, comprising: The binary data stream of the firmware to be authenticated is divided into blocks to obtain multiple blocks, and the block hash value of each block is calculated using the SHA256 algorithm. The physical starting address, block length, and block hash value of the block are concatenated sequentially to obtain a flattened block directory; Obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream, and use the SHA256 algorithm to calculate the global root hash value of the combined byte stream; The starting physical storage address, the physical storage length, and the global root hash value are written into the first area of ​​the firmware header in ASCII format. The global root hash value is signed based on the R&D private key and the mass production private key respectively to generate an R&D signature and a mass production signature. The R&D signature is written into the first field of the second region of the firmware header, and the mass production signature is written into the second field of the second region in an append manner. The first region and the second region are independent of each other, and the first field and the second field are independent of each other.

[0007] In one possible implementation, the binary data stream of the firmware to be authenticated is divided into blocks to obtain multiple blocks, including: The block granularity is determined based on the erasure and write characteristics of automotive flash memory and the memory addressing characteristics. The binary data stream is continuously and non-overlappingly divided into blocks based on the block granularity to obtain multiple blocks.

[0008] In one possible implementation, the step of performing continuous, non-overlapping segmentation of the binary data stream based on the segmentation granularity to obtain multiple blocks includes: The ratio of the total length of the binary data stream to the block granularity is rounded up to obtain the initial number of blocks N; The total length of the first N-1 blocks is calculated based on the block granularity, the loading base address of the firmware to be certified, and the physical start address of the block. Calculate the difference between the total length of the binary data stream and the total length of the block. When the difference is equal to zero, remove the Nth block and determine the total number of blocks as N-1.

[0009] In one possible implementation, calculating the block hash value of each block using the SHA256 algorithm includes: Extract the service payload data of the block, calculate the data hash value of the service payload data using the SHA256 algorithm, and use the data hash value as the block hash value.

[0010] In one possible implementation, the combined byte stream has a partitioning interval of greater than or equal to a preset byte size between the combined storage area in the firmware header and the code storage area where the firmware code is located.

[0011] Secondly, the present invention also provides a method for firmware boot verification of an on-board controller, comprising: When the vehicle controller firmware is powered on, the firmware header is parsed to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format; Based on the starting physical storage address and the physical storage length, the original data of the flattened block directory is read from the flash memory. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated. If the number of bytes in the original data is equal to the physical storage length, then the starting physical storage address, the physical storage length, and the original data are concatenated into a byte string in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream to be verified. The root hash value of the combined byte stream to be verified is calculated using the SHA256 algorithm. If the root hash value to be verified is inconsistent with the global root hash value, then the verification is determined to fail and the startup is terminated. If the root hash value to be verified is consistent with the global root hash value, the original data is parsed to extract the physical start address, block length, and block hash value of each block. Based on the physical start address and block length of each block, the payload data of each block is read from the flash memory one by one. The SHA256 algorithm is used to calculate the hash value of the block to be verified of the payload data. The hash value of the block to be verified is compared with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated. If the hash values ​​of all blocks pass the comparison, the key status flag of the vehicle controller is read; if the key status flag is a first preset value, a preset R&D public key is obtained, and the R&D signature is read from the first field of the second area of ​​the firmware header, and the R&D signature is verified using the R&D public key; if the key status flag is a second preset value, a preset mass production public key is obtained, and the mass production signature is read from the second field of the second area of ​​the firmware header, and the mass production signature is verified using the mass production public key; if the verification result is unsuccessful, the verification is deemed to have failed and the startup is terminated; if the verification result is successful, the vehicle controller firmware is allowed to start and execute the application. The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method described in any of the above possible implementations.

[0012] In one possible implementation, the raw data further includes a hash algorithm version identifier and the total number of blocks; then, before reading the payload data of each block one by one from the flash memory according to the physical start address and block length of each block, the method further includes: Determine whether the hash algorithm version identifier is a preset valid value and whether the total number of blocks is consistent with the actual total number of the multiple blocks; Then, based on the physical start address and block length of each block, the payload data of each block is read sequentially from the flash memory, including: When the version identifier is a preset valid value and the total number of blocks is consistent with the actual total number of the multiple blocks, the payload data of each block is read from the flash memory one by one according to the physical starting address and block length of each block.

[0013] In one possible implementation, the research and development public key is pre-installed in a one-time programmable memory. The one-time programmable memory is programmed and hardware locked when the chip leaves the factory, prohibiting external read, write, erase or modification operations. After reading the key status flag of the vehicle controller, the following is also included: If the key status flag is the first preset value, then all external key reading commands are blocked, and the R&D public key is prohibited from being provided to external parties; If the key status flag is the second preset value, then the public key hash value reading interface is opened. When an external key reading request is received, only the hash value of the mass-produced public key is returned, and reading the original modulus and exponent data of the mass-produced public key is prohibited.

[0014] Thirdly, the present invention also provides an apparatus for generating firmware authentication information for an on-board controller, comprising: The block hash calculation unit is used to divide the binary data stream of the firmware to be authenticated into blocks to obtain multiple blocks, and to calculate the block hash value of each block using the SHA256 algorithm. A block directory construction unit is used to sequentially concatenate the physical starting address, block length, and block hash value of the block to obtain a flattened block directory; The global hash calculation unit is used to obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address-physical storage length-flattened block directory to obtain a combined byte stream, and calculate the global root hash value of the combined byte stream using the SHA256 algorithm. Storage unit, used to write the starting physical storage address, the physical storage length and the global root hash value into the first area of ​​the firmware header in ASCII format; The dual-signature generation unit is used to sign the global root hash value based on the R&D private key and the mass production private key respectively, generate an R&D signature and a mass production signature, and write the R&D signature into the first field of the second region of the firmware header, and write the mass production signature into the second field of the second region in an append manner. The first region and the second region are independent of each other, and the first field and the second field are independent of each other.

[0015] Fourthly, the present invention also provides a vehicle controller firmware boot verification device, comprising: The firmware header parsing unit is used to parse the firmware header after the vehicle controller firmware is powered on to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format. An initial verification unit is used to read the original data of the flattened block directory from the flash memory according to the starting physical storage address and the physical storage length. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated. The first-level verification unit is used to concatenate the starting physical storage address, the physical storage length, and the original data into a byte string according to a fixed order of starting physical storage address - physical storage length - flattened block directory when the number of data bytes of the original data is equal to the physical storage length, to obtain a combined byte stream to be verified, and to calculate the root hash value of the combined byte stream to be verified using the SHA256 algorithm. When the root hash value to be verified is inconsistent with the global root hash value, the verification is determined to be unsuccessful and the startup is terminated. The second-layer verification unit is used to parse the original data and extract the physical start address, block length, and block hash value of each block when the root hash value to be verified is consistent with the global root hash value; according to the physical start address and block length of each block, the payload data of each block is read from the flash memory one by one, the SHA256 algorithm is used to calculate the hash value of the block to be verified of the payload data, and the hash value of the block to be verified is compared with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated. The third-layer verification unit is used to read the key status flag of the vehicle controller when the hash values ​​of all blocks pass the comparison; if the key status flag is a first preset value, a preset R&D public key is obtained, and the R&D signature is read from the first field of the second area of ​​the firmware header, and the R&D signature is verified using the R&D public key; if the key status flag is a second preset value, a preset mass production public key is obtained, and the mass production signature is read from the second field of the second area of ​​the firmware header, and the mass production signature is verified using the mass production public key; if the verification result is unsuccessful, the verification is determined to be unsuccessful and the startup is terminated; if the verification result is successful, the vehicle controller firmware is allowed to start and execute the application. The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method described in any of the above possible implementations.

[0016] The beneficial effects of this invention are as follows: The vehicle controller firmware authentication information generation method provided by this invention adopts a flat structure that sequentially splices physical start address-block length-block hash value triples to construct a flat block directory, replacing the multi-level recursive summary structure of the traditional hash tree. This allows the verification end to complete the directory parsing without performing hierarchical traversal and recursive operations when parsing the directory. It only needs to read the verification information of each block in order according to a fixed offset to complete the directory parsing, which significantly reduces the directory parsing overhead of the vehicle controller during firmware startup and is suitable for embedded environments with single nodes and limited resources in the vehicle controller.

[0017] Furthermore, this invention calculates a global root hash value by concatenating the starting physical storage address, physical storage length, and original directory data in a fixed order. This global root hash value is then bound to both the directory content and its physical storage location. When an attacker attempts to migrate the authentication information directory to another storage address, the change in physical storage address will directly cause the global root hash value calculation to fail. This effectively defends against firmware replacement attacks targeting specific storage addresses and overcomes the shortcomings of existing solutions that only perform hash verification on firmware data content and cannot detect address changes.

[0018] Furthermore, this invention sets up independent first and second fields in the second region of the firmware header to store the R&D signature and mass production signature respectively. Since the first and second fields are independent of each other, when the firmware transitions from the R&D stage to the mass production stage, only the mass production signature needs to be appended to the second field. There is no need to recompile or re-sign the complete firmware. This not only preserves the traceability of the R&D version, but also achieves independent control of the key in the mass production stage, effectively improving the efficiency of the transition from R&D to mass production. Attached Figure Description

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

[0020] Figure 1 A schematic flowchart of an embodiment of the vehicle controller firmware authentication information generation method provided by the present invention; Figure 2 This is a schematic diagram of an embodiment of the present invention, which divides the binary data stream of the firmware to be authenticated into blocks to obtain multiple blocks. Figure 3 For the present invention Figure 2 A schematic diagram of an embodiment of step S202; Figure 4 A schematic flowchart of an embodiment of the vehicle controller firmware startup verification method provided by the present invention; Figure 5 A schematic diagram of an embodiment of the vehicle controller firmware authentication information generation device provided by the present invention; Figure 6 This is a schematic diagram of an embodiment of the vehicle controller firmware startup verification device provided by the present invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0022] It should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this invention illustrate operations implemented according to some embodiments of the invention. It should be understood that the operations in the flowcharts may be implemented out of order, and steps without logical contextual relationships may be reversed or performed simultaneously. Furthermore, those skilled in the art, guided by the content of this invention, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] This invention provides a method for generating firmware authentication information for an on-board controller, a method for verifying startup, and an apparatus, which are described below.

[0025] Figure 1 This is a schematic flowchart of an embodiment of the vehicle controller firmware authentication information generation method provided by the present invention, as shown below. Figure 1 As shown, the method for generating vehicle controller firmware authentication information includes: S101. Divide the binary data stream of the firmware to be authenticated into blocks to obtain multiple blocks, and use the SHA256 algorithm to calculate the block hash value of each block.

[0026] This invention improves the accuracy of location during subsequent verification by performing block hashing on the binary data stream of the firmware to be authenticated. Specifically, if the entire binary data stream is hashed as a whole, the verification failure will only reveal that the firmware has been tampered with. Block hashing, on the other hand, can accurately locate the specific address range of the firmware that has been tampered with by comparing each block during verification, providing a basis for subsequent fault isolation, firmware rollback, or targeted repair.

[0027] S102. Concatenate the physical starting address, block length, and block hash value of the block in sequence to obtain a flattened block directory.

[0028] It should be noted that the flattened block directory also includes the version identifier of the hash algorithm and the total number of blocks. Specifically, the version identifier is 2 bytes, the total number of blocks is 2 bytes, and the physical start address, block length, and block hash value form a triple: physical start address - block length - block hash value. The physical start address is 4 bytes, the block length is 4 bytes, and the block hash value is 32 bytes, for a total of 40 bytes.

[0029] The formula for calculating the total directory length LAIC_raw of a flattened block directory is: LAIC_raw=2+2+N×(4+4+32)=4+40N; In the formula, N is the total number of blocks.

[0030] It should also be noted that the flat block directory generation process does not involve compression, encryption, or zero-byte padding to avoid hash avalanche effects and ensure that the hash calculation results before and after are reproducible.

[0031] S103. Obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream, and use the SHA256 algorithm to calculate the global root hash value of the combined byte stream.

[0032] Specifically, the expression for combining byte streams is: Concat_Data=AddrAIC_target∥LenAIC_target∥AICRaw_Data; The expression for the global root hash value is: AICHash=SHA256(AddrAIC_target∥LenAIC_target∥AICRaw_Data); In the formula, Concat_Data is the combined byte stream; AddrAIC_target is the physical storage address; LenAIC_target is the physical storage length; AICRaw_Data is the flattened block directory; ∥ is the byte string concatenation operator; and AICHash is the global root hash value.

[0033] S104. Write the starting physical storage address, physical storage length, and global root hash value into the first area of ​​the firmware header in ASCII format.

[0034] Specifically, during the writing of the first area of ​​the firmware header, no newlines, spaces, or escape characters are added, matching the native parsing syntax of the Bootloader.

[0035] Specifically, the format of the configuration field in the first region of the firmware header that writes the starting physical storage address, physical storage length, and global root hash value is fixed as follows: {abt_start=0xXXXXXXXX;abt_length=0xXXXXXXXX;abt_hash=0xYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY}; In the formula, abt_start is the write field for the starting physical storage address; abt_length is the write field for the physical storage length; and abt_hash is the write field for the global root hash value.

[0036] Among them, the starting physical storage address and physical storage length fields are 8-bit hexadecimal (corresponding to 4 bytes of storage), and the global root hash value field is 64-bit hexadecimal (corresponding to 32 bytes of storage).

[0037] S105. Sign the global root hash value based on the R&D private key and the mass production private key respectively to generate the R&D signature and the mass production signature. Write the R&D signature into the first field of the second area of ​​the firmware header and write the mass production signature into the second field of the second area in an append manner. The first area and the second area are independent of each other, and the first field and the second field are independent of each other.

[0038] In some embodiments of the present invention, the cryptographic suite used in the signing process adopts the RSA2048 algorithm and the RSASA-PSS-SHA256 signature scheme, strictly follows the PKCS#1 v2.2 industry standard, has a fixed salt length of 32 bytes, and uses the MGF1-SHA256 mask generation function.

[0039] Complete calculation formulas for two independent signatures: dev_signature=RSASSA-PSS-SHA256(SKdev,AICHash,Salt=32,MGF1-SHA256); prod_signature=RSASSA-PSS-SHA256(SKprod,AICHash,Salt=32,MGF1-SHA256); In the formula, dev_signature is the R&D signature; prod_signature is the mass production signature; MGF1 is the mask generation function; Salt is the salt length; SKdev is the R&D private key; and SKprod is the mass production private key.

[0040] In this embodiment of the invention, only the 32-byte global root hash value AIC_Hash is used as the original signature, abandoning the mode of signing the complete firmware content, which significantly reduces the computing power consumption of the vehicle controller in performing signature verification during the startup phase.

[0041] It should be noted that after the firmware is mass-produced and solidified, Flash hardware write protection is enabled for the first area, prohibiting external diagnostic ports from rewriting the contents of the abt_start, abt_length, and abt_hash fields to prevent the verification parameters from being maliciously tampered with.

[0042] It should also be noted that the starting physical storage address, physical storage length, and global root hash value in the first area, along with the R&D signature in the first field and the mass production signature in the second field of the second area, together constitute the verification information area of ​​the firmware header. This verification information area, along with the raw data of the flattened block directory, is appended to the firmware payload data or at the corresponding location to form a complete vehicle controller firmware binary file. The verification information area provides a complete verification benchmark and authentication basis for the firmware's trusted authentication during vehicle controller startup.

[0043] It should be understood that the vehicle controller firmware authentication information generation method in this embodiment of the invention can be implemented in any system aimed at trusted authentication of vehicle controller firmware, such as vehicle controller development toolchain systems, production line firmware signing servers, ECU firmware compilation and packaging systems, and other electronic devices. Specifically, the vehicle controller firmware authentication information generation method is pre-stored in the memory of the aforementioned electronic device in the form of a computer program. When the processor executes the computer program, it generates a firmware binary file carrying an authentication information directory, a global root hash value, and dual signature information, providing a foundation for the secure startup and trusted verification of the vehicle controller throughout its entire lifecycle.

[0044] Compared with existing technologies, the vehicle controller firmware authentication information generation method provided in this embodiment of the invention adopts a flat structure that sequentially splices physical start address-block length-block hash value triples to construct a flat block directory, replacing the multi-level recursive summary structure of the traditional hash tree. This allows the verification end to complete the directory parsing without performing hierarchical traversal and recursive operations when parsing the directory. It only needs to read the verification information of each block in order according to a fixed offset to complete the directory parsing, which significantly reduces the directory parsing overhead of the vehicle controller during firmware startup and is suitable for embedded environments with single nodes and limited resources of the vehicle controller.

[0045] Furthermore, in this embodiment of the invention, the global root hash value is calculated by concatenating the starting physical storage address, physical storage length, and original directory data in a fixed order. This allows the global root hash value to be bound to both the directory content and its physical storage location. When an attacker attempts to migrate the authentication information directory to another storage address, the change in physical storage address will directly cause the global root hash value calculation to fail. This effectively defends against firmware replacement attacks targeting specific storage addresses and overcomes the shortcomings of existing solutions that only perform hash verification on firmware data content and cannot detect address changes.

[0046] Furthermore, this embodiment of the invention sets up a first field and a second field, which are independent of each other, in the second region of the firmware header to store the R&D signature and the mass production signature, respectively. Since the first field and the second field are independent of each other, when the firmware transitions from the R&D stage to the mass production stage, only the mass production signature needs to be appended to the second field. There is no need to recompile or re-sign the complete firmware. This not only preserves the traceability of the R&D version, but also realizes independent control of the key in the mass production stage, effectively improving the efficiency of the transition from R&D to mass production.

[0047] In some embodiments of the present invention, such as Figure 2 As shown, in step S101, the binary data stream of the firmware to be authenticated is divided into blocks to obtain multiple blocks, including: S201. Determine the block granularity based on the vehicle flash memory erase / write characteristics and memory addressing characteristics.

[0048] Specifically, the write / erase characteristics of automotive flash memory include the smallest unit of automotive flash memory write operations. Memory addressing characteristics include: the address alignment requirements for the processor in the automotive controller to access flash memory addresses, that is, the target address of the read operation must meet specific alignment boundaries.

[0049] The block granularity can be any one of 256 bytes, 512 bytes, or 1024 bytes.

[0050] S202. Perform continuous, non-overlapping segmentation of the binary data stream based on the segmentation granularity to obtain multiple blocks.

[0051] This invention determines the block granularity based on the write and erase characteristics of automotive flash memory and memory addressing characteristics, thereby obtaining multiple blocks. This allows the block length to match the flash page size, avoiding reduced write efficiency and read anomalies caused by storing a single block across pages. At the same time, the block granularity matches the alignment boundary, satisfying the flash memory addressing alignment requirements and avoiding performance loss caused by non-aligned access. Thus, it enables efficient execution of firmware block verification in embedded environments with limited automotive controller resources.

[0052] In specific embodiments of the present invention, such as Figure 3 As shown, step S202 includes: S301. Round up the ratio of the total length of the binary data stream to the block granularity to obtain the initial number of blocks N.

[0053] Specifically, the initial number of blocks N is calculated as follows: N = [Ltotal / P]; [ ] is the round-up operator; Ltotal is the total length of the binary data stream; P is the block granularity.

[0054] S302. Calculate the total length of the first N-1 blocks based on the block granularity, the loading base address of the firmware to be certified, and the physical starting address of the block.

[0055] Specifically, the total length of the first N-1 blocks is LenN. 1 is: P×(N) 1).

[0056] S303. Calculate the difference between the total length of the binary data stream and the total length of the blocks. When the difference is equal to zero, remove the Nth block and determine the total number of blocks as N-1.

[0057] Specifically, when the difference between the total length of the binary data stream and the total length of the block is zero, it indicates that the Nth block is a zero-length empty block generated by firmware padding at the end.

[0058] This invention, by eliminating blocks that are determined to be empty blocks of zero length, can avoid invalid hash operations and further save MCU computing power.

[0059] It should be noted that all blocks strictly follow the 4-byte Flash basic alignment rule, with continuous addresses without gaps or overlaps, adapting to MCU direct memory addressing.

[0060] To further save computing power and improve the security of the vehicle controller firmware, in some embodiments of the present invention, step S101, which calculates the block hash value of each block using the SHA256 algorithm, includes: Extract the service payload data of the block, calculate the data hash value of the service payload data using the SHA256 algorithm, and use the data hash value as the block hash value.

[0061] This invention extracts only the service payload data within the block, without concatenating auxiliary metadata such as block address, length, and version number. On the one hand, this can further reduce the amount of data involved in hash operations and avoid the invalidation of MCU computing power. On the other hand, it can prevent attackers from bypassing the verification link by tampering with auxiliary metadata fields, thereby further improving the security of the vehicle controller firmware.

[0062] To prevent firmware tampering operations from overwriting the flattened block directory, in some embodiments of the present invention, there is a partition interval of greater than or equal to a preset byte size between the combined storage area of ​​the combined byte stream in the firmware header and the code storage area where the firmware code is located.

[0063] Specifically, the default byte size is 2KB.

[0064] This invention provides an independent storage partition in flash memory that is physically isolated from the firmware code partition for the flattened block directory, and maintains an address gap of no less than 2KB between the two partitions. This effectively prevents attackers from overwriting the flattened block directory when tampering with the firmware code partition due to cross-partition writing. At the same time, even if the firmware code area is abnormally erased or written out of bounds, the combined storage area where the flattened block directory is located can still maintain data integrity due to the address gap, providing a reliable source of directory data for subsequent boot verification, and further improving the survivability of the vehicle controller firmware when subjected to physical attacks or abnormal writes.

[0065] It should be noted that the actual storage length of the combined storage area strictly matches the size of the combined byte stream. That is, the actual storage length of the combined storage area is equal to the number of data bytes in the combined byte stream. It is not expanded or truncated to ensure that the length of the combined byte stream does not change during writing and reading, thus avoiding failure of subsequent root hash recalculation due to inconsistent length.

[0066] On the other hand, embodiments of the present invention also provide a method for firmware startup verification of an on-board controller, such as... Figure 4 As shown, the vehicle controller firmware startup verification method includes: S401. After the vehicle controller firmware is powered on, the firmware header is parsed to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format.

[0067] S402. Based on the starting physical storage address and physical storage length, read the original data of the flattened block directory from the flash memory. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated.

[0068] S403. If the number of bytes in the original data is equal to the physical storage length, then the starting physical storage address, physical storage length and original data are concatenated into a byte string according to the fixed order of starting physical storage address - physical storage length - flattened block directory to obtain the combined byte stream to be verified. The root hash value to be verified of the combined byte stream is calculated using the SHA256 algorithm. If the root hash value to be verified is inconsistent with the global root hash value, the verification is determined to fail and the startup is terminated.

[0069] S404. If the root hash value to be verified is consistent with the global root hash value, then parse the original data and extract the physical start address, block length and block hash value of each block; according to the physical start address and block length of each block, read the payload data of each block from the flash memory one by one, use the SHA256 algorithm to calculate the hash value of the block to be verified of the payload data, and compare the hash value of the block to be verified with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated.

[0070] S405. If the hash values ​​of all blocks pass the comparison, read the key status flag of the vehicle controller; if the key status flag is the first preset value, obtain the preset R&D public key, and read the R&D signature from the first field of the second area of ​​the firmware header, and use the R&D public key to verify the R&D signature; if the key status flag is the second preset value, obtain the preset mass production public key, and read the mass production signature from the second field of the second area of ​​the firmware header, and use the mass production public key to verify the mass production signature; if the verification result is unsuccessful, determine that the verification has failed and terminate the startup; if the verification result is successful, allow the vehicle controller firmware to start and execute the application.

[0071] The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method in any of the above embodiments.

[0072] This invention, through header information reading, flattened block directory restoration, and root hash recalculation comparison performed at the verification end, simultaneously verifies the integrity of the directory content and the authenticity of the storage location, effectively preventing attackers from migrating legitimate directories to other addresses to carry out address hijacking attacks. By recalculating the block-by-block payload hash and comparing it with the directory record value, even minor tampering at any location in the firmware code can be accurately located and intercepted. By reading the key status flag bit and automatically matching the corresponding R&D or mass production signature and public key for signature verification, the same firmware can seamlessly switch authentication strategies at different stages. If any step in the above multi-layer verification fails, the startup process is terminated, giving the firmware loading process a defense-in-depth capability and improving the startup security and reliability of the vehicle controller.

[0073] In specific embodiments of the present invention, the original data also includes a hash algorithm version representation and the total number of blocks. Therefore, to further improve startup security, in some embodiments of the present invention, before step S405, the following steps are also included: Determine whether the hash algorithm version identifier is a preset valid value and whether the total number of blocks is consistent with the actual total number of multiple blocks; Then step S405 includes: When the version identifier is a preset valid value and the total number of blocks is consistent with the actual total number of multiple blocks, the payload data of each block is read from the flash memory one by one according to the physical starting address and block length of each block.

[0074] This invention adds version identifier verification and total block count verification before block-by-block payload hash comparison. This ensures that firmware with mismatched algorithm versions or abnormal block counts is intercepted before entering hash calculation, avoiding the waste of MCU computing power from invalid block-by-block reading and hash calculation, improving verification efficiency. At the same time, it enhances the defense capability against directory structure-level tampering during the verification process, further strengthening the robustness and anti-attack capability of firmware startup verification.

[0075] In some embodiments of this invention, a 1-byte key state flag, KeyStateFlag, is set in the secure non-volatile storage area inside the ECU. Upon power-up, the chip is reset to 0x00 by default, corresponding to the R&D operation state. During the chip manufacturing process, the R&D public key PKdev (256-byte modulus + industry-fixed public index 0x00010001) is written to the OTP one-time programmable memory in a single operation. After writing, the hardware permanently locks read, write, erase, and rewrite permissions. Only the chip's internal signature verification kernel can access the public key; external systems and chip disassembly cannot extract the original public key text, thus eliminating the risk of R&D public key leakage and tampering from the hardware level.

[0076] It should be noted that: if the key status flag is at the first preset value, all external key reading commands are blocked, and the R&D public key is prohibited from being provided to external parties; if the key status flag is at the second preset value, the public key hash value reading interface is opened to external parties. When an external key reading request is received, only the hash value of the mass-produced public key is returned, and reading the original modulus and exponent data of the mass-produced public key is prohibited. Through this setting, the R&D state can completely block external key reading commands, while the mass production state follows the principle of least privilege and only opens the irreversible 32-byte public key hash reading interface. Relying on the one-way nature of SHA256 hash, even if the hash value is intercepted, it is impossible to deduce the original public key modulus. This effectively prevents attackers from using the leaked public key information to construct malicious firmware or implement signature forgery. Thus, while ensuring that the production line can verify the correctness of the public key burning, the exposure surface of key information is minimized, and the overall security of the vehicle controller key system is improved.

[0077] In summary, the embodiments of the present invention, by setting up a flat block directory bound to the physical storage address at the generation end, allowing independent coexistence and append writing of dual signatures, and setting up layered interception verification and key status linkage control at the verification end, form a complete and trusted chain from firmware authentication information generation to startup verification, which significantly improves the firmware security and productization efficiency of the vehicle controller.

[0078] On the other hand, embodiments of the present invention also provide a device for generating firmware authentication information for an on-board controller, such as... Figure 5 As shown, the vehicle controller firmware authentication information generation device 500 includes: The block hash calculation unit 501 is used to divide the binary data stream of the firmware to be authenticated into blocks, obtain multiple blocks, and calculate the block hash value of each block using the SHA256 algorithm. The block directory construction unit 502 is used to sequentially concatenate the physical starting address, block length and block hash value of the block to obtain a flattened block directory; The global hash calculation unit 503 is used to obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream, and calculate the global root hash value of the combined byte stream using the SHA256 algorithm. Storage unit 504 is used to write the starting physical storage address, physical storage length and global root hash value into the first area of ​​the firmware header in ASCII format; The dual signature generation unit 505 is used to sign the global root hash value based on the R&D private key and the mass production private key respectively, generate the R&D signature and the mass production signature, and write the R&D signature into the first field of the second area of ​​the firmware header, and write the mass production signature into the second field of the second area in an append manner. The first area and the second area are independent of each other, and the first field and the second field are independent of each other.

[0079] The vehicle controller firmware authentication information generation device 500 provided in the above embodiments can implement the technical solutions described in the above vehicle controller firmware authentication information generation method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above vehicle controller firmware authentication information generation method embodiments, and will not be repeated here.

[0080] On the other hand, embodiments of the present invention also provide a vehicle controller firmware boot verification device, such as... Figure 6 As shown, the vehicle controller firmware startup verification device 600 includes: The firmware header parsing unit 601 is used to parse the firmware header after the vehicle controller firmware is powered on to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format. The initial verification unit 602 is used to read the original data of the flattened block directory from the flash memory according to the starting physical storage address and the physical storage length. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated. The first-level verification unit 603 is used to concatenate the starting physical storage address, physical storage length and original data into a byte string according to the fixed order of starting physical storage address-physical storage length-flattened block directory when the number of data bytes of the original data is equal to the physical storage length, to obtain the combined byte stream to be verified, and to calculate the root hash value of the combined byte stream to be verified using the SHA256 algorithm. When the root hash value to be verified is inconsistent with the global root hash value, the verification is determined to be unsuccessful and the startup is terminated. The second-layer verification unit 604 is used to parse the original data and extract the physical start address, block length and block hash value of each block when the root hash value to be verified is consistent with the global root hash value; according to the physical start address and block length of each block, the payload data of each block is read from the flash memory one by one, the SHA256 algorithm is used to calculate the hash value of the block to be verified of the payload data, and the hash value of the block to be verified is compared with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated. The third-layer verification unit 605 is used to read the key status flag of the vehicle controller when the hash values ​​of all blocks pass the comparison; if the key status flag is a first preset value, it obtains a preset R&D public key and reads the R&D signature from the first field of the second area of ​​the firmware header, and performs signature verification on the R&D signature using the R&D public key; if the key status flag is a second preset value, it obtains a preset mass production public key and reads the mass production signature from the second field of the second area of ​​the firmware header, and performs signature verification on the mass production signature using the mass production public key; if the signature verification result is unsuccessful, it determines that the verification has failed and terminates the startup; if the signature verification result is successful, it allows the vehicle controller firmware to start and execute the application. The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method in any of the above embodiments.

[0081] The vehicle controller firmware startup verification device 600 provided in the above embodiments can implement the technical solutions described in the above vehicle controller firmware startup verification method embodiments. The specific implementation principles of each module or unit can be found in the corresponding content in the above vehicle controller firmware startup verification method embodiments, which will not be repeated here.

[0082] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.), and the computer program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0083] The present invention has provided a detailed description of a method for generating firmware authentication information for an on-board controller, a method for verifying startup, and an apparatus for doing so. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for generating firmware authentication information for an on-board controller, characterized in that, include: The binary data stream of the firmware to be authenticated is divided into blocks to obtain multiple blocks, and the block hash value of each block is calculated using the SHA256 algorithm. The physical starting address, block length, and block hash value of the block are concatenated sequentially to obtain a flattened block directory; Obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream, and use the SHA256 algorithm to calculate the global root hash value of the combined byte stream; The starting physical storage address, the physical storage length, and the global root hash value are written into the first area of ​​the firmware header in ASCII format. The global root hash value is signed based on the R&D private key and the mass production private key respectively to generate an R&D signature and a mass production signature. The R&D signature is written into the first field of the second region of the firmware header, and the mass production signature is written into the second field of the second region in an append manner. The first region and the second region are independent of each other, and the first field and the second field are independent of each other.

2. The method for generating vehicle controller firmware authentication information according to claim 1, characterized in that, The binary data stream of the firmware to be authenticated is divided into blocks to obtain multiple blocks, including: The block granularity is determined based on the erasure and write characteristics of automotive flash memory and the memory addressing characteristics. The binary data stream is continuously and non-overlappingly divided into blocks based on the block granularity to obtain multiple blocks.

3. The method for generating vehicle controller firmware authentication information according to claim 2, characterized in that, The binary data stream is continuously and non-overlappingly divided into multiple blocks based on the block granularity, including: The ratio of the total length of the binary data stream to the block granularity is rounded up to obtain the initial number of blocks N; The total length of the first N-1 blocks is calculated based on the block granularity, the loading base address of the firmware to be certified, and the physical start address of the block. Calculate the difference between the total length of the binary data stream and the total length of the block. When the difference is equal to zero, remove the Nth block and determine the total number of blocks as N-1.

4. The method for generating vehicle controller firmware authentication information according to claim 1, characterized in that, The calculation of the block hash value of each block using the SHA256 algorithm includes: Extract the service payload data of the block, calculate the data hash value of the service payload data using the SHA256 algorithm, and use the data hash value as the block hash value.

5. The method for generating vehicle controller firmware authentication information according to claim 1, characterized in that, The combined byte stream has a partitioning interval of greater than or equal to a preset byte size between the combined storage area in the firmware header and the code storage area where the firmware code is located.

6. A method for firmware startup verification of an on-board controller, characterized in that, include: When the vehicle controller firmware is powered on, the firmware header is parsed to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format; Based on the starting physical storage address and the physical storage length, the original data of the flattened block directory is read from the flash memory. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated. If the number of bytes in the original data is equal to the physical storage length, then the starting physical storage address, the physical storage length, and the original data are concatenated into a byte string in a fixed order of starting physical storage address - physical storage length - flattened block directory to obtain a combined byte stream to be verified. The root hash value of the combined byte stream to be verified is calculated using the SHA256 algorithm. If the root hash value to be verified is inconsistent with the global root hash value, then the verification is determined to fail and the startup is terminated. If the root hash value to be verified is consistent with the global root hash value, the original data is parsed to extract the physical start address, block length, and block hash value of each block. Based on the physical start address and block length of each block, the payload data of each block is read from the flash memory one by one. The SHA256 algorithm is used to calculate the hash value of the block to be verified of the payload data. The hash value of the block to be verified is compared with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated. If the hash values ​​of all blocks pass the comparison, then read the key status flag of the vehicle controller; If the key status flag is a first preset value, then the preset R&D public key is obtained, and the R&D signature is read from the first field of the second area of ​​the firmware header. The R&D signature is then verified using the R&D public key. If the key status flag is a second preset value, the preset mass production public key is obtained, and the mass production signature is read from the second field of the second area of ​​the firmware header. The mass production signature is verified using the mass production public key. If the verification result is unsuccessful, the verification is determined to be unsuccessful and the startup is terminated. If the verification result is successful, the vehicle controller firmware is allowed to start and execute the application. The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method described in any one of claims 1-5.

7. The vehicle controller firmware boot verification method according to claim 6, characterized in that, The raw data also includes a hash algorithm version identifier and the total number of blocks; therefore, before reading the payload data of each block from the flash memory one by one according to the physical starting address and block length of each block, the process further includes: Determine whether the hash algorithm version identifier is a preset valid value and whether the total number of blocks is consistent with the actual total number of the multiple blocks; Then, based on the physical start address and block length of each block, the payload data of each block is read sequentially from the flash memory, including: When the version identifier is a preset valid value and the total number of blocks is consistent with the actual total number of the multiple blocks, the payload data of each block is read from the flash memory one by one according to the physical starting address and block length of each block.

8. The vehicle controller firmware boot verification method according to claim 6, characterized in that, The research and development public key is pre-installed in a one-time programmable memory. The one-time programmable memory is programmed and hardware locked when the chip leaves the factory, prohibiting external read, write, erase or modification operations. After reading the key status flag of the vehicle controller, the following is also included: If the key status flag is the first preset value, then all external key reading commands are blocked, and the R&D public key is prohibited from being provided to external parties; If the key status flag is the second preset value, then the public key hash value reading interface is opened. When an external key reading request is received, only the hash value of the mass-produced public key is returned, and reading the original modulus and exponent data of the mass-produced public key is prohibited.

9. A device for generating firmware authentication information for an on-board controller, characterized in that, include: The block hash calculation unit is used to divide the binary data stream of the firmware to be authenticated into blocks to obtain multiple blocks, and to calculate the block hash value of each block using the SHA256 algorithm. A block directory construction unit is used to sequentially concatenate the physical starting address, block length, and block hash value of the block to obtain a flattened block directory; The global hash calculation unit is used to obtain the starting physical storage address and physical storage length of the flattened block directory, concatenate the byte strings in a fixed order of starting physical storage address-physical storage length-flattened block directory to obtain a combined byte stream, and calculate the global root hash value of the combined byte stream using the SHA256 algorithm. Storage unit, used to write the starting physical storage address, the physical storage length and the global root hash value into the first area of ​​the firmware header in ASCII format; The dual-signature generation unit is used to sign the global root hash value based on the R&D private key and the mass production private key respectively, generate an R&D signature and a mass production signature, and write the R&D signature into the first field of the second region of the firmware header, and write the mass production signature into the second field of the second region in an append manner. The first region and the second region are independent of each other, and the first field and the second field are independent of each other.

10. A vehicle controller firmware boot verification device, characterized in that, include: The firmware header parsing unit is used to parse the firmware header after the vehicle controller firmware is powered on to obtain the starting physical storage address, physical storage length and global root hash value in ASCII format. An initial verification unit is used to read the original data of the flattened block directory from the flash memory according to the starting physical storage address and the physical storage length. If the number of data bytes of the original data is not equal to the physical storage length, the verification is determined to fail and the startup is terminated. The first-level verification unit is used to concatenate the starting physical storage address, the physical storage length, and the original data into a byte string according to a fixed order of starting physical storage address - physical storage length - flattened block directory when the number of data bytes of the original data is equal to the physical storage length, to obtain a combined byte stream to be verified, and to calculate the root hash value of the combined byte stream to be verified using the SHA256 algorithm. When the root hash value to be verified is inconsistent with the global root hash value, the verification is determined to be unsuccessful and the startup is terminated. The second-layer verification unit is used to parse the original data and extract the physical start address, block length, and block hash value of each block when the root hash value to be verified is consistent with the global root hash value; according to the physical start address and block length of each block, the payload data of each block is read from the flash memory one by one, the SHA256 algorithm is used to calculate the hash value of the block to be verified of the payload data, and the hash value of the block to be verified is compared with the corresponding block hash value in the flattened block directory block by block. If the hash value of any block is inconsistent, the verification is determined to be unsuccessful and the startup is terminated. The third-layer verification unit is used to read the key status flag of the vehicle controller when the hash values ​​of all blocks pass the comparison. If the key status flag is a first preset value, then the preset R&D public key is obtained, and the R&D signature is read from the first field of the second area of ​​the firmware header. The R&D signature is then verified using the R&D public key. If the key status flag is a second preset value, the preset mass production public key is obtained, and the mass production signature is read from the second field of the second area of ​​the firmware header. The mass production signature is verified using the mass production public key. If the verification result is unsuccessful, the verification is determined to be unsuccessful and the startup is terminated. If the verification result is successful, the vehicle controller firmware is allowed to start and execute the application. The starting physical storage address, physical storage length, and global root hash value in ASCII format are generated by the vehicle controller firmware authentication information generation method described in any one of claims 1-5.

Images