CN116302165A - Firmware support package trusted loading method, device, terminal and storage medium - Google Patents

Firmware support package trusted loading method, device, terminal and storage medium Download PDF

Info

Publication number
CN116302165A
CN116302165A CN202310014237.4A CN202310014237A CN116302165A CN 116302165 A CN116302165 A CN 116302165A CN 202310014237 A CN202310014237 A CN 202310014237A CN 116302165 A CN116302165 A CN 116302165A
Authority
CN
China
Prior art keywords
firmware
firmware support
hash value
package
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310014237.4A
Other languages
Chinese (zh)
Inventor
翟庆伟
王兴隆
李金锋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Suzhou Inspur Intelligent Technology Co Ltd
Original Assignee
Suzhou Inspur Intelligent Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Suzhou Inspur Intelligent Technology Co Ltd filed Critical Suzhou Inspur Intelligent Technology Co Ltd
Priority to CN202310014237.4A priority Critical patent/CN116302165A/en
Publication of CN116302165A publication Critical patent/CN116302165A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The invention relates to the field of firmware support packet loading, in particular to a method, a device, a terminal and a storage medium for trusted loading of a firmware support packet, wherein a private key is used for digitally signing the firmware support packet, and the signature comprises a hash value of the firmware support packet; storing the hash value of the firmware support packet in a storage area; before the firmware supporting package is loaded by the Coreboot, verifying the signature of the firmware supporting package by using a public key, obtaining a hash value in the signature, and calculating the hash value of the current firmware supporting package; comparing whether the current hash value is the same as the hash value obtained from the signature; if the hash values are the same, comparing whether the current hash value is the same as the hash value in the storage area; if the current firmware support package is different at any time, judging that the current firmware support package is not trusted, and refusing to load; if the two times are identical, the current firmware supporting package is judged to be credible, and the current firmware supporting package is loaded. The invention can immediately identify and prevent FSP loading, thereby greatly improving the security of the server.

Description

Firmware support package trusted loading method, device, terminal and storage medium
Technical Field
The invention relates to the field of firmware support packet loading, in particular to a method, a device, a terminal and a storage medium for trusted loading of a firmware support packet.
Background
In the field of current server firmware, BIOS system firmware based on UEFI is still mainstream, but the problem of closing source and difficult development faced by UEFI BIOS is also becoming obvious, especially for large-scale internet service providers with large-scale data centers, how to quickly adapt to the service scene demands, and it is becoming more and more important to realize quick development and maintenance of system firmware. Under the background, an open source firmware solution based on Coreboot+FSP++ LinuxBoot is generated, an integral starting framework is provided by open source Coreboot codes, FSP is loaded in the starting process to initialize hardware, and then the system is accessed through the LinuxBoot. Compared with the traditional UEFI starting mode, the open source firmware scheme is quicker and more efficient, and can be more quickly adapted to specific service scenes. However, the current scheme does not have a security verification step in the process of loading the FSP, and the FSP exists in BIOS Flash as a binary file, so that the risk of tampering exists.
The patent application with the application number of CN202210155238.6 provides a firmware file credibility verification method based on a unified extensible firmware interface, UEFI locates and loads a firmware file through GUID, in the process of loading the firmware file, the GUID of the firmware file is extracted and compared with a reference table stored in BMC through an extension measurement module, if the GUID which is not in the reference table appears, the file can be considered to be illegally embedded into the firmware, and the file is not credible. And then, continuously using the hash value (hash) of the file to check whether the file is tampered, storing the hash value of the trusted firmware file in a reference value table, calculating the hash value of the current file when loading, and comparing the hash value with the current file through an expansion measurement module to ensure that the firmware file is not tampered and ensure the safety of the firmware file.
However, the implementation focuses on the verification of the PEI and DXE module loads by the traditional UEFI boot process, and does not involve the verification of the current latest FSP load; secondly, the verification process is simply compared with the Hash value after the GUID is used for positioning the firmware file, and if the firmware file and the reference Hash value are tampered at the same time, the method can still pass the verification, so that the safety is greatly reduced.
Disclosure of Invention
In order to solve the problems, the invention provides a method, a device, a terminal and a storage medium for trusted loading of firmware support packages, which are based on an open source firmware starting scheme of Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for trusted loading of FSP and a double verification step of comparison is carried out by storing a reference Hash in a storage area, once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
In a first aspect, the present invention provides a method for trusted loading of firmware support packages, including the following steps:
digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
storing the hash value of the firmware support packet in a storage area;
before the firmware supporting package is loaded by the Coreboot, verifying the signature of the firmware supporting package by using the public key, obtaining a Bao Haxi value of the firmware supporting in the signature, and calculating a hash value of the current firmware supporting package;
comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
Further, the method specifically comprises the following steps:
the Coreboot and the BMC agree that a block area is selected to store the hash value of the firmware support packet in the static random access memory of the BMC H2B device;
the hash value of the firmware support packet is stored in the selected region.
Further, the method specifically comprises the following steps:
the Coreboot completes the initialization of the BMC H2B device in the starting stage, so that the selected area of the static random access memory can be accessed;
in response to the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, the firmware support Bao Haxi value is fetched from the static random access memory selected area of the BMC H2B device.
Further, the method comprises the following steps:
judging whether the selected area of the static random access memory of the BMC H2B device is empty or not in response to the fact that the hash value of the current firmware supporting packet is the same as the firmware supporting Bao Haxi value obtained from the signature;
if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, the hash value of the current firmware supporting packet is written into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded;
if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
Further, the method specifically comprises the following steps:
the firmware support package is digitally signed using a private key during the compilation of the Coreboot code.
In a second aspect, the present invention provides a firmware support packet trusted loading apparatus, including,
digital signature module: digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
a hash value storage module: storing the hash value of the firmware support packet in a storage area;
signature verification module: before the firmware support package is loaded by the Coreboot, verifying the signature of the firmware support package by using a public key to obtain a Bao Haxi value of the firmware support in the signature;
the hash value calculation module: calculating a hash value of a current firmware support packet;
and the trusted verification module is used for: comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
Further, coreboot and BMC agree to store the hash value of the firmware support packet in a selected block area of the static random access memory of the BMC H2B device;
accordingly, the hash value storage module stores the hash value of the firmware support packet in the selected region.
Further, the device also comprises a device for detecting the position of the object,
an initialization module: the Coreboot completes the initialization of the BMC H2B device in the starting stage, so that the selected area of the static random access memory can be accessed;
responding to the comparison of the trusted verification module with the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, and judging whether the selected area of the static random access memory of the BMC H2B device is empty; if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, a trigger hash value storage module is used for writing the hash value of the current firmware supporting packet into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded; if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
In a third aspect, a technical solution of the present invention provides a terminal, including:
a memory for storing a firmware support package trusted loader;
a processor, configured to implement the steps of the firmware support package trusted loading method according to any one of the above when executing the firmware support package trusted loader.
In a fourth aspect, the present invention provides a computer readable storage medium, where a firmware support packet trusted loading program is stored, where the firmware support packet trusted loading program when executed by a processor implements the steps of the firmware support packet trusted loading method according to any one of the above claims.
The method, the device, the terminal and the storage medium for trusted loading of the firmware support packet have the following beneficial effects compared with the prior art: firstly, carrying out digital signature on the FSP by using a private key, including a hash value of the FSP in the signature, storing the hash value of the FSP in a storage area, obtaining comparison of the hash value of the FSP and a current hash value of the FSP through a signature mechanism before loading the FSP, comparing the hash value of the current FSP with the hash value of the FSP in the storage area after the comparison is passed, refusing to load the FSP if any comparison is not passed, and allowing the FSP to be loaded again if the comparison is passed. According to the open source firmware starting scheme based on Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for realizing trusted loading of FSP, and a reference Hash is stored in a storage area for comparison, so that once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
Drawings
For a clearer description of embodiments of the present application or of the prior art, the drawings that are used in the description of the embodiments or of the prior art will be briefly described, it being apparent that the drawings in the description that follow are only some embodiments of the present application, and that other drawings may be obtained from these drawings by a person of ordinary skill in the art without inventive effort.
Fig. 1 is a flowchart of a trusted loading method of a firmware support packet according to an embodiment of the present invention.
FIG. 2 is a flowchart of a method for trusted loading of firmware support packages according to an embodiment of the present invention.
Fig. 3 is a schematic block diagram of a firmware supporting packet trusted loading device according to an embodiment of the present invention.
Fig. 4 is a schematic structural diagram of a terminal according to an embodiment of the present invention.
Detailed Description
Some terms related to the present invention are explained below.
Basic Input Output System, basic input/output system;
FSP Firmware Support Package, firmware support package;
H2B, host To Bridge equipment;
BMC Baseboard Management Controller, baseboard management controller;
coreboot: an open source item of software intended to replace the proprietary BIOS (firmware) in most computers. Coreboot will perform some hardware initialization and then other boot logic.
In order to provide a better understanding of the present application, those skilled in the art will now make further details of the present application with reference to the drawings and detailed description. It will be apparent that the described embodiments are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.
The embodiment of the invention provides a firmware support packet trusted loading method, which is independent of the constraint of the traditional UEFI starting mode, focuses on an open source firmware starting scheme of Coreboot+FSP++ LinuxBoot, and solves the problem of trusted verification of Coreboot in the FSP loading process.
Fig. 1 is a flowchart of a method for trusted loading of a firmware support package according to an embodiment of the present invention, as shown in fig. 1, the method includes the following steps.
S1, carrying out digital signature on the firmware supporting package by using a private key, wherein the signature comprises a hash value of the firmware supporting package.
S2, storing the hash value of the firmware support packet in a storage area.
And S3, before the Coreboot loads the firmware support package, verifying the signature of the firmware support package by using the public key, and obtaining a Bao Haxi value of the firmware support in the signature.
S4, calculating the hash value of the current firmware support packet.
S5, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature.
And S6, if the current firmware support package is different, judging that the current firmware support package is not trusted, and refusing to load.
And S7, if the hash value of the current firmware support packet is the same as the value of the firmware support Bao Haxi in the storage area, executing the step S6 if the hash value of the current firmware support packet is different from the value of the firmware support Bao Haxi in the storage area, and if the hash value of the current firmware support packet is the same as the value of the firmware support Bao Haxi in the storage area, executing the step S8.
And S8, if the current firmware support package is the same, judging that the current firmware support package is credible, and loading the current firmware support package.
In the embodiment, firstly, a private key is used for carrying out digital signature on the FSP, the hash value of the FSP is contained in the signature, meanwhile, the hash value of the FSP is stored in a storage area, before the FSP is loaded, the hash value of the FSP is obtained through a signature mechanism and compared with the hash value of the current FSP, after the comparison is passed, the hash value of the current FSP is compared with the hash value of the FSP in the storage area, the FSP is refused to be loaded after any comparison is not passed, and the FSP is allowed to be loaded after the comparison is passed for two times. According to the open source firmware starting scheme based on Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for realizing trusted loading of FSP, and a reference Hash is stored in a storage area for comparison, so that once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
Based on the above embodiment, as a preferred implementation manner, the Coreboot realizes trusted loading of the firmware supporting packet through the H2B, and the Coreboot and the BMC agree to store the hash value of the firmware supporting packet in a selected area of the static random access memory of the BMC H2B device, and correspondingly store the hash value of the firmware supporting packet in the selected area.
In order to realize the access of the selected area of the static random access memory of the BMC H2B device, coreboot completes the initialization of the BMC H2B device in a starting stage so that the selected area of the static random access memory can be accessed. In the trusted loading process of the firmware support package, when the hash value of the current firmware support package is judged to be the same as the firmware support Bao Haxi value obtained from the signature, signature mechanism verification is completed, then second verification is executed, the stored firmware support Bao Haxi value is required to be obtained, and at the moment, the firmware support Bao Haxi value is fetched from the selected area of the static random access memory of the BMC H2B device.
Based on the above embodiment, as a preferred implementation, at the initial boot-up of Coreboot, the firmware support Bao Haxi value is written to the sram select area of the BMC H2B device. Specifically, in response to the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, determining whether the static random access memory selected area of the BMC H2B device is empty; if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, the hash value of the current firmware supporting packet is written into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded; if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
Before the firmware supporting package is loaded by the Coreboot, firstly, signature verification is carried out by using a public key, then, after the current firmware supporting Bao Haxi value is the same as the firmware supporting Bao Haxi value in the signature, second hash value verification is carried out, at the moment, whether the firmware supporting package exists in a selected area or not is detected, if not, the firmware supporting package is started for the first time, the firmware supporting package is stored in the selected area, meanwhile, the firmware supporting package is loaded, and if yes, the firmware supporting Bao Haxi value is called from the selected area to carry out the second hash value verification.
For further understanding of the present invention, a detailed description of the present invention is provided below, and fig. 2 is a schematic flow chart of the detailed embodiment, and as shown in fig. 2, the detailed embodiment includes the following steps.
Step 1) a private key is used for digitally signing the FSP in the step of compiling Coreboot codes, and the signature contains Hash information of the FSP.
Step 2) Coreboot and BMC agree to select a block area in the H2B SRAM area for storing the Hash value of FSP.
Step 3) Coreboot completes initialization of the BMC H2B device in early starting so that an FSP Hash area in an SRAM area can be accessed.
Step 4) before loading the FSP, the Coreboot firstly verifies the signature of the FSP by using a public key, takes the Hash value in the signature, calculates the Hash value of the current FSP at the same time, judges whether the two HVBash values are equal, and enters the step 5 if the two HVBash values are equal, otherwise, enters the step 8.
Step 5) Coreboot reads the BMC H2B FSP Hash area and judges whether the BMC H2B FSP Hash area is empty, if so, the step 6 is entered, if not, whether the current FSP Hash value is equal to the Hash value in H2B is judged, if so, the step 7 is entered, and if not, the step 8 is entered.
Step 6) Coreboot considers that the current starting is the first time, writes the Hash value of the current FSP into the H2B Hash area, loads the FSP, and continues the starting process.
Step 7) Coreboot considers that the Hash value of the current FSP accords with the expectation, namely, the FSP is loaded, and the starting process is continued.
Step 8) Coreboot considers that the Hash value of the current FSP is not in accordance with expectations, namely, the Hash value is not trusted, loading of the FSP is refused, and the starting process is stopped.
In the specific embodiment, the Coreboot realizes FSP trusted loading through H2B, a private key is used for carrying out digital signature on the FSP in the step of compiling Coreboot codes, the signature contains Hash information of the FSP, coreboot and BMC agree that a region is selected in an H2B SRAM region for storing a Hash value of the FSP, and the Coreboot completes initialization of BMC H2B equipment in early starting so that the FSP Hash region in the SRAM region can be accessed. Before loading the FSP, the Coreboot firstly verifies the signature of the FSP by using a public key, takes the Hash value in the signature, calculates the Hash value of the current FSP at the same time, judges whether the Hash value of the current FSP is not in line with expectations or not if the two values are not equal, namely, the Coreboot refuses to load the FSP, stops the starting process, continues to read the BMC H2B FSP Hash area if the two values are equal, judges that the current FSP Hash value is started for the first time if the area is empty, loads the FSP, continues the starting process, judges whether the Hash value of the current FSP is equal to the Hash value in the H2B if the two values are not empty, if the Hash value of the current FSP is equal, the Coreboot judges that the Hash value of the current FSP is in line with expectations, namely, the FSP is trusted, loads the FSP, otherwise, the Coreboot refuses to load the FSP, and stops the starting process. The scheme is based on an open source firmware starting scheme of Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for realizing trusted loading of the FSP, and a reference Hash is stored in BMC H2B for comparison, so that once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
The embodiment of the method for trusted loading the firmware support package is described in detail above, and the embodiment of the invention also provides a device for trusted loading the firmware support package corresponding to the method based on the method for trusted loading the firmware support package described in the embodiment.
Fig. 3 is a schematic block diagram of a firmware supporting packet trusted loading device according to an embodiment of the present invention, where, as shown in fig. 3, the device includes: the system comprises a digital signature module, a hash value storage module, a hash value calculation module, a trusted verification module and an initialization module.
Digital signature module: the firmware support packet is digitally signed using the private key and the hash value of the firmware support packet is included in the signature.
A hash value storage module: the hash value of the firmware support packet is stored in the storage area.
Signature verification module: before the firmware support package is loaded by the Coreboot, the signature of the firmware support package is verified by using the public key, and the value of the firmware support Bao Haxi in the signature is obtained.
The hash value calculation module: the hash value of the current firmware support packet is calculated.
And the trusted verification module is used for: comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
In this embodiment, coreboot and BMC agree to store the hash value of the firmware support packet in a selected block of the static random access memory of the BMC H2B device. Accordingly, the hash value storage module stores the hash value of the firmware support packet in the selected region.
Meanwhile, the embodiment sets an initialization module: coreboot completes initialization of BMC H2B devices during the boot phase, enabling access to selected areas of its SRAM.
Responding to the comparison of the trusted verification module with the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, and judging whether the selected area of the static random access memory of the BMC H2B device is empty; if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, a trigger hash value storage module is used for writing the hash value of the current firmware supporting packet into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded; if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
The firmware supporting package trusted loading device of this embodiment is used for implementing the foregoing firmware supporting package trusted loading method, so that the specific implementation manner in the device can be seen from the foregoing example part of the firmware supporting package trusted loading method, so that the specific implementation manner of the firmware supporting package trusted loading device can refer to the description of the corresponding examples of each part, and will not be further described herein.
In addition, since the firmware supporting package trusted loading device of the present embodiment is used to implement the foregoing firmware supporting package trusted loading method, the function of the firmware supporting package trusted loading device corresponds to the function of the foregoing method, and the description thereof is omitted herein.
Fig. 4 is a schematic structural diagram of a terminal device 400 according to an embodiment of the present invention, including: processor 410, memory 420, and communication unit 430. The processor 410 is configured to implement the following steps when implementing the firmware support package trusted loader stored in the memory 420:
digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
storing the hash value of the firmware support packet in a storage area;
before the firmware supporting package is loaded by the Coreboot, verifying the signature of the firmware supporting package by using the public key, obtaining a Bao Haxi value of the firmware supporting in the signature, and calculating a hash value of the current firmware supporting package;
comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
The method comprises the steps of firstly carrying out digital signature on the FSP by using a private key, including a hash value of the FSP in the signature, storing the hash value of the FSP in a storage area, obtaining comparison of the hash value of the FSP and a hash value of the current FSP through a signature mechanism before loading the FSP, comparing the hash value of the current FSP with the hash value of the FSP in the storage area after the comparison is passed, refusing to load the FSP after any comparison is not passed, and allowing the FSP to be loaded after both comparison passes. According to the open source firmware starting scheme based on Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for realizing trusted loading of FSP, and a reference Hash is stored in a storage area for comparison, so that once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
The terminal device 400 includes a processor 410, a memory 420, and a communication unit 430. The components may communicate via one or more buses, and it will be appreciated by those skilled in the art that the configuration of the server as shown in the drawings is not limiting of the invention, as it may be a bus-like structure, a star-like structure, or include more or fewer components than shown, or may be a combination of certain components or a different arrangement of components.
The memory 420 may be used to store instructions for execution by the processor 410, and the memory 420 may be implemented by any type of volatile or nonvolatile memory terminal or combination thereof, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. The execution of the instructions in memory 420, when executed by processor 410, enables terminal 400 to perform some or all of the steps in the method embodiments described below.
The processor 410 is a control center of the storage terminal, connects various parts of the entire electronic terminal using various interfaces and lines, and performs various functions of the electronic terminal and/or processes data by running or executing software programs and/or modules stored in the memory 420, and invoking data stored in the memory. The processor may be comprised of an integrated circuit (Integrated Circuit, simply referred to as an IC), for example, a single packaged IC, or may be comprised of a plurality of packaged ICs connected to the same function or different functions. For example, the processor 410 may include only a central processing unit (Central Processing Unit, simply CPU). In the embodiment of the invention, the CPU can be a single operation core or can comprise multiple operation cores.
And a communication unit 430 for establishing a communication channel so that the storage terminal can communicate with other terminals. Receiving user data sent by other terminals or sending the user data to other terminals.
The invention also provides a computer storage medium, which can be a magnetic disk, an optical disk, a read-only memory (ROM) or a random access memory (random access memory, RAM) and the like.
The computer storage medium stores a firmware support package trusted loader that when executed by the processor performs the steps of:
digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
storing the hash value of the firmware support packet in a storage area;
before the firmware supporting package is loaded by the Coreboot, verifying the signature of the firmware supporting package by using the public key, obtaining a Bao Haxi value of the firmware supporting in the signature, and calculating a hash value of the current firmware supporting package;
comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
The method comprises the steps of firstly carrying out digital signature on the FSP by using a private key, including a hash value of the FSP in the signature, storing the hash value of the FSP in a storage area, obtaining comparison of the hash value of the FSP and a hash value of the current FSP through a signature mechanism before loading the FSP, comparing the hash value of the current FSP with the hash value of the FSP in the storage area after the comparison is passed, refusing to load the FSP after any comparison is not passed, and allowing the FSP to be loaded after both comparison passes. According to the open source firmware starting scheme based on Coreboot+FSP++ LinuxBoot, a signature mechanism is adopted for realizing trusted loading of FSP, and a reference Hash is stored in a storage area for comparison, so that once the FSP in BIOS Flash is maliciously tampered, the scheme can immediately identify and prevent the FSP from loading, and the security of a server is greatly improved.
It will be apparent to those skilled in the art that the techniques of embodiments of the present invention may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solution in the embodiments of the present invention may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium such as a U-disc, a mobile hard disc, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk or an optical disk, etc. various media capable of storing program codes, including several instructions for causing a computer terminal (which may be a personal computer, a server, or a second terminal, a network terminal, etc.) to execute all or part of the steps of the method described in the embodiments of the present invention.
In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.
The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.
The foregoing disclosure is merely illustrative of the preferred embodiments of the invention and the invention is not limited thereto, since modifications and variations may be made by those skilled in the art without departing from the principles of the invention.

Claims (10)

1. A method for trusted loading of firmware support packages, comprising the steps of:
digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
storing the hash value of the firmware support packet in a storage area;
before the firmware supporting package is loaded by the Coreboot, verifying the signature of the firmware supporting package by using the public key, obtaining a Bao Haxi value of the firmware supporting in the signature, and calculating a hash value of the current firmware supporting package;
comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area;
if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load;
if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
2. The method for trusted loading of firmware support packages according to claim 1, wherein the method specifically comprises:
the Coreboot and the BMC agree that a block area is selected to store the hash value of the firmware support packet in the static random access memory of the BMC H2B device;
the hash value of the firmware support packet is stored in the selected region.
3. The method for trusted loading of firmware support packages according to claim 2, wherein the method specifically comprises:
the Coreboot completes the initialization of the BMC H2B device in the starting stage, so that the selected area of the static random access memory can be accessed;
in response to the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, the firmware support Bao Haxi value is fetched from the static random access memory selected area of the BMC H2B device.
4. A method of trusted loading of firmware support packages as claimed in claim 3, further comprising the steps of:
judging whether the selected area of the static random access memory of the BMC H2B device is empty or not in response to the fact that the hash value of the current firmware supporting packet is the same as the firmware supporting Bao Haxi value obtained from the signature;
if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, the hash value of the current firmware supporting packet is written into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded;
if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
5. The method for trusted loading of firmware support packages according to any one of claims 1 to 4, wherein the method specifically comprises:
the firmware support package is digitally signed using a private key during the compilation of the Coreboot code.
6. A firmware support package trusted loading device is characterized by comprising,
digital signature module: digitally signing the firmware support package using the private key, and including a hash value of the firmware support package in the signature;
a hash value storage module: storing the hash value of the firmware support packet in a storage area;
signature verification module: before the firmware support package is loaded by the Coreboot, verifying the signature of the firmware support package by using a public key to obtain a Bao Haxi value of the firmware support in the signature;
the hash value calculation module: calculating a hash value of a current firmware support packet;
and the trusted verification module is used for: comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value obtained from the signature; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if so, comparing whether the hash value of the current firmware support packet is the same as the firmware support Bao Haxi value in the storage area; if the current firmware support packet is different, judging that the current firmware support packet is not trusted, and refusing to load; if the current firmware support package is the same, the current firmware support package is judged to be credible, and the current firmware support package is loaded.
7. The trusted firmware-supported package loading apparatus of claim 6, wherein the Coreboot and the BMC agree to store the hash value of the firmware-supported package in a selected block of the static random access memory of the BMC H2B device;
accordingly, the hash value storage module stores the hash value of the firmware support packet in the selected region.
8. The firmware support package trusted loading device of claim 7, further comprising,
an initialization module: the Coreboot completes the initialization of the BMC H2B device in the starting stage, so that the selected area of the static random access memory can be accessed;
responding to the comparison of the trusted verification module with the hash value of the current firmware support packet being the same as the firmware support Bao Haxi value obtained from the signature, and judging whether the selected area of the static random access memory of the BMC H2B device is empty; if the current firmware supporting packet is empty, the Coreboot is judged to be started for the first time, a trigger hash value storage module is used for writing the hash value of the current firmware supporting packet into a selected area of a static random access memory of the BMC H2B device, and the current firmware supporting packet is loaded; if not, the firmware support Bao Haxi value is fetched from the selected region of the static random access memory of the BMC H2B device, compared to whether the hash value of the current firmware support package is the same as the firmware support Bao Haxi value in the selected region.
9. A terminal, comprising:
a memory for storing a firmware support package trusted loader;
a processor for implementing the steps of the firmware support package trusted loading method according to any one of claims 1 to 5 when executing said firmware support package trusted loading program.
10. A computer readable storage medium, wherein a firmware support package trusted loader is stored on the readable storage medium, which when executed by a processor implements the steps of the firmware support package trusted loading method according to any of claims 1-5.
CN202310014237.4A 2023-01-05 2023-01-05 Firmware support package trusted loading method, device, terminal and storage medium Pending CN116302165A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310014237.4A CN116302165A (en) 2023-01-05 2023-01-05 Firmware support package trusted loading method, device, terminal and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310014237.4A CN116302165A (en) 2023-01-05 2023-01-05 Firmware support package trusted loading method, device, terminal and storage medium

Publications (1)

Publication Number Publication Date
CN116302165A true CN116302165A (en) 2023-06-23

Family

ID=86791366

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310014237.4A Pending CN116302165A (en) 2023-01-05 2023-01-05 Firmware support package trusted loading method, device, terminal and storage medium

Country Status (1)

Country Link
CN (1) CN116302165A (en)

Similar Documents

Publication Publication Date Title
US7272830B2 (en) Ordering program data for loading on a device
US11579893B2 (en) Systems and methods for separate storage and use of system BIOS components
US8473417B2 (en) Signing program data payload sequence in program loading
US20210232691A1 (en) Automatically replacing versions of a key database for secure boots
US7484095B2 (en) System for communicating program data between a first device and a second device
CN107567629A (en) Dynamic firmware module loader in credible performing environment container
CN111427596A (en) Software upgrading method and device and terminal equipment
CN113110891B (en) Firmware loading method and device for solid state disk, computer equipment and storage medium
CN115062307A (en) Open POWER-based program integrity verification method, system, terminal and storage medium
US7392518B1 (en) Robust remote flash ROM upgrade system and method
CN114329358A (en) Application signature method and system, transaction terminal and service platform
CN107077342B (en) Firmware module operation authority
US20040143739A1 (en) Run time code integrity checks
US20210019419A1 (en) Bidirectional trust chaining for trusted boot
CN116302165A (en) Firmware support package trusted loading method, device, terminal and storage medium
US7165246B2 (en) Optimized representation of data type information in program verification
US20240031166A1 (en) Web-side data signature method and apparatus and computer device
US7222331B2 (en) Linking of virtual methods
US20040154013A1 (en) Using a digital fingerprint to commit loaded data in a device
CN112054895A (en) Trusted root construction method and application
CN112463244B (en) CPU starting method and device, electronic equipment and computer readable storage medium
CN107360167B (en) Authentication method and device
CN113868700B (en) BIOS mirror image offline signature method, system, terminal and storage medium
CN117009003B (en) Safe starting method and related device
CN111782230B (en) Program installation control method and device and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination