A method and system for firmware protection based on a secure coprocessor

Abstract

The present invention relates to the technical field of firmware protection, and particularly to a method and system for firmware protection based on a secure co-processor. The method includes the following steps: obtaining co-processor feature data; extracting hardware entropy source data according to the co-processor feature data; generating a hardware root of trust key based on the hardware entropy source data; performing partition processing on the firmware based on the hardware root of trust key to obtain firmware partition data; constructing hierarchical verification structure data according to the firmware partition data; implementing firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data; establishing a secure communication channel between processors according to the integrity verification data; performing a two-way authentication process based on the secure communication channel and generating session key data; monitoring the firmware running environment based on the session key data. The present invention extracts the hardware entropy source by measuring the physical characteristics of the co-processor, establishes an unforgeable hardware root of trust, and fundamentally improves the security.

Description

Technical Field

[0001] The present invention relates to the technical field of firmware protection, and particularly to a method and system for firmware protection based on a secure co-processor. Background Art

[0002] A co-processor is a processor that assists the main processor (CPU) in completing specific tasks. It cannot run independently and must be used in conjunction with the main processor. The main processor assigns some specific computing tasks to the co-processor, and the co-processor executes these tasks under the control of the main processor. When the co-processor finishes the tasks, it returns the results to the main processor. This way of division of labor and cooperation can improve the overall efficiency of the system. A secure co-processor is a processing unit dedicated to enhancing system security. It usually runs independently of the main processor and focuses on executing security-related tasks such as data encryption, authentication, secure boot, key management, etc. Secure co-processors are usually used to improve the anti-attack ability of the system, prevent data leakage and malicious tampering.

[0003] However, traditional firmware protection methods (such as digital signatures and hash checks at the software level) mainly rely on software implementation, which makes them vulnerable to hardware attacks (such as physical tampering, side-channel attacks, debug interface attacks, etc.). Secure co-processors provide hardware-level encryption and authentication, which can effectively prevent these hardware attacks and improve the overall security of the firmware. The startup process of the firmware usually requires integrity verification and authentication, but without hardware support, the startup process is vulnerable to attacker tampering. Secure co-processors provide independent security protection at the firmware startup stage, ensuring the integrity and trustworthiness of the startup firmware and avoiding security vulnerabilities in the traditional startup process. Summary of the Invention

[0004] Based on this, it is necessary for the present invention to provide a method and system for firmware protection based on a secure co-processor to solve at least one of the above technical problems.

[0005] To achieve the above object, a method for firmware protection based on a secure co-processor includes the following steps:

[0006] Step S1: Obtain co-processor feature data; extract hardware entropy source data according to the co-processor feature data; generate a hardware root of trust key based on the hardware entropy source data;

[0007] Step S2: Perform partition processing on the firmware based on the hardware root of trust key to obtain firmware partition data; construct hierarchical verification structure data according to the firmware partition data; perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data;

[0008] Step S3: Establish a secure communication channel between processors based on the integrity verification data; perform a two-way authentication process based on the secure communication channel, and generate session key data;

[0009] Step S4: Monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain protection status data during firmware operation;

[0010] Step S5: Monitor data access requests according to the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; establish a data anti-tampering protection mechanism according to the hardware encryption result data to obtain firmware data security status data.

[0011] The present invention also provides a firmware protection system based on a secure co-processor for executing the above-mentioned firmware protection method based on a secure co-processor. The firmware protection system based on a secure co-processor includes:

[0012] An entropy source generation module, configured to obtain co-processor feature data; extract hardware entropy source data according to the co-processor feature data; generate a hardware root of trust key based on the hardware entropy source data;

[0013] A firmware partitioning and verification module, configured to perform partitioning processing on the firmware based on the hardware root of trust key to obtain firmware partition data; construct hierarchical verification structure data according to the firmware partition data; perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data;

[0014] A secure communication establishment module, configured to establish a secure communication channel between processors based on the integrity verification data; perform a two-way authentication process based on the secure communication channel, and generate session key data;

[0015] An execution environment monitoring module, configured to monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain protection status data during firmware operation;

[0016] A data access encryption module, configured to monitor data access requests according to the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; establish a data anti-tampering protection mechanism according to the hardware encryption result data to obtain firmware data security status data.

[0017] The present invention realizes comprehensive security protection for firmware at different stages through a firmware protection method based on a security coprocessor. Refined protection measures are taken for each link from firmware startup to the running process. First, by obtaining the characteristic data of the coprocessor and extracting the hardware entropy source data based on these data, a hardware root of trust key is generated. This key serves as the basic root of trust for firmware protection, ensuring the reliability of subsequent security operations. The generation of the hardware entropy source data makes full use of the hardware characteristics, ensuring the randomness and security of the root key and avoiding potential risks brought by software attacks. The firmware is partitioned through the hardware root of trust key to obtain the partition data of the firmware. On this basis, a hierarchical verification structure data is constructed to implement firmware startup security verification. Through the hierarchical verification structure, each module of the firmware can independently verify its integrity, thus avoiding security vulnerabilities caused by a single checkpoint. This process ensures that the firmware has not been tampered with or forged during startup, eliminating the loading of malicious firmware from the source and enhancing the security of the startup process. Based on the integrity verification data, a secure communication channel between processors is established in the system, and a session key is generated through a two-way authentication process. The two-way authentication not only ensures the authentication between the firmware and the processor, preventing identity forgery, but also provides encryption protection for subsequent secure communication. The generated session key is used to ensure the confidentiality and integrity during the data exchange process between the firmware and the processor, avoiding man-in-the-middle attacks and the leakage of communication data. Based on the session key, the system monitors the running environment of the firmware in real time. By monitoring the running state of the firmware, the system can timely identify potential abnormal behaviors, such as memory tampering, illegal access, or external attacks, and can actively implement protection measures. These protection measures can be interruption operations, alarms, or repair behaviors, thus providing dynamic security guarantees during the firmware operation, preventing malicious behaviors from damaging the firmware, and ensuring the secure operation of the firmware. The system monitors the data access requests according to the firmware protection status data and performs hardware encryption processing on the data access process. Through hardware encryption, the system ensures that during the firmware operation, all access requests are encrypted and protected, avoiding data theft or tampering. In addition, the system establishes a data anti-tampering protection mechanism to ensure that the firmware data always maintains its integrity and security during storage and transmission, thus providing anti-tampering protection for the firmware data and preventing data leakage and tampering. In summary, the present invention conducts comprehensive protection for each link from firmware startup, operation to data access through multi-level protection measures, makes full use of the hardware characteristics of the security coprocessor, and realizes efficient security protection for the firmware at each stage. This method can effectively prevent the firmware from being maliciously tampered with, leaked, or attacked in other forms, ensuring the overall security of the system, and providing a strong protection scheme for embedded systems, Internet of Things devices, and other hardware systems that require high security. Brief Description of the Drawings

[0018] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non - restrictive embodiments read in conjunction with the accompanying drawings:

[0019] Figure 1 It is a schematic flowchart of the steps of a method for firmware protection based on a security coprocessor according to the present invention;

[0020] Figure 2 is Figure 1 a detailed schematic flowchart of step S1 in Specific Embodiments

[0021] The technical method of the present invention will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are part of the embodiments of the present invention, rather than all of them. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without creative efforts belong to the scope of protection of the present invention. In addition, the accompanying drawings are only schematic illustrations of the present invention and are not necessarily drawn to scale. The same reference numerals in the drawings represent the same or similar parts, and thus repeated descriptions thereof will be omitted. Some of the block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. The functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor methods and / or microcontroller methods. It should be understood that although terms such as "first" and "second" may be used here to describe various units, these units should not be limited by these terms. These terms are only used to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, the first unit can be called the second unit, and similarly the second unit can be called the first unit. The term "and / or" used here includes any and all combinations of one or more of the listed related items.

[0022] To achieve the above object, please refer to Figures 1 to 2 The present invention provides a method for firmware protection based on a security coprocessor, and the method includes the following steps:

[0023] Step S1: Obtain coprocessor feature data; extract hardware entropy source data according to the coprocessor feature data; generate a hardware root - of - trust key based on the hardware entropy source data;

[0024] In an embodiment of the present invention, in a trusted execution environment (TEE), the system first obtains its characteristic data from a coprocessor (such as a TPM module or a secure encryption coprocessor SE). The characteristic data includes the unique identifier of the coprocessor, version information, register status data, and initialization configuration data provided by the manufacturer. The system then extracts hardware entropy source data such as dynamic voltage, current fluctuation signals, or the original output values of a random number generator for entropy source generation from these characteristic data. During the extraction process, the rate of change of the voltage fluctuation amplitude within a finite time window is used as the input, and low-entropy segments are removed through filtering and a randomness metric function, and the high-entropy part is retained to construct the original randomness input. The system uses a distributed entropy evaluation model to evaluate the quality of the extracted hardware entropy source data. After meeting the minimum entropy requirement (for example, the minimum entropy is higher than 0.98 per 128 bits), it is used as a seed and input into a key expansion module based on inverse permutation mapping to generate a 256-bit hardware root of trust key. This key serves as the basic security credential for subsequent steps such as firmware verification, communication verification, and data encryption, and is used to support the construction of the trust chain throughout the firmware life cycle.

[0025] Step S2: Perform partition processing on the firmware based on the hardware root of trust key to obtain firmware partition data; construct hierarchical verification structure data according to the firmware partition data; perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data;

[0026] After generating the hardware root of trust key in an embodiment of the present invention, the system performs partition processing on the firmware to be started. The specific method is to logically divide the firmware by functional modules, such as a startup boot code area, a driver initialization area, a security policy control area, and a peripheral control interface area, etc. Each partition is assigned a fixed offset address and a maximum memory boundary to form firmware partition data. The system uses a Merkle hash tree-based method to construct hierarchical verification structure data. First, calculate the SHA-512 digest value for each partition as the underlying leaf node, and then merge the digest values by level to generate upper-level hash nodes. Finally, generate a unique root hash value as the overall firmware integrity identifier. During the firmware startup phase, the system will calculate the hash value of each partition in real time and compare whether it is consistent with the hash nodes in the hierarchical structure, and recursively verify from bottom to top. If a certain level of node in the middle does not match, the abort mechanism will be triggered and integrity verification data will be recorded, including the failed partition index, the failed level, and the difference information between the expected hash and the current hash. This structure ensures that even if part of the firmware is tampered with, the affected area can be accurately located. In practical applications, it is recommended that the startup boot area of the embedded device be limited to within 64KB to ensure fast verification, while the policy control area can be set to 256KB for dynamic loading of policy scripts.

[0027] Step S3: Establish a secure communication channel between processors based on the integrity verification data; perform a two-way authentication process based on the secure communication channel, and generate session key data;

[0028] In the embodiment of the present invention, after the firmware startup integrity check is completed and the integrity verification data is obtained, it is determined whether to establish a secure communication channel between processors according to whether the check is successful. If the check passes, the main processor shakes hands with the coprocessor or remote trusted device through its root trust key, negotiates a session random number using the ECC elliptic curve key exchange algorithm (such as Curve25519), combines the unique identifiers and timestamps of both devices, and generates session key data through the HMAC-SHA3 algorithm. The length of the session key is determined according to the security level requirements. For example, a 512-bit key is generated under a high security level. The communication channel uses a TLS lightweight protocol variant to ensure low-latency and high-security two-way authentication communication in resource-constrained devices. During the authentication process, the main processor verifies the validity of the certificate chain signature of the coprocessor, and the coprocessor requires the main processor to present a proof of successful firmware startup signed by the root key. If the two-way authentication is successful, both parties can start subsequent key encapsulation, data transmission, or control command interaction. In practical applications, this mechanism is applicable to the data synchronization interaction between the control end and the execution end in industrial control devices to ensure that critical instructions are not tampered with by a man-in-the-middle.

[0029] Step S4: Monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain protection status data during firmware operation;

[0030] In the embodiment of the present invention, after the communication channel is established and the session key data is generated, the system configures the environment monitoring module during firmware operation using the session key. By continuously sampling and analyzing metrics such as stack space, exception interrupt calls, system call paths, and memory usage behaviors, a firmware operation profile based on a behavior model is constructed. The system uses lightweight anomaly detection algorithms (such as Isolation Forest or boundary detection based on K-means clustering) to perform real-time discrimination on the collected data to identify potential abnormal behaviors such as memory out-of-bounds, illegal system calls, or code segment modification. When an anomaly is detected, the system enables a protection mechanism according to the policy, such as forcibly rolling back to the nearest trusted operation snapshot, freezing the current thread execution, or transferring the current process to a simulation sandbox environment for execution, to prevent the spread of the anomaly. The process of enabling the protection mechanism will record information such as the protection trigger time, protection level, current call stack, and anomaly event label, which ultimately constitutes the protection status data during firmware operation. In an application example, in a medical device control system, the monitoring period can be set to every 10 ms, and the threshold for abnormal hard real-time response task paths is set to 2 consecutive timeouts to trigger an emergency downgrade protection.

[0031] Step S5: monitor data access requests according to the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; establish a data tamper-proof protection mechanism according to the hardware encryption result data to obtain firmware data security status data.

[0032] According to the protection status data of the aforementioned firmware during operation, when an external system or user process initiates a data access request, the embodiment of the present invention first determines whether the current protection status is a trusted state. If it is not trusted, the request is rejected or switched to read-only mode; if it is a trusted state, the hardware encryption processing flow is entered. The system uses session key data as a symmetric encryption seed, combines the data type label (such as configuration data, user key, log information) and visitor identification information in the access request, encrypts the data through the SM4 or AES-GCM algorithm, obtains hardware encryption result data, and adds an integrity label (such as CMAC or SHA-256 digest) to the encrypted data. Subsequently, the system constructs a data tamper-proof protection mechanism, and writes the encrypted result data and its meta information (including creation time, access path, key version, etc.) in a structured form to a tamper-proof storage area (such as eFuse or TPM NV storage area). In subsequent access requests, the system compares the existing encryption label with the current calculation result to identify whether the data has been tampered with, and finally forms firmware data security status data, including data tampering risk level, encryption strength index, visitor reputation evaluation, etc. This mechanism is suitable for applications that have integrity requirements for critical data, such as encrypting the flight parameter configuration table in a drone flight control system to ensure that it has not been maliciously modified before and during flight.

[0033] Preferably, step S1 comprises the following steps:

[0034] Step S11: During the coprocessor power-on initialization phase, measuring the transistor threshold voltage and static power consumption;

[0035] In the power-on initialization stage of the co-processor according to the embodiments of the present invention, the system first activates the process test module embedded in the bottom layer of the chip, and collects the electrical characteristic data of typical transistors in its core area through the on-chip test channel. Specifically, the system applies gradually increasing gate voltages to the control terminals of the selected NMOS and PMOS transistors respectively, and detects the voltage point at which the drain current first significantly rises as the transistor threshold voltage under the condition of a fixed drain-source voltage. At the same time, the static power consumption at the power input terminal of the entire co-processor is measured in the state where the chip is stationary and no tasks are being executed, and the static power consumption value is obtained through a precise low-power measurement circuit. The acquisition process needs to be carried out under a constant temperature (such as 25 degrees Celsius) and a stable power supply voltage (such as 1.2 volts) to ensure the comparability between different batches of devices. This process is usually carried out in the first power-on or reset initialization stage of the chip and is used to establish the basis for subsequent feature fingerprint templates. Taking the intelligent door lock chip as an example, its typical static power consumption is 0.05 watts, and the average threshold voltage of PMOS is 0.42 volts.

[0036] Step S12: Collect the startup response time and signal stability index of the co-processor memory unit;

[0037] After the co-processor is initialized according to the embodiments of the present invention, the self-check mechanism of its on-chip SRAM or Flash storage unit is activated. At the system clock frequency, a storage unit initialization loading command is initiated, and the time elapsed from the issuance of the loading command to the reading of the first stable data bit is measured using a high-speed signal sampling module as the startup response time. At the same time, the number of level transitions and the duration of the stable time window during the data output process are monitored to evaluate the signal stability index. In specific operations, the system repeats the test on 128 representative addresses with a sampling accuracy of 1 nanosecond per cycle, records the average response time and stability variance, and forms a startup behavior feature vector. The calculation methods of the signal stability index include the maximum level transition amplitude, the deviation of the rising and falling edge durations, and the signal-to-noise ratio statistic. When applied to a secure payment chip, the upper limit of the response time can be set to 200 nanoseconds, and the signal stability standard is that the number of transitions does not exceed 5 times and the steady state duration is not less than 90%.

[0038] Step S13: Obtain the reference operation speed and timing characteristics of the encryption module of the co-processor;

[0039] In the embodiment of the present invention, after the coprocessor completes the basic hardware loading, the system calls its integrated symmetric encryption module (such as AES or SM4) to perform a benchmark operation task. Using 512-byte random data as input, it executes a fixed number of rounds of encryption operations and records the total number of cycles used from the completion of input loading to the output of the ciphertext, which is converted into the benchmark operation speed. At the same time, the system extracts the timing characteristics of each stage of the encryption module (such as key expansion, round function, permutation, mixing, etc.) by monitoring the edge relationship between the control signal and the clock signal, including stage delay, inter-stage dependence path, parallelism utilization, etc. To improve the sampling accuracy, the system repeats the same task 10 times, and calculates the average performance after excluding the maximum and minimum values. Taking an industrial control security chip as an example, the average time-consuming for a single round of encryption of its AES module is 35 clock cycles, and it takes about 1450 clock cycles for the encryption module to complete the processing of 512-byte data, with a clock frequency of 150 MHz.

[0040] Step S14: Generate coprocessor feature data according to the transistor threshold voltage, static power consumption, startup response time, signal stability index, benchmark operation speed, and timing characteristics;

[0041] In the embodiment of the present invention, after respectively obtaining the transistor threshold voltage, static power consumption, storage response time, signal stability index, benchmark speed of the encryption module, and timing characteristics, a feature fusion method is used to generate coprocessor feature data. Specifically, the system first standardizes the above six types of physical quantities. For example, the response time is normalized to a floating-point value between 0 and 1; then, based on the cooperative entropy evaluation model, the independent entropy value of each feature and its joint entropy value with other features are calculated to determine its discrimination and uniqueness in the overall fingerprint; then, the different types of data are arranged in the structural order of timing characteristics - static power consumption - storage response - encryption speed by using a hierarchical feature splicing method, and finally a coprocessor feature vector with a length of 2048 bits is generated as the unique physical feature identity identifier of the coprocessor. This data is not only used for subsequent entropy source generation, but also supports device fingerprint binding and trust initialization verification. In an IoT security node, this feature data can be used as part of the initial verification conditions for the access gateway to prevent forged chips from accessing the network.

[0042] Step S15: Generate hardware entropy source data by using a ring oscillator array based on the coprocessor feature data;

[0043] Based on the co-processor feature data generated above, the embodiment of the present invention starts the ring oscillator array to collect data that can be used to generate the hardware entropy source. The specific method is that the system maps some feature values (such as the timing offset of the encryption module and the storage response variance) to oscillator control parameters, which are used to configure multiple ring oscillator units with different frequencies and phase delays, and high-precision counting of the oscillation times of these oscillators is performed within a specified time window. Since the ring oscillator is extremely sensitive to process variations, power supply fluctuations, and temperature, its output has a high degree of randomness. The system uses non-overlapping sampling windows to pack the count values into several bit segments, and uses a debiasing algorithm (such as the Von Neumann algorithm or the polynomial perturbation algorithm) to eliminate the significantly biased bits, and extracts a high-quality entropy bit stream as the hardware entropy source data. Usually, the oscillator array consists of 32 groups of ring oscillators, each group consists of 5-stage inverter chains, and an entropy stream of 128 Kb per second can be generated under a 100 MHz reference clock, which meets most embedded key generation tasks.

[0044] Step S16: Generate a hardware root of trust key based on the hardware entropy source data.

[0045] After obtaining high-quality hardware entropy source data, the embodiment of the present invention generates a hardware root of trust key based on this data. During implementation, the system first performs an in-chip fidelity detection on the entropy source data to verify whether its minimum entropy is higher than the system security threshold (such as 0.96), and detects whether there are long repeated bit sequences or periodic patterns. The entropy stream that passes the detection is input into the secure key derivation function (KDF) module as the key seed. The KDF module can be constructed based on HMAC, uses SHA3-512 as the digest core, and combines the co-processor identity identifier and the timestamp as additional inputs to generate a context-bound key. Finally, the hardware root of trust key output by the system is of a fixed length of 256 bits and is written into the key storage area of the co-processor. This area adopts a one-time write and permanent read-only protection mechanism to ensure that the root key cannot be read, modified, or copied during the chip life cycle. In the intelligent gateway device, this root key is used to sign the verification label of the firmware update package, or as the root node of the key derivation tree to generate a temporary session key, thereby realizing chain trust between devices.

[0046] Preferably, step S15 includes the following steps:

[0047] Step S151: Configure and start the built-in ring oscillator array according to the co-processor feature data, and set the sampling window to obtain oscillator configuration data;

[0048] After the co-processor feature data is obtained in the embodiment of the present invention, first, the feature quantities sensitive to circuit process fluctuations are extracted, including the transistor threshold voltage, the timing offset of the encryption module, and the signal stability index, as the configuration reference of the ring oscillator array. Taking each eigenvalue as a seed for oscillator configuration, the system uses internal registers to control the number of inverter stages, the load capacitance value, and the drive current intensity of each oscillator unit, so as to form diverse oscillation frequencies. After the array configuration is completed, the control logic starts all oscillator units and synchronously starts the sampling counter, and at the same time sets a fixed sampling window, such as 100 microseconds, and continuously counts the number of oscillations of each oscillator within this time window, which is called oscillator configuration data. Taking a set of typical parameters as an example, if the oscillator consists of 7-stage inverters, under a standard 1.2V power supply, the expected oscillation frequency of each oscillator ranges from 150 MHz to 250 MHz; within a 100-microsecond sampling window, the theoretical number of oscillations should be between 15,000 and 25,000, providing sufficient resolution for subsequent difference analysis.

[0049] Step S152: Record the oscillation count value within the sampling window based on the oscillator configuration data, and calculate the count difference between adjacent oscillator groups to obtain frequency difference data;

[0050] After the sampling window ends in the embodiment of the present invention, the system reads the count values of each ring oscillator during sampling, and pairs them up in logical number order to form adjacent oscillator groups. For example, the first group and the second group, the second group and the third group are paired up in turn, and the oscillation count difference between each pair is calculated, that is, the number of oscillations of the latter group is subtracted from the number of oscillations of the former group to obtain frequency difference data. The system can implement this difference calculation through a hardware comparator, and at the same time uses a sign bit to record the positive and negative attributes of the difference. To reduce the interference of high-frequency jitter errors, the system introduces a threshold filtering strategy. If the absolute value of the difference between a pair of oscillators is lower than the set noise threshold (such as within 5 times), the data of this pair is invalidated. Taking a certain acquisition as an example, the count of the first group is 22345, the count of the second group is 22411, and the difference is +66 times, so the frequency difference of this pair is positive; the count of the third group is 22120, and the difference compared with the second group is -291 times, which is negative. Such frequency difference values reflect the frequency non-uniformity of the ring oscillator unit caused by small disturbances such as process differences, power supply fluctuations, and temperature offsets, and are the key basis for constructing the entropy source.

[0051] Step S153: Convert the count difference in the frequency difference data into a bit sequence, where converting to a bit sequence specifically means recording it as bit sequence 1 when the difference is positive, recording it as 0 when the difference is negative, and discarding it when the difference is zero;

[0052] In the embodiment of the present invention, the count difference in the frequency difference data is converted into a normalized bit sequence. The specific rule is as follows: if a certain group of differences is positive, the corresponding bit is 1; if it is negative, it is 0; if it is zero, the data pair is discarded. This conversion process can be quickly mapped through a look-up table logic or a comparison module. At the same time, the system records the number of valid bits generated to control the overall entropy source bit quantity. During the conversion process, to avoid the influence of a continuous single-bit sequence on the entropy quality, the system can perform real-time distribution detection on the bit generation process. If the proportion of 1 or 0 in a certain round of bits exceeds 75%, the re-sampling mechanism is triggered. Taking the result of one sampling as an example, 60 groups of difference data are obtained, and 52 groups of them are non-zero differences. After conversion according to the rules, an initial bit sequence with a length of 52 bits is formed, such as "101001100111000...". Such bits represent the trend change of the adjacent oscillator frequency being "faster" or "slower" than the previous oscillator, and have high non-repeatability and unpredictability.

[0053] Step S154: Connect multiple groups of bit sequences to generate original hardware entropy source data with a length of at least 1024 bits;

[0054] In the embodiment of the present invention, multiple bit sequences are batch-connected to form original hardware entropy source data with a continuous length of at least 1024 bits. In the specific process, the system parallel extracts bit sequences from multiple oscillator arrays. For example, 4 array groups are started to generate in parallel, and each group outputs at least 256 valid bits according to the sampling window. After splicing, a complete entropy source data segment is obtained. The splicing method usually adopts sequential stacking, that is, each array sequence is continuously appended to ensure no repetition or coverage. At the same time, the system performs a one-bit distribution statistics on the splicing result to detect its entropy density (such as whether the information entropy index is greater than 0.98) to ensure that it meets the randomness requirements. If the data is less than 1024 bits, the system will increase the sampling window or restart the oscillator array sampling process once. In the typical initial startup process of a security chip, the system can complete three rounds of sampling within 300 milliseconds, generating a total of 3072-bit original entropy source bit stream as the original material for generating random seeds, signature private keys, or dynamic keys.

[0055] Step S155: Monitor the current ambient temperature, voltage fluctuation, and electromagnetic interference intensity to obtain environmental parameters; and perform a linear compensation process with a temperature coefficient of -0.2% / °C on the original hardware entropy source data according to the environmental parameters to obtain the hardware entropy source data.

[0056] After the embodiments of the present invention generate the original entropy source data, the on-chip sensors are started in real time to collect the current ambient temperature, the amplitude of the power supply voltage fluctuation, and the electromagnetic interference intensity, and generate environmental parameter data. The temperature is measured using an on-chip thermistor diode with an accuracy of ±1 degree Celsius; the voltage fluctuation is detected by the ADC channel for the VCC voltage jitter range; the electromagnetic interference is obtained by detecting the frequency anomaly rate in the oscillator count or the built-in EMI sensor to obtain the interference intensity level. The system performs linear debiasing compensation on the entropy source bit sequence according to the offset of the measured temperature value relative to the standard temperature (such as 25°C), and according to the empirical value that the bit error increases by 0.2% for every 1°C increase in the compensation coefficient. The compensation method is to perform bit re-encoding processing on the entire sequence. For example, the ratio of 1 and 0 is statistically counted in groups of 8 bits. If the deviation exceeds the current environmental compensation threshold, it is corrected according to the redundant sequence or logical inversion. Taking the entropy source data generated in a high-temperature environment (60°C) as an example, the system detects that the bit deviation slope reaches 6.8%. After temperature compensation, the entropy density is restored to more than 0.985, meeting the usage standard of the subsequent security module.

[0057] Particularly importantly, step S16 includes the following steps:

[0058] Step S161: Perform bit flip error correction on the hardware entropy source data to obtain high-steady-state entropy core data;

[0059] After the embodiments of the present invention obtain the hardware entropy source data with a length of more than 1024 bits, they first perform the detection and correction operations on the bit flip errors. Specifically, the BCH (Bose–Chaudhuri–Hocquenghem) error correction code is used for encoding matching, and the entropy source bit stream is logically block-divided, such as each group of 128 bits. The potential single-bit or multi-bit flip errors are detected and corrected by using the preset redundant check bits in each group. During the error correction process, the system extracts the check bits from each group, and calculates whether there is parity inconsistency or redundant bit conflict in the current entropy block through the hardware check logic. If an error is found, the decoding method based on matrix inverse operation is used to locate the error bit and flip and repair it. For example, it is found that the 5th bit is a flipped error after the BCH decoding of a certain group of entropy source block "10110011...". The system changes this bit to the correct value "0" and then reorganizes the entire entropy source data stream. After completing the error correction of all blocks, the system will verify the stability and consistency of the entire data stream through multiple rounds of CRC32 check, and finally form high-steady-state entropy core data with no significant bit errors and an entropy density maintained above 0.99 for subsequent use as an encryption seed. In a certain type of security authentication chip, this error correction process can be completed within 5 ms, and it is ensured that the entropy core data of each batch meets the strong consistency requirements for the secure random number generator in the national commercial cryptography standard.

[0060] Step S162: Perform SHA-256 hashing operation on the high-steady-state entropy core data to generate a 256-bit key seed; expand the key seed into a 512-bit initial master key;

[0061] In the embodiment of the present invention, after the entropy core stability is ensured, the system uses the SHA-256 hashing algorithm to perform a digest operation on the high-steady-state entropy core data. The hashing process is completed by the SHA hardware acceleration module built in the coprocessor. The input is the first 1024 bits or all valid entropy bits of the high-steady-state entropy core data, and the output is a 256-bit irreversible hash value, which serves as the basic seed for key generation. Subsequently, the system inputs the 256-bit seed into the master key expansion logic and expands it into an initial master key with a length of 512 bits through two rounds of hashing transformation and bit reconstruction operations. The expansion method usually adopts a double-hashing splicing strategy, that is, perform a SHA-256 calculation on the original 256-bit seed to obtain the first 256 bits, and then append the original seed with a random perturbation vector and calculate SHA-256 again to obtain the last 256 bits. The two segments are spliced into a complete 512-bit master key. In a certain type of trusted computing module, this master key structure can be used as an initialization key seed to participate in security tasks such as platform startup authentication, secure boot, and chip uniqueness confirmation, ensuring that the key not only originates from the physical hardware characteristics but also has a secure foundation with high entropy and high distribution balance.

[0062] Step S163: Generate a hierarchical key structure including a verification key, an encryption key, and a communication key based on the initial master key through the HKDF key derivation function;

[0063] In the embodiment of the present invention, the key derivation function HKDF implemented based on HMAC (Hash-based Message Authentication Code with key) is used to structurally split a 512-bit initial master key to generate a hierarchical key structure including multiple uses. First, the 512-bit master key is used as the input key material of HKDF, and a standard salt value (such as device ID or startup timestamp) and context tags (such as "verify_key", "encryption_key", "comm_key") are used as additional inputs. The two-stage operations of HKDF-Extract and HKDF-Expand are performed to derive three logically independent but related keys from the master key: the first segment is a 256-bit verification key, which is commonly used for digital signature or identity authentication; the second segment is a 256-bit encryption key, which is specifically used in the data encryption module; the third segment is a 128-bit communication key, which is used to protect the communication channel between the chip and the external bus. During the derivation process, the HKDF function calculates each key segment through HMAC-SHA256 to ensure that there is no content duplication between the keys for different uses and to meet the requirements of pseudo-randomness. In a smart terminal chip with a high security level, this derivation process can be completed within 20 milliseconds, and the key usage tags can be dynamically adjusted by the upper-layer security policy to meet various actual requirements such as subsequent trusted execution environments, TEE applications, or remote credential management.

[0064] Step S164: Store the hierarchical key structure in the secure storage area of the coprocessor to form a hardware root of trust key.

[0065] After the key structure derivation is completed in the embodiment of the present invention, the generated verification key, encryption key, and communication key are stored together in an independent secure storage area within the coprocessor chip to form a hardware root of trust key. This secure storage area is usually a section of anti-tamper on-chip EEPROM or eFuse configuration memory, which has characteristics such as write encryption protection, non-readable plaintext, and power-off data retention. The write operation is performed through a dedicated secure channel and is authorized by the secure boot management module, prohibiting direct access during system operation. To enhance security, the system performs AES encryption wrapping on each key data segment before writing, records the key version number and write timestamp, and activates the write protection bit to prohibit overwriting once the write is successful. Taking a domestic encryption chip as an example, its secure storage supports up to 4 groups of root of trust key backups, and the main system selects the currently used version through the OTP status word. This method ensures that throughout the system life cycle, each coprocessor can have a unique and unpredictable hardware root key, which serves as the starting point of the chip trust chain and supports the security foundation for various scenarios such as subsequent device identity authentication, secure boot verification, blockchain trusted storage, or password service invocation.

[0066] Preferably, the partitioning process of the firmware based on the hardware root of trust key described in step S2 includes:

[0067] Perform firmware binary code analysis based on coprocessor feature data, identify functional modules and data regions, and establish a firmware structure mapping table;

[0068] Divide the firmware security level based on the firmware structure mapping table, and divide the firmware into a boot area, a core execution area, a configuration area, and a data storage area;

[0069] Perform hash encryption on the firmware code in the boot area, and generate boot area signature data using the hardware trust root key;

[0070] Perform block slicing on the firmware code in the core execution area to generate sequence data of code blocks with a data block size of 4KB;

[0071] Calculate the HMAC value of each code block based on the hardware trust root key and the sequence data of code blocks, and construct a code integrity verification chain;

[0072] Encrypt and store the parameters in the configuration area, and set an access control policy based on the hardware trust root key;

[0073] Perform security isolation on the data storage area, and establish a data encryption channel based on the hardware trust root key;

[0074] Merge the boot area signature data, the code integrity verification chain, the configuration area access control, and the data encryption channel into firmware partition data.

[0075] In the system initialization stage of the embodiments of the present invention, the firmware binary code file to be analyzed in the coprocessor is loaded. This file is usually in binary executable format (such as ELF or raw binary BIN). A static analysis tool (such as the Capstone disassembly engine or IDA Pro plugin) is used to parse the firmware instruction by instruction byte by byte. Combining with the known coprocessor instruction set architecture (such as ARM Cortex-M or RISC-V), instruction patterns are identified and a control flow graph is constructed. The system logically separates the code segment and the data segment, and by matching call instructions, jump addresses, and data read ranges, the instruction ranges and data area boundaries corresponding to each functional module are identified. During the analysis process, auxiliary information such as symbol information, function entry characteristics, and string constant positions is also used to gradually mark functional areas such as initialization functions, driver calls, configuration interfaces, and interrupt responses. Finally, the system organizes the identification results into structured data to generate a firmware structure mapping table. This table records the starting address, length, attributes (code or data), associated hardware modules, and access methods of each module, serving as the basis for subsequent firmware security partitioning and processing. For example, in a coprocessor of an IoT device, a typical structure mapping table may include 0x00000000 - 0x0000FFFF as the boot code area, 0x00010000 - 0x0003FFFF as the main execution area, 0x00040000 - 0x00047FFF as the parameter configuration area, and 0x00048000 - 0x0007FFFF as the data buffer and communication storage area. The entire firmware file is logically divided into security levels according to the firmware structure mapping table. The division criteria are evaluated based on the role, access frequency, attack possibility, and content sensitivity of each area. The boot area is marked as the highest security level because it is responsible for initializing the system and loading the trusted execution environment; the core execution area is the second highest level, used to run the main business logic; the configuration area stores device initialization parameters and operation policies, classified as medium security level; while the data storage area stores communication buffer data or non-critical status information generated during operation, usually classified as the lowest security level but still requires isolation and protection. The division operation is completed by the secure firmware partitioning management module within the system, and corresponding access permissions and page attributes are set in the memory management unit (MMU) or storage mapping logic. For example, the boot area is set to read-only + executable, the configuration area is set to read-write + no execution permission, and the data area enables isolated address space mapping to prevent any code segment from accessing the data in this area. Finally, the security level division information is embedded in the firmware mapping table as additional metadata for subsequent secure control logic to call. The firmware code in the boot area cannot be changed after the system is burned, and it is necessary to ensure long-term trust through encryption and signature methods. The system first reads all the code content in the boot area (such as within 64KB) and generates a hash digest value for it through the SHA-256 algorithm.Subsequently, using the hardware root of trust key that has been generated and written to the coprocessor's secure area, a digital signature engine based on ECDSA or RSA is called to sign the hash value, generating boot signature data with a length of 256 bits or more. This signature data is packaged with the original code and, when the device boots, the hash is recalculated and verified by the firmware verification module to ensure that the boot code has not been tampered with. In a certain type of trusted boot environment, the verification process is completed when the coprocessor is first loaded, and if it fails, a hardware lockdown mechanism is triggered to prevent the device from entering an untrusted state. To achieve a higher level of code integrity monitoring, the system performs a chunking and slicing process on the firmware code in the core execution area. The specific operation is to divide the execution area into fixed-length data blocks in ascending address order. Each data block is set to a size of 4KB, corresponding to the typical size of a Flash erase page or cache page. The starting address, data content, and block number of each code block are recorded as a structured sequence. If the total size of the core execution area is 256KB, the system will generate 64 consecutively numbered code blocks, each numbered from Block0 to Block63 in sequence. Subsequently, the system will perform independent integrity encryption processing on each block and support local verification and loading during operation. After the code blocks are chunked, the system uses the hardware root of trust key as the encryption seed for the HMAC (Hash-based Message Authentication Code) algorithm to calculate the HMAC value for each 4KB code block individually. The system uses the HMAC-SHA256 algorithm for processing. Each time, the block number is used as the tag and the block content is used as the message body input, and a 256-bit checksum is output. The HMAC values of each block are concatenated in order of their numbers to form a complete code integrity verification chain. This verification chain is used for the dynamic verification mechanism during firmware operation. For example, when the coprocessor executes Block32, it will retrieve the expected HMAC value from the verification chain and compare it with the real-time calculation result. If there is a mismatch, an interrupt or core locking process will be triggered. This mechanism effectively prevents the code from being implanted or replaced in the middle and is commonly used to protect the security of critical instructions in industrial control, financial terminals, and cryptographic modules. The configuration area stores information such as parameters required for firmware operation, device identifiers, and dynamic key configurations. The system performs symmetric encryption processing on this area when building the firmware image. Specifically, the AES-GCM algorithm is used for encryption. The key is derived from the hardware root of trust key, and a unique initialization vector is generated for each set of configuration parameters to enhance the encryption strength. At the same time, the system embeds an access control policy in the configuration access logic, allowing only the trusted boot area or execution area code to access the configuration after authentication. Other code areas will be rejected by the MMU or an exception will be thrown if they attempt to access the configuration area. For example, in a certain device, the configuration area is 8KB. The system sets access conditions for information such as "Wi-Fi configuration" and "system identification code" in it, and uses timestamps and access counters to determine the frequency of illegal access, ensuring the integrity and confidentiality of the configuration parameters.The data storage area is used to cache the status data, intermediate communication data or external interface return results generated during the operation of the system, and the system performs security isolation on it through hardware logic. In terms of address mapping, a separate address space is demarcated for this area, and through the security MMU configuration, it is restricted to read-write only and non-executable. At the same time, an AES encryption and decryption channel module generated based on the hardware trust root key is deployed in front of the data access interface. Each time data is written, it is processed by the encryption module and decrypted in real time when read. This mechanism ensures that even if the Flash or SRAM is captured by an external probe, the plaintext data cannot be restored. For example, the communication buffer used by a certain encryption communication module is 32KB, and its data is encrypted and processed in the AES-CTR mode, and the initial counter is dynamically refreshed each time to avoid data replay attacks. After completing the signature data of the boot area, the integrity verification chain of the core code, the access control policy of the configuration area, and the encryption channel setting of the data storage area, the structures of each part are integrated into a complete firmware partition data structure. This structure is usually encoded in the TLV (Type-Length-Value) format, including the type identifier, length field, data content and verification information of each partition. Before the overall firmware structure is written into the Flash, it is encapsulated by the firmware compilation tool chain, and metadata such as version number, verification digest and firmware size are written into the firmware header. After the device is powered on, the co-processor security boot module sequentially loads, verifies and maps the partition data to the running memory space. This firmware partition data structure is compatible with the standard firmware upgrade mechanism, supports secure differential upgrade and rollback protection, and is widely used in trusted terminals, automotive-grade chips and national cryptography information devices to ensure the structural consistency and security verifiability of the entire firmware life cycle.

[0076] Preferably, constructing the hierarchical verification structure data according to the firmware partition data in step S2 includes:

[0077] Constructing multi-level verification nodes based on the firmware partition data to form a tree-like verification hierarchy and determining the master-slave verification relationship;

[0078] Allocating verification priorities according to the master-slave verification relationship, constructing a verification dependency graph, and generating the node verification order;

[0079] Setting the signature data in the boot area of the firmware partition data as the root verification node;

[0080] Establishing a cascading verification structure for the core execution area based on the code integrity verification chain in the firmware partition data to form a verification transfer chain;

[0081] Establishing a hash verification table for the configuration area parameters in the firmware partition data and associating it with the access control policy to generate a configuration verification mapping;

[0082] Performing runtime data consistency verification according to the node verification order, the root verification node and the verification transfer chain to obtain a dynamic integrity verification matrix;

[0083] Integrate the dynamic integrity verification matrix and the configuration verification mapping into a hierarchical verification structure data.

[0084] Based on the firmware partition data constructed in the previous step, the embodiments of the present invention parse the meta-information of the boot area, core execution area, configuration area, and data storage area during the initialization of the verification framework, including their signature data, code block verification chain, parameter table, and encrypted channel description. To implement an efficient and controllable multi-level verification mechanism, the system adopts a tree structure design, abstracting each firmware partition as a verification node and hierarchically organizing them according to their logic and security levels. The root node is set as the boot area verification node, its child nodes are the code integrity verification nodes of the core execution area, and the next level is the verification nodes corresponding to the configuration area and data storage area. Each node records its verification data type (such as signature, HMAC, or hash table), verification method (such as ECDSA signature verification, HMAC comparison, etc.), and the verification dependency relationship with its parent node. In this way, a tree-like verification hierarchy structure with the boot area as the root and other partitions as the branches and leaves is constructed, and the system stores it structurally as a verification relationship table and a node definition table for use during runtime or the secure boot process. In practical applications such as financial security chips, this structure can be defined as "Root_Node (boot area) → Exec_Verify_Node (Block0~Block63) → Config_Node+Data_Node", which facilitates subsequent dynamic verification path tracking and management. After establishing the multi-level verification tree, the system enters the verification strategy allocation stage. According to the master-slave dependency relationship, the verification priority of each node during startup and runtime is determined. First, the system starts from the root node and traverses the verification tree using the depth-first search algorithm. Each time a node is passed, an increasing priority number is marked for it to ensure that the upper-level nodes are verified before the lower-level nodes. For example, the boot area verification node is numbered 1, Block0 of the core execution area is 2, Block1 is 3, and so on. The nodes in the configuration area and data area are numbered after all code blocks. Subsequently, the system constructs a directed acyclic graph (DAG) from the number relationship generated during this traversal process to form a verification dependency graph, and derives a node verification order list from the graph. This list is loaded and strictly executed by the security verification engine after the device is powered on to ensure that when any verification fails, all sub-verification processes dependent on that node are immediately terminated, preventing security bypass. Taking the intelligent gateway coprocessor as an example, during the secure boot process, the system will verify in the order of "1 (boot signature) → 2~65 (code block HMAC) → 66 (configuration table) → 67 (data channel)" to ensure the minimization of the attack window. As the core starting point of firmware security, the signature data of the boot area needs to be immediately verified during system initialization and loaded into the verification system as the root node. The specific method is as follows: after the device is powered on, the boot verification engine is started to extract the hash digest and signature data of the boot area from the firmware image, and digital signature verification is performed using the pre-set hardware trust root public key in the chip.After successful verification, the system generates a verification node structure for it, which includes the node number, verification status, dependency being empty, verification method being "signature verification", and registers it as the root verification node. This node serves as the starting point of the entire verification structure, and all subsequent verification processes are allowed to start only after its successful completion. Therefore, the timeliness and reliability of the verification of this node are crucial. The system usually completes this process at an early stage of startup through a secure startup engine (such as the ARM TrustZone Boot ROM or the RISC-V PMP module), and only allows the loading of the code for the next execution area after successful verification to prevent the boot logic from being replaced or malicious jumps from being inserted. The core execution area contains multiple code blocks divided according to a fixed block size (such as 64 4KB blocks). When the system constructs the verification structure, these blocks are organized into a linear linked list structure in sequence. Each code block verification node records its corresponding HMAC value, the block number it belongs to, the starting address, the length, and the pointer to the previous block node. The system attaches a verification pointer to the node of the previously verified block in each node to form a cascading verification structure that passes block by block. During runtime, for each block verified, the system needs to read its code content, calculate the current HMAC value, and compare it with the preset value. If they are the same, it continues to verify the next block; if it fails, it rolls back or interrupts the execution. This verification structure forms a complete transfer chain, advancing step by step from Block0 to the back, and finally connecting to the verification nodes of the configuration area and the data area. This structure can be used for linear verification during the startup phase and also supports random access verification during the runtime phase. For example, in a vehicle-mounted security module, if Block25 is loaded due to a function call during system operation, the system requires that the HMAC verification of the previous 24 blocks be all passed before accessing this segment to ensure that the overall logical flow has not been inserted or tampered with. The device parameters contained in the configuration area need to maintain long-term consistency. The system achieves the integrity protection of parameter items by constructing a hash verification table. The specific operation is as follows: When the system generates the firmware partition data, each configuration parameter item (such as device ID, communication frequency band, working mode) is extracted as a key-value pair, and its hash digest value is generated using the SHA-256 algorithm and recorded in the configuration hash verification table. Each item in the table also comes with its offset address in the configuration area, access permission information, and update timestamp. During runtime, when the configuration interface attempts to read or modify a certain parameter, the system re-hashes its value in real-time and compares it with the hash value in the verification table to ensure that its value has not been silently modified by external attackers. At the same time, this verification table is used in combination with the access control policy module. After successful verification, it further determines whether it conforms to the access policy (such as the access user identity, the source of the calling code, etc.), and only allows access if it passes. For example, in the configuration area of an industrial control device, the "threshold setting" item is a key parameter, and its original hash value is stored as "A1B2C3...". After the user changes this parameter, if the system automatically re-hashes and generates the current value as "A1B2C3...", it is considered consistent; otherwise, the operation exception is recorded and written into the log system.During the operation phase, data consistency checks are performed dynamically on each node according to the node verification sequence, root verification node, and verification transfer chain of the core execution area generated above, and a dynamic integrity verification matrix is ​​constructed in real time. The matrix is ​​a two-dimensional structure, with the horizontal axis being the verification node number and the vertical axis being the verification time axis. Each element records the verification status of the corresponding node at a certain point in time (such as unverified, passed, or failed). The system sets the verification strategy to activate the verification process of the specified node and its dependent nodes periodically or by event triggering (such as loading modules or external instruction responses). For example, in a certain secure routing device, when a core Block 36 loading request is detected during operation, the system automatically triggers the HMAC check of Block 0~36, and gradually updates the corresponding cell status in the matrix, thereby realizing execution path consistency and timing integrity detection. If a node is in the "failed" state during verification, the system immediately blocks the execution request of its child node and triggers a response mechanism (such as locking, restarting, or switching to a backup image). The matrix is ​​not only used for runtime security control, but also recorded as part of the system audit log for subsequent analysis. Finally, the dynamic integrity verification matrix is ​​integrated with the configuration verification mapping data to form a complete hierarchical verification structure data. The structure is stored in a structured format such as JSON or TLV, and each hierarchical node contains the node type, verification method, upper layer dependency, status history, and access control mapping. For example, the root node is "type: boot_signature, method: ECDSA, status:verified", the core node chain is "type: code_block, method: HMAC, dependency: boot_signature", and the configuration mapping is "type: config_hash, linked_policy: ACL#001, access_control: verified_only". The integrated data is loaded into the verification control module once during the system startup phase, and provides a security decision basis for firmware execution and configuration access throughout the system life cycle. The structure is also easy to export through the remote security audit interface, supporting firmware security status comparison verification before OTA upgrade. In a security camera device, the verification structure is directly compared after the upgrade package is verified. If the structure of the new firmware is inconsistent with the current one, the system will refuse to upgrade and record the difference for manual review.

[0085] Preferably, the implementation of firmware startup security verification based on hierarchical verification structure data in step S2 includes:

[0086] Loading hierarchical verification structure data during coprocessor startup and initializing the verification engine;

[0087] Decrypt the verification parameters and check values of the hierarchical verification structure data based on the hardware trust root key to generate a verification configuration set;

[0088] Perform hash verification on each partition of the firmware in sequence according to the hierarchical order of the hierarchical verification structure to obtain the partition verification result;

[0089] Execute priority verification on the key areas in the firmware partition data, extract the startup key parameters and confirm their validity to generate path credibility;

[0090] Perform consistency check on the configuration area parameters in the hierarchical verification structure data and compare with the standard configuration values to generate configuration consistency data;

[0091] Record the verification time information of each partition according to the verification configuration set to generate timing behavior data;

[0092] Perform abnormal label recognition on the partition verification result, path credibility, configuration consistency result and timing behavior data, and summarize them to form a verification status report to obtain integrity verification data.

[0093] In the initialization stage of the co-processor startup in the embodiments of the present invention, the system will first read the stored hierarchical verification structure data from the local Flash or external storage medium (such as eMMC). This data file usually adopts an encrypted storage structure and contains content such as verification node levels, verification methods for each layer of nodes (such as signature verification, hash verification, HMAC comparison, etc.), dependency relationships, configuration area mapping tables, etc. After parsing the read structure data, the boot loader loads it into the internal verification structure table of the security verification engine, and at the same time creates an index for each node to form an object-oriented node tree or hierarchical linked list. Next, the system initializes the verification engine: configures the corresponding function interfaces for each verification method, registers the node information to the verification scheduling table, and prepares the verification result storage area. For example, in an industrial safety control gateway, this process will initialize nodes such as "boot signature node", "executable code block node", "configuration table node", whose verification methods are ECDSA signature verification, SHA-256 hash comparison, hash value comparison respectively, and bind them to the security accelerator resources in the co-processor chip to improve verification efficiency. After the hierarchical verification structure data is loaded, its internal node verification parameters (such as hash values of each partition, signature data, HMAC keys, standard configuration tables) are usually encrypted for storage. To ensure that they cannot be forged during operation, the system must decrypt them with the help of the hardware root of trust. The specific operation is as follows: the verification engine reads the key material through the security boot key controller embedded in the co-processor (such as the public key stored in eFuse or the built-in trusted root key), and decrypts and performs integrity verification on the encrypted verification parameters in the structure data through the hardware encryption and decryption engine (such as AES-GCM or RSA-OAEP). The decrypted verification parameters are loaded into the memory in a structured configuration form, and the system organizes them into a verification configuration set according to the node type. Each node contains information such as verification algorithm type, reference value, verification method, priority, policy flag, etc. Taking a certain drone main control SoC as an example, its co-processor will load the SHA-256 digest values of 64 encrypted code blocks in the structure and the HMAC key of the configuration area, decrypt them through the built-in TrustZone and load them into the verification mapping table for subsequent partition verification tasks. According to the node order of the hierarchical verification structure, starting from the boot area, each firmware partition is subjected to a hash verification one by one in the parsed hierarchical order. The system calls the hash module of the verification engine, reads the content of the corresponding block according to the partition start address and length recorded in the node, inputs each byte into the SHA-256 hash engine to generate the current digest value, and compares it with the standard digest value recorded in the structure. If the comparison is consistent, mark that the partition verification passes and write it into the result table; if not, record the failure status, mark the exception level and the reason for failure. This process adopts a serial or pipelined manner to ensure that the verification result is not overwritten by subsequent steps.For example, when a certain embedded encrypted router starts up, it sequentially verifies: the boot area (64KB), the execution area (256KB), and the configuration area (32KB). The verification time for each area is recorded accurately to the millisecond level, and finally a partition verification result matrix is obtained. Each row in it records the partition ID, verification method, comparison status, failure bit flag, and timestamp for subsequent analysis. Some areas in the firmware partition are highly sensitive, such as the interrupt vector table, startup jump logic, key initialization segment, etc. in the execution area. These areas need to be verified first at the initial stage of the coprocessor startup to ensure path security. The system extracts the key offset segment (such as the first 4KB startup entry) from the execution area according to the priority flag recorded in the hierarchical verification structure, and performs a quick hash comparison or signature verification to verify that it has not been tampered with. If the verification passes, the system further parses the key startup parameters from it, such as the boot jump address, key loading offset, startup flag bit, etc., and judges the validity of the legality of these parameters, such as whether the address falls within the preset security segment, whether the flag bit is an allowed value, etc., and then generates a path credibility mark. This mark contains information such as the source of the jump path, the serial number of the trusted verification node, the ID of the valid parameter set, etc., as a reference basis for whether the subsequent startup behavior is trusted. In a certain financial security card terminal, this process can verify that the startup segment jump address is within the range of the security page segment [0x1000 - 0x1FFF], and the included encrypted initialization code block passes the HMAC verification, and then mark the path credibility as "strongly trusted". During the firmware verification process, the consistency check of the parameter items in the configuration area is also performed. The method used is: match and compare the configuration area parameter hash table recorded in the structure data, that is, extract the actual values (such as network mode, device type, sensor threshold) of the configuration area in the current firmware item by item, calculate their hash values, and then compare them one by one with the standard hash values recorded in the verification structure. The items that pass the comparison are included in the "matching set" of the consistency result, and the failed items are included in the "inconsistent set", and the failure type (such as numerical mismatch, missing, illegal format, etc.) is also recorded. If a version number conflict or illegal value (such as frequency band overrun, null value) is found during the comparison process, the system marks it as a high-risk item. Finally, the system generates configuration consistency data, which includes the proportion of consistent items, the list of abnormal items, and recommended operations. For example, during the startup process of a certain intelligent industrial terminal, it is found that the original value of the configuration area parameter "Max_Sampling_Rate" should be "1000", but the actual value is "1500", and the hash comparison fails and prompts "illegal parameter out of bounds", which is recorded in the consistency check report for operation and maintenance intervention. To improve security traceability, when the system performs the verification operations of each partition, it will accurately record the verification startup time, end time, and total time consumption of each partition, and organize them into timing behavior data in combination with the node sequence information. This data is stored in a structured form, and the recorded content includes the verification node number, start timestamp, end timestamp, time consumption (millisecond level), whether it is the expected timing, verification status flag, etc.This data can not only be used to analyze the compliance of system startup behavior, but also assist in detecting behaviors such as abnormal delays and skipped verifications. In scenarios with high security requirements, the system sets the maximum allowable verification time threshold for each stage. For example, the verification of each piece of code in the execution area shall not exceed 20 ms. If the time consumption of a certain piece exceeds the limit, a "delay warning" flag will be triggered. For example, in an embedded industrial controller, one of the 64 blocks in the execution area, Block 37, takes 62 ms, which exceeds the threshold and is recorded as an "overtime exception". The mark is used for subsequent integrity report analysis. After completing all partition verifications, critical path verifications, configuration consistency comparisons, and timing behavior records, the system uniformly calls the exception recognition module of the verification engine to integrate and identify the above data. The module first compares the nodes marked as failed or timed out in the partition verification results to confirm their exception types and impact levels; secondly, it analyzes the path flags of "untrusted" or "illegal parameters" in the path credibility; then, combined with the inconsistent items in the configuration consistency data and the records of overrun or jumps in the timing behavior, it classifies the exceptions of all data and summarizes them by partition, time, and severity level to generate a verification status report. The report details each exception, cause analysis, affected nodes, and recommended response methods (such as switching to a backup image, blocking access, forced restart, etc.). This report is finally written into the security log area and output as integrity verification data for the upper-layer security management system to call. For example, in an edge computing node, the final report points out "inconsistency of the configuration item Freq_Mode", "abnormal execution path jump address", and "excessive time consumption of Block 42". The system triggers a degraded operation mode according to the level and prompts the operation and maintenance personnel to check the integrity of the image and the configuration of the security policy.

[0094] Preferably, step S3 includes the following steps:

[0095] Step S31: Trigger an inter-processor session initialization request based on the integrity verification data, construct a verification channel handshake frame, and generate a secure communication channel;

[0096] In the embodiment of the present invention, after the firmware integrity verification is completed, the main processor will judge whether the current startup path meets the secure communication conditions according to indicators such as path credibility, configuration consistency results, and partition verification results in the integrity verification data in the verification status report. When it is satisfied, the main processor initiates an inter-processor communication session initialization request and sends a handshake initialization command to the coprocessor through the underlying shared memory area or on-chip bus (such as AXI or AHB); subsequently, the main processor constructs a verification channel handshake frame according to the preset format of the secure communication protocol. The handshake frame contains the unique session ID, device identity tag, timestamp, session mode parameters (such as encryption algorithm type, key negotiation method, etc.) of this communication. For example, a combination mode of "SHA256-HMAC+ECDH" is adopted, and an initial session structure of the secure channel is established through this handshake frame to complete the communication channel initialization process.

[0097] Step S32: Use the verification key preset in the coprocessor to perform HMAC signature verification on the identity tag of the handshake frame in the secure communication channel, and return the verification response to the main processor to obtain handshake confirmation data;

[0098] In the embodiment of the present invention, after receiving the verification channel handshake frame transmitted by the main processor, the coprocessor extracts the identity tag field and timestamp therein, and calls its built-in HMAC verification module to use the preset session verification key (for example, a symmetric key with a length of 256 bits, written by the trusted platform module TPM during the chip initialization phase) to perform hash signature verification on the identity tag and timestamp in the handshake frame, and calculates the verification digest value through the SHA256-HMAC algorithm; the coprocessor encapsulates the verification result into a verification response frame, which includes a verification passed / failed flag, the coprocessor's own identity confirmation information (such as chip serial number, firmware version number), and a timestamp confirmation field. This response frame is returned to the main processor through the original channel, and the main processor completes the session initialization confirmation accordingly and saves it as handshake confirmation data.

[0099] Step S33: Generate a random challenge number based on the hardware root of trust key, and use the main processor to send the random challenge number to the coprocessor through the handshake confirmation data to start the two-way authentication process and obtain two-way authentication process data;

[0100] In the embodiment of the present invention, the main processor starts the two-way authentication process after handshake confirmation. To improve communication security, the main processor calls its root of trust security module (such as ARM TrustZone or Intel SGX) to generate a random challenge number with a length of 256 bits. This challenge number is generated by a high-strength hardware random number generator (such as sampled through the entropy source TRNG module), and this random number has uniqueness and unpredictability; subsequently, the main processor encapsulates this challenge number as an authentication challenge parameter into the authentication request message and sends it to the coprocessor together with the handshake confirmation data of the previous stage, triggering the coprocessor to start the identity verification process, and the entire process information formed is saved as two-way authentication process data.

[0101] Step S34: According to the two-way authentication process data, use the coprocessor to perform asymmetric encryption signature on the received challenge number, and attach its own authentication information to construct an identity response message, and return it to the main processor for identity matching verification to obtain identity verification data;

[0102] After receiving the authentication request message sent by the main processor, the coprocessor in the embodiment of the present invention first unpacks it to obtain the challenge number and the main processor identity information. Subsequently, it calls the asymmetric encryption module in its encryption engine (such as the encryption and decryption core based on RSA-2048 or ECC-256) to perform a digital signature operation on the challenge number using its private key, and attaches the identity authentication information of the coprocessor, including device ID, authentication certificate chain digest, firmware signature, etc. These data are combined to construct an identity response message. The coprocessor sends the identity response message back to the main processor through the predefined secure channel protocol, and the main processor calls its public key to verify the response message to determine whether the coprocessor is a legal entity. The verification comparison result generated in this process is the identity authentication data.

[0103] Step S35: Jointly generate an initial shared key based on the identity authentication data using the ECDH elliptic curve key agreement algorithm, and perform PBKDF2 strengthening processing to obtain a secure channel seed key;

[0104] After the two-way authentication is completed in the embodiment of the present invention, the main processor and the coprocessor jointly start the key negotiation process. Using the Elliptic Curve Diffie-Hellman (ECDH) algorithm, the main processor and the coprocessor respectively generate private key and public key pairs on the elliptic curve (such as using the NIST P-256 curve), and exchange the public key data. The two parties calculate the same initial shared key through their respective private keys and the other party's public key, and then call the PBKDF2 key derivation function for strengthening processing based on the initial shared key. Set the number of iterations to 10,000 times, and introduce a session-unique ID as a salt parameter to enhance the anti-cracking ability of the seed key, and finally form a set of high-strength secure channel seed keys with a length of 512 bits.

[0105] Step S36: Generate a session key dataset through the AES-GCM algorithm using the secure channel seed key, where the session key dataset includes a symmetric encryption key, a MAC verification key, and a time limit control parameter;

[0106] In the embodiment of the present invention, the coprocessor and the main processor respectively call their symmetric encryption modules to derive and generate a session key dataset through the AES-GCM algorithm using the generated secure channel seed key, including: a set of 128-bit AES symmetric encryption keys for protecting the communication content; a set of MAC keys for integrity verification of each communication frame, usually also 128 bits; at the same time, session control parameters are attached, such as the session validity period is set to 30 seconds, the initial value of the frame sequence number, and the maximum number of retries, etc. These parameters are encapsulated into a standard key data structure for encryption, decryption, and integrity verification of each frame of data in subsequent secure communication, ensuring the confidentiality, integrity, and anti-replay ability of the communication.

[0107] Step S37: Load the session key data set into the encryption context of the dual-processor, and start the two-way encryption communication task queue to obtain the session key data.

[0108] After the session key data set is generated in the embodiment of the present invention, the main processor and the coprocessor respectively load it into their respective secure encryption contexts. That is, the corresponding hardware encryption engine or encryption driver module will write the key data into the exclusive key register or secure memory area, and register the session control parameters into the communication task manager. Subsequently, the main processor issues a start encryption communication instruction, and both parties enter the two-way encryption communication state. The coprocessor starts the encryption communication task queue, listens to and encrypts the upcoming communication tasks. All communication data frames will be encrypted, verified, and reorganized based on the currently loaded key pair, completing the deployment of the entire session key data generation and encryption communication environment, ensuring that the data communication between the dual-processors is always under trusted, encrypted, and authenticated protection.

[0109] Preferably, step S4 includes the following steps:

[0110] Step S41: Initialize the environment monitoring engine based on the session key data, configure the runtime exception detection threshold parameters, and establish a firmware runtime environment monitoring framework.

[0111] After the main processor and the coprocessor in the embodiment of the present invention complete the establishment of the encrypted session, the main processor uses the negotiated session key data to initialize the built-in environment monitoring engine module. This engine runs in a secure context based on the chip security architecture (such as the ARM TrustZone Secure Monitor or the RISC-V PMP module), and has the ability to monitor the memory area, instruction stream, and access behavior in real time. During the initialization process, the session key is used to encrypt and protect the data between the monitoring engine and the communication channel to ensure that the monitoring process cannot be tampered with. At the same time, the system security policy configures the parameter thresholds for runtime exception detection, such as the memory tampering alarm threshold is set to 1 time / second, the maximum tolerance for control flow deviation is 16 bytes, and an alarm is triggered when the illegal access interval in the sensitive area is less than 100 ms. These parameters are written into the monitoring policy table to drive the behavior decision logic of the firmware runtime environment monitoring framework.

[0112] Step S42: Start periodic memory integrity scanning based on the firmware runtime environment monitoring framework, perform hash verification on the critical code segments of the firmware, and compare with the reference value to generate memory integrity monitoring data.

[0113] After the monitoring framework of the present invention embodiment is started, the environmental monitoring engine periodically triggers a memory integrity scanning task. The scanning frequency is default set to once every 100 milliseconds. This task traverses the memory address ranges of the firmware key code segments, such as the startup loading area, the exception handling function segment, and the key interrupt handling function segment, etc., reads the corresponding memory content and performs a hash operation, and uses the SHA-256 hash algorithm to generate a hash digest value for each code block; subsequently, the current hash digest value is compared with the firmware hash reference value saved in the trusted storage area (such as OTP or eFuse) before startup. If the comparison fails, the address segment is recorded as an integrity exception area, and a memory integrity monitoring data record is generated, including the address segment identifier, the current hash value, the reference hash value, and the timestamp. The monitoring engine uploads this data to the security analysis module for subsequent analysis.

[0114] Step S43: Deploy control flow monitoring points for the firmware running environment monitoring framework, track the firmware instruction execution order, and obtain the actual instruction execution data;

[0115] The monitoring engine of the present invention embodiment predefines multiple control flow monitoring points in the system. These monitoring points are usually inserted at the positions before and after key branches, function entrances, and jump instructions. The instrumentation method can be implemented through compiler instrumentation (such as -fsanitize=control-flow in GCC) or binary rewriting technology. The inserted logic is used to record data such as the current PC (program counter) value, call stack information, and call depth in real time when the instruction execution reaches the monitoring point; these actual instruction execution data are cached in a secure area after being collected, and are asynchronously transmitted to the main processor or analysis core through an encrypted channel, and are mapped and compared with the static control flow graph (CFG) to identify whether there is a situation where the instruction flow deviates from the predefined path.

[0116] Step S44: Identify unexpected jump instructions or function calls according to the actual instruction execution, and obtain execution flow exception data;

[0117] The main processor of the present invention embodiment performs behavior graph analysis on the collected actual instruction execution data, matches the call sequence collected during runtime with the control flow graph generated during firmware compilation one by one path, and focuses on identifying whether there are behaviors such as the function return address being tampered with (such as return address hijacking caused by stack overflow), illegal jumps (such as jumping to an undefined area or an external loading area); the criteria for the system to determine an unexpected jump include that the jump target address is not in the legal section, the function call depth is abnormal, the jump path does not appear in the pre-compiled control flow graph, etc. If an anomaly is found, the anomaly type, the PC address at the time of triggering, the instruction content, and the time tag are recorded to form execution flow anomaly data and reported to the analysis module.

[0118] Step S45: Monitor the firmware access behavior pattern according to the firmware running environment monitoring framework to obtain firmware access data;

[0119] In the embodiment of the present invention, the monitoring engine monitors the access behavior of the firmware to on-chip resources through the built-in bus listening mechanism, mainly focusing on the read and write operations of address ranges such as Flash, RAM, and peripheral registers. The event recording method is adopted to record information such as the access address, access type (read / write), access initiation time, and the current running context of the processor (such as interrupt state / user state) for each firmware access behavior; for example, if it is detected that the communication buffer or certain specific IO address areas are frequently written during the interrupt handling process, this behavior will be marked as a high-risk mode; all access behavior data is standardized and stored in a circular buffer queue to form structured firmware access data, and abnormal behavior patterns are filtered through an event filter.

[0120] Step S46: Record the read and write operation frequencies and timing characteristics of the sensitive area according to the firmware access data, and construct a behavior baseline model to generate access pattern analysis data;

[0121] In the embodiment of the present invention, after obtaining the firmware access data, the main processor calls the access behavior analysis module. According to the preset sensitive area table (such as including device configuration registers, system key registers, Flash write protection segments, etc.), characteristic parameters such as the read and write behavior frequencies, interval times, and access granularities (bytes / words / blocks) of the corresponding address areas are extracted, and the frequency distribution of the past N times (such as N = 128) of access is statistically analyzed based on the sliding time window model; then these timing characteristics are used to train the baseline behavior model. This model uses unsupervised clustering (such as based on K-Means or DBSCAN) to classify access behaviors into normal access and abnormal access categories, and establish a characteristic profile for each category of behaviors to be used for real-time classification and risk assessment of new behaviors. Finally, access pattern analysis data is generated as one of the input items for environmental anomaly detection.

[0122] Step S47: Merge the memory integrity monitoring data, execution flow anomaly data, and access pattern analysis data into the firmware running environment;

[0123] The firmware monitoring module of the main processor in the embodiments of the present invention periodically aggregates the above three types of data. First, it cross-analyzes the abnormal address segments in the memory integrity monitoring data with the abnormal trigger positions recorded in the control flow exception data to determine whether there is a corresponding relationship (for example, an instruction jumps to a certain integrity exception area); then it aligns the timestamps of the high-frequency sensitive access behaviors in the access mode analysis data with the abnormal points of the execution flow to determine whether there are access behavior anomalies and control flow deviation events within the same time window; based on the results of the fusion of these multi-dimensional data, it constructs the current firmware running environment information set, indicating its various abnormal risk levels, possible intrusion paths, abnormal coverage areas, etc., to form a complete view of the running environment security situation.

[0124] Step S48: Identify potential abnormal behaviors according to the firmware running environment and implement protection measures to obtain the protection status data during the firmware operation.

[0125] The main processor in the embodiments of the present invention analyzes the threat level and influence range of potential abnormal behaviors based on the firmware running environment information set. If high-risk anomalies are found (such as simultaneous integrity damage of the code segment, abnormal jumps, and abnormal writes to sensitive registers), the firmware protection mechanism will be immediately triggered. Typical measures include freezing the execution of relevant tasks, disconnecting the communication channel with external devices, rolling back to the firmware version with the last successful integrity verification, etc.; in the case of low-risk anomalies (such as occasional increase in access frequency), the system can adopt methods such as dynamically adjusting the access threshold, recording logs, and increasing the monitoring frequency for mitigation; all processing results will be recorded as protection status data and fed back to the system security management module for generating security audit logs or triggering security alerts.

[0126] Particularly importantly, step S48 includes the following steps:

[0127] Step S481: Identify potential intrusion behaviors based on rule matching detection according to the firmware running environment to obtain an intrusion detection report;

[0128] After the firmware running environment is established and monitored in the embodiments of the present invention, the system will perform rule matching detection on the behavior data during the firmware operation according to a predefined rule library. These rules include known malicious code behavior patterns, attack sequences (such as buffer overflows, illegal memory accesses across boundaries, abnormal resource access requests, etc.), and historical attack characteristics. Each rule in the rule library is defined for different types of intrusion behaviors. For example, a rule can be defined as "if a certain module frequently accesses sensitive memory areas without authorization, it is considered a potential code injection attack"; the monitoring engine compares each detected behavior, and if it meets the rule conditions, it marks it as a potential intrusion behavior. The system will summarize all the matching potential intrusion behaviors to form an intrusion detection report, which contains information such as the matching rule, detection time, and triggering conditions of each behavior. For example, if a certain instruction stream is found to match a known malicious pattern, the report will detail the abnormal instruction address and the triggered rule number.

[0129] Step S482: Classify and grade the detected abnormal behaviors according to the intrusion detection report, and activate the protection response strategy according to the threat level to generate the protection response strategy;

[0130] In the embodiments of the present invention, once the intrusion detection report is generated, the main processor will classify and grade these behaviors according to the detected abnormal behaviors in the report. The classification is based on the type of abnormal behavior, such as memory tampering, unauthorized instruction execution, abnormal data writing, etc.; the grading is based on the threat level of the intrusion behavior. For example, memory tampering may be classified as a "high-risk" level, while abnormal access to non-critical data areas is a "medium-risk" level. An appropriate protection response strategy is selected for each behavior according to the threat level. For example, for "high-risk" behaviors, the protection strategy may activate protection measures such as immediate isolation execution, firmware rollback, or network disconnection, while for "medium-risk" behaviors, the system may take measures such as increasing the monitoring frequency or performing log auditing. Finally, these decisions will form a set of protection response strategies, including specific protection tasks, emergency response steps, and required resource operation permissions.

[0131] Step S483: Deploy a dynamic code isolation mechanism based on the protection response strategy, perform runtime sandboxing on the suspicious module, restrict the resource access permissions, and record the behaviors within the sandbox to obtain the isolation execution log;

[0132] In the embodiment of the present invention, based on the protection response strategy, the system will start the dynamic code isolation mechanism. This mechanism will perform runtime sandboxing on the detected suspicious modules, aiming to execute these modules in an isolated environment to prevent them from causing harm to the entire system. During this process, the resource access permissions within the sandbox will be restricted. For example, the module is prohibited from accessing external storage devices, network interfaces, or sensitive registers, etc. In addition, the behaviors within the sandbox will be comprehensively recorded, including each instruction executed by the module, each memory address accessed, read and written data, externally called library functions, etc. All these records will generate a sandbox isolation execution log, which not only records the details of abnormal behaviors but also includes the execution duration within the sandbox, the system response time, and the interaction data between the inside and outside of the sandbox. This process helps prevent the suspicious module from damaging the main system and at the same time provides detailed analysis data for subsequent review and analysis.

[0133] Step S484: Summarize the intrusion detection report, the protection response strategy, and the isolation execution log to obtain the protection status data during the firmware runtime.

[0134] All the data generated in the embodiment of the present invention, including the intrusion detection report, the protection response strategy, and the sandbox isolation execution log, will be summarized and processed in the main processor. The system will perform fusion analysis on these data to form a complete protection status data during the firmware runtime. These data will indicate the security posture of the entire system and record in detail the activation and execution of the protection measures. The summarized data will include, for example, the triggering conditions of the protection strategy, the isolation duration of the sandbox, the abnormal behaviors within the sandbox, and their subsequent response measures. Finally, these protection status data will generate a detailed security report, which can be provided to security managers or used as the basis for security audits to evaluate the security of the current firmware environment and further adjust the protection strategy if necessary.

[0135] Preferably, step S5 includes the following steps:

[0136] Step S51: Configure the data access monitoring engine based on the protection status data, deploy the access control strategy and monitoring points to obtain the access monitoring framework;

[0137] In the embodiments of the present invention, based on the protected state data, the system will configure a data access monitoring engine and deploy access control policies and monitoring points. First, by analyzing the protected state data, it is determined which sensitive areas or critical resources need access control. Based on this, the system configures access control policies to define which users or processes can access which resources and sets different permission levels. For example, ordinary users can only read data, while administrators can modify configuration files. Then, monitoring points are deployed on critical data access paths, such as memory read / write, file system access, etc., to monitor all data access requests in real time. The monitoring framework captures and records each access request, including detailed information such as the access source, target resource, and access time. Finally, the access monitoring framework continuously runs and provides support for subsequent access request verification and encryption / decryption operations.

[0138] Step S52: Based on the data access request intercepted by the access monitoring framework, verify the identity and permission level of the request source, generate an access token for a legitimate request, and obtain access control data;

[0139] In the embodiments of the present invention, after the access monitoring framework captures a data access request, the system first authenticates the source of the request. This can be done by comparing it with pre-registered user credentials or device identifiers. For example, hardware-based authentication (such as TPM, HSM, etc.) is used. Then, the system determines the permission level of the request based on the authentication result of the request source and the permission management rules within the system. For a verified legitimate request, the system generates an access token according to the access permission of the request. This token contains information such as the specific resources to be accessed, the allowed operation types, and the validity period. The generated access token is used as access control data and returned to the requester or used in subsequent data processing stages. If the request identity or permission level does not match, the access request will be rejected and an access log will be generated for auditing.

[0140] Step S53: Transmit the request to the security coprocessor according to the access control data, perform data encryption / decryption operations, and append an integrity check code to generate hardware encryption result data;

[0141] Once the access control data is generated in the embodiments of the present invention, the system will pass the verified data access request to the secure co-processor. The role of the co-processor is to perform encryption and decryption operations on the data. Specifically, based on the content of the request (such as reading sensitive data or modifying system configuration), the co-processor will call the hardware encryption module (such as AES, RSA, etc.) to encrypt or decrypt the data to ensure the confidentiality of the data during transmission. In addition, the co-processor will also verify the integrity of the data, using a hash algorithm (such as SHA-256) to generate an integrity verification code for the data. This verification code will be appended to the encrypted data for subsequent verification of whether the data has been tampered with. After the processing is completed, the co-processor will return the encrypted data and the appended integrity verification code to the requester or use them for the next data interaction.

[0142] Step S54: Based on the hardware encryption result data, construct a tamper-proof data encapsulation structure to form a data tamper-proof mechanism, where the tamper-proof data encapsulation structure includes a version stamp, an integrity hash, and an access log;

[0143] In the embodiments of the present invention, according to the hardware encryption result data obtained from the secure co-processor, the system will construct a tamper-proof data encapsulation structure. The role of this structure is to protect the data from being tampered with or illegally modified. Specifically, the encapsulation structure will include the following elements: First, the version stamp is used to mark the version information of the data to ensure the timeliness and update history of the data; Second, the integrity hash (such as SHA-256) is used to ensure that the data content has not been tampered with. Any change to the data will cause the hash value to change, making it impossible to pass the verification; Finally, the access log will record each access operation to the data, including information such as the identity of the visitor, the access time, and the operation type for subsequent auditing and tracing. This tamper-proof data encapsulation structure ensures the integrity of the data during storage or transmission and prevents unauthorized modification.

[0144] Step S55: Monitor the data interaction status according to the data tamper-proof mechanism, record the integrity verification results and abnormal events of the access operations, and generate firmware data security status data.

[0145] In an embodiment of the present invention, according to the data anti-tampering mechanism, the system will monitor the data interaction status in real time, including the integrity verification results of each data access and any abnormal events. When an access operation occurs, the system will verify whether the integrity hash of the data matches the stored version stamp. If it matches, it indicates that the data has not been tampered with; if it does not match, it will be marked as an abnormal event and further protection measures (such as warnings, locking operations, etc.) will be executed. In addition, the system will record the detailed information of all access operations, including the verification results at the time of access, the detailed description of abnormal events, the time stamps when they occurred, etc. These data will constitute the firmware data security status data and form a report for the security administrator to view and audit. The system will continuously monitor the data interaction status to ensure the security of the firmware.

[0146] The present invention also provides a system for firmware protection based on a security coprocessor, which is used to execute the method for firmware protection based on a security coprocessor as described above. The system for firmware protection based on a security coprocessor includes:

[0147] An entropy source generation module, which is used to obtain coprocessor feature data; extract hardware entropy source data according to the coprocessor feature data; and generate a hardware root of trust key based on the hardware entropy source data;

[0148] A firmware partitioning and verification module, which is used to perform partitioning processing on the firmware based on the hardware root of trust key to obtain firmware partition data; construct hierarchical verification structure data according to the firmware partition data; and perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data;

[0149] A secure communication establishment module, which is used to establish a secure communication channel between processors according to the integrity verification data; perform a two-way authentication process based on the secure communication channel, and generate session key data;

[0150] A running environment monitoring module, which is used to monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain the protection status data during firmware runtime;

[0151] A data access encryption module, which is used to monitor data access requests according to the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; and establish a data anti-tampering protection mechanism according to the hardware encryption result data to obtain firmware data security status data.

[0152] Therefore, in all aspects, the embodiments should be regarded as exemplary and non-restrictive. The scope of the present invention is defined by the appended claims rather than the above description. Thus, it is intended to embrace all changes that fall within the meaning and scope of the equivalent elements of the application documents within the present invention. The above description is only a specific implementation manner of the present invention, enabling those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be obvious to those skilled in the art. The general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to these embodiments shown herein, but rather to the broadest scope consistent with the principles and novel features invented herein.

Claims

1. A method for firmware protection based on a secure coprocessor, characterized in that, It includes the following steps: Step S1: Obtain coprocessor feature data; extract hardware entropy source data according to the coprocessor feature data; Generate a hardware trust root key based on the hardware entropy source data; Step S2: Perform partition processing on the firmware based on the hardware trust root key to obtain firmware partition data; Construct hierarchical verification structure data according to the firmware partition data; perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data, where performing partition processing on the firmware based on the hardware trust root key specifically is: Perform firmware binary code analysis based on the coprocessor feature data, identify functional modules and data regions, and establish a firmware structure mapping table; Divide the firmware security level based on the firmware structure mapping table, and divide the firmware into a boot area, a core execution area, a configuration area, and a data storage area; Perform hash encryption on the firmware code in the boot area, and generate boot area signature data using the hardware trust root key; Perform block slicing processing on the firmware code in the core execution area to generate a sequence of code blocks with a data block size of 4KB; Calculate the HMAC value of each code block based on the hardware trust root key and the sequence of code blocks, and construct a code integrity verification chain; Encrypt and store the parameters in the configuration area, and set an access control policy based on the hardware trust root key; Perform security isolation on the data storage area, and establish a data encryption channel based on the hardware trust root key; Merge the boot area signature data, the code integrity verification chain, the configuration area access control, and the data encryption channel into firmware partition data; Where constructing hierarchical verification structure data according to the firmware partition data specifically is: Construct multi-level verification nodes based on the firmware partition data, form a tree-like verification hierarchy, and determine the master-slave verification relationship; Allocate verification priorities according to the master-slave verification relationship, construct a verification dependency graph, and generate a node verification order; Set the boot area signature data in the firmware partition data as the root verification node; Establish a cascading verification structure for the core execution area based on the code integrity verification chain in the firmware partition data to form a verification transfer chain; Establish a hash verification table for the configuration area parameters in the firmware partition data, and associate it with the access control policy to generate a configuration verification mapping; Perform runtime data consistency verification according to the node verification order, the root verification node, and the verification transfer chain to obtain a dynamic integrity verification matrix; Integrate the dynamic integrity verification matrix and the configuration verification mapping into hierarchical verification structure data; Where performing firmware startup security verification based on the hierarchical verification structure data specifically is: Load the hierarchical verification structure data during the coprocessor startup process, and initialize the verification engine; Decrypt the verification parameters and check values of the hierarchical verification structure data based on the hardware trust root key to generate a verification configuration set; Perform hash verification on each partition of the firmware in turn based on the hierarchical verification structure level order to obtain partition verification results; Perform priority verification on the key areas in the firmware partition data, extract startup key parameters and confirm their validity, and generate path credibility; Perform consistency verification on the configuration area parameters in the hierarchical verification structure data, and compare with the standard configuration values to generate configuration consistency data; Record the verification time information of each partition according to the verification configuration set, and generate timing behavior data; Perform anomaly label recognition on the partition verification result, path credibility, configuration consistency result, and timing behavior data, and summarize them to form a verification status report to obtain integrity verification data; Step S3: Establish a secure communication channel between processors based on the integrity verification data; Execute a two-way authentication process based on the secure communication channel and generate session key data; Step S4: Monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain the protection status data during firmware runtime; Step S5: Monitor data access requests based on the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; establish a data tamper-proof protection mechanism based on the hardware encryption result data to obtain the firmware data security status data.

2. The method for firmware protection based on a secure coprocessor according to claim 1, wherein Step S1 includes the following steps: Step S11: Measure the transistor threshold voltage and static power consumption during the power-on initialization stage of the coprocessor; Step S12: Collect the startup response time and signal stability index of the coprocessor memory unit; Step S13: Obtain the reference operation speed and timing characteristics of the encryption module of the coprocessor; Step S14: Generate coprocessor feature data based on the transistor threshold voltage, static power consumption, startup response time, signal stability index, reference operation speed, and timing characteristics; Step S15: Generate hardware entropy source data using a ring oscillator array based on the coprocessor feature data; Step S16: Generate a hardware root of trust key based on the hardware entropy source data.

3. The method for firmware protection based on a secure coprocessor according to claim 2, characterized in that, Step S15 includes the following steps: Step S151: Configure and start the built-in ring oscillator array according to the coprocessor feature data, and set the sampling window to obtain oscillator configuration data; Step S152: Record the oscillation count values within the sampling window based on the oscillator configuration data, and calculate the count difference between adjacent oscillator groups to obtain frequency difference data; Step S153: Convert the count difference in the frequency difference data into a bit sequence, specifically, when the difference is positive, it is recorded as bit sequence 1, when the difference is negative, it is recorded as 0, and when the difference is zero, it is discarded; Step S154: Connect multiple groups of bit sequences to generate raw hardware entropy source data with a length of at least 1024 bits; Step S155: Monitor the current environmental temperature, voltage fluctuation, and electromagnetic interference intensity to obtain environmental parameters; and perform linear compensation processing on the raw hardware entropy source data with a temperature coefficient of -0.2% / °C according to the environmental parameters to obtain the hardware entropy source data.

4. The method for firmware protection based on a secure coprocessor according to claim 3, wherein Step S3 includes the following steps: Step S31: Trigger a session initialization request between processors based on the integrity verification data, construct a verification channel handshake frame, and generate a secure communication channel; Step S32: Use the pre-set verification key in the coprocessor to perform HMAC signature verification on the identity tag of the handshake frame in the secure communication channel, and return the verification response to the main processor to obtain handshake confirmation data; Step S33: Generate a random challenge number based on the hardware trust root key, and use the main processor to send the random challenge number to the coprocessor through the handshake confirmation data, start the two-way authentication process, and obtain the two-way authentication process data; Step S34: According to the two-way authentication process data, use the coprocessor to perform an asymmetric encryption signature on the received challenge number, and attach its own authentication information to construct an identity response message, and return it to the main processor for identity matching verification to obtain the identity verification data; Step S35: Jointly generate an initial shared key based on the identity verification data using the ECDH elliptic curve key agreement algorithm, and perform PBKDF2 strengthening processing to obtain the secure channel seed key; Step S36: Use the secure channel seed key to generate a session key dataset through the AES-GCM algorithm, where the session key dataset includes a symmetric encryption key, a MAC verification key, and a timeliness control parameter; Step S37: Load the session key dataset into the encryption context of the dual processors, and start the two-way encryption communication task queue to obtain the session key data.

5. The method for firmware protection based on a secure coprocessor according to claim 4, characterized in that Step S4 includes the following steps: Step S41: Initialize the environment monitoring engine based on the session key data, configure the runtime exception detection threshold parameter, and establish a firmware runtime environment monitoring framework; Step S42: Based on the firmware runtime environment monitoring framework, start a periodic memory integrity scan, perform a hash check on the firmware critical code segment, and compare it with the reference value to generate memory integrity monitoring data; Step S43: Deploy control flow monitoring points to the firmware runtime environment monitoring framework, track the firmware instruction execution order, and obtain the actual instruction execution data; Step S44: Identify unexpected jump instructions or function calls according to the actual instruction execution to obtain execution flow exception data; Step S45: Monitor the firmware access behavior pattern according to the firmware runtime environment monitoring framework to obtain the firmware access data; Step S46: Record the read and write operation frequencies and timing characteristics of the sensitive area according to the firmware access data, and construct a behavior baseline model to generate access pattern analysis data; Step S47: Merge the memory integrity monitoring data, the execution flow exception data, and the access pattern analysis data into the firmware runtime environment; Step S48: Identify potential abnormal behaviors according to the firmware runtime environment, and implement protection measures to obtain the protection status data during the firmware runtime.

6. The method for firmware protection based on a secure co-processor according to claim 5, wherein Step S5 includes the following steps: Step S51: Configure a data access monitoring engine based on the protection status data, deploy access control policies and monitoring points to obtain an access monitoring framework; Step S52: Intercept data access requests based on the access monitoring framework, verify the request source identity and permission level, and generate an access token for legitimate requests to obtain access control data; Step S53: Transfer the request to the secure coprocessor according to the access control data, perform data encryption and decryption operations, and attach an integrity check code to generate hardware encryption result data; Step S54: Construct a tamper-proof data encapsulation structure based on the hardware encryption result data to form a data tamper-proof mechanism, where the tamper-proof data encapsulation structure includes a version stamp, an integrity hash, and an access log; Step S55: Monitor the data interaction status according to the data anti-tampering mechanism, record the integrity verification results and abnormal events of the access operations, and generate the firmware data security status data.

7. A system for firmware protection based on a secure coprocessor, characterized in that, A method for performing firmware protection based on a security coprocessor as described in claim 1, the system for firmware protection based on a security coprocessor includes: An entropy source generation module, configured to obtain coprocessor feature data; extract hardware entropy source data according to the coprocessor feature data; generate a hardware root of trust key based on the hardware entropy source data; A firmware partitioning and verification module, configured to perform partitioning processing on the firmware based on the hardware root of trust key to obtain firmware partition data; construct hierarchical verification structure data according to the firmware partition data; perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data; A secure communication establishment module, configured to establish a secure communication channel between processors according to the integrity verification data; perform a two-way authentication process based on the secure communication channel, and generate session key data; A running environment monitoring module, configured to monitor the firmware running environment based on the session key data; identify potential abnormal behaviors according to the firmware running environment, and implement protection measures to obtain the protection status data during the firmware runtime; A data access encryption module, configured to monitor data access requests according to the protection status data; perform hardware encryption processing based on the data access requests to obtain hardware encryption result data; establish a data anti-tampering protection mechanism according to the hardware encryption result data to obtain the firmware data security status data.

Images