Firmware protection method and system based on security coprocessor

Abstract

The invention relates to the technical field of firmware protection, in particular to a firmware protection method and system based on a security coprocessor. The method comprises the following steps: acquiring characteristic data of the coprocessor; extracting hardware entropy source data according to the coprocessor feature data; generating a hardware trust root key based on the hardware entropy source data; performing partition processing on the firmware based on the hardware trust root key to obtain firmware partition data; constructing hierarchical verification structure data according to the firmware partition data; implementing firmware starting security verification based on the hierarchical verification structure data to obtain integrity verification data; establishing a secure communication channel between the processors according to the integrity verification data; executing a bidirectional authentication process based on the secure communication channel, and generating session key data; a firmware runtime environment is monitored based on the session key data. According to the method, the hardware entropy source is extracted by measuring the physical characteristics of the coprocessor, and an unforgeable hardware trust root is established, so that the security is improved fundamentally.

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 coprocessor. Background Art

[0002] A coprocessor 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 coprocessor, and the coprocessor executes these tasks under the control of the main processor. When the coprocessor completes the task, it returns the result to the main processor. This way of division of labor and cooperation can improve the overall efficiency of the system. A secure coprocessor is a processing unit specifically used to enhance the security of the system. 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 coprocessors 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 coprocessors 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 in the absence of hardware support, the startup process is vulnerable to attacker tampering. Secure coprocessors provide independent security protection at the firmware startup stage, ensuring the integrity and credibility 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 coprocessor 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 coprocessor includes the following steps: 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; 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; Step S3: 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; 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 operation; Step S5: Monitor the data access request according to the protection status data; perform hardware encryption processing based on the data access request to obtain the 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.

[0006] The present invention also provides a system for firmware protection based on a secure co-processor, which is used to execute the method for firmware protection based on a secure co-processor described above. The system for firmware protection based on a secure co-processor includes: An entropy source generation module, which is used to obtain co-processor feature data; extract hardware entropy source data according to the co-processor feature data; generate a hardware trust root key based on the hardware entropy source data; A firmware partitioning and verification module, which is used to perform partitioning 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; implement firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data; 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; 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 operation; A data access encryption module, which is used to monitor the data access request according to the protection status data; perform hardware encryption processing based on the data access request to obtain the 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.

[0007] Through the firmware protection method based on a secure co-processor, the present invention achieves comprehensive security protection for the firmware at different stages, and fine-grained protection measures are taken for each link from firmware startup to the running process. First, by obtaining the characteristic data of the co-processor 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 the security verification of firmware startup. 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 protection 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 protection status data of the firmware and performs hardware encryption processing on the data access process. Through hardware encryption, the system ensures that all access requests are encrypted and protected during the firmware operation, 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, through multi-level protection measures, the present invention comprehensively protects each link from firmware startup, operation to data access, makes full use of the hardware characteristics of the secure co-processor, and achieves 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 solution for embedded systems, Internet of Things devices, and other hardware systems that require high security. Description of the Drawings

[0008] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments read in conjunction with the accompanying drawings: Figure 1 It is a schematic diagram of the step flow of a method for firmware protection based on a security coprocessor of the present invention; Figure 2 For Figure 1 a detailed step flow diagram of step S1 in Specific embodiments

[0009] The technical method of the present invention will be clearly and completely described below with reference to 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 skilled 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 their repeated description 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 the terms "first", "second", etc. may be used here to describe each unit, 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.

[0010] 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: Step S1: Obtain coprocessor feature data; extract hardware entropy source data based on the coprocessor feature data; generate a hardware root of trust key based on the hardware entropy source data; In the embodiment of the present invention, in the 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 for entropy source generation, or the original output values of a random number generator 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 randomness measurement functions, while 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 lifecycle.

[0011] 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; After generating the hardware root-of-trust key in the 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 into 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 it with the hash nodes in the hierarchical structure. It recursively verifies 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.

[0012] Step S3: 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; After the firmware startup integrity check is completed and the integrity verification data is obtained in the embodiments of the present invention, 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 data synchronization and 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.

[0013] 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 operation; After the communication channel is established and the session key data is generated in the embodiments of the present invention, the system configures the environment monitoring module during firmware operation using the session key. By continuously sampling and analyzing indicators such as stack space, exception interrupt calls, system call paths, and memory usage behaviors, a firmware running 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 the protection mechanism according to the policy, such as forcibly rolling back to the nearest trusted running snapshot, freezing the current thread execution, or transferring the current process to a simulated sandbox environment for execution, to prevent the spread of the anomaly. Information such as the protection trigger time, protection level, current call stack, and anomaly event label will be recorded during the enabling process of the protection mechanism, and finally constitute 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 emergency downgrade protection.

[0014] Step S5: Monitor the data access request according to the protection status data; perform hardware encryption processing based on the data access request to obtain the 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.

[0015] In an embodiment of the present invention, according to the protection status data during the operation of the foregoing firmware, when an external system or a user process initiates a data access request, it is first determined whether the current protection status is a trusted state. If it is not trusted, the request is rejected or the read-only mode is entered; if it is a trusted state, the hardware encryption processing flow is entered. The system uses the session key data as a symmetric encryption seed, combines the data type tags (such as configuration data, user keys, log information) and the visitor identification information in the access request, and encrypts the data through the SM4 or AES-GCM algorithm to obtain the hardware encryption result data, and attaches an integrity tag (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.) into the tamper-proof storage area (such as eFuse or TPM NV storage area) in a structured form. The system identifies whether the data has been tampered with by comparing whether the existing encryption tag is consistent with the current calculation result in subsequent access requests, and finally forms the firmware data security status data, the content of which includes the data tampering risk level, encryption strength index, visitor reputation assessment, etc. This mechanism is applicable to applications with integrity requirements for critical data, such as encrypting the flight parameter configuration table in an unmanned aerial vehicle flight control system to ensure that it has not been maliciously modified before and during flight.

[0016] Preferably, 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; In an embodiment of the present invention, during the power-on initialization stage of the coprocessor, the system first activates the process test module embedded in the chip bottom layer, and collects the electrical characteristic data of typical transistors in its core area through the on-chip test channel. Specifically, the system applies a gradually increasing gate voltage 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 of the power input terminal of the entire coprocessor 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 precision low-power measurement circuit. The collection 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 during the first power-on or reset initialization stage of the chip and is used to establish the basis for the subsequent feature fingerprint template. 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.

[0017] Step S12: Collect the startup response time and signal stability index of the coprocessor memory unit; After the co - processor is initialized in the embodiments of the present invention, the self - test mechanism of its on - chip SRAM or Flash storage unit is activated. A storage unit initialization and loading command is initiated at the system clock frequency, 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 continuously stable time window during the data output process are monitored to evaluate the stability index of the output signal. In specific operations, the system repeats the test for 128 representative addresses with a sampling accuracy of 1 nanosecond per cycle, records the average response time and the stability variance, and forms a startup behavior feature vector. The calculation methods of the signal stability index include the maximum level transition amplitude, the duration deviation between the rising edge and the falling edge, 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%.

[0018] Step S13: Obtain the reference operation speed and timing characteristics of the encryption module of the co - processor; After the co - processor in the embodiments of the present invention completes the basic hardware loading, the system calls its integrated symmetric encryption module (such as AES or SM4) to perform reference operation tasks. With 512 - byte random data as the input, fixed - round encryption operations are executed, and the total number of cycles from the completion of the input loading to the output of the ciphertext is recorded and converted into the reference 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 dependency 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 consumption of a single - round 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.

[0019] Step S14: Generate co - processor feature data according to the transistor threshold voltage, static power consumption, startup response time, signal stability index, reference operation speed, and timing characteristics; In the embodiments of the present invention, after separately obtaining the transistor threshold voltage, static power consumption, storage response time, signal stability index, encryption module reference speed, and timing characteristics, a feature fusion method is used to generate co-processor 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 co-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. Next, a hierarchical feature splicing method is used to arrange different types of data in the structural order of timing characteristics - static power consumption - storage response - encryption speed, and finally, a co-processor feature vector with a length of 2048 bits is generated as the unique physical feature identity of the co-processor. This data is not only used for subsequent entropy source generation but also supports device fingerprint binding and trust initialization verification. In the Internet of Things 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.

[0020] Step S15: Generate hardware entropy source data using a ring oscillator array based on the co-processor feature data; In the embodiments of the present invention, based on the generated co-processor feature data, the ring oscillator array is started 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 encryption module timing offset and storage response variance) to oscillator control parameters, which are used to configure multiple ring oscillator units with different frequencies and phase delays, and the oscillation times of these oscillators are counted with high precision 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 a debiasing algorithm (such as the Von Neumann algorithm or polynomial perturbation algorithm) is used to eliminate the significantly biased bits, and a high-quality entropy bit stream is extracted 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 on average at a 100 MHz reference clock, which meets most embedded key generation tasks.

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

[0022] In the embodiment of the present invention, after obtaining high-quality hardware entropy source data, a hardware root of trust key is generated based on this data. During implementation, the system first performs 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 repeating 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 coprocessor 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 coprocessor. This area uses 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's life cycle. In an 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.

[0023] Preferably, 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 a sampling window to obtain oscillator configuration data; In the embodiment of the present invention, after obtaining the coprocessor feature data, the characteristic quantities sensitive to circuit process fluctuations are first extracted, including transistor threshold voltage, encryption module timing offset, and signal stability index, as the configuration reference for the ring oscillator array. Using each characteristic value as a seed for oscillator configuration, the system uses internal registers to control the number of inverter stages, load capacitance value, and drive current intensity of each oscillator unit, thereby forming diverse oscillation frequencies. After completing the array configuration, 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. The number of oscillations of each oscillator is continuously counted 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 stages of 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.

[0024] 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; After the sampling window ends in the embodiments of the present invention, the system reads the count values of each ring oscillator during sampling, and pairs them up in sequence of logical numbers to form adjacent oscillator groups. For example, the first group is paired with the second group, and the second group is paired with the third group in turn. Calculate the oscillation count difference between each pair, that is, subtract the oscillation times of the previous group from the oscillation times of the latter group to obtain frequency difference data. The system can implement this difference calculation through a hardware comparator, and at the same time use 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 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 from 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 minute perturbations such as process differences, power supply fluctuations, and temperature offsets, and are the key basis for constructing the entropy source.

[0025] Step S153: Convert the count difference in the frequency difference data into a bit sequence, where converting into a bit sequence specifically means that when the difference is positive, it is recorded as 1 in the bit sequence, and when the difference is negative, it is recorded as 0, and when the difference is zero, it is discarded; In the embodiments of the present invention, the count difference in the frequency difference data is converted into a standardized bit sequence. The specific rule is: if the difference of a certain group 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, which is used to control the overall entropy source bit amount. 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 a sampling as an example, 60 groups of difference data are obtained, among which 52 groups 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 frequency of adjacent oscillators being "faster" or "slower" than the previous oscillator, and have high non-repeatability and unpredictability.

[0026] Step S154: Connect multiple groups of bit sequences to generate original hardware entropy source data with a length of not less than 1024 bits; In the embodiment of the present invention, multiple bit sequences are concatenated in batches to form original hardware entropy source data with a continuous length of at least 1024 bits. In the specific process, the system extracts bit sequences in parallel 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 appended continuously to ensure no repetition or coverage. At the same time, the system performs a 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.

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

[0028] After the embodiment of the present invention generates the original entropy source data, it starts the on-chip sensor to collect the current ambient temperature, the amplitude of the power supply voltage fluctuation and the electromagnetic interference intensity in real time, and generates 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 to detect 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 the empirical value that the bit error increases by 0.2% for every 1°C increase according to 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 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 above 0.985, meeting the usage standard of the subsequent security module.

[0029] Particularly importantly, step S16 includes the following steps: Step S161: Correct the bit flip error of the hardware entropy source data to obtain high-steady-state entropy core data; After the embodiment of the present invention obtains the hardware entropy source data with a length of more than 1024 bits, it first performs the detection and correction operations for bit flipping errors. Specifically, it uses the BCH (Bose–Chaudhuri–Hocquenghem) error correction code for encoding and matching, divides the entropy source bit stream into logical blocks, such as every 128 bits as a group, and uses the preset redundant check bits in each group to detect and correct potential single-bit or multi-bit flipping errors. During the error correction process, the system extracts the check bits from each group, 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, it uses the decoding method based on matrix inverse operation to locate the error bit and flip and repair it. For example, if the 5th bit is found to be 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 a 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 ensures that the entropy core data of each batch meets the strong consistency requirements for secure random number generators in the national commercial cryptography standard.

[0030] 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; After the embodiment of the present invention completes the guarantee of entropy core stability, 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 through 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 is used as the basic seed for key generation. Subsequently, the system inputs this 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 the 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, and splice the two segments 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 this key not only comes from the physical hardware characteristics but also has a secure basis with high entropy and high distribution balance.

[0031] 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; In the embodiments of the present invention, a 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 with multiple uses. First, the 512-bit master key is used as the input key material of HKDF, and a standard salt value (such as a device ID or a startup timestamp) and context tags (such as "verify_key", "encryption_key", "comm_key") are used as additional inputs. Two-phase 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 often used for digital signatures 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 keys for different uses and to meet the requirements of pseudo-randomness. In a high-security intelligent terminal chip, 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.

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

[0033] After the key structure derivation is completed in the embodiments 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.

[0034] Preferably, the partitioning process of the firmware based on the hardware root of trust key described in step S2 includes: Perform firmware binary code analysis based on 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 root of trust key; Perform block slicing on the firmware code in the core execution area to generate code block sequence data with a data block size of 4KB; Calculate the HMAC value of each code block based on the hardware root of trust key and the code block sequence data, 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 root of trust key; Perform security isolation on the data storage area, and establish a data encryption channel based on the hardware root of trust 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.

[0035] In the system initialization phase 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). The firmware is parsed byte-by-byte for instructions using static analysis tools (such as the Capstone disassembly engine or IDA Pro plugin), and in combination 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 recognition results into structured data to generate a firmware structure mapping table. This table records the start 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 running policies and is classified as a medium security level; while the data storage area stores communication buffer data or non-critical status information generated during operation and is 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 needs to be ensured to be permanently trusted through an encrypted signature. 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 starts up, 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 lockout mechanism is triggered to prevent the device from entering an untrusted state. To achieve a higher granularity of code integrity monitoring, the system performs block slicing 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 order of address. 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 divided, 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 separately. 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 digest is output. The HMAC values of each block are concatenated in order of number 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 that has passed authentication to access the configuration. 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 to ensure 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 isolates it securely through hardware logic. In terms of address mapping, this area has a separate address space demarcated, and through the security MMU configuration, it is restricted to read-write only and not 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. Before each data write, 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 through the AES-CTR mode, and the initial counter is refreshed dynamically 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 various parts of the structure are integrated into a complete firmware partition data structure. This structure usually uses the TLV (Type-Length-Value) format for encoding, including the type identifier, length field, data content, and verification information of each partition. Before the overall firmware structure is written to the Flash, it is encapsulated by the firmware compilation tool chain, and metadata such as the version number, verification digest, and firmware size are written in the firmware header. After the device is powered on, the co-processor security boot module loads, verifies, and maps the partition data to the running memory space in sequence. 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.

[0036] Preferably, the constructing the hierarchical verification structure data according to the firmware partition data described in step S2 includes: 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; Allocating verification priorities according to the master-slave verification relationship, constructing a verification dependency graph, and generating the node verification order; Setting the signature data of the boot area in the firmware partition data as the root verification node; 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; 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; Performing data consistency verification during runtime according to the node verification order, the root verification node, and the verification transfer chain to obtain a dynamic integrity verification matrix; Integrating the dynamic integrity verification matrix and the configuration verification mapping into the hierarchical verification structure data.

[0037] 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, the core execution area, the configuration area, and the data storage area during the initialization of the verification framework, including their signature data, code block verification chains, parameter tables, and encrypted channel descriptions. 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 organizing them hierarchically 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 the 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 is convenient for subsequent dynamic verification path tracking and management. After establishing the multi-level verification tree, the system enters the verification policy 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 the data area are numbered after all the 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 verification is passed, the system generates a verification node structure for it, which includes the node number, verification status, dependencies being empty, and the 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 only allowed to start after it has been successfully completed. Therefore, the timeliness and reliability of the verification of this node are crucial. The system usually completes this process early during 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 next-stage execution area code after verification is passed to prevent the boot logic from being replaced or malicious jumps being inserted. The core execution area contains multiple code blocks divided by 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, block number, starting address, length, and the pointer to the previous block node. The system attaches a verification pointer to each node, pointing to the node of the previously verified block, forming a cascading verification structure for block-by-block transmission. 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 transmission 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 both linear verification during the startup phase and random access verification during the runtime phase. For example, in an in-vehicle safety 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 all pass before accessing this section to ensure that the overall logic 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 the 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 conjunction with the access control policy module. After verification is passed, it further determines whether it conforms to the access policy (such as the identity of the accessing user, 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 critical parameter, and its original hash 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, it records the operation exception and writes it to the log system.During the running phase, based on the node verification order, root verification node, and verification transfer chain in the core execution area generated as described above, perform dynamic data consistency verification for each node, and construct a dynamic integrity verification matrix in real time. This matrix is a two-dimensional structure, with the horizontal axis representing the verification node number and the vertical axis representing the verification time axis. Each element records the verification status (such as unverified, passed, failed) of the corresponding node at a certain time point. The system sets verification policies to activate the verification process of specified nodes and their dependent nodes periodically or triggered by events (such as loading modules, external instruction responses). For example, in a certain secure routing device, when a core Block36 loading request is detected during runtime, the system automatically triggers the HMAC verification for Block0 to 36, gradually updating the status of the corresponding cells in the matrix, thereby achieving the detection of execution path consistency and timing integrity. If a node's status is "failed" during verification, the system immediately blocks the execution request of its child nodes and triggers a response mechanism (such as locking, restarting, switching to a backup image). This matrix is not only used for runtime security control but also recorded as part of the system audit log for post-event analysis. Finally, integrate the dynamic integrity verification matrix with the configuration verification mapping data to construct a complete hierarchical verification structure data. This structure is stored in a structured format such as JSON or TLV. Each hierarchical node contains the node type, verification method, upper-layer dependency, status history, and access permission 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 at one time during the system startup phase and provides a basis for secure adjudication of firmware execution and configuration access throughout the system lifecycle. This structure also facilitates export through a remote security audit interface, supporting the comparison and verification of the firmware security status before OTA upgrade. In a certain security camera device, this verification structure is directly compared after the upgrade package verification. If the structure of the new firmware is inconsistent with the current one, the system will reject the upgrade and record the differences for manual review.

[0038] Preferably, the firmware startup security verification based on the hierarchical verification structure data described in step S2 includes: Load the hierarchical verification structure data during the co-processor startup process and initialize the verification engine; Decrypt the verification parameters and verification 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 sequence based on the hierarchical order of the hierarchical verification structure to obtain the partition verification result; Perform priority verification on the key areas in the firmware partition data, extract the startup key parameters and confirm their validity to generate the path credibility; Perform consistency verification on the configuration area parameters in the hierarchical verification structure data and compare them with the standard configuration values to generate the configuration consistency data; Record the verification time information of each partition according to the verification configuration set to generate the timing behavior data; Perform anomaly flag 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 the integrity verification data.

[0039] In the initialization stage when the co-processor starts, 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 the verification node levels, the verification methods for each layer of nodes (such as signature verification, hash verification, HMAC comparison, etc.), dependency relationships, and configuration area mapping tables. 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 in 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", and "configuration table node", whose verification methods are ECDSA signature verification, SHA-256 hash comparison, and hash value comparison respectively, and bind them to the security accelerator resources in the co-processor chip to improve the 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 trust root. 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 the verification algorithm type, reference value, verification method, priority, and policy flag. 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 then 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 byte-by-byte hash verification in accordance with 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 method to ensure that the verification results are 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 segments (such as the first 4KB startup entry) from the execution area according to the priority flags recorded in the hierarchical verification structure, and performs fast hash comparison or signature verification to verify that they have 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 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, and the ID of the valid parameter set, which is used 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 safe 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 of the parameter items in the configuration area is also verified. 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) in the configuration area of 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 verification 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 (in milliseconds), 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, Block37, 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 Block42". The system triggers a downgraded 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.

[0040] Preferably, 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; 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 a processor - to - 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.

[0041] 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; 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 (such as 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 pass / fail 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 sent back 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.

[0042] 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 mutual authentication process and obtain mutual authentication process data; In the embodiment of the present invention, the main processor starts the mutual 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 sampling through an entropy source TRNG module), and this random number is unique and unpredictable; then the main processor encapsulates this challenge number as an authentication challenge parameter into an authentication request message and sends it to the coprocessor together with the handshake confirmation data in the previous stage, triggering the coprocessor to start the identity verification process, and the entire process information formed is saved as mutual authentication process data.

[0043] Step S34: According to the mutual 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; After receiving the authentication request message sent by the main processor, the coprocessor in the embodiment of the present invention first unpacks the message to obtain the challenge number and the identity information of the main processor. 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 legitimate entity. The verification comparison result generated in this process is the identity authentication data.

[0044] 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; 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 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 public keys of the other party, 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. Finally, a set of high-strength secure channel seed keys with a length of 512 bits is formed.

[0045] 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; 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. The session key dataset includes: 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.

[0046] 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.

[0047] 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 an instruction to start the encrypted communication. Both parties enter the two - way encrypted communication state. The coprocessor starts the encrypted 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 encrypted communication environment, ensuring that the data communication between the dual - processors is always under trusted, encrypted, and authenticated protection.

[0048] Preferably, 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 parameters, and establish a firmware runtime environment monitoring framework. After the main processor and the coprocessor in the embodiment of the present invention complete the establishment of the encrypted session, the main processor initializes the built - in environment monitoring engine module with the negotiated session key data. This engine runs in a secure context based on the chip security architecture (such as ARM TrustZone Secure Monitor or 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.

[0049] 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. After the monitoring framework of the present invention embodiment is started, the environmental monitoring engine periodically triggers a memory integrity scan task. The scan frequency is default set to once every 100 milliseconds. This task traverses the memory address ranges of the firmware's critical code segments, such as the startup loading area, exception handling function segment, and critical 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.

[0050] Step S43: Deploy control flow monitoring points for the firmware running environment monitoring framework, track the firmware instruction execution order, and obtain actual instruction execution data; In the embodiment of the present invention, the monitoring engine predefines multiple control flow monitoring points in the system. These monitoring points are usually inserted at positions before and after key branches, function entrances, and jump instructions. The instrumentation method can be achieved 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.

[0051] Step S44: Identify unexpected jump instructions or function calls according to the actual instruction execution, and obtain execution flow exception data; In the embodiment of the present invention, the main processor 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 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 abnormality is found, the exception type, the PC address at the time of triggering, the instruction content, and the time tag are recorded, forming execution flow exception data and reporting it to the analysis module.

[0052] Step S45: Monitor the firmware access behavior pattern according to the firmware running environment monitoring framework, and obtain firmware access data; In the embodiment of the present invention, the monitoring engine monitors the access behavior of the firmware to on-chip resources through a built-in bus listening mechanism, mainly focusing on read and write operations of address ranges such as Flash, RAM, and peripheral registers. It records 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 in an event recording manner. For example, if it is detected that the communication buffer or certain specific IO address areas are frequently written during interrupt processing, 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.

[0053] Step S46: According to the firmware access data, record the read and write operation frequencies and timing characteristics of sensitive areas, and construct a behavior baseline model to generate access pattern analysis data. After obtaining the firmware access data in the embodiment of the present invention, the main processor calls the access behavior analysis module. According to a preset sensitive area table (such as including device configuration registers, system key registers, Flash write protection segments, etc.), it extracts characteristic parameters such as the read and write behavior frequencies, interval times, and access granularities (bytes / words / blocks) of the corresponding address areas, and statistically analyzes the frequency distribution of the past N times (such as N = 128) of access based on a sliding time window model. Subsequently, these timing characteristics are used to train a 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 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.

[0054] Step S47: Merge the memory integrity monitoring data, execution flow anomaly data, and access pattern analysis data into the firmware running environment. In the embodiment of the present invention, the firmware monitoring module of the main processor regularly aggregates the above three types of data. First, it cross-analyzes the abnormal address segments in the memory integrity monitoring data and the abnormal trigger positions recorded in the control flow anomaly data to determine whether there is a corresponding relationship (for example, an instruction jumps to a certain integrity anomaly area). Then, it aligns the timestamps of the high-frequency sensitive access behaviors in the access pattern analysis data with the execution flow anomaly points to determine whether access behavior anomalies and control flow deviation events occur within the same time window. Based on the results of these multi-dimensional data fusions, an information set of the current firmware running environment is constructed, indicating its various abnormal risk levels, possible intrusion paths, abnormal coverage areas, etc., to form a complete view of the running environment security situation.

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

[0056] In the embodiment of the present invention, the main processor analyzes the threat level and the scope of influence of potential abnormal behaviors based on the firmware running environment information set. If high-risk abnormalities are found (such as simultaneous damage to the integrity 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 abnormalities (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.

[0057] Of particular importance is that step S48 includes the following steps: Step S481: Identify potential intrusion behaviors through rule-matching detection based on the firmware running environment to obtain an intrusion detection report; After the firmware running environment is established and monitored in the embodiment of the present invention, the system performs 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 summarizes all the matched potential intrusion behaviors to form an intrusion detection report, which contains information such as the matching rule, detection time, and trigger condition for 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.

[0058] 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 a protection response strategy; In the embodiments of the present invention, once an intrusion detection report is generated, the main processor classifies and grades these detected abnormal behaviors according to the report. The classification is based on the types of abnormal behaviors, 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.

[0059] Step S483: Deploy a dynamic code isolation mechanism based on the protection response strategy, perform runtime sandboxing on the suspicious module, restrict resource access permissions, and record the behaviors within the sandbox to obtain an isolation execution log. In the embodiments of the present invention, based on the protection response strategy, the system will start a dynamic code isolation mechanism. This mechanism performs 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.

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

[0061] All the data generated in the embodiments of the present invention, including intrusion detection reports, protection response policies, and sandbox isolation execution logs, will be aggregated and processed in the main processor. The system will perform fusion analysis on this 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 protection measures. The aggregated data will include, for example, the triggering conditions of protection policies, 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 a basis for security audits to evaluate the security of the current firmware environment and further adjust the protection policies if necessary.

[0062] Preferably, 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, and obtain an access monitoring framework; In the embodiments of the present invention, based on the protection status data, the system will configure a data access monitoring engine and deploy access control policies and monitoring points. First, by analyzing the protection status data, it is determined which sensitive areas or key 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 key data access paths, such as memory read / write, file system access, etc., to monitor all data access requests in real time. The monitoring framework will capture and record each access request, including detailed information such as the access source, target resource, and access time. Finally, the access monitoring framework will run continuously and provide support for subsequent access request verification and encryption / decryption operations.

[0063] Step S52: Intercept data access requests based on the access monitoring framework, verify the identity and permission level of the request source, generate an access token for legitimate requests, and obtain access control data; After the access monitoring framework in the embodiments of the present invention 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, based on the authentication result of the request source and the permission management rules within the system, the system determines the permission level of the request. 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.

[0064] Step S53: Transmit the request to the secure co-processor according to the access control data, perform data encryption and decryption operations, and append an integrity check code to generate hardware-encrypted result data; Once the access control data is generated in the embodiments of the present invention, the system transmits the verified data access request to the secure co-processor. The role of the co-processor is to perform data encryption and decryption operations. Specifically, based on the content of the request (such as reading sensitive data or modifying system configuration), the co-processor calls a 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 also checks the integrity of the data and uses a hash algorithm (such as SHA-256) to generate an integrity check code for the data. This check code is appended to the encrypted data for subsequent verification of whether the data has been tampered with. After processing, the co-processor returns the encrypted data and the appended integrity check code to the requester or uses them for the next data interaction.

[0065] Step S54: Based on the hardware-encrypted 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; According to the hardware-encrypted result data obtained from the secure co-processor in the embodiments of the present invention, the system constructs 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 includes 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 records 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.

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

[0067] In the 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 means 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 will be executed (such as warnings, locking operations, etc.). In addition, the system will record the detailed information of all access operations, including the verification results during access, the detailed description of abnormal events, the time stamps when they occur, etc. These data will constitute the firmware data security status data and form a report for security administrators to view and audit. The system will continuously monitor the data interaction status to ensure the security of the firmware.

[0068] 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: 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; A firmware partition and verification module, which is used to 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; and perform firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data; 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; 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 protection status data during firmware operation; 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.

[0069] Therefore, in all respects, the embodiments should be regarded as exemplary and non-limiting. The scope of the present invention is defined by the appended claims rather than the above description. Thus, all changes falling within the meaning and scope of the equivalent elements of the application documents are intended to be encompassed 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 security coprocessor, characterized in that: The following steps are involved: Step S1: Acquire coprocessor characteristic data; extract hardware entropy source data according to the coprocessor characteristic data; Generate a hardware root of trust key based on hardware entropy source data; Step S2: partitioning the firmware based on the hardware trusted root key to obtain firmware partition data; Building hierarchical verification structure data based on firmware partition data; Implement firmware startup security verification based on hierarchical verification structure data to obtain integrity verification data; Step S3: establishing a secure communication channel between processors based on the integrity verification data; Performing a two-way authentication process based on a secure communication channel and generating session key data; Step S4: monitoring the firmware operating environment based on the session key data; identifying potential abnormal behaviors according to the firmware operating environment, and implementing protective measures to obtain protection status data during firmware operation; 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.

2. The method for firmware protection based on a security coprocessor according to claim 1, characterized in that: Step S1 includes the following steps: Step S11: During the coprocessor power-on initialization phase, measuring the transistor threshold voltage and static power consumption; Step S12: collecting the startup response time and signal stability index of the coprocessor memory unit; Step S13: obtaining the benchmark operation speed and timing characteristics of the encryption module of the coprocessor; Step S14: generating coprocessor characteristic data according to transistor threshold voltage, static power consumption, startup response time, signal stability index, benchmark operation speed and timing characteristics; Step S15: Generate hardware entropy source data using a ring oscillator array based on the coprocessor characteristic data; Step S16: Generate a hardware trusted root key based on the hardware entropy source data.

3. The method for firmware protection based on a security coprocessor according to claim 2, characterized in that: Step S15 includes the following steps: Step S151: configuring and starting a built-in ring oscillator array according to the coprocessor characteristic data, and setting a sampling window to obtain oscillator configuration data; Step S152: recording the oscillation count value within the sampling window based on the oscillator configuration data, and calculating the count difference between adjacent oscillator groups to obtain frequency difference data; Step S153: converting the count difference in the frequency difference data into a bit sequence, wherein the converted bit sequence is specifically a bit sequence 1, a negative difference is recorded as 0, and a difference is discarded when it is zero; Step S154: connecting multiple groups of bit sequences to generate original hardware entropy source data with a length of no less than 1024 bits; Step S155: monitor the current ambient temperature, voltage fluctuation and electromagnetic interference intensity to obtain environmental parameters; and perform linear compensation processing of the temperature coefficient of -0.2% / °C on the original hardware entropy source data according to the environmental parameters to obtain hardware entropy source data.

4. The method for firmware protection based on a security coprocessor according to claim 1, characterized in that: Partitioning the firmware based on the hardware trusted root key in step S2 includes: Perform firmware binary code analysis based on coprocessor feature data, identify functional modules and data areas, 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; Hash the firmware code in the boot area and use the hardware trusted root key to generate the boot area signature data; The firmware code of the core execution area is divided into blocks and sliced ​​to generate code block sequence data with a data block size of 4KB; Calculate the HMAC value of each code block based on the hardware trust root key and code block sequence data to build a code integrity verification chain; Encrypt and store the parameters in the configuration area, and set access control policies based on the hardware trusted root key; Securely isolate the data storage area and establish a data encryption channel based on the hardware trusted root key; The boot area signature data, code integrity check chain, configuration area access control and data encryption channel are combined into firmware partition data.

5. The method for firmware protection based on a security coprocessor according to claim 1, characterized in that: The step S2 of constructing hierarchical verification structure data according to the firmware partition data includes: Build multi-level verification nodes based on firmware partition data, form a tree-like verification hierarchy, and determine the master-slave verification relationship; Assign verification priorities according to the master-slave verification relationship, build 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; Based on the code integrity check chain in the firmware partition data, a cascade verification structure of the core execution area is established to form a verification transfer chain; Establish a hash verification table for the configuration area parameters in the firmware partition data, associate it with the access control policy, and generate a configuration verification map; Perform data consistency check at runtime based on the node verification order, root verification node, and verification transfer chain to obtain a dynamic integrity verification matrix; Integrate the dynamic integrity verification matrix and configuration verification map into hierarchical verification structure data.

6. The method for firmware protection based on a security coprocessor according to claim 1, characterized in that: The implementation of firmware startup security verification based on the hierarchical verification structure data described in step S2 includes: Loading hierarchical verification structure data during coprocessor startup and initializing the verification engine; Decrypt the verification parameters and check values ​​of the hierarchical verification structure data based on the hardware trusted root key to generate a verification configuration set; Perform hash verification on each partition of the firmware in sequence based on the hierarchical verification structure to obtain the partition verification result; Perform priority verification on key areas in the firmware partition data, extract key startup parameters and confirm their validity, and generate path credibility; Perform consistency check on configuration area parameters in hierarchical verification structure data, and compare with standard configuration values ​​to generate configuration consistency data; Record the verification time information of each partition according to the verification configuration set to generate time series behavior data; The partition verification results, path credibility, configuration consistency results and timing behavior data are marked with abnormalities and summarized into a verification status report to obtain integrity verification data.

7. The method for firmware protection based on a security coprocessor according to claim 6, characterized in that: Step S3 includes the following steps: Step S31: triggering a session initialization request between processors based on the integrity verification data, and constructing a verification channel handshake frame to generate a secure communication channel; 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; Step S33: Generate a random challenge number based on the hardware trusted root key, and use the main processor to send the random challenge number to the coprocessor through 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, the coprocessor performs an asymmetric encryption signature on the received challenge number, and adds its own authentication information to construct an identity response message, which is returned to the main processor for identity matching verification to obtain identity authentication data; Step S35: jointly generate an initial shared key based on the ECDH elliptic curve key agreement algorithm according to the identity authentication data, and perform PBKDF2 strengthening processing to obtain a secure channel seed key; Step S36: Generate a session key data set using the secure channel seed key through the AES-GCM algorithm, where the session key data set includes a symmetric encryption key, a MAC verification key, and a time control parameter; 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.

8. The method for firmware protection based on a security coprocessor according to claim 7, 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 anomaly detection threshold parameters, and establish a firmware runtime environment monitoring framework; Step S42: starting a periodic memory integrity scan based on the firmware operating environment monitoring framework, performing a hash check on the firmware key code segments, and comparing them with the benchmark values ​​to generate memory integrity monitoring data; Step S43: deploying control flow monitoring points to the firmware operating environment monitoring framework, tracking the firmware instruction execution sequence, and obtaining actual instruction execution data; Step S44: identifying unexpected jump instructions or function calls according to actual instruction execution, and obtaining execution flow exception data; Step S45: monitoring the firmware access behavior pattern according to the firmware operating environment monitoring framework to obtain firmware access data; Step S46: Record the read and write operation frequency and timing characteristics of the sensitive area according to the firmware access data, and build a behavioral baseline model to generate access pattern analysis data; Step S47: merging the memory integrity monitoring data, the execution flow anomaly data, and the access pattern analysis data into a firmware operating environment; Step S48: Identify potential abnormal behaviors according to the firmware operating environment, and implement protective measures to obtain protection status data when the firmware is running.

9. The method for firmware protection based on a security coprocessor according to claim 8, characterized in that: Step S5 includes the following steps: Step S51: configuring a data access monitoring engine based on the protection status data, deploying access control policies and monitoring points, and obtaining an access monitoring framework; Step S52: intercepting data access requests based on the access monitoring framework, verifying the identity and permission level of the request source, generating access tokens for legitimate requests, and obtaining access control data; Step S53: according to the access control data, the request is transmitted to the security coprocessor, data encryption and decryption operations are performed, and an integrity check code is added to generate hardware encryption result data; Step S54: constructing a tamper-proof data encapsulation structure based on the hardware encryption result data to form a data tamper-proof mechanism, wherein 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 tamper-proof mechanism, record the integrity verification results and abnormal events of the access operation, and generate firmware data security status data.

10. A firmware protection system based on a security coprocessor, characterized in that: The method for executing the firmware protection based on the security coprocessor according to claim 1, wherein the system for firmware protection based on the security coprocessor comprises: An entropy source generation module is used to obtain coprocessor characteristic data; extract hardware entropy source data according to the coprocessor characteristic data; and generate a hardware trusted root key based on the hardware entropy source data; The firmware partitioning and verification module is used to partition the firmware based on the hardware trusted root key to obtain firmware partition data; construct hierarchical verification structure data based on the firmware partition data; implement firmware startup security verification based on the hierarchical verification structure data to obtain integrity verification data; A secure communication establishment module is used 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; The operating environment monitoring module is used to monitor the firmware operating environment based on the session key data; identify potential abnormal behaviors according to the firmware operating environment, and implement protective measures to obtain protection status data during firmware operation; The data access encryption module is used to monitor data access requests according to protection status data; perform hardware encryption processing based on 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.

Images