A secure boot method and system based on HSM double digest delayed submission

Abstract

A secure starting method and system based on HSM double-digest delay submission, the method is applied to a vehicle-mounted controller with a hardware security module and a physical double-Bank flash, comprising: logically dividing an active digest area and a candidate digest area in an HSM isolated secure nonvolatile memory; writing a new version of Bootloader into a standby Bank during self-update and setting a trial starting flag to trigger a hardware Bank Swap; entering a double-digest verification mode after reset, and passing through any digest matching; after the new version of Bootloader starts successfully and passes through self-checking, actively calling an HSM interface by the new version of Bootloader to perform delay submission; if starting fails, automatically falling back to the original Bank to restore a single-digest verification mode. The application completely eliminates the risk of double-locking through the hardware linkage of physical double-Bank and HSM double-digest slots, the delay trust anchor update mechanism of two-stage submission, the version counter anti-downgrade verification and the state mirror redundancy guarantee, while ensuring the flexibility of Bootloader upgrade, and improves the information security protection capability and upgrade robustness of the vehicle-mounted controller.

Description

Technical Field

[0001] This invention belongs to the technical field of information security and functional safety of vehicle controllers, and particularly relates to a secure startup method and system based on HSM double digest delayed submission. Background Technology

[0002] With the continuous development of intelligent driving and smart cockpits, in-vehicle ECUs are becoming increasingly centralized and networked. ECUs can communicate directly with each other via Ethernet and also with the outside world via V2X technology, effectively opening up numerous communication channels between the vehicle and the outside world. If the software running in the ECU is suddenly tampered with or controlled by hackers during driving, it will greatly affect driving safety. To address this, regulations and standards such as UNECE R155 and ISO / SAE 21434 have clearly defined firmware integrity protection as a fundamental element of cybersecurity management systems, requiring ECUs to establish a complete trust chain during the startup phase to nip hacker tampering in the bud.

[0003] The core idea of ​​Secure Boot technology is to use a Hardware Security Module (HSM) as the root of trust, and leverage an independent cryptographic acceleration engine within the HSM (AES-CMAC, RSA / ECC, SHA, etc.) to perform step-by-step integrity checks on the Bootloader and application (App), forming a trust chain from ROM to Bootloader to App. As a secure island physically isolated from the main kernel, the HSM's key storage and cryptographic operations are not visible to the outside world, ensuring the security of password storage and guaranteeing boot timeliness through hardware acceleration. Secure Boot typically includes two parts: secure boot of the Bootloader and secure boot of the App.

[0004] Traditional bootloader secure boot schemes typically employ the following mechanism: Upon initial power-up of the ECU, the bootloader code is executed first. Before receiving a flashing tool command to perform a flashing operation, a secure boot verification of the bootloader is performed. Flashing only proceeds after confirming the current bootloader is reliable and trustworthy; otherwise, a reset is executed. The trust anchor is established in the HSM based on the CMAC value generated through AES-CMAC verification using the initially flashed bootloader code and verification range. This value is securely protected and stored by the HSM and cannot be erased or rewritten by the flashing device.

[0005] The above solution presents an irreconcilable contradiction between security and ease of production: Because the CMAC value stored in the HSM is only generated during the initial flashing after the secure boot function is activated in the final stage of factory production, subsequent flashing does not recalculate and generate it based on the re-flashed bootloader. This means that if a bootloader defect is discovered and re-flashing is required, the upgraded bootloader will fail the secure boot verification and cannot start, necessitating a reversion to the original code. This is the long-standing problem in this technical field of balancing security and ease of production.

[0006] For secure app startup, the industry standard is to flash the app during the production phase using an information security refresh process. After successful flashing, the bootloader uses AES-CMAC or a hash algorithm to calculate a checksum across the entire app's code area, storing it in non-volatile memory (NVM) or a security module (such as ICU-S). Subsequently, after each power-on or reset, the checksum is recalculated and compared with the previously stored value before launching the app. If they match, the app runs; otherwise, it remains under the bootloader and only performs the refresh function.

[0007] The solution has the following prominent problems: If the Hash calculation of the App is implemented through software, the calculation speed is slow and the time consumption is long (up to tens of seconds depending on the code size), which seriously affects the overall refresh efficiency; if the Hash value is stored in NVM, the security is low and it is easy to be erased, which does not meet the information security requirements; if it is stored through the security module ICU-S, each time the Hash value is updated, an update counter needs to be passed in, and this counter depends on the main core to accumulate in NVM, which is easy to be erased, thus causing the entire secure boot function to fail.

[0008] To address the aforementioned shortcomings in Bootloader self-updating and secure App startup, existing technologies propose a secure startup method based on HSM secure hardware support. The improvements include: A copy of the Bootloader2 transport code, relocated to the App code segment and with HSM interaction removed, is made on the Bootloader code side. A Boot manager module is added to the original Bootloader. The Bootloader' to be updated is compiled and offset, then merged with Bootloader2 into a self-updating refresh file. After the self-updating file is verified by the certificate chain and signature, it is written to the App's CODE FLASH area. After reset, Bootloader2 erases the original Bootloader area except for the Boot manager, and then writes Bootloader'. After completion, the secure boot table is reset and CMAC is recalculated through HSM. For secure boot of the App, after the refresh is completed, HSM calculates the App's Hash1 and stores it in the HSM's dedicated DataFlash. For each subsequent boot, HSM calculates Hash2 and compares it with Hash1.

[0009] While this solution addresses the security verification issue of Bootloader self-updates to some extent, its technical approach still has the following limitations: The trust anchor is updated prematurely, lacking fault tolerance buffer. If the new bootloader exposes defects during subsequent operation or fails to start due to abnormal environment, the original bootloader's CMAC has been overwritten, and the old version cannot be rolled back to start, posing a risk of "two-way deadlock".

[0010] The hardware characteristics of the physical dual-bank Flash were not fully utilized, and the hardware bank swap mechanism of the MCU's physical dual-bank Flash was not used, which made it impossible for the old and new versions to coexist physically in parallel during the upgrade process. The rollback path completely relied on the main core software's rollback logic, resulting in insufficient robustness.

[0011] The lack of a downgrade prevention mechanism means that when faced with attackers flashing back to an older firmware version with known vulnerabilities, it cannot be rejected at the trust chain level, which does not comply with the mandatory requirements for rollback prevention in regulations such as UNECE R155.

[0012] The system lacks sufficient state consistency guarantees and is prone to state loss in the event of an unexpected power outage, causing the system state machine to enter an unknown state. It also lacks a mirror redundancy mechanism between HSM DataFlash and Retain RAM. Summary of the Invention

[0013] Therefore, it is necessary to provide a secure boot method and system based on HSM double digest delayed submission to address the above-mentioned technical problems, so as to eliminate the risk of bidirectional lock-up while ensuring the flexibility of bootloader upgrades, and improve the information security protection capability and upgrade robustness of the vehicle controller.

[0014] In a first aspect, this application provides a secure boot method based on HSM dual digest delayed submission, applied to an on-board controller with a hardware security module (HSM) and physical dual-bank Flash, comprising: In the isolated secure non-volatile memory of the HSM, two independent digest slots are logically divided: the active digest area Active_MAC and the candidate digest area Candidate_MAC; When the Bootloader self-update is performed, the new version of the Bootloader is written to the backup Bank and its authentication digest is written to the Candidate_MAC, without modifying the Active_MAC; Set the one-time trial start flag and trigger hardware Bank Swap to make the standby bank the current mapped bank; After the system is reset, the HSM detects that the test start flag is valid and enters the dual digest verification mode: simultaneously verifying the Bootloader of the current mapped Bank using Active_MAC and Candidate_MAC, and passing is achieved if either matches; If the new version of Bootloader successfully starts in the backup Bank and passes the self-test, the new version of Bootloader will actively call the HSM interface to perform delayed commit: overwrite the Candidate_MAC with the Active_MAC, and clear the trial start flag and Candidate_MAC; If the new version of the Bootloader fails to start, a reset is triggered, the system automatically reverts to the original Bank, the HSM reverts to single digest verification mode, and only uses the original Active_MAC for verification. The old version of the Bootloader then starts normally.

[0015] In one embodiment, the trigger reset is triggered by at least one of watchdog overflow, hardware error detection, or software self-test failure.

[0016] In one embodiment, a further anti-downgrade mechanism is included: a monotonically increasing version counter is embedded in the secure NVM of the HSM, with each legitimate Bootloader version corresponding to a unique count value; before writing the authentication digest of the new version Bootloader to Candidate_MAC, the HSM verifies whether the target version number it carries is greater than the version number bound to the current Active_MAC. If so, the writing is allowed; otherwise, the writing to Candidate_MAC is rejected.

[0017] In one embodiment, the verification request initiated by the main core to the HSM is encapsulated as structured parameters, including at least: the starting address of the code area, the verification length, the target bank identifier, the version number, and the digest slot selector. After receiving the request, the HSM first verifies whether the address range is within the preset whitelist, then calls the hardware acceleration engine to calculate the authentication code, and returns a three-state result: MATCH_ACTIVE, MATCH_CANDIDATE, or MISMATCH, for the main core boot manager to decide which target bank to jump to.

[0018] In one embodiment, the self-updating refresh file constructs a block hash chain with a Code Flash erasure granularity, and the overall digital signature covers the root hash; when Bootloader2 is transporting and writing each block, it calculates the hash of the block in real time and verifies it up the hash chain. If any block fails to be verified, the transport is immediately stopped and the system is rolled back to the original Bank for startup.

[0019] In one embodiment, key status flags include a self-update phase flag, a delayed commit completion flag, and the current version number. Simultaneously, a copy is stored in both the Retain RAM and the HSM DataFlash to form a mirror redundancy. After each power-on, the Boot Manager first compares the two mirrors. If they match, the system proceeds according to this status. If they do not match, the data in the HSM DataFlash takes precedence, and the Retain RAM is repaired.

[0020] In one embodiment, the HSM writes a failure classification code to the security log circular buffer in the HSM DataFlash each time the security boot verification fails. The classification codes include: MAC_MISMATCH, VERSION_ROLLBACK, CANDIDATE_CORRUPT, and BANK_SWAP_ABORT. The master core can read the classification code through the diagnostic service to distinguish between attack events and upgrade anomalies.

[0021] In one embodiment, the one-time trial start flag is automatically cleared by the HSM after a reset to ensure that subsequent starts use only the single digest check mode unless a self-update command is received again and the flag is reset.

[0022] In one embodiment, the delayed submission is performed by the new version of the Bootloader actively calling the dedicated interface of HSM after completing its own health self-check in the backup Bank. After the submission is completed, HSM automatically clears the Candidate_MAC slot to prevent reuse.

[0023] In one embodiment, if an unexpected power outage or reset occurs before the delayed submission is executed, the HSM will detect that the Candidate_MAC exists and the Active_MAC has not been updated after power-on. It will then automatically determine that the upgrade is incomplete, force a rollback to the original Bank startup, and keep the Active_MAC unchanged.

[0024] In one embodiment, under the dual digest verification mode, the HSM calculates a temporary authentication code for the Bootloader of the current mapping Bank and compares it with Active_MAC and Candidate_MAC respectively. As long as it matches either one, the verification is considered successful, and the main core is allowed to continue execution.

[0025] Secondly, this application also provides a secure boot system based on HSM dual digest delayed submission, applied to an on-board controller with a hardware security module (HSM) and physical dual-bank Flash, comprising: The HSM secure storage module is configured to logically divide the HSM's isolated secure non-volatile memory into two independent digest slots: the active digest area Active_MAC and the candidate digest area Candidate_MAC; The self-update trigger module is configured to write the new version of the Bootloader to the backup Bank and write its authentication digest to the Candidate_MAC when the Bootloader self-update is executed, without modifying the Active_MAC. At the same time, it sets the one-time trial start flag and triggers the hardware Bank Swap to make the backup Bank the current mapping Bank. The dual digest verification module is configured to enter dual digest verification mode when the test start flag is detected to be valid after system reset: simultaneously verify the Bootloader of the current mapped Bank using Active_MAC and Candidate_MAC, and pass if either matches. The delayed submission module is configured so that after the new version of Bootloader successfully starts on the backup bank and passes the self-test, the new version of Bootloader actively calls the HSM interface to overwrite the Candidate_MAC to Active_MAC and clear the trial start flag and Candidate_MAC. The automatic rollback module is configured to trigger a reset by watchdog overflow when the new version of the Bootloader fails to start, and the system will automatically roll back to the original Bank. The HSM will be restored to single digest verification mode, and only the original Active_MAC will be used for verification, so that the old version of the Bootloader can start normally.

[0026] In one embodiment, the HSM secure storage module is further configured with a monotonically increasing version counter, with each valid Bootloader version corresponding to a unique count value; before writing to Candidate_MAC, the self-update triggering module calls the HSM to verify whether the target version number is greater than the version number bound to the current Active_MAC. If so, writing is allowed; otherwise, writing to Candidate_MAC is rejected.

[0027] In one embodiment, the dual digest verification module is configured to receive a structured verification request sent by the main core. The structured verification request includes at least the code area start address, verification length, target bank identifier, version number, and digest slot selector. The dual digest verification module first verifies whether the address range is within a preset whitelist, then calls the hardware acceleration engine to calculate the authentication code, and returns a three-state result: MATCH_ACTIVE, MATCH_CANDIDATE, or MISMATCH.

[0028] In one embodiment, the self-update triggering module is further configured to: construct a block hash chain within the self-update refresh file at the Code Flash erasure granularity, with the overall digital signature covering the root hash; when moving and writing each block, calculate the hash of that block in real time and verify it upwards along the hash chain; if any block fails to verify, immediately stop the movement and trigger the automatic rollback module.

[0029] In one embodiment, a state mirroring module is also included, configured to store key state flags, including a self-update phase flag, a delayed commit completion flag, and the current version number, in both the Retain RAM and the HSM DataFlash. After each power-on, the Boot Manager first compares the two mirrors. If they match, the Boot Manager proceeds with the current state. If they do not match, the Boot Manager uses the data in the HSM DataFlash and repairs the Retain RAM accordingly.

[0030] The aforementioned secure boot method, system, and vehicle controller based on HSM dual-digest delayed submission significantly improve the information security protection capabilities and upgrade robustness of the vehicle controller while ensuring the flexibility of bootloader upgrades. This is achieved through hardware linkage between the physical dual-bank Flash and the HSM dual-digest slots, a delayed trust anchor update mechanism for two-stage submissions, version counter anti-downgrade verification, and state mirror redundancy protection. By independently maintaining the active digest area (Active_MAC) and candidate digest area (Candidate_MAC) in the HSM, the upgrade phase only writes the new version's authentication digest to the candidate area without modifying the active area, allowing the old and new versions to coexist physically. Even if the new version of the bootloader fails to start in the backup bank, the system can automatically fall back to the original bank, where the original active digest perfectly matches the original version, and the old version of the bootloader starts normally, fundamentally eliminating the problem of permanent controller failure caused by irreversible updates to the trust chain. During normal operation, a single-digest verification mode is used, allowing only the authorized version corresponding to the active digest to start, strictly preventing downgrade attacks. During the upgrade phase, it temporarily switches to a dual-digest verification mode, providing a brief coexistence window for the new and old versions, achieving a smooth transition from "trial startup—verification—commit / rollback," and resolving the long-standing industry contradiction between security and upgrade flexibility. Before writing the candidate digest, HSM forcibly verifies that the target version number is greater than the current active version number, preventing attackers from flashing back to an older firmware version with known vulnerabilities at the trust chain level. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the 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.

[0032] Figure 1 This is a schematic diagram of an HSM hierarchical security storage and trust chain architecture in one embodiment.

[0033] Figure 2 This is a flowchart of a secure startup method based on HSM double digest delayed submission in one embodiment.

[0034] Figure 3 This is a block diagram illustrating the collaborative operation of two-level cryptographic verification and dual-digest in one embodiment. Detailed Implementation

[0035] 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 some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0036] To enable those skilled in the art to better understand the present invention, the overall hardware architecture and layered trust chain of the present invention will first be summarized with reference to Figures 1-3.

[0037] like Figure 1 , Figure 3 As shown, this invention is built upon an automotive-grade safety MCU hardware platform. This platform includes a lockstep main CPU core for executing the main program, an independent window watchdog for monitoring startup timeliness, and a Flash controller for managing the underlying flash memory write / erase. The core hardware feature is the hardware Bank Swap address mapping switching mechanism, which allows the system to physically map Bank A (active working partition) and Bank B (backup upgrade partition) to the same logical address space, achieving seamless switching.

[0038] At the software and trust chain level, the system constructs a three-layer security defense system: The underlying algorithm and execution layer: On the lockstep main CPU core side, hash algorithms such as SHA256 or the national cryptographic SM3 are combined with asymmetric cryptographic algorithms such as RSA2048 or SM2 to perform step-by-step trusted startup verification of the application.

[0039] The intermediate HSM (Hardware Storage System) is the core of this invention. To prevent the main core from being attacked and having its keys directly tampered with, the HSM is isolated from the main core via a firewall through a shared computer channel. The main core cannot directly read or write the keys and authentication values ​​inside the HSM. The HSM integrates an asymmetric signature verification engine and is divided into three key logical areas: OTP Root Trust Zone: Stores the RSA2048 / SM2 root public key hash and the AES / SM4 secure boot root key. This zone is immutable once burned and is unaffected by bank swaps, serving as the absolute root of trust for the entire system.

[0040] The secure NVM dual digest area is logically divided into Active_MAC (active authentication benchmark) and Candidate_MAC (candidate authentication benchmark).

[0041] Status flag area: contains SWAP_ONESHOT (one-time trial boot flag), SWAP_PERM (permanent swap flag), and BOOT_HEALTH (partition health flag).

[0042] Top-level application and control flow: including OTA upgrade package verification, secure bootloader authentication, and application hierarchical trusted startup.

[0043] Supported by the above architecture, this invention provides a secure startup method based on HSM double digest delayed commit. The following is combined with... Figure 1-3 The details are explained in detail, and the specific implementation steps are elaborated.

[0044] This invention provides a secure boot method based on HSM dual-digest delayed submission. This method is applicable to onboard controllers (ECUs) equipped with a Hardware Security Module (HSM) and a physical dual-bank Flash architecture. The specific implementation steps are described in detail below.

[0045] First, the HSM secure storage layer is initialized and dual digest slots are partitioned. Upon the ECU's first power-on or the first activation of the secure boot function, the HSM firmware logically partitions two independent digest storage slots in its isolated secure non-volatile memory (e.g., HSM-dedicated DataFlash or NVRAM): the Active Digest Area (Active_MAC) and the Candidate Digest Area (Candidate_MAC). Each slot has a storage capacity sufficient to hold at least one complete AES-CMAC or HMAC value (e.g., 16 bytes or 32 bytes). Active_MAC stores the authentication digest of the currently officially licensed Bootloader version, serving as the sole verification benchmark during normal boot. Candidate_MAC temporarily stores the authentication digest of the Bootloader version to be upgraded, participating in verification only during the gray-scale trial boot phase.

[0046] HSM also maintains a monotonically increasing version counter, which is stored in Figure 1 The OTP root trust zone shown (utilizing the one-time burning feature of OTP) automatically increments with each successful new version submission. Each legitimate Bootloader version is assigned a unique version number upon release, which corresponds one-to-one with the version counter value. Before writing to Candidate_MAC, HSM verifies whether the target version number carried by the new Bootloader version is greater than the version number bound to the current Active_MAC. Only if the condition is met is writing allowed, thus preventing downgrade attacks.

[0047] Then, self-update triggering and double digest writing are performed; see [link / reference] Figure 2The self-update triggering and double-digest writing steps: When a remote upgrade of the bootloader is required via OTA or diagnostic tools, the ECU first receives a digitally signed self-update refresh file. Internally, this refresh file constructs a block hash chain according to the smallest erase / write granularity of the Code Flash (e.g., 4KB or one sector): the SHA256 hash value of each data block serves as a leaf node, and the parent node hash is calculated layer by layer upwards, ultimately forming a root hash. The digital signature of the entire self-update refresh file overwrites this root hash to ensure that any tampering with any data block can be detected.

[0048] After the certificate chain verification and signature verification pass, combined with Figure 1 The Flash controller and Bank mapping relationship are defined in the code. The ECU writes the new version of the Bootloader (denoted as Bootloader') into the currently inactive backup Bank (e.g., Bank B). Simultaneously, the HSM calls its internal asymmetric signature verification engine (see...). Figure 3 The "cryptographic algorithm engine group" calculates the authentication digest of this new version of the bootloader and writes it to... Figure 3 The Candidate_MAC slot in the "Secure NVM Dual Digest Area" is used. During this process, the Active_MAC slot remains unchanged, still storing the authentication digest of the original bootloader. Subsequently, the ECU sets the one-time trial boot flag (e.g., by writing a specific value to a specific register in the HSM or Retain RAM, i.e., in...). Figure 1 , 3 The "status flag area" is set to SWAP_ONESHOT, and a hardware Bank Swap address mapping switching operation is triggered. The Flash controller responds to this instruction, making the spare Bank the default mapping Bank after the next reset.

[0049] Key status flags (such as the self-update phase flag, delayed commit completion flag, and current version number) are stored not only in the HSM's DataFlash but also in the Retain RAM accessible by the main core, forming a mirrored redundancy (see [link]). Figure 3 (Input feedback logic of the "Status Control Unit").

[0050] After each power-on (including after a reset), the Boot Manager first reads and compares the two images: If they match, proceed with the subsequent process in that state; if they do not match, use the data in the HSM DataFlash (because it is not lost when power is off and has anti-tampering properties), and use the correct data to repair the Retain RAM.

[0051] This design addresses the vulnerability of traditional solutions that rely solely on retained RAM, leading to state loss after power failure. It ensures the state machine starts from a known, correct state. (See [link to relevant documentation]). Figure 2 The "State Mirroring and Consistency Guarantee" steps.

[0052] In dual-digest verification mode, after a system reset, the main kernel starts execution from the Boot manager. The Boot manager first communicates with the HSM and queries the SWAP_ONESHOT status in the "status flag area". If the test boot flag is detected as valid, the HSM enters dual-digest verification mode. See [link to documentation]. Figure 3 The "Verification Mode Switching Unit" employs a "Dual-Baseline Verification Mode." In this mode, the HSM calculates a temporary authentication code for the Bootloader code in the currently mapped Bank (i.e., the newly switched-to backup Bank), and then compares this temporary authentication code with both Active_MAC and Candidate_MAC. If either matches, the verification is considered successful, allowing the main core to continue executing the Bootloader. This dual-digest verification mechanism provides a temporary coexistence space for the old and new versions: even if the Candidate_MAC is newly written, the Active_MAC remains the old one; a match between either allows the process to proceed, thus avoiding the problem of the new version failing to boot due to an outdated trust chain.

[0053] To improve verification efficiency and flexibility, the verification request initiated by the main core to the HSM is encapsulated as structured parameters, including at least: the starting address of the code segment, the verification length, the target bank identifier, the version number, and the digest slot selector. Upon receiving the request, the HSM utilizes its isolated hardware resources (such as an asymmetric signature verification engine or a CMAC authentication engine) to perform calculations. First, it verifies whether the address range is within a preset security whitelist (to prevent out-of-bounds access). Then, it calls the hardware acceleration engine to calculate the authentication code. The HSM ultimately returns a tri-state result: MATCH_ACTIVE (matches Active_MAC), MATCH_CANDIDATE (matches Candidate_MAC), or MISMATCH (neither matches). The boot manager determines whether to jump to the bootloader for execution based on this result.

[0054] After successfully booting from the backup bank, the new version of the bootloader first performs its own integrity self-check, including but not limited to: checking the validity of key configuration parameters, verifying the integrity of the secure boot table, and testing the basic functionality of hardware peripherals. After passing the self-check, the new version of the bootloader proactively calls the HSM's dedicated interface to perform a delayed commit operation: copying the contents of the Candidate_MAC slot to overwrite the Active_MAC slot, while simultaneously clearing the trial boot flag and the Candidate_MAC slot (zeroing or setting it to an invalid value). At this point, the trust anchor is officially updated, and subsequent boots will revert to single digest verification mode. See [link to documentation]. Figure 3 The "Single Baseline Verification Mode" of the "Verification Mode Switching Unit" uses only the new Active_MAC for verification.

[0055] After a delayed commit is completed, the HSM automatically clears the Candidate_MAC slot to prevent it from being reused or misused. Simultaneously, the new version of the Bootloader writes a "delayed commit complete" flag to the mirror area of ​​the Retain RAM and HSM DataFlash for use upon power-up restoration.

[0056] If the new version of the bootloader fails to boot from the backup bank (e.g., due to code errors, hardware malfunctions, or watchdog timeouts), a watchdog timer overflow triggers a system reset. After the reset, because the test boot flag has not yet been cleared, the bootmanager re-enters dual-digest verification mode. However, since the hardware bank swap may automatically revert to the default original bank mapping after a reset (depending on the chip design), or the system may force a rollback to the original bank (Bank A) through the boot manager's boot logic. In this case, the HSM detects that the Candidate_MAC exists but the Active_MAC has not been updated, automatically determining that the upgrade is incomplete and forcing the use of the original bank for booting. In the original bank, the HSM reverts to single-digest verification mode, using only the original Active_MAC for verification, and the old version of the bootloader boots normally, achieving a lossless rollback.

[0057] At any point before the delayed submission is executed (including during transport or trial startup), if an unexpected power outage or reset occurs, the HSM will detect the existence of Candidate_MAC and the fact that Active_MAC has not been updated upon power-up. It will automatically determine that the upgrade is incomplete, force a rollback to the original bank startup, and maintain the Active_MAC unchanged. This mechanism ensures that even under extreme abnormal conditions, the controller will not fall into a bidirectional lockout state.

[0058] Each time a secure boot verification fails, the HSM writes a failure classification code to the security log circular buffer in the HSM DataFlash. Classification codes include, but are not limited to: MAC_MISMATCH (authentication code mismatch), VERSION_ROLLBACK (version rollback attack), CANDIDATE_CORRUPT (candidate digest corruption), BANK_SWAP_ABORT (bank switch abort), etc. Each classification code occupies one byte and includes a timestamp or reset count. The main core can read this classification code through the UDS diagnostic service (e.g., reading DTC extended data in 0x19) to distinguish between a hacker tampering attack and an upgrade anomaly, facilitating after-sales analysis and problem localization.

[0059] The present invention also provides a secure boot system based on HSM dual digest delayed submission, which is deployed in an on-board controller with a hardware security module HSM and physical dual bank flash, and includes the following functional modules.

[0060] The HSM secure storage module is configured to logically divide the HSM's isolated secure non-volatile memory into two independent digest slots: the Active_MAC area and the Candidate_MAC area. See [link to HSM secure storage module]. Figure 3 The module includes a dual-authentication value storage unit. Additionally, it maintains a monotonically increasing version counter, with a unique count value corresponding to each valid Bootloader version. Before writing to Candidate_MAC, the module calls HSM to verify whether the target version number is greater than the version number bound to the current Active_MAC. If so, writing is allowed; otherwise, writing is rejected.

[0061] The self-update trigger module is configured to write the new version of the Bootloader to the standby Bank and its authentication digest to the Candidate_MAC when a Bootloader self-update is performed, without modifying the Active_MAC. Simultaneously, this module sets a one-time trial boot flag and triggers a hardware Bank Swap, making the standby Bank the current mapped Bank. This module is further configured to: construct a block hash chain within the self-update refresh file at the Code Flash erasure granularity, with the overall digital signature overwriting the root hash; and calculate the hash of each block in real time and verify it upwards along the hash chain, immediately stopping the transfer and triggering the automatic rollback module if any block verification fails.

[0062] The dual-digest verification module is configured to enter dual-digest verification mode upon detecting a valid trial boot flag after a system reset. This mode simultaneously verifies the Bootloader of the currently mapped Bank using both Active_MAC and Candidate_MAC; a match between either verifies the Bootloader. This module receives a structured verification request from the main core. The structured verification request includes at least the code segment start address, verification length, target Bank identifier, version number, and digest slot selector. The module first verifies whether the address range is within a preset whitelist, then calls the hardware acceleration engine to calculate the authentication code and returns a tri-state result: MATCH_ACTIVE, MATCH_CANDIDATE, or MISMATCH.

[0063] The delayed commit module is configured so that after the new version of the Bootloader successfully boots on the backup Bank and passes the self-test, the new version of the Bootloader actively calls the HSM interface to overwrite the Candidate_MAC with the Active_MAC, and clears the trial boot flag and the Candidate_MAC. After the commit is completed, the HSM automatically clears the Candidate_MAC slot to prevent reuse.

[0064] The automatic rollback module is configured to automatically roll back to the original bank when a watchdog overflow triggers a reset if the new version of the bootloader fails to start. The HSM will then revert to single digest verification mode, using only the original Active_MAC for verification, allowing the old version of the bootloader to start normally. If an unexpected power outage or reset occurs before the delayed commit is executed, this module will also force a rollback to the original bank for startup.

[0065] The status mirroring module is configured to store key status flags, including the self-update phase identifier, the delayed commit completion identifier, and the current version number, in both the Retain RAM and the HSM DataFlash. Upon each power-on, the Bootmanager first compares the two mirrors. If they match, it proceeds with that status; otherwise, it uses the data in the HSM DataFlash and repairs the Retain RAM accordingly.

[0066] The security audit module is configured to write a failure classification code to the security log circular buffer in the HSM DataFlash each time a security boot verification fails. Classification codes include MAC_MISMATCH, VERSION_ROLLBACK, CANDIDATE_CORRUPT, and BANK_SWAP_ABORT. The master kernel can read this classification code through the diagnostic service to distinguish between attack events and upgrade anomalies.

[0067] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

[0068] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0069] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0070] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this application. It is understood that this invention has been described through some embodiments, and those skilled in the art will recognize that various changes or equivalent substitutions can be made to these features and embodiments without departing from the spirit and scope of this invention. Furthermore, under the teachings of this invention, these features and embodiments can be modified to adapt to specific situations and materials without departing from the spirit and scope of this invention. Therefore, this invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application are protected by this invention.

Claims

1. A secure boot method based on HSM dual-digest delayed submission, applied to an on-board controller with a hardware security module (HSM) and physical dual-bank Flash, characterized in that, include: In the isolated secure non-volatile memory of the HSM, two independent digest slots are logically divided: the active digest area Active_MAC and the candidate digest area Candidate_MAC; When the Bootloader self-update is performed, the new version of the Bootloader is written to the backup Bank and its authentication digest is written to the Candidate_MAC, without modifying the Active_MAC; Set the one-time trial start flag and trigger hardware Bank Swap to make the standby bank the current mapped bank; After the system is reset, the HSM detects that the test start flag is valid and enters the dual digest verification mode: simultaneously verifying the Bootloader of the current mapped Bank using Active_MAC and Candidate_MAC, and passing is achieved if either matches; If the new version of Bootloader successfully starts in the backup Bank and passes the self-test, the new version of Bootloader will actively call the HSM interface to perform delayed commit: overwrite the Candidate_MAC with the Active_MAC, and clear the trial start flag and Candidate_MAC; If the new version of the Bootloader fails to start, a reset is triggered, the system automatically reverts to the original Bank, the HSM reverts to single digest verification mode, and only the original Active_MAC is used for verification. The old version of the Bootloader then starts normally.

2. The method according to claim 1, characterized in that, Further, a downgrade prevention mechanism is included: a monotonically increasing version counter is embedded in the secure NVM of HSM, with each legitimate Bootloader version corresponding to a unique count value; before writing the authentication digest of the new version Bootloader to Candidate_MAC, HSM verifies whether the target version number it carries is greater than the version number bound to the current Active_MAC. If so, writing is allowed; otherwise, writing to Candidate_MAC is rejected.

3. The method according to claim 1, characterized in that, The verification request initiated by the main core to the HSM is encapsulated as structured parameters, including at least: code segment start address, verification length, target bank identifier, version number, and digest slot selector. After receiving the request, the HSM first verifies whether the address range is within the preset whitelist, then calls the hardware acceleration engine to calculate the authentication code, and returns a three-state result: MATCH_ACTIVE, MATCH_CANDIDATE, or MISMATCH, for the main core boot manager to decide which target bank to jump to.

4. The method according to claim 1, characterized in that, The self-updating refresh file internally constructs a block hash chain with code flash erasure granularity, and the overall digital signature covers the root hash; when Bootloader2 is transporting and writing each block, it calculates the hash of the block in real time and verifies it up the hash chain. If any block fails to be verified, the transport is immediately stopped and the system is rolled back to the original Bank to start.

5. The method according to claim 1, characterized in that, Key status flags include the self-update phase flag, the delayed commit completion flag, and the current version number. Simultaneously, a copy is stored in both the Retain RAM and the HSM DataFlash to form a mirror redundancy. After each power-on, the Boot Manager first compares the two mirrors. If they match, the system proceeds according to this status. If they do not match, the data in the HSM DataFlash takes precedence, and the Retain RAM is repaired.

6. The method according to claim 1, characterized in that, Each time a security boot verification fails, HSM writes a failure classification code to the security log circular buffer in HSMDataFlash. The classification codes include: MAC_MISMATCH, VERSION_ROLLBACK, CANDIDATE_CORRUPT, and BANK_SWAP_ABORT. The master core can read the classification code through the diagnostic service to distinguish between attack events and upgrade anomalies.

7. The method according to claim 1, characterized in that, The one-time trial start flag is automatically cleared by the HSM after a reset to ensure that subsequent starts only use the single digest check mode, unless a self-update command is received again and the flag is reset.

8. The method according to claim 1, characterized in that, The delayed submission is performed by the new version of Bootloader actively calling the dedicated interface of HSM after completing its own health self-check in the backup Bank. After the submission is completed, HSM automatically clears the Candidate_MAC slot to prevent reuse.

9. The method according to claim 1, characterized in that, If an unexpected power outage or reset occurs before the delayed submission is executed, the HSM will detect that the Candidate_MAC exists and the Active_MAC has not been updated after power-on. It will then automatically determine that the upgrade is incomplete, force a rollback to the original Bank startup, and keep the Active_MAC unchanged.

10. The method according to claim 1, characterized in that, In the dual digest verification mode, HSM calculates a temporary authentication code for the Bootloader of the current mapping Bank and compares it with Active_MAC and Candidate_MAC respectively. As long as it matches one of them, it is considered to pass the verification and the main core is allowed to continue execution.

11. A secure boot system based on HSM dual-digest delayed submission, applied to an on-board controller with a hardware security module (HSM) and physical dual-bank Flash, characterized in that, include: The HSM secure storage module is configured to logically divide the HSM's isolated secure non-volatile memory into two independent digest slots: the active digest area Active_MAC and the candidate digest area Candidate_MAC; The self-update trigger module is configured to write the new version of the Bootloader to the backup Bank and write its authentication digest to the Candidate_MAC when the Bootloader self-update is executed, without modifying the Active_MAC. At the same time, it sets the one-time trial start flag and triggers the hardware Bank Swap to make the backup Bank the current mapping Bank. The dual digest verification module is configured to enter dual digest verification mode when the test start flag is detected to be valid after system reset: simultaneously verify the Bootloader of the current mapped Bank using Active_MAC and Candidate_MAC, and pass if either matches. The delayed submission module is configured so that after the new version of Bootloader successfully starts on the backup bank and passes the self-test, the new version of Bootloader actively calls the HSM interface to overwrite the Candidate_MAC to Active_MAC and clear the trial start flag and Candidate_MAC. The automatic rollback module is configured to trigger a reset by watchdog overflow when the new version of the Bootloader fails to start, and the system will automatically roll back to the original Bank. The HSM will be restored to single digest verification mode, and only the original Active_MAC will be used for verification, so that the old version of the Bootloader can start normally.

12. The system according to claim 11, characterized in that, The HSM secure storage module is also configured with a monotonically increasing version counter, with each valid Bootloader version corresponding to a unique count value; before writing to Candidate_MAC, the self-update triggering module calls the HSM to verify whether the target version number is greater than the version number bound to the current Active_MAC. If so, writing is allowed; otherwise, writing to Candidate_MAC is rejected.

13. The system according to claim 11, characterized in that, The dual digest verification module is configured to receive a structured verification request sent by the main core. The structured verification request includes at least the code area start address, verification length, target bank identifier, version number, and digest slot selector. The dual digest verification module first verifies whether the address range is within a preset whitelist, then calls the hardware acceleration engine to calculate the authentication code, and returns a three-state result: MATCH_ACTIVE, MATCH_CANDIDATE, or MISMATCH.

14. The system according to claim 11, characterized in that, The self-update triggering module is further configured as follows: the self-update refresh file internally constructs a block hash chain according to the Code Flash erasure granularity, and the overall digital signature covers the root hash; when moving and writing each block, the hash of the block is calculated in real time and verified upward along the hash chain; if any block fails to be verified, the moving is immediately stopped and the automatic rollback module is triggered.

15. The system according to claim 11, characterized in that, It also includes a status mirroring module, configured to store key status flags, including the self-update phase flag, the delayed commit completion flag, and the current version number, in both the Retain RAM and the HSM DataFlash. After each power-on, the Boot Manager first compares the two mirrors. If they match, it proceeds with that status; if they do not match, it uses the data in the HSM DataFlash and repairs the Retain RAM.

Images