AB double-area safe starting method and system based on HSM core

Abstract

The invention discloses and relates to an AB double-area safe starting method and system based on an HSM core, the system adopts a multi-core cooperative hardware architecture, and an application core is used as an execution main body of a refreshing service and is responsible for firmware receiving, writing into a storage area and refreshing state management; the main core schedules encryption services, including request receiving, parameter analysis and operation resource allocation; the HSM core depends on a built-in hardware encryption acceleration engine to provide efficient cryptographic operation support; through a standardized interface and a cross-core communication mechanism provided by a runtime environment, the system realizes inter-core asynchronous request and callback, and constructs a verification system with'security isolation, transparent process and extensible function '.

Description

Technical Field

[0001] This invention relates to the information security aspects of automotive electronic intelligent connected vehicles, and particularly to an AB dual-zone secure boot method and system based on an HSM core. Background Technology

[0002] In the early design of automotive chips and software systems, because automotive electronics were a closed system, not interconnected with the outside world, information security was not given much consideration. With the development of the four new trends in automobiles, especially the advancement of connectivity and autonomous driving, the connections between vehicles and between vehicles and the outside world are becoming increasingly close, which has inadvertently increased the channels of communication between the outside world and vehicles, making automotive network information security increasingly important.

[0003] For example, with common over-the-air (OTA) technology for vehicles, if the software running on the ECU is tampered with or controlled by hackers during driving, it will seriously affect driving safety. Furthermore, with the further development of driver assistance and autonomous driving in the future, intelligent driving systems may completely control the vehicle's power and braking control, making the importance of vehicle information security even more prominent.

[0004] Secure boot is a crucial part of vehicle information security. It effectively prevents malicious software modification by attackers. Secure boot ensures that the software booting is trustworthy, secure, and untampered. By enabling the ECU to perform relevant security checks and verifications during the boot phase, secure boot allows for timely risk control and prevents vehicle safety issues.

[0005] Based on the principles of secure boot, code encryption or boot code verification require more CPU resources to complete these tasks. Traditional CPUs alone may not be able to complete such tasks efficiently. Typically, it is necessary to implement the Secure Boot requirement on an automotive-grade chip using a Hardware Security Module (HSM) to improve program startup efficiency.

[0006] The HSM runs as an independent core, performing independent computations and configured with hardware acceleration for algorithms. It is responsible for executing all cryptographic applications, including symmetric key encryption / decryption (AES-CMAC, etc.), integrity checks, asymmetric key encryption / decryption (RSA), digital signature generation and verification, hash calculation, and secure boot. This ensures secure password storage while the hardware acceleration guarantees computing power and improves device boot speed.

[0007] A secure boot mechanism typically consists of two levels: bootloader security verification and application (App) security verification.

[0008] After the ECU is powered on, the CPU takes priority control of the Bootloader. If no valid application or external trigger for a refresh request is detected, the Bootloader mode is maintained. Before entering refresh mode, the Bootloader's own integrity verification must be completed; if the verification fails, a forced reset is immediately performed.

[0009] The bootloader verification process begins with the main core establishing a secure channel with the HSM and querying the verification range table in the HSM's dedicated DataFlash to check if the flag is configured. If the flag is not set, the main core calls the HSM firmware interface to write the starting address and length of the area to be verified to establish the verification range table. Upon successful verification, the flag is set and written back to the HSM's protected DataFlash to prevent subsequent tampering. Subsequently, the HSM calculates the bootloader fingerprint based on the verification range using a hardware AES-CMAC engine and stores the result in the HSM's internal secure storage. Upon power-up, the refresh process is directly initiated without recalculation. Upon power-up again, the main core only reads the HSM flag and the HSM recalculates the current bootloader fingerprint and compares it with the stored value. If they match, execution continues; otherwise, the boot process is terminated.

[0010] The production line does not pre-burn the merged image of the Bootloader and App, but only pre-installs the Bootloader. The App is injected separately through a secure refresh process. After the App is downloaded and reset, before jumping, the Bootloader needs to perform AES-CMAC calculation on the entire area of ​​the App. If the system does not have high security requirements, the digest can be stored in the unencrypted NVM. If a high security level is required, the digest is imported as a key into the independent security module ICU-S. Subsequently, each time the Bootloader is powered on or reset, it first verifies the validity of the App and then recalculates its CMAC value and compares it with the stored value. If they match, control is transferred to the App; otherwise, the Bootloader mode is maintained and only refresh is allowed again.

[0011] From the perspectives of vehicle upgrade process, safe start efficiency, and system reliability, the above-mentioned safe start solution has the following technical limitations: (1) The CMAC value required for secure startup verification is generated by software algorithm, which has low computational efficiency and its time consumption is positively correlated with the code size. In extreme scenarios with a large amount of code, the time consumption can be as long as tens of seconds, which directly leads to a significant decrease in the overall efficiency of the vehicle upgrade process.

[0012] (2) The calculated CMAC value needs to be stored using the security module ICU-S. Although this mechanism provides some security improvements, ICU-S relies on an update counter to write the CMAC value corresponding to the new version of the application code. Since this counter is only stored in non-volatile memory (NVM), it is difficult to provide sufficient security protection during code refresh; if the update counter is accidentally erased, it will directly cause the CMAC value verification calculation to fail, thereby causing the entire secure boot function to fail.

[0013] (3) The application (App) upgrade method based on the traditional Bootloader has gradually shown its lack of competitiveness in the current era of rapid evolution of vehicle intelligence and connectivity. Specifically, the downtime during the vehicle upgrade process is relatively long, the upgrade time perceived by users is significantly increased for domain controller devices with integrated complex functions, and the power consumption during the upgrade process is relatively high. These are all prominent shortcomings of the traditional OTA upgrade mode. Summary of the Invention

[0014] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides an AB dual-zone secure boot method and system based on the HSM core, which can effectively prevent attackers from maliciously modifying the vehicle software and causing damage. In particular, it differentiates the secure boot processes of the main core and the HSM core, taking into account both security and boot efficiency.

[0015] This invention discloses an AB dual-zone secure boot method and system based on an HSM core, characterized in that: the system adopts a multi-core collaborative hardware architecture, including: The application core, as the main body responsible for executing the refresh service, is responsible for receiving firmware, writing it to the storage area, and managing the refresh status. The main core schedules encryption services, including receiving requests, parsing parameters, and allocating computing resources. The HSM core, relying on its built-in hardware encryption acceleration engine, provides efficient cryptographic operation support; Through standardized interfaces and cross-core communication mechanisms provided by the runtime environment, the system implements asynchronous requests and callbacks between cores, building a verification system that is "securely isolated, transparent in process, and functionally scalable".

[0016] A further feature of this invention is that it also includes a seamless refresh triggering mechanism. After the refresh service in the application core completes the firmware data reception, preliminary verification, and writing to the target storage area, it will automatically trigger the CMAC update process once it detects a "firmware write successful" status indicator, such as a data write complete signal or RSA signature verification passed.

[0017] A further feature of this invention is the inclusion of a multi-core collaboration and cross-core communication mechanism. When the application core confirms that the firmware update is complete, it will initiate a call through the cross-core service interface provided by RTE. It encapsulates the CMAC generation request into structured data, including parameters such as the starting address, length, version number, and target Bank identifier of the code region of the firmware to be verified, and sends it to the main core through the IOC channel. After receiving the request, the encryption service manager running on the main core first verifies the legality of the parameters, such as whether the code region is within the secure address range and whether the version number conforms to the upgrade rules. After the verification is passed, it calls the hardware encryption interface of the HSM core and assigns the actual AES-CMAC operation task to the HSM core for execution. After receiving the computation request, the HSM core loads the preset CMAC key and uses the hardware acceleration engine to perform AES-CMAC computation on the firmware data in the specified code region, generating the firmware's CMAC digest value. The computation result, including the CMAC value and status code, is then returned to the main core through the IOC channel. After receiving the result, the main core notifies the application core to update the refresh status, such as changing from "pending verification" to "verification", through an asynchronous event mechanism, such as triggering a Core3 interrupt or pushing the result to its message queue.

[0018] Further features of this invention include CMAC update and integrity verification. After receiving a CMAC generation request, the HSM core first retrieves a preset CMAC root key from its built-in secure storage area. Combined with the code region range specified in the request, the HSM core uses a hardware-accelerated AES-CMAC engine to calculate the firmware digest. After the calculation is completed, the HSM core compares the generated CMAC value with the "expected CMAC value" carried in the firmware flash package and signed by the publisher. If the two match, the HSM core returns a "verification passed" status to the main core. The system then determines that the firmware is intact and valid, allowing subsequent Bank switching or normal startup. If the comparison is inconsistent, the HSM core immediately triggers a security exception handling mechanism: sends a "verification failed" alarm to the main core, records an exception log in the HSM secure storage area, and locks the storage area where the target firmware is located, thereby preventing the execution of illegal code from the hardware level. The generated valid CMAC value is flexibly stored according to the system security level requirements: it is preferentially stored in the dedicated secure DataFlash area of ​​the HSM core, which has hardware-level anti-erasure and anti-illegal access protection, and can only be read and written by the HSM core; it can also be written to an external high-security module, such as an independent secure core ICU-S, to ensure that the verification data is not maliciously tampered with or accidentally erased during its life cycle.

[0019] Further features of this invention include an AB dual-zone mechanism and seamless refresh collaboration. The system adopts an AB dual-zone storage architecture, with two banks being physically independent FLASH storage areas. Each bank has a complete firmware image storage space and an independent CMAC verification data storage area, and shares a set of activation status control logic. During normal operation, only one bank is in an "active state," while the other bank is in an "inactive state." The system stores the identifier of the currently active bank through a dedicated hardware register. For example, a register value of 0 indicates that Bank A is active, and a value of 1 indicates that Bank B is active. During the integrity verification phase, the system automatically selects the CMAC data of the corresponding bank for comparison based on this identifier. In the seamless refresh process, the application core first reads the value of the SCDS0.CFSWSTT register to determine the current inactive bank. If the current active bank is A, then the inactive bank is B. Subsequently, the new firmware is written to the inactive bank by default. Before writing, the system erases the old data in the bank to avoid residue. During the writing process, the RSA-4096 asymmetric encryption algorithm is used to verify the data to ensure its correctness. After the writing is completed, the CMAC update calculation and verification process for the inactive bank is triggered. If CMAC verification passes, the system updates the SCDS0.CFSWSTT register value, for example, changing it from 0 to 1, and switches the active bank to B, completing the bank-level switch and achieving a smooth transition of firmware versions. The next time the system starts, it will automatically load the firmware from the newly activated bank. If CMAC verification fails or an anomaly occurs during the refresh process, the system will maintain the SCDS0.CFSWSTT register value unchanged, still load the firmware from the original active bank, and start normally, thereby ensuring the security of the update process and the recoverability of the system.

[0020] Further features of this invention include asynchronous processing and state management. The entire CMAC update process adopts a dual management mechanism of "event-driven + state machine". After the application core initiates a CMAC request through RTE, it immediately releases the encryption service request resources and returns to the "request submitted" state. Then it continues to execute other preset tasks, such as cleaning up temporary files or reporting the refresh status. When the HSM core completes the encryption operation and returns the result, the main core triggers the "CMAC result processing" event of the application core through a callback mechanism, such as calling the CmacResultCallback function preset by the application core. In this event, the application core updates the local state machine, such as switching from "pending verification" to "verification passed" or "verification failed", and determines the subsequent process according to the state. If the verification is passed, the Bank switch is executed. If the verification fails, an exception alarm is triggered. The mechanism has built-in robust exception handling capabilities: it supports timeout detection and dynamically sets the threshold based on the size of the code to be verified. For example, the threshold is 100ms when the code size is <1MB and 500ms when it is >10MB. It automatically retryes after a timeout. Supports error retries. Automatically re-initiates after a single failed request, up to 3 times. If all retries fail, it enters a security exception process. It supports concurrency control, protects the CMAC request queue with a mutex lock to prevent multi-task resource contention, and ensures the uniqueness of the calculation result.

[0021] Further features of the present invention include secure storage and key management. The HSM core integrates an independent hardware encrypted storage unit that supports AES-256 encryption protection and is specifically used to store critical security data required for CMAC calculation, including: CMAC key, CMAC checksum corresponding to each Bank, and device certificate chain. All encryption operations are performed within a closed environment inside the HSM core. The main core and application core can only send operation requests or receive final results through standardized interfaces, and cannot directly access the key data or intermediate values ​​inside the HSM. This architecture ensures the physical isolation and operational trustworthiness of the encryption process. The system supports obtaining key resources through the Crypto_KeySearch interface: the caller needs to pass in a unique key identifier. The interface will first verify the caller's permissions and the validity of the key. After successful verification, it will return a key handle that is only valid within the current session. The caller uses this handle to initiate encryption operations, thereby reducing the risk of key leakage. At the same time, the system supports dynamic key updates: the new key must carry the vendor's signature. When updating, the old key is first marked as "to be expired", the new key is activated and the CMAC value is recalculated. After the system is running stably, the old key is deleted, realizing seamless key updates.

[0022] The beneficial effects of this invention are as follows: This system constructs a closed-loop security protection through the collaborative mechanism of "refresh-to-verify" and "dual-zone redundancy". Once the firmware is written to an inactive bank, CMAC calculation and comparison are immediately triggered, and bank switching is prepared only after verification is passed. The entire process has no verification delay, completely eliminating the security window period that may exist "after firmware refresh and before startup" in traditional bootloader-less architectures (i.e., the risk of illegal firmware being loaded due to verification delay).

[0023] The system automatically updates the CMAC value, selects the Bank activation status, and synchronizes the status between cores (through real-time information transmission via IOC). The entire process is completely transparent to users (such as vehicle maintenance personnel) and upper-layer applications (such as vehicle control systems), requiring no additional operations (such as manual restarts or inputting verification commands). This design not only enhances the system's security (anti-tampering, anti-abnormal startup) and reliability (avoiding system unavailability due to refresh failures), but also significantly reduces maintenance costs—reducing the number of on-site repairs required due to refresh anomalies and shortening system downtime. Attached Figure Description

[0024] Figure 1 The present invention first enables the HSM core, and after the secure boot related modules are initialized, secure boot is enabled. The AES-CMAC algorithm is used to generate or verify the CMAC value for the partition that needs to be booted. After the verification is completed, the main core is released to run the App code. Figure 2 This invention describes the steps of cross-core calling the CSM interface to request the HSM core to calculate and verify the asymmetric encrypted ciphertext of the new code and update the CMAC value of the new code when the main core performs a seamless refresh. Detailed Implementation

[0025] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings: In the description of this invention, it should be understood that the terms "upper", "lower", "bottom", "top", "front", "rear", "inner", "outer", "left", "right", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.

[0026] In response to problems (1) and (2), this application provides a secure startup scheme for App code that performs hash calculations based on HSM and stores the data in HSM-dedicated DataFlash.

[0027] The method is as follows: The ECU receives the refresh command issued by the refresh tool. After the refresh process is successfully completed, it writes the App valid flag to the CODE FLASH. At the same time, it calculates the CMAC value of the App by calling the hardware-accelerated AES-CMAC algorithm in the HSM and stores the CMAC value in the HSM's dedicated DataFlash. After each subsequent reset or power-on restart, the HSM core is started first. It reads the CMAC value in its dedicated DataFlash and compares it with the calculated App image CMAC value. If the comparison results are consistent, the HSM core releases the main core resources, allowing the main core to run the App normally; if the comparison results are inconsistent, the HSM core maintains its current working state and prevents the main core from starting.

[0028] To address issue (3), this application provides a seamless OTA upgrade technology. The core of this technology lies in using a dual A / B system to perform OTA remote upgrades and complete A / B system switching while the vehicle is running, thereby reducing vehicle downtime during the upgrade process. This embodiment proposes a secure boot strategy adapted to seamless OTA upgrades, specifically as follows: First, the boot verification of the Bootloader program is cancelled; second, for the App images stored in both A / B zones, HSM-based CMAC integrity verification operations are performed respectively; and finally, error handling is implemented after boot verification failure.

[0029] In a preferred embodiment of this application, the above-mentioned refresh process should comply with information security, and the steps include: firstly, before executing the download request, it is necessary to securely access the 27 service, using a random number as the seed, and using the AES-CMAC value generated based on the random number and the key stored in the ECU as the key. Only after passing the secure access verification is the operation of Flash allowed; then, the downloaded data needs to be verified by the HSM core's asymmetric encryption algorithm RSA-4096 to ensure the integrity and security of the refresh packet during the refresh process; finally, the HSM core is requested to use the AES-CMAC algorithm to calculate the CMAC value, and the encrypted code used for the calculation has passed the refresh packet verified by RSA in the previous step.

[0030] In a preferred embodiment of this application, when the ECU side calls the AES-CMAC algorithm of the HSM core for computation, the time consumption should be taken into account. Since the App code area to be computed is large and the address and length are relatively fixed, in order to avoid affecting the overall refresh efficiency and power-on startup time, the method of directly processing the complete data segment is adopted, and hardware acceleration is used to obtain the shortest computation time.

[0031] This architecture abandons the traditional bootloader's pre-boot verification step, instead relying on kernel-level security mechanisms to directly ensure the legitimacy of the boot process. After completing a firmware flashing operation (such as OTA upgrade or local update), the system automatically performs firmware integrity verification and updates the corresponding CMAC (Cipher-based Message Authentication Code) value. This process, combined with an AB dual-zone (Bank A / B) storage mechanism, achieves redundant firmware backup and version rollback capabilities. Through the above design, the system ensures that the entire process from "firmware flashing" to "integrity verification" to "normal boot" is secure (defending against illegal code injection), stable (preventing system crashes due to flashing failure), and maintainable (reducing manual intervention).

[0032] The system adopts a multi-core collaborative hardware architecture: the application core (Core3) acts as the main executor of the refresh service, responsible for firmware reception, writing to the storage area, and refresh status management; the main core (Core0) schedules the encryption service, including receiving requests, parsing parameters, and allocating computing resources; the HSM core relies on its built-in hardware encryption acceleration engine to provide efficient cryptographic operation support. Through the standardized interface and cross-core communication mechanism (IOC) provided by the runtime environment (RTE), the system implements asynchronous requests and callbacks between cores, building a verification system that is "securely isolated, transparent in process, and functionally scalable." The specific technical implementation is as follows: Seamless refresh trigger mechanism After the refresh service in the application core (Core3) completes firmware data reception, preliminary verification, and writing to the target storage area, it automatically triggers the CMAC update process once it detects a "firmware write successful" status indicator (such as a data write complete signal or RSA signature verification passed). This process requires no manual user intervention or external commands and is entirely driven by the state machine within the refresh logic. The state machine triggers preset security verification events by monitoring the refresh status code in real time (such as changing from "writing" to "write complete"), thereby ensuring that integrity verification is enforced after each firmware update. This mechanism fundamentally avoids verification omissions caused by human negligence or system anomalies, preventing tampered firmware from being loaded and run.

[0033] Multi-core collaboration and cross-core communication mechanisms.

[0034] Once the application core (Core3) confirms the firmware update is complete, it initiates a call through the cross-core service interface provided by RTE (e.g., RTE_Call_CryptoRequest). It encapsulates the CMAC generation request into structured data (containing parameters such as the starting address, length, version number, and target bank identifier of the firmware code region to be verified) and sends it to the main core (Core0) via the IOC channel. Upon receiving the request, the Cryptographic Service Manager (CSM) running on the main core first verifies the validity of the parameters (e.g., whether the code region is within the secure address range and whether the version number conforms to the upgrade rules). If the verification passes, it calls the hardware encryption interface of the HSM core (e.g., HSM_Crypto_CMACGenerate) to assign the actual AES-CMAC computation task to the HSM core for execution.

[0035] After receiving the computation request, the HSM core loads the preset CMAC key and uses the hardware acceleration engine to perform AES-CMAC computation on the firmware data in the specified code region (a one-time processing method that directly processes the complete data segment, resulting in faster speed and avoiding impact on upgrade efficiency), generating the firmware's CMAC digest value. The computation result (including the CMAC value and status code) is then returned to the main core (Core0) via the IOC channel. After receiving the result, the main core notifies Core3 to update the refresh status (e.g., from "Pending Verification" to "Verifying") through an asynchronous event mechanism (such as triggering an interrupt on Core3 or pushing the result to its message queue).

[0036] This multi-core collaborative process adopts a non-blocking asynchronous mode: after Core3 initiates a request, it does not need to wait for the result and can immediately release resources to execute other tasks (such as responding to refresh diagnostic services or feeding the watchdog), which significantly improves the system's response efficiency and parallel processing capabilities.

[0037] CMAC Update and Integrity Verification Upon receiving a CMAC generation request, the HSM core first retrieves the pre-set CMAC root key from its built-in secure storage area (this key is burned at the factory and can only be accessed through the HSM internal interface). Combining this with the code region range specified in the request (typically covering application code segments, critical configuration data segments, and core driver segments, excluding temporary data areas and log areas), the HSM core uses a hardware-accelerated AES-CMAC engine to calculate the firmware digest. After calculation, the HSM core compares the generated CMAC value with the "expected CMAC value" signed by the publisher and carried in the firmware flash package.

[0038] If the two match, the HSM core returns a "verification passed" status to the main core. Based on this, the system determines that the firmware is intact and valid, allowing subsequent bank switching or normal startup. If the comparison is inconsistent (possibly due to firmware tampering or write errors), the HSM core immediately triggers a security exception handling mechanism: sending a "verification failed" alarm to the main core, recording an exception log in the HSM secure storage area (to prevent tampering), and locking the storage area where the target firmware is located (preventing loading), thereby preventing illegal code execution at the hardware level.

[0039] The generated valid CMAC value is flexibly stored according to the system security level requirements: it is preferentially stored in the HSM core's dedicated secure DataFlash area (with hardware-level anti-erasure and anti-illegal access protection, which can only be read and written by the HSM core); it can also be written to an external high-security module (such as an independent secure core ICU-S) according to the configuration to ensure that the verification data is not maliciously tampered with or accidentally erased during its life cycle.

[0040] AB dual-zone mechanism and seamless refresh collaboration The system employs an AB dual-zone (Bank A / B) storage architecture, with each Bank being a physically independent FLASH storage area. Each Bank has a complete firmware image storage space (including application code and configuration data) and an independent CMAC verification data storage area, sharing a set of activation status control logic. During normal operation, only one Bank is in an "active state" (responsible for loading and running the firmware), while the other Bank is in an "inactive state" (used to receive new firmware and not involved in the current boot process). The system stores the identifier of the currently active Bank through a dedicated hardware register (such as SCDS0.CFSWSTT) (for example, a register value of 0 indicates Bank A is active, and a value of 1 indicates Bank B is active). During the integrity verification phase, the system automatically selects the corresponding Bank's CMAC data for comparison based on this identifier.

[0041] In the seamless refresh process, the application core (Core3) first reads the SCDS0.CFSWSTT register value to determine the current inactive bank (e.g., if the current active bank is A, then the inactive bank is B). Subsequently, the new firmware is written to this inactive bank by default. Before writing, the system erases the old data in this bank to avoid residue; during the writing process, an asymmetric encryption algorithm RSA-4096 is used for verification to ensure data integrity; after writing is complete, a CMAC update calculation and verification process for this inactive bank is triggered (i.e., the aforementioned multi-core collaborative CMAC operation).

[0042] If CMAC verification passes, the system completes the bank-level switch by updating the SCDS0.CFSWSTT register value (e.g., changing 0 to 1, switching the active bank to B), achieving a smooth transition of firmware versions. The next time the system boots, it will automatically load the firmware from the newly activated bank. If CMAC verification fails (e.g., the firmware has been tampered with) or an anomaly occurs during the update process (e.g., a power outage causing write interruption), the system will maintain the SCDS0.CFSWSTT register value unchanged, still loading the firmware from the original active bank and booting normally, thus ensuring the security of the update process and the recoverability of the system.

[0043] Asynchronous processing and state management The entire CMAC update process employs a dual management mechanism of "event-driven + state machine". After the application core (Core3) initiates a CMAC request via RTE, it immediately releases the encryption service request resources, returns to the "request submitted" state, and then continues to execute other preset tasks (such as cleaning up temporary files or reporting the refresh status). When the HSM core completes the encryption operation and returns the result, the main core (Core0) triggers the "CMAC result processing" event of Core3 through a callback mechanism (such as calling the preset CmacResultCallback function of Core3). In this event, Core3 updates its local state machine (such as switching from "pending verification" to "verification passed" or "verification failed") and determines the subsequent process based on the state (if verification passes, a bank switch is performed; if verification fails, an exception alarm is triggered).

[0044] This mechanism incorporates robust exception handling capabilities: it supports timeout detection (dynamically setting a threshold based on the size of the code to be verified, e.g., 100ms for code <1MB, 500ms for code >10MB, with automatic retries after timeout); it supports error retries (automatically re-initiating a request after a single failure, up to 3 times; if all retries fail, a safe exception process is initiated); and it supports concurrency control (protecting the CMAC request queue with mutex locks to prevent multi-task resource contention and ensure the uniqueness of computation results). These measures collectively guarantee the system's secure recovery capabilities in abnormal situations such as communication interruptions or computation timeouts.

[0045] Secure storage and key management The HSM core integrates an independent hardware encrypted storage unit (supporting AES-256 encryption protection) specifically for storing critical security data required for CMAC calculations, including: CMAC keys (stored categorized by version, supporting multiple versions of keys to facilitate key updates), CMAC checksums corresponding to each Bank (bound to the Bank identifier to ensure matching), and the device certificate chain (including the device identity certificate and the vendor root certificate, used to verify the legality of the keys).

[0046] All encryption operations (including CMAC generation, key derivation, and digest comparison) are performed within a closed environment inside the HSM core. The main core (Core0) and application core (Core3) can only send operation requests or receive final results through standardized interfaces (such as the Crypto_* series interfaces provided by HSM). They cannot directly access the key data or intermediate values ​​inside HSM, which ensures the physical isolation and operational trustworthiness of the encryption process from an architectural perspective.

[0047] The system supports obtaining key resources via the Crypto_KeySearch interface: The caller (such as the main core Core0) needs to provide a unique key identifier (key ID). The interface will first verify the caller's permissions (checking the security level) and the validity of the key (such as whether it is within its validity period and has not been marked as "expired"). After successful verification, a key handle (not the plaintext key) that is only valid within the current session is returned. The caller uses this handle to initiate encryption operations, thereby reducing the risk of key leakage. Simultaneously, the system supports dynamic key updates: New keys must carry a vendor signature (verified through the root certificate). During updates, the old key is first marked as "to be expired," the new key is activated, and the CMAC value is recalculated. Once the system is running stably, the old key is deleted, achieving seamless key updates.

[0048] Security advantages of seamless refresh and dual-zone collaboration This system constructs a closed-loop security protection through a collaborative mechanism of "refresh-to-verify" and "dual-zone redundancy." Once the firmware is written to an inactive bank, CMAC calculation and comparison are immediately triggered. Only after successful verification will the bank switch be prepared. The entire process has no verification delay, completely eliminating the security window period that may exist between "firmware refresh and startup" in traditional bootloader-less architectures (i.e., the risk of illegal firmware being loaded due to verification delay).

[0049] The system automatically updates the CMAC value, selects the Bank activation status, and synchronizes the status between cores (through real-time information transmission via IOC). The entire process is completely transparent to users (such as vehicle maintenance personnel) and upper-layer applications (such as vehicle control systems), requiring no additional operations (such as manual restarts or inputting verification commands). This design not only enhances the system's security (anti-tampering, anti-abnormal startup) and reliability (avoiding system unavailability due to refresh failures), but also significantly reduces maintenance costs—reducing the number of on-site repairs required due to refresh anomalies and shortening system downtime.

Claims

1. A method and system for secure AB dual-zone boot based on an HSM core, characterized in that: The system adopts a multi-core collaborative hardware architecture, including: The application core, as the main body responsible for executing the refresh service, is responsible for receiving firmware, writing it to the storage area, and managing the refresh status. The main core schedules encryption services, including receiving requests, parsing parameters, and allocating computing resources. The HSM core, relying on its built-in hardware encryption acceleration engine, provides efficient cryptographic operation support; This secure boot scheme uses the HSM core to perform hash calculations and store the App code in the HSM core's dedicated DataFlash. The ECU receives the refresh command from the refresh tool. After the refresh process is successfully completed, it writes the App validity flag to the CODE FLASH. At the same time, it calculates the CMAC value of the App by calling the hardware-accelerated AES-CMAC algorithm in the HSM core and stores the CMAC value in the HSM core's dedicated DataFlash. After each subsequent reset or power-on restart, the HSM core is started first, and the CMAC value in its dedicated DataFlash is read and compared with the calculated App image CMAC value. If the comparison results are consistent, the HSM core releases the main core resources, allowing the main core to run the App normally; if the comparison results are inconsistent, the HSM core maintains its current working state and prevents the main core from starting. The A / B dual-system approach enables OTA remote upgrades and A / B system switching while the vehicle is running. Before executing the download request, secure access via service 27 is required. A random number is used as the seed, and an AES-CMAC value generated from the random number and a key stored in the ECU is used as the key. Only after secure access verification is Flash access permitted. The downloaded data then needs to be verified using the HSM core's asymmetric encryption algorithm RSA-4096 to ensure the integrity and security of the refresh packet during the flashing process. Finally, the HSM core is requested to calculate the CMAC value using the AES-CMAC algorithm. The encrypted code used for the calculation has passed the previous RSA verification of the refresh packet.

2. The AB dual-zone secure boot method and system based on an HSM core according to claim 1, characterized in that: It also includes a seamless refresh triggering mechanism. After the refresh service in the application core completes the firmware data reception, preliminary verification and writing to the target storage area, once it detects the "firmware write successful" status indicator, such as the data write complete signal or RSA signature verification passed, it will automatically trigger the CMAC update process.

3. A method and system for AB dual-zone secure boot based on an HSM core according to claim 1 or 2, characterized in that: It also includes multi-core collaboration and cross-core communication mechanisms. When the application core confirms that the firmware update is complete, it will initiate a call through the cross-core service interface provided by RTE. It encapsulates the CMAC generation request into structured data, including parameters such as the starting address, length, version number, and target Bank identifier of the code region of the firmware to be verified, and sends it to the main core through the IOC channel. After receiving the request, the encryption service manager running on the main core first verifies the legality of the parameters, such as whether the code region is within the secure address range and whether the version number conforms to the upgrade rules. After the verification is passed, it calls the hardware encryption interface of the HSM core and assigns the actual AES-CMAC operation task to the HSM core for execution. After receiving the computation request, the HSM core loads the preset CMAC key and uses the hardware acceleration engine to perform AES-CMAC computation on the firmware data in the specified code region, generating the firmware's CMAC digest value. The computation result, including the CMAC value and status code, is then returned to the main core through the IOC channel. After receiving the result, the main core notifies the application core to update the refresh status, such as changing from "pending verification" to "verification", through an asynchronous event mechanism, such as triggering a Core3 interrupt or pushing the result to its message queue.

4. The AB dual-zone secure boot method and system based on an HSM core according to claim 3, characterized in that: It also includes CMAC update and integrity verification. After receiving the CMAC generation request, the HSM core first retrieves the preset CMAC root key from its built-in secure storage area. Combined with the code region range specified in the request, the HSM core uses the hardware-accelerated AES-CMAC engine to calculate the firmware digest. After the calculation is completed, the HSM core compares the generated CMAC value with the "expected CMAC value" carried in the firmware flash package and signed by the publisher. If the two match, the HSM core returns a "verification passed" status to the main core. The system then determines that the firmware is intact and valid, allowing subsequent Bank switching or normal startup. If the comparison does not match, the HSM core immediately triggers a security exception handling mechanism: sends a "verification failed" alarm to the main core, records an exception log in the HSM secure storage area, and locks the storage area where the target firmware is located, thereby preventing the execution of illegal code from the hardware level. The generated valid CMAC value is flexibly stored according to the system security level requirements: it is preferentially stored in the dedicated secure DataFlash area of ​​the HSM core, which has hardware-level anti-erasure and anti-illegal access protection, and can only be read and written by the HSM core; it can also be written to an external high-security module, such as an independent secure core ICU-S, to ensure that the verification data is not maliciously tampered with or accidentally erased during its life cycle.

5. The AB dual-zone secure boot method and system based on an HSM core according to claim 1, characterized in that: It also includes an AB dual-zone mechanism and seamless refresh collaboration. The system adopts an AB dual-zone storage architecture, with two banks being physically independent FLASH storage areas. Each bank has a complete firmware image storage space and an independent CMAC verification data storage area, and shares a set of activation status control logic. During normal operation, only one bank is in the "active state" and the other bank is in the "inactive state". The system stores the identifier of the currently active bank through a dedicated hardware register. For example, a register value of 0 indicates that Bank A is active, and a value of 1 indicates that Bank B is active. During the integrity verification phase, the system automatically selects the CMAC data of the corresponding bank for comparison based on this identifier. In the seamless refresh process, the application core first reads the value of the SCDS0.CFSWSTT register to determine the current inactive bank. If the current active bank is A, then the inactive bank is B. Subsequently, the new firmware is written to the inactive bank by default. Before writing, the system will erase the old data in the bank to avoid residue. During the writing process, an asymmetric encryption algorithm, RSA-4096, is used for verification to ensure data integrity. Once the write operation is complete, the CMAC update calculation and verification process for the inactive Bank is triggered. If CMAC verification passes, the system updates the SCDS0.CFSWSTT register value, for example, changing it from 0 to 1, and switches the active bank to B, completing the bank-level switch and achieving a smooth transition of firmware versions. The next time the system starts, it will automatically load the firmware from the newly activated bank. If CMAC verification fails or an anomaly occurs during the refresh process, the system will maintain the SCDS0.CFSWSTT register value unchanged, still load the firmware from the original active bank, and start normally, thereby ensuring the security of the update process and the recoverability of the system.

6. The AB dual-zone secure boot method and system based on an HSM core according to claim 1, characterized in that: It also includes asynchronous processing and state management. The entire CMAC update process adopts a dual management mechanism of "event-driven + state machine". After the application core initiates a CMAC request through RTE, it immediately releases the encryption service request resources and returns the "request submitted" status. Then it continues to execute other preset tasks, such as cleaning up temporary files or reporting the refresh status. When the HSM core completes the encryption operation and returns the result, the main core triggers the "CMAC result processing" event of the application core through a callback mechanism, such as calling the application core's preset CmacResultCallback function. In this event, the application core updates the local state machine, such as switching from "pending verification" to "verification passed" or "verification failed", and determines the subsequent process according to the status. If the verification is successful, the Bank switch is executed; if the verification fails, an exception alarm is triggered. The mechanism has built-in robust exception handling capabilities: it supports timeout detection and dynamically sets the threshold based on the size of the code to be verified. For example, the threshold is 100ms when the code size is <1MB and 500ms when it is >10MB. It automatically retryes after a timeout. Supports error retries. Automatically re-initiates after a single failed request, up to 3 times. If all retries fail, it enters a security exception process. It supports concurrency control, protects the CMAC request queue with a mutex lock to prevent multi-task resource contention, and ensures the uniqueness of the calculation result.

7. The AB dual-zone secure boot method and system based on an HSM core according to claim 1, characterized in that: It also includes secure storage and key management. The HSM core integrates an independent hardware encrypted storage unit that supports AES-256 encryption protection, including: CMAC key, CMAC checksum corresponding to each bank, and device certificate chain; All encryption operations are performed in a closed environment inside the HSM core. The main core and application core can only send operation requests or receive final results through standardized interfaces, and cannot directly access the key data or intermediate values ​​inside the HSM. The system supports obtaining key resources through the Crypto_KeySearch interface: the caller needs to pass in a unique key identifier. The interface will first verify the caller's permissions and the validity of the key. After successful verification, it will return a key handle that is only valid within the current session. The caller uses this handle to initiate encryption operations, thereby reducing the risk of key leakage. At the same time, the system supports dynamic key updates: the new key must carry the vendor's signature. When updating, the old key is first marked as "to be expired", the new key is activated and the CMAC value is recalculated. After the system is running stably, the old key is deleted, realizing seamless key updates.

Images