Firmware security starting method, device and system and electronic medium

Abstract

The invention provides a firmware security startup method, device and system and an electronic medium, which effectively prevent firmware from being tampered and illegally injected through sequential control, anomaly detection and blocking of a hardware metric root on a firmware security startup process in combination with multi-stage file signature and feature information verification based on a public key, and improve the security of the firmware. A security chip is utilized to enhance security and establish a security monitoring mechanism, so that firmware security of the whole life cycle of the system is guaranteed; and meanwhile, the hardware metric root has a periodic firmware integrity detection function and an efficient trusted firmware recovery function when the hardware metric root is damaged, rapid repair and re-verification can be realized, the system downtime is shortened, the production loss is reduced, and the firmware protection capability and the overall performance of the DCS controller in a complex industrial environment are greatly improved.

Description

Technical Field

[0001] The present application belongs to the technical field of industrial control system firmware protection, and specifically relates to a firmware secure startup method, device, system and electronic medium. Background Art

[0002] In the context of the rapid development of industrial automation technology, DCS controllers, as the core network nodes of distributed control systems, undertake the key mission of processing field I / O and realizing direct digital control (DDC) functions, and play an indispensable role in the entire industrial production process. However, DCS controllers currently on the market generally have a significant defect, that is, they focus too much on the real-time control performance and reliability of the system, but seriously ignore the crucial aspect of the system's safety protection performance.

[0003] In terms of communication mechanism, the existing DCS controllers mostly use plain text for data transmission, which makes it impossible for the controller to effectively identify the authenticity of the data source. Attackers can use various malicious means such as implanting viruses on the network and launching man-in-the-middle attacks to arbitrarily tamper with the controller firmware and configuration programs, thereby achieving the purpose of controlling the system function.

[0004] Traditional trusted boot methods for computing systems are mainly built on TPM chips. In a typical boot process, after the system is powered on, the CPU first starts and runs the BIOS firmware. At the same time, the TPM chip is initialized to prepare for the subsequent security verification process. In this system, the hardware measurement root is usually an immutable code segment in the BIOS firmware, whose main responsibility is to measure and record the hash value of the initial boot code and properly store these hash values ​​in the TPM's PCR. As the boot process progresses, the code of each subsequent stage, including the boot loader, operating system kernel, etc., will be measured in turn, and the hash value obtained by each measurement will be extended to the corresponding PCR, thus forming a theoretically tamper-proof measurement chain. In each boot stage, the system can use the PCR value in the TPM to rigorously verify the integrity of the previous stage. However, this traditional method has a security risk that cannot be ignored, that is, the BIOS itself is likely to be tampered with. Once the BIOS is maliciously tampered with, the security of the entire trusted boot mechanism will be greatly reduced.

[0005] In contrast, the domestic TPCM trusted boot technology has solved the security problem of BIOS to a certain extent by introducing the TCM security chip. After the system is powered on, the boot process first starts the TCM security chip, which acts as a hardware trusted root to verify the BIOS firmware on the memory, ensuring the security and trustworthiness of the BIOS. After the BIOS is successfully loaded, the subsequent boot process is similar to the trusted boot process based on TPM.

[0006] Traditional trusted boot technology ensures the security of firmware by verifying the hash or signature of the firmware. The firmware stored in FLASH can modify the code content through hardware. However, the firmware loading process is not monitored in real time, so non-secure firmware can be injected through the FLASH communication bus loaded by the firmware during the boot process, posing a serious threat to system security.

[0007] In summary, in view of the many serious problems existing in the firmware security boot of existing DCS controllers, there is an urgent need for a new and more complete firmware security boot method to effectively improve the security of DCS embedded controller firmware trusted boot and firmware data, and resolutely prevent attackers from illegally tampering with the DCS controller system firmware program in any form. Summary of the invention

[0008] In view of the above-mentioned shortcomings and deficiencies of the prior art, the present application provides a firmware secure startup method, device, system and electronic medium, which monitors the firmware loading process in real time, detects and blocks anomalies through a hardware measurement root, and combines multi-stage file signature and feature information verification based on a public key to effectively prevent firmware tampering and illegal injection. Security is enhanced by using a security chip and a security monitoring mechanism is established to ensure firmware security throughout the life cycle of the system. At the same time, the hardware measurement root has periodic firmware integrity detection and efficient trusted firmware recovery functions when damaged, which can be quickly repaired and re-verified, reducing system downtime and production losses, greatly improving the firmware protection capability and overall performance of DCS controllers in complex industrial environments.

[0009] To achieve the above objectives, the present application adopts the following technical solution, a firmware secure boot method, comprising: S1: After the hardware measurement root is powered on, other hardware is put into a power-on state and the CPU is woken up; S2: The CPU starts the built-in Boot program and sends a data read request to the BootFlash memory. The hardware measurement root captures the BootLoader file and verifies it. If the verification passes, the BootLoader program is loaded. If the verification fails, the hardware measurement root resets the CPU. S3: After the BootLoader completes loading, the hardware trusted root controls the security chip and NandFlash module to power on, and the BootLoader obtains the public key in the security chip to verify the NandFlash system program; if the verification passes, the CPU loads the system program; if the verification fails, the BootLoader notifies the trusted measurement root to reset the CPU; S4: After the system program is loaded, the hardware trusted root controls the peripheral circuit to power on, and the system program verifies the user program of the peripheral circuit; if the verification passes, the CPU loads and executes the user program; if the verification fails, the hardware trusted root CPU re-downloads the user program.

[0010] Furthermore, the hardware measurement root is FPGA, and the FPGA is burned and solidified with the manufacturer's public key information FSK when it leaves the factory. The BootLoader file verification method in S2 includes: S201: The hardware trusted root captures the BootLoader file and obtains the BootLoader file signature information using the built-in manufacturer public key information FSK; S202: Calculate the characteristic hash value of the BootLoader file; S203: Compare the BootLoader file feature hash value with the hardware trusted root built-in BootLoader file feature baseline to determine whether they are consistent. If yes, execute S204; otherwise, execute S205; S204: The CPU loads the BootLoader and transfers the startup control to the BootLoader; S205: The hardware metric root resets the CPU.

[0011] Furthermore, the security chip is burned with the platform public key information PSK when it leaves the factory, and the verification method for the system program in S3 includes: S301: BootLoader loads and runs, and notifies the hardware measurement root control security chip and NandFlash module to power on. BootLoader uses the platform public key information PSK to obtain the signature information of the system program file; S302: Calculate characteristic hash values ​​for system program files; S303: BootLoader submits the system file hash value to the security chip and compares it with the system program file feature baseline built into the security chip to determine whether they are consistent. If yes, execute S304; otherwise, execute S305; S304: The CPU loads the system program and transfers the startup control right to the system program; S305: The hardware trusted root resets the CPU.

[0012] Furthermore, the security chip downloads user public key information USK when the user configures, and the verification method for the user program in S4 includes: S401: The system program is loaded and run, and the hardware measurement root is notified to control the peripheral circuit to power on. The system program uses the user public key information USK in the security chip to obtain the user program file signature information; S402: Calculate the characteristic hash value of the user program file; S403: Compare the characteristic hash value of the user program file with the characteristic baseline of the user program file built in NandFlash to determine whether they are consistent. If yes, execute S404; otherwise, execute S405; S404: CPU loads and executes the user program; S405: Forbid the loading of the user program and download the user program again.

[0013] Furthermore, during the operation of the system, the hardware measurement monitors the CPU's reading and writing of the memory in real time, and if an abnormality is found, the communication bus between the CPU and the memory is blocked.

[0014] Furthermore, after the system is started up, the hardware measurement root periodically detects the firmware, and if an abnormality is found, the system is reset.

[0015] Furthermore, the system reset method includes: Extract the backup file of the last successful startup from the preset storage area; Replace the files that failed verification or detected abnormalities with the extracted backup files; Restart the power-on firmware and re-verify. If the verification passes, start normally. If the verification fails, repeat the backup file extraction and replacement operations.

[0016] The present invention also provides another embodiment, a firmware secure boot device, comprising: Hardware measurement root: used to monitor the communication between CPU and memory, perform exception blocking, and control the startup sequence; CPU: used to execute the startup program in sequence after the system is powered on, and load and run the Boot program after the hardware measurement root verification passes; Memory: used to store BootLoader files, system programs, user programs and related data; Security chip: stores public keys for authentication; External circuit: including IO control module, Ethernet communication module, USB communication module and other external circuits, used to receive input signals from external devices or send output signals to external devices.

[0017] The present application also discloses a firmware secure boot system, comprising: one or more processors; A computer readable storage medium for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method described in any one of claims 1 to 7.

[0018] The present application also discloses a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

[0019] The beneficial effects of this application are: 1. Scalability: Using FPGA as the hardware measurement root, with dedicated processing and connected I / O ports, it has a response speed of nanoseconds, adapts to components of different sizes and complexities, and can be expanded to multiple devices, multiple levels or multiple security domains to meet the needs of various application scenarios.

[0020] 2. Non-bypassability: Designed around the FPGA hardware measurement root, it has physical isolation and defense mechanisms, which can maintain security when an attacker gains physical control of the device. Unauthorized firmware cannot bypass the hardware measurement root, thus ensuring the security of the component.

[0021] 3. High reliability: The hardware measurement root can periodically detect the integrity of the system firmware. Once the firmware is detected to be damaged, the trusted firmware recovery process can be quickly started. The backup file of the last successful startup can be extracted from the pre-set secure storage area to replace the damaged firmware, and the security measurement verification can be re-performed to ensure that the system can quickly recover to a reliable operating state after a firmware problem occurs, reduce system downtime caused by firmware failure, and ensure the continuity of industrial production. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The present application is described with the aid of the following drawings: Figure 1 The schematic diagram of the system framework structure of the present application is shown; Figure 2 A schematic diagram of the system framework structure of another embodiment of the present application is shown; Figure 3 A schematic diagram of the trusted startup process of the system of the present application is shown; Figure 4 The flowchart of each stage of the trusted startup method of the present application is shown; Figure 5 The flowchart of the system recovery method of the present application is shown; Figure 6A schematic diagram of FPGA application expansion of the present application is shown. DETAILED DESCRIPTION

[0023] In order to better explain the present invention and facilitate understanding, the present invention is described in detail below in conjunction with the accompanying drawings through specific implementation methods. It is understood that the specific embodiments described below are only used to explain the relevant inventions, rather than to limit the invention. It should also be noted that the embodiments and features in the embodiments of this application can be combined with each other in the absence of conflict; for ease of description, only the parts related to the invention are shown in the accompanying drawings.

[0024] As known from the background art, in the existing firmware secure boot method, the firmware loading process is not monitored in real time, so non-secure firmware can be injected through the FLASH communication bus loaded with firmware during the boot process, thus posing a serious threat to system security.

[0025] In view of the above problems, this application provides a firmware secure boot method, such as Figure 1 As shown, it is a schematic diagram of the system framework structure of the present invention. The core of the present invention is to add a hardware measurement root between the CPU and the memory, and make innovative improvements on the basis of the architecture of the traditional hardware system power-on startup. The hardware measurement root is added to the communication bus between the CPU and the memory. In this way, a close information interaction channel is established between the CPU and the hardware measurement root through the communication bus. At the same time, the hardware measurement root and the memory also use the communication bus to achieve efficient data transmission and control. After the system is powered on, when the CPU performs read and write operations on the memory, the hardware measurement root will accurately receive the communication signal initiated by the CPU and smoothly forward it to the memory. In this process, the hardware measurement root will monitor the CPU's read and write operations on the memory in real time and in an all-round manner. Through the preset intelligent anomaly detection algorithm, it can keenly capture any possible abnormal operations and block the communication at the first time, thereby effectively preventing the transmission of malicious data and the injection of illegal firmware.

[0026] The memory includes BootFlash memory and NandFlash memory. The BootFlash stores the Boot program. The CPU initiates a data read request to BootFlash to start the BootLoader program. The NandFlash memory stores the system program and the user program. After NandFlash is powered on, the CPU can read the system program and the user program in the NandFlash memory and verify whether the program is correct.

[0027] Further, such as Figure 2As shown, in another embodiment of the present invention, only one memory is required to divide the functions in the memory into a BootFlash storage area, a system program storage area, and a user program storage area, and through a hardware trusted root, the CPU is controlled to read data from each area, thereby achieving control over the firmware secure boot sequence.

[0028] The safe startup method provided by the present invention is as follows: Figure 3 As shown, including: S1: After the hardware measurement root is powered on, it puts other hardware into a powered state and wakes up the CPU.

[0029] like Figure 4 As shown, the trusted startup process of the system of the present invention mainly includes four stages. In the first stage, at the moment the system is powered on, the hardware measurement root quickly starts and enters the working state, and performs a series of initialization operations, and performs comprehensive self-inspection and pre-configuration on each functional module inside itself, including the monitoring unit, the control unit, and the storage unit, to ensure that it is in the best working state. Subsequently, other hardware devices in the system, such as the CPU, the security chip, the storage area, and the peripheral circuits, are uniformly placed in the reset state to ensure that any possible unknown interference factors are eliminated before the system starts. After completing the above preparations, the hardware measurement root will accurately wake up the CPU according to the preset security startup timing, and officially start the firmware security startup sequence. Preferably, in this embodiment, FPGA is used as the hardware measurement root, and the SPI bus is used as the communication bus, and the method of the present invention is described in detail.

[0030] S2: The CPU starts the built-in Boot program and sends a data read request to the BootFlash memory. The hardware measurement root captures the BootLoader file and verifies it. If the verification passes, the BootLoader program is loaded. If the verification fails, the hardware measurement root resets the CPU.

[0031] In the second stage of the trusted startup of this system, when the CPU starts the built-in Boot program and tries to read the FLASH data, the FPGA hardware measurement root captures the BootLoader file through the SPI communication bus. Then, the FPGA uses the factory public key information FSK that is burned and fixed at the factory and cannot be tampered with to strictly verify the legitimacy of the signature source of the captured BootLoader file. The specific verification methods include:

[0032] S201: The hardware trusted root captures the BootLoader file and uses the built-in manufacturer public key information FSK to obtain the BootLoader file signature information. The BootLoader file contains the BootLaoder boot program and the BootLaoder boot program version. The BootLoader file is decrypted using the manufacturer public key information FSK to extract the signature information. The signature information contains the file information and file version number of the BootLoader file. The decrypted signature information is the key to subsequent file authentication. If the manufacturer public key information FSK in the hardware trusted root FPGA cannot decrypt the BootLoader file, it is determined that there is an abnormality in the BootLoader file, and the FPGA hardware trusted root directly resets the CPU.

[0033] S202: Calculate the characteristic hash value of the BootLoader file. The hash algorithm first takes all the binary data of the BootLoader file as part of the input. These binary data contain the program's instruction set, configuration information, data segments, and various codes and data structures, which constitute the core functions and implementation logic of the program. At the same time, the version number of the BootLoader program file is used as another key input element. The version number can reflect the iterative update of the program. Different versions may have different functional characteristics and repair conditions. When calculating the hash value, the algorithm will combine the binary content of the BootLoader program file and its version number information in a specific order. It may be to first add the binary representation of the version number to the end of the binary content of the program file, or to interleave them to ensure that the version number information is closely associated with the program file content.

[0034] S203: Compare the BootLoader file feature hash value with the BootLoader file feature baseline built into the hardware trusted root to determine whether they are consistent. If so, execute S204, otherwise execute S205. Among them, the BootLoader file feature baseline built into the hardware trusted root, that is, the feature hash value of the BootLoader file, can determine whether the BootLoader file captured by the hardware trusted root is correct by calculating the feature hash value of the BootLoader file and comparing it with the BootLoader file feature baseline, so as to prevent attackers from tampering with the file and affecting the normal operation of the system.

[0035] S204: The CPU loads the BootLoader and transfers the startup control to the BootLoader. After the BootLoader file is verified, the CPU loads the BootLoader program. At the same time, the FPGA transfers the startup control to the BootLoader, which executes the next startup program. By transferring the startup control, the startup sequence of the firmware can be strictly controlled to ensure that only verified components are loaded and executed in a predefined order, which prevents attackers from loading unauthorized components by changing the startup sequence.

[0036] S205: The hardware measurement root resets the CPU. If the verification fails, the FPGA hardware measurement root stops the system from continuing to start up to prevent the potential security risk from spreading further, and resets the CPU to restart the system startup process.

[0037] Furthermore, after the BootLoader verification is passed, the hardware root of trust will also check the consistency between the contents of the BootLoader program backup area and the BootLoader file. If they are inconsistent, the BootLoader file will be written into the BootLoader program backup area as a backup BootLoader file.

[0038] If an error occurs during the verification process, the hardware root of trust will calculate the hash of the backup BootLoader file in the BootLoader program backup area, and determine the correctness of the backup BootLoader file based on the built-in BootLoader file feature baseline. If correct, the backup BootLoader file will be rewritten into the BootLoader file storage area. Otherwise, the FPGA hardware root of trust will be notified to reset the CPU and power on again.

[0039] S3: After the BootLoader completes loading, the hardware trusted root controls the security chip and NandFlash module to power on, and the BootLoader obtains the public key in the security chip to verify the NandFlash system program; if the verification passes, the CPU loads the system program; if the verification fails, the BootLoader notifies the trusted measurement root to reset the CPU.

[0040] In the third stage of the trusted boot process of this application, the BootLoader verifies the system firmware. After the BootLoader is successfully loaded and run, the FPGA hardware trusted root transfers the power-on control to the BootLoader, and the BootLoader notifies the FPGA hardware trusted root to control the power-on of modules such as the security chip and NandFlash. The BootLoader reads the platform public key information PSK built into the security chip to verify the legitimacy of the source of the system program signature stored in NandFlash, and verifies whether the system program file is the expected version. Specific methods include.

[0041] S301: BootLoader loads and runs, and notifies the hardware measurement root control security chip and NandFlash module to power on. BootLoader uses the platform public key information PSK to obtain the signature information of the system program file.

[0042] S302: Calculate characteristic hash values ​​for system program files.

[0043] S303: BootLoader submits the system file hash value to the security chip and compares it with the system program file feature baseline built into the security chip to determine whether they are consistent. If yes, execute S304; otherwise, execute S305.

[0044] S304: The CPU loads the system program and transfers the startup control right to the system program; S305: The hardware trusted root resets the CPU.

[0045] The overall process is basically the same as the FPGA hardware trusted root verification BootLoader file process. It mainly determines whether the system file stored in NandFlash meets the expected version by calculating the hash value of the system program file and comparing the system file feature baseline stored in the security chip.

[0046] Furthermore, NandFlash contains a system file storage area and a system file backup area. After BootLoader is started, the system files in the system file storage area are verified. If the verification is successful, BootLoader will check the consistency between the backup system program file and the system program file in the system program backup area. If they are inconsistent, the system program file will be written into the system program backup area as a backup system program file. If a verification error occurs, BootLoader calculates the hash of the backup system file in the system program backup area in NandFlash, and determines the correctness of the backup system program file in combination with the system program file feature baseline built into the security chip. If correct, the backup system program file will be rewritten into the system program file storage area. Otherwise, the hardware root of trust will be notified, and the system will be reset and powered on again.

[0047] S4: After the system program is loaded, the hardware trusted root controls the peripheral circuit to power on, and the system program verifies the user program of the peripheral circuit; if the verification passes, the CPU loads and executes the user program; if the verification fails, the hardware trusted root controls the CPU to re-download the user program.

[0048] In the fourth stage of the trusted boot process of this application, the boot control is transferred to the system program, which verifies the user program. After the system program obtains the boot control, it notifies the FPGA hardware trusted root, controls the power-on of the peripheral circuit, and then reads the user public key information USK built into the security chip to verify the legitimacy of the source of the user program signature stored in NandFlash. The specific verification process includes.

[0049] S401: The system program is loaded and run, and the hardware measurement root is notified to control the peripheral circuit to power on. The system program uses the user public key information USK in the security chip to obtain the user program file signature information.

[0050] S402: Calculate the characteristic hash value of the user program file.

[0051] S403: Compare the user program file feature hash value with the NandFlash built-in user program file feature baseline to determine whether they are consistent. If yes, execute S404; otherwise, execute S405.

[0052] S404: The CPU loads and executes the user program.

[0053] S405: Forbid the loading of the user program and download the user program again.

[0054] Among them, the user public key information USK will be downloaded by the user and solidified in the security chip when the controller is configured, and it cannot be tampered with. After reading the user public key information USK in the security chip, the system program verifies the legitimacy of the user program signature stored in the NandFlash user program storage area, including the user program file and the user program file version. And after calculating the user program hash value, it is compared with the user program feature baseline stored in the security chip. If they are consistent, the CPU loads and executes the user program to complete the overall power-on sequence of the system. If the verification fails, the user program is prohibited from loading and the user program is downloaded again.

[0055] Furthermore, after the user program is verified, the system program will check the consistency between the backup user program file and the user program file in the NandFlash user program backup area. If they are inconsistent, the user program file will be written into the user program backup area as a new backup user program file. If the verification fails, the system program calculates the hash of the backup user program file in the user program backup area, and determines the correctness of the backup user program file in combination with the hash value of the user program file feature built into the security chip. If correct, the backup user program file will be rewritten into the system program file storage area and the user program will be reloaded. Otherwise, the system program will be in a silent state and inform the user program that the loading error has occurred, waiting for the user to download the user program again.

[0056] At this point, the system has successfully built a complete boot credit chain, completed the trusted boot process, and the system has officially entered a stable operating state. During the entire boot process, by transferring the boot control, it is ensured that each boot step is strictly executed in accordance with the boot sequence of the control firmware, and only verified components are loaded and executed in a predefined order, which prevents attackers from loading unauthorized components by changing the boot sequence.

[0057] During the entire trusted boot process, the trusted boot security platform will record the information of each key step in detail, including the boot time, boot order, firmware verification results of each hardware module, and the time and type of any abnormal events. These records are stored in a specific secure storage area for subsequent viewing and analysis by local system administrators, and can also be sent to a remote monitoring center according to the preset secure communication protocol for security audits and compliance verification.

[0058] During normal system operation, the FPGA hardware measurement root continuously monitors the CPU's read and write memory operations in real time. It uses built-in intelligent monitoring algorithms to accurately analyze various parameters in the data transmission process. For example, it monitors the size and change trend of data traffic. When data traffic suddenly fluctuates abnormally, such as when the data traffic peak value far exceeds normal read and write operations, the FPGA hardware measurement root regards it as a potential abnormality; at the same time, it checks the legitimacy and integrity of the data content to prevent illegal data from being written to the memory. If it is detected that the data content contains malicious code or does not conform to the preset data format and range, it will also be judged as abnormal; in addition, the compliance of the operation instructions is reviewed. Only instructions that conform to the system's preset legal operation instruction set are allowed to be executed. If an unauthorized operation instruction is received, the blocking mechanism will be immediately activated to quickly cut off the communication bus to prevent the transmission of malicious data and the continuation of illegal operations.

[0059] After the system is started, the hardware measurement root periodically detects the firmware. During the detection process, the FPGA hardware measurement root uses advanced hash algorithms to accurately calculate the key data areas of the firmware to obtain a unique hash value, and strictly compares it with the legal hash value pre-stored in the secure area. If the two are completely matched, it means that the firmware is intact and undamaged, and the system continues to operate normally; if the hash value is detected to be inconsistent with the legal hash value, it means that the firmware may have been damaged or tampered with in some form. At this time, the FPGA hardware measurement root will quickly start the trusted firmware recovery process.

[0060] like Figure 4 As shown, when the verification fails during the startup process, or an abnormality occurs during the operation of the hardware measurement root monitoring system, the hardware measurement root resets the system. The specific system reset methods include: S501: Extract the backup file of the last successful startup from the preset safe storage area. The safe storage area can be set in the memory. Figure 1 For example, the BootLoader backup file is stored in the BootLoader file backup area of ​​the BootFlash memory, and the system program and user program backup files are stored in the system file backup area and user program backup area of ​​NandFlash, respectively. Figure 2 In the embodiment shown, when there is only one Flash, the Flash is divided into areas to determine the secure storage area for backing up different files, and the secure storage area of ​​the Flash is configured with permissions such as encrypted storage and access restrictions to ensure the security and confidentiality of data storage in the secure storage area and prevent tampering of data in the secure storage area during any other operation.

[0061] S502: Replace the firmware program that failed verification or detected anomaly with the extracted backup file. After verification fails or detects anomaly, the FPGA hardware measurement root extracts the backup file of the last successful startup from the secure storage area and replaces the abnormal firmware program to ensure accurate writing and overwriting of data and recovery of the abnormal firmware program.

[0062] S503: Restart the power-on firmware and re-verify. If the verification passes, it will start normally. If the verification fails, repeat the backup file extraction and replacement operations. After the replacement is completed, in order to ensure the security and integrity of the restored firmware, the FPGA hardware measurement root will restart the firmware startup security measurement process and perform comprehensive verification and validation on the restored firmware again. The verification content includes but is not limited to file hash value comparison, signature source legitimacy verification, and file feature information verification. If the verification passes, the normal operation of the system is restored, the system continues to run stably and re-enters the monitoring and protection state. If the verification fails, repeat the extraction and replacement steps until the verification passes or the preset maximum number of attempts is reached.

[0063] Preferably, the preset maximum number of attempts is 8 times. If the system recovery operation still fails to pass the verification after 8 attempts, a system alarm is triggered and the error information is recorded in detail so that the system administrator can further investigate the cause of the failure.

[0064] Furthermore, during the firmware's secure boot process, the hardware measurement root records and reports events and logs during the boot process and system operation, including boot information recording: accurately recording the boot time and boot sequence of each hardware module (such as CPU, security chip, etc.), clarifying the sequence in which each module is activated, and helping to troubleshoot problems caused by abnormal boot sequence.

[0065] Verification result record: Record each verification process during the firmware startup process in detail, such as recording the results of each step in the verification process of the BootLoader file and the system firmware. For the BootLoader file, it includes the result of using the manufacturer's public key information FSK to verify the legitimacy of the signature source, whether the match is successful or failed; the calculation result of the file hash value and the comparison with the legal hash value to clarify whether they are consistent; the verification result of the file version information to see whether it meets the expected version range. For the system firmware, it also records the use of the platform public key information PSK to verify the legitimacy of the signature source, the verification result of the system firmware hash value, and the verification of the version information. It can quickly locate whether the firmware has been tampered with or there are version compatibility issues.

[0066] Abnormal event record: When any abnormal event is detected, the time of the event is recorded in detail, accurate enough to trace the source of the problem. At the same time, the type of abnormal event is recorded, such as abnormal data flow, specifying the value and duration of the flow that exceeds the normal range; illegal data write events, recording the content characteristics of the data that is judged to be illegal; unauthorized operation instruction events, recording the source of the instruction (if traceable) and the content of the instruction. It also includes hardware communication failure information, such as the error code of the communication bus, the location of the failure (is it at the FPGA hardware measurement root end, the CPU end or the memory end), etc.

[0067] Through the event and log records of the FPGA hardware measurement root, the specific link, time and cause of the abnormality can be accurately located, which can greatly shorten the troubleshooting time, reduce system downtime, and improve industrial production efficiency.

[0068] like Figure 4 As shown, the present invention strictly controls the secure boot sequence of the firmware with the FPGA hardware measurement root as the core. The architectural characteristics of FPGA itself give it excellent basic expansion capabilities. FPGA is equipped with a dedicated processing unit and a rich connection I / O port, which makes it possible for it to gain a foothold in industrial control systems of different scales and complexities. Its processing unit can flexibly allocate computing resources and efficiently process firmware protection tasks according to actual needs. Whether it is firmware management in simple small embedded devices or firmware collaborative protection of numerous devices in large industrial automation networks, it can handle it with ease. The rich I / O ports provide a convenient channel for connecting with various external devices, control systems at different levels, and multiple security domains, so that it can be easily integrated into a diverse industrial environment architecture to achieve seamless docking and interactive collaboration.

[0069] Secondly, this solution shows excellent adaptability and scalability when dealing with multi-device integration scenarios. With the continuous development of industrial automation, more and more devices are often integrated into the system, and these devices may come from different manufacturers and have different hardware characteristics and firmware architectures. The FPGA-based firmware protection device can customize the firmware protection requirements of different devices through its flexibly programmable logic units. For example, for new device types, it only needs to add corresponding adapter modules to the logic design of the FPGA to incorporate them into the overall firmware protection system without the need for large-scale redesign and transformation of the entire industrial control system. This method effectively reduces the cost and complexity of system upgrades and expansions, allowing industrial control systems to continue to maintain efficient and stable firmware protection capabilities as the number of devices increases and the types of devices become richer.

[0070] In the present invention, the communication bus can be an SPI bus, or other communication bus protocols such as I2C, SSP, etc., and FPGA can be used as the hardware measurement root to perform adaptability adjustment according to the corresponding protocol to adapt to most communication buses, ensuring that under different communication protocols, it can still effectively play its core functions of monitoring and protecting firmware security, ensuring that the system can run stably and maintain a high degree of security in a variety of hardware environments, and has a wide range of applications.

[0071] In the present invention, the security chip can also be replaced by FPGA, and the FPGA hardware measurement root can assume the functions originally performed by the security chip. In the system initialization stage, the platform public key information PSK is stored in the FPGA hardware measurement root, and the corresponding encryption and decryption module and security policy storage and execution function module are configured. During the system startup and operation process, the FPGA hardware measurement root uses the stored platform public key information PSK to sign and verify the system firmware according to the preset security process, and executes the relevant security policies to ensure that the system can still maintain a high firmware security level without an independent security chip.

[0072] If the system is configured with multiple CPU cores, the FPGA hardware measurement root allocates independent monitoring and control threads for the startup process of each CPU core. When the system is powered on, the FPGA hardware measurement root monitors the startup programs of multiple CPU cores at the same time, captures the BootLoader file corresponding to each CPU core, and uses the corresponding manufacturer's public key information FSK for signature verification and file feature information verification. During system operation, the operations of reading and writing FLASH memory of each CPU core are independently monitored and anomaly detected. Once a security problem occurs in the firmware corresponding to a CPU core, the FPGA hardware measurement root can quickly locate and take corresponding recovery measures, such as starting a trusted firmware recovery process for the CPU core separately to ensure the security of the firmware corresponding to each CPU core, thereby ensuring the stable operation of the entire multi-core system.

[0073] In summary, the beneficial effects of the method of the present invention are: 1. Scalability: Using FPGA as the hardware measurement root, with dedicated processing and connected I / O ports, it has a response speed of nanoseconds, adapts to components of different sizes and complexities, and can be expanded to multiple devices, multiple levels or multiple security domains to meet the needs of various application scenarios.

[0074] 2. Non-bypassability: Designed around the FPGA hardware measurement root, it has physical isolation and defense mechanisms, which can maintain security when an attacker gains physical control of the device. Unauthorized firmware cannot bypass the hardware measurement root, thus ensuring the security of the component.

[0075] 3. High reliability: The hardware measurement root can periodically detect the integrity of the system firmware. Once the firmware is detected to be damaged, the trusted firmware recovery process can be quickly started. The backup file of the last successful startup can be extracted from the pre-set secure storage area to replace the damaged firmware, and the security measurement verification can be re-performed to ensure that the system can quickly recover to a reliable operating state after a firmware problem occurs, reduce system downtime caused by firmware failure, and ensure the continuity of industrial production.

[0076] Another embodiment of the present invention is a firmware secure boot device, comprising: Hardware measurement root: used to monitor the communication between CPU and memory, perform exception blocking, and control the startup sequence; CPU: used to execute the startup program in sequence after the system is powered on, and load and run the Boot program after the hardware measurement root verification passes; Memory: used to store firmware programs, BootLoader files and related data; Security chip: Stores public keys used for firmware authentication.

[0077] A third embodiment of the present invention is a firmware secure boot system, comprising: one or more processors; A computer readable storage medium for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method described in any one of claims 1 to 7.

[0078] A fourth embodiment of the present invention is a computer-readable storage medium, wherein a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps of the device address allocation method described in any one of claims 1 to 7 are implemented.

[0079] It should be noted that in the claims, any reference signs placed between brackets shall not be construed as limiting the claims. The word "comprising" does not exclude the presence of components or steps not listed in the claims. The word "a" or "an" preceding a component does not exclude the presence of a plurality of such components. The invention may be implemented by means of hardware comprising several distinct components and by means of a suitably programmed computer. The use of the words first, second, third, etc., is for convenience of expression only and does not imply any order. These words may be understood as part of the component name.

[0080] In addition, it should be noted that, in the description of this specification, the description of the terms "one embodiment", "some embodiments", "embodiment", "example", "specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are contradictory.

[0081] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments after knowing the basic creative concept. Therefore, the claims should be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present invention.

[0082] Obviously, those skilled in the art can make various modifications and variations to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention should also include these modifications and variations.

Claims

1. A firmware secure boot method, characterized in that: The method comprises: S1: After the hardware measurement root is powered on, other hardware is put into a power-on state and the CPU is woken up; S2: The CPU starts the built-in Boot program and sends a data read request to the BootFlash memory. The hardware measurement root captures the BootLoader file and verifies it. If the verification passes, the BootLoader program is loaded. If the verification fails, the hardware measurement root resets the CPU. S3: After the BootLoader completes loading, the hardware trusted root controls the security chip and NandFlash module to power on, and the BootLoader obtains the public key in the security chip to verify the NandFlash system program; if the verification passes, the CPU loads the system program; if the verification fails, the BootLoader notifies the trusted measurement root to reset the CPU; S4: After the system program is loaded, the hardware trusted root controls the peripheral circuit to power on, and the system program verifies the user program of the peripheral circuit; if the verification passes, the CPU loads and executes the user program; if the verification fails, the hardware trusted root controls the CPU to re-download the user program.

2. The firmware secure boot method according to claim 1, characterized in that: The hardware measurement root is FPGA, and the FPGA is burned and solidified with the manufacturer's public key information FSK when it leaves the factory. The BootLoader file verification method in S2 includes: S201: The hardware trusted root captures the BootLoader file and obtains the BootLoader file signature information using the built-in manufacturer public key information FSK; S202: Calculate the characteristic hash value of the BootLoader file; S203: Compare the BootLoader file feature hash value with the BootLoader file feature baseline built in the hardware trusted root to determine whether they are consistent. If yes, execute S204; otherwise, execute S205; S204: The CPU loads the BootLoader and transfers the startup control to the BootLoader; S205: The hardware metric root resets the CPU.

3. The firmware secure boot method according to claim 1, characterized in that: The security chip is burned with the platform public key information PSK when it leaves the factory. The verification method for the system program in S3 includes: S301: BootLoader loads and runs, and notifies the hardware measurement root control security chip and NandFlash module to power on. BootLoader uses the platform public key information PSK to obtain the signature information of the system program file; S302: Calculate characteristic hash values ​​for system program files; S303: BootLoader submits the system file hash value to the security chip and compares it with the system program file feature baseline built into the security chip to determine whether they are consistent. If yes, execute S304; otherwise, execute S305; S304: The CPU loads the system program and transfers the startup control right to the system program; S305: The hardware trusted root resets the CPU.

4. The firmware secure boot method according to claim 1, characterized in that: The security chip downloads the user public key information USK when the user configures, and the verification method for the user program in S4 includes: S401: The system program is loaded and run, and the hardware measurement root is notified to control the peripheral circuit to power on. The system program uses the user public key information USK in the security chip to obtain the user program file signature information; S402: Calculate the characteristic hash value of the user program file; S403: Compare the characteristic hash value of the user program file with the characteristic baseline of the user program file built in NandFlash to determine whether they are consistent. If yes, execute S404; otherwise, execute S405; S404: CPU loads and executes the user program; S405: Forbid the loading of the user program and download the user program again.

5. The firmware secure boot method according to claim 2, 3 or 4, characterized in that: During the operation of the system, the hardware measurement monitors the CPU's reading and writing of the memory in real time. If an abnormality is found, the communication bus between the CPU and the memory is blocked.

6. The firmware secure boot method according to claim 2, 3 or 4, characterized in that: After the system is started up, the hardware measurement root periodically checks the firmware, and if an abnormality is found, the system is reset.

7. The firmware secure boot method according to claim 1, characterized in that: The system reset method comprises: Extract the backup file of the last successful startup from the preset storage area; Replace the files that failed verification or detected abnormalities with the extracted backup files; Restart the power-on firmware and re-verify. If the verification passes, start normally. If the verification fails, repeat the backup file extraction and replacement operations.

8. A firmware secure boot device, characterized in that: include: Hardware measurement root: used to monitor the communication between CPU and memory, perform exception blocking, and control the startup sequence; CPU: used to execute the startup program in sequence after the system is powered on, and load and run the Boot program after the hardware measurement root verification passes; Memory: used to store BootLoader files, system programs, user programs and related data; Security chip: stores public keys for authentication; External circuit: including IO control module, Ethernet communication module, USB communication module and other external circuits, used to receive input signals from external devices or send output signals to external devices.

9. A firmware secure boot system, characterized in that: include: one or more processors; A computer readable storage medium for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the steps of the method described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images