Safe boot methods and apparatus, storage media and electronic devices

Abstract

This application provides a secure boot method and apparatus, storage medium, and electronic device. The method includes: upon receiving a boot command from a server, determining target information based on a target address obtained from the BIOS flash memory by the BMC, and performing a hash calculation on the target information to obtain first verification data; decrypting pre-stored verification information obtained from the BIOS firmware using a target public key; if the decryption result of the verification information matches the first verification data, responding to a second verification notification sent by the BMC, performing a second verification process on reference configuration data at a reference address based on key hash data in the target information, wherein the key hash data is the hash value of data that has undergone encrypted signature processing of the reference configuration data; and booting the server's operating system if the second verification process result meets the target conditions.

Description

Technical Field

[0001] This application relates to the field of server technology, and more specifically, to a secure boot method and apparatus, a storage medium, and an electronic device. Background Technology

[0002] In current technologies where Intel Boot Guard is enabled, the hardware checks the firmware's digital signature during system startup. If the signature is valid and matches a preset security policy, the system is allowed to continue the boot process. If any abnormal or unauthorized changes are detected, the boot process is blocked, thus preventing potential attackers from exploiting these stages for malicious activities.

[0003] When generating the BIOS binary file, the Boot Guard signing process is as follows: Motherboard manufacturers' R&D personnel need to generate a KM key and a BMP key using the GenBootGuardKey.bat script, and then package these KM and BMP keys into the BIOS source code. Prior to the Intel BirchStream platform, engineers would fill the KM key's hash value into the PCH configuration on the motherboard. However, on the Intel BirchStream platform, Intel removed the PCH component, and the configuration information originally stored on the PCH was organized into the FIT4 table and stored in the BIOS binary. That is, FIT4 table checksum protection was transferred to the Intel PFR feature. However, the Intel PFR feature is too cumbersome and requires increased flash chip capacity to support it, also increasing the cost of motherboard generation. In other words, related technologies suffer from poor verification effectiveness and low efficiency during the server boot process.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a secure boot method and apparatus, storage medium and electronic device to at least solve the problems of poor verification effect and low efficiency of verification data during the boot process of related technologies.

[0006] According to one embodiment of this application, a secure boot method is provided, comprising: upon receiving a boot instruction from a server, determining target information based on a target address obtained by the BMC from the BIOS flash memory, and performing a hash calculation on the target information to obtain first verification data; decrypting pre-stored verification information obtained from the BIOS firmware using a target public key; if the decryption result of the verification information matches the first verification data, responding to a second verification notification sent by the BMC, performing a second verification process on reference configuration data in a reference address based on key hash data in the target information, wherein the key hash data is the hash value of data for which the reference configuration data has been encrypted and signed; and booting the server's operating system if the result of the second verification process meets the target conditions.

[0007] According to another aspect of the embodiments of this application, a secure boot device is also provided, comprising: a determining unit, which, upon receiving a boot command from a server, determines target information based on a target address obtained by a BMC from BIOS flash memory, and performs a hash calculation on the target information to obtain first verification data; a decryption unit, which decrypts pre-stored verification information obtained from BIOS firmware using a target public key; a processing unit, which, upon receiving a second verification notification from a BMC and, if the decryption result of the verification information matches the first verification data, performs a second verification process on reference configuration data in a reference address based on key hash data in the target information, wherein the key hash data is the hash value of data for which the reference configuration data has been encrypted and signed; and a boot unit, which boots the operating system of the server if the result of the second verification process meets the target conditions.

[0008] Optionally, the aforementioned determining unit includes: an encryption module, used to perform hash calculation on the target information to obtain target hash information; obtain a target private key that matches the target public key; and perform encryption signature processing on the target hash information based on the target private key to obtain verification information.

[0009] Optionally, the above processing unit includes: a verification module, configured to perform a hash calculation on the first reference data in the first sub-address of the first reference address range to obtain first reference hash data; if the key hash data in the target information is the same as the first reference hash data, obtain second hash data in the second sub-address of the first reference address range; perform a hash calculation on the second reference data in the first sub-address of the second reference address range to obtain second reference hash data, wherein the first reference data is used to perform encrypted signature processing on the second reference data; if the second hash data is the same as the second reference hash data, obtain second signature data in the second sub-address of the second reference address range; decrypt the second signature data according to the second reference data to obtain reference decrypted data; perform a hash calculation on the third reference data in the third reference address to obtain third reference hash data, and verify the third reference hash data and the reference decrypted data.

[0010] Optionally, the encryption module is also used to: store the verification information in the first address of the BIOS firmware; and store the first address in the target pointer, wherein the target pointer is used to indicate the configuration information of the boot server.

[0011] Optionally, the above verification module includes: a second determining module configured to: acquire data description information matching the third reference hash data and the reference decryption data respectively, wherein the data description information is used to indicate the data partition marker, the data timestamp marker, and the data chain tail value; verifying the third reference hash data and the reference decryption data based on the data description information includes at least one of the following: if the data partition markers of the corresponding partitions of the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition; if the timestamp markers corresponding to the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition; if the data chain tail values ​​corresponding to the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition.

[0012] Optionally, the above processing unit is further configured to: send a verification success notification when the second verification processing result meets the target conditions; and perform a fault confirmation task when no verification success notification is received before the first time, wherein the time interval between the first time and the time when the BMC sends the second verification notification is the target time interval, and the fault confirmation task is used to read register information to locate the fault location and generate fault description information.

[0013] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, and the computer program is configured to execute the above-described secure boot method when it is run.

[0014] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the secure boot method as described above.

[0015] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to execute the above-described secure boot method through the computer program.

[0016] This application achieves the following: First, upon receiving a boot command, the server determines the target information based on the target address obtained by the BMC from the BIOS flash memory and performs a hash calculation on the target information to obtain first verification data. Next, the pre-stored verification information obtained from the BIOS firmware is decrypted using the target public key. If the decryption result of the verification information matches the first verification data, in response to a second verification notification sent by the BMC, a second verification process is performed on the reference configuration data at the reference address based on the key hash data in the target information. Here, the key hash data is the hash value of the data used to encrypt and sign the reference configuration data. This enables the secure booting of the server's operating system when the second verification result meets the target conditions, ensuring the validity of the firmware digital signature and thus ensuring that the application and data have not been tampered with. This solves the problems of poor verification effect and low efficiency in the verification data during the server boot process in related technologies, and achieves the purpose of complete Intel Boot Guard verification without enabling the Intel PFR feature. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0018] Figure 1 This is a hardware structure block diagram of a server device for a secure boot method according to an embodiment of this application;

[0019] Figure 2 This is a flowchart of a secure boot method according to an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of a secure boot method according to an embodiment of this application;

[0021] Figure 4This is a flowchart of another secure boot method according to an embodiment of this application;

[0022] Figure 5 This is a schematic diagram of another secure boot method according to an embodiment of this application;

[0023] Figure 6 This is a schematic diagram of the structure of a safety start device according to an embodiment of this application;

[0024] Figure 7 This is a schematic diagram of the structure of a secure start electronic device according to an embodiment of this application. Detailed Implementation

[0025] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0026] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0027] The following is an explanation of the terms used in this application:

[0028] BIOS: Basic Input Output System. It is firmware integrated on the computer's motherboard, responsible for performing initialization and self-test processes during startup, and providing basic services before the operating system runs. BIOS is one of the first software programs to run when a personal computer boots up.

[0029] BMC: Baseboard Management Controller. A BMC is a dedicated microcontroller used to monitor and manage the hardware status and functionality of servers or other computing devices. It is typically integrated on the server motherboard and can operate independently of the main processor, providing remote monitoring and management capabilities for server health.

[0030] Intel Boot Guard is a security technology provided by Intel designed to help protect computers from malware tampering during the initial stages of the boot process. This technology enhances system security by ensuring that only verified firmware can be loaded and run. Specifically, Intel Boot Guard verifies the integrity and authenticity of the system BIOS / UEFI firmware, preventing unauthorized modifications.

[0031] PRoT: Platform Root of Trust. A root of trust is a fundamental component in a system that provides basic trust. These components are typically part of hardware, firmware, or software, providing an immutable foundation of trust during system startup and operation. The main functions of a root of trust include: Authentication: Ensuring the authenticity and integrity of system components, preventing unauthorized modification or replacement. Key Management: Storing and managing encryption keys to protect data and communication security. Secure Boot: Verifying each step of the boot process, ensuring that only verified code can run.

[0032] S3M: Safe Start Measurement, is a security technology introduced by Intel, primarily used to enhance the secure boot process of a system. The main goal of S3M is to provide a trusted measurement mechanism during system startup to ensure that critical components during the boot process have not been tampered with, thereby improving system security.

[0033] BPM, or Boot Policy Manifest, is a crucial component of Intel Boot Guard technology. It's a file containing boot policies used to define and control which firmware and bootloaders are trusted during the system boot process. Through BPM, the system can verify the integrity and authenticity of firmware and bootloaders at startup, thus preventing unauthorized modifications and malware injection.

[0034] ACM: Authenticated Code Module, is a security technology provided by Intel, primarily used to enhance system security, especially during the boot process. ACM is a signed and verified code module that typically runs in the early stages of system startup to ensure that critical security functions are executed correctly.

[0035] KM: Key Management, refers to a key management technology provided by Intel to ensure the security and integrity of a system during startup and operation. Intel KM is primarily used to manage and protect encryption keys, which play a crucial role in system security, especially in scenarios involving data encryption, authentication, and secure boot.

[0036] IBB (Initial Boot Block) is a crucial component in Intel platforms used to enhance system boot security. The IBB is part of the system firmware, typically located in the early boot stages of the BIOS / UEFI firmware, and is responsible for verifying and loading subsequent firmware modules. The primary purpose of the IBB is to ensure that critical components during the system boot process have not been tampered with, thereby improving system security.

[0037] PFR (Platform Firmware Resilience) is a security technology provided by Intel designed to enhance the resilience and recovery capabilities of platform firmware, ensuring the system remains secure and stable in the face of firmware attacks. Through PFR's verification mechanism, the system can refuse to load any unauthorized or tampered firmware, thereby preventing malware injection during the boot process. This ensures the system is trusted at every stage of the boot process, reducing the risk of malicious attacks.

[0038] OEM: Original Equipment Manufacturer.

[0039] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device for a secure boot method according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that… Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0040] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the secure boot method in this embodiment. The processor 102 executes various functional applications and secure boot by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0041] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0042] As an optional implementation method, such as Figure 2 As shown, the above-mentioned secure boot method includes:

[0043] S202, upon receiving the boot command, the server determines the target information based on the target address obtained from the BIOS flash memory by the BMC, and performs a hash calculation on the target information to obtain the first verification data;

[0044] S204, decrypt the pre-stored verification information obtained from the BIOS firmware using the target public key;

[0045] S206, if the decryption result of the verification information and the first verification data meet the matching condition, in response to the second verification notification sent by the BMC, the reference configuration data in the reference address is subjected to second verification processing according to the key hash data in the target information, wherein the key hash data is the hash value of the data for which the reference configuration data has been encrypted and signed.

[0046] S208, if the second verification result meets the target conditions, start the server's operating system.

[0047] In an optional implementation, it should be noted that in step S202 above, when the server receives the boot command, the target information is determined based on the target address obtained by the BMC from the BIOS flash memory, and a hash calculation is performed on the target information to obtain the first verification data. Specifically, the target information may be FIT4table data storing the HASH value of the KM key. This FIT4 table data is stored in the BIOS Flash memory, and the information included in the FIT4 table data is as follows: Figure 3 As shown. The first verification data is the data obtained by performing SHA384 hash processing on the saved FIT4 table data.

[0048] Further, in step S204, the pre-stored verification information obtained from the BIOS firmware is decrypted using the target public key. The pre-stored verification information is a signature obtained by hashing the FIT4 table data and encrypting it using the target private key. Specifically, the BMC first obtains read / write control of the BIOS Flash, locates the FIT Pointer in the BIOS Flash, then positions the address of the FIT4 signature, reads the FIT4 signature data, and then decrypts the signature using the target public key. The target public key and target private key are a pre-configured set of keys.

[0049] Optionally, in step S206, if the decryption result of the verification information matches the first verification data, in response to the second verification notification sent by the BMC, a second verification process is performed on the reference configuration data in the reference address based on the key hash data in the target information. It should be noted that the key hash data is the hash value of the data after encrypting and signing the reference configuration data. The matching condition can be that the hash value after decrypting the verification information is the same as the first verification data. The second verification notification can be a notification to call the ACM to verify the KM, BPM, and IBB regions. The key hash data can be the hash value of the KM key stored in the FIT4 table. The reference address can be an address that matches the KM, BPM, or IBB regions. The reference configuration data can be data such as the KM key, BPM key, the hash value of the BPM key, and IBB region information.

[0050] As an optional implementation, the second verification process of the reference configuration data in the reference address based on the key hash data in the target information can be performed by calling ACM to read the KM key HASH in the FIT4 table data to verify the KM key; then, by reading the hash value of the BPM key in the KM area through ACM to verify the BPM area; and further, by reading the BPM key in the BPM area through ACM to verify the IBB area.

[0051] It should be noted that the Boot Guard signing process during BIOS binary file generation is as follows: A KM key and a BPM key are generated using the GenBootGuardKey.bat script. These KM and BPM keys are then included in the BIOS source code. During BIOS source code compilation, the IBB area is first hashed, and then the BPM key is used to sign the hash value, generating a BPM Signature. This BPM Signature, along with the BPM key, IBB area information, and hash value, is stored in the Boot Policy Manifest area of ​​the BIOS flash. Here, the BPM key encrypts the IBB area to ensure its security. Then, the KM key encrypts the BPM key hash to generate a KM signature. The BPM key hash value, KM signature, and KM key are stored in the Key Manifest area of ​​the BIOS flash. Here, the KM key encrypts the BPM key to ensure its security. Following this method, the FIT4 table data in this application is stored in the BIOS binary file.

[0052] Then, in step S208, if the second verification result meets the target conditions, the server's operating system is started. That is, the server's operating system is securely started after verifying that the KM, BPM, and IBB areas have not been tampered with.

[0053] The following is a flowchart Figure 4 The above process will be explained as follows:

[0054] S402, G3 power-on, BMC out-of-band BIOS update completes boot; "G3" is Intel's server platform, the out-of-band update mechanism does not require the server to be completely shut down, and can be performed during server operation intervals.

[0055] In S404, PRoT reads the FIT4 table from the BIOS flash based on the FIT pointer; then, in S406, it finds the table address with Type 0xFE based on the FIT pointer, which stores the encrypted signature of the FIT4 table.

[0056] In S408, PRoT checks if the signature matches the saved Pubkey. If not, it executes S422, Boot Guard Varify Fail. BMC update SEL. This means the verification failed, and the BMC needs to actively read the CPU MSR register to confirm the location of the error and generate an SEL log. The SEL (System Event Log) records events and errors in the system, including hardware failures, software anomalies, and security warnings.

[0057] If a match is found, S410 is executed. Upon detecting the PLTRST_SYNC#signal, the ProT holds off the RESET# signal. It's important to note that during server startup, the ProT (e.g., BMC) monitors and waits for a specific hardware signal, PLTRST_SYNC#signal. This signal is typically issued by the platform's hardware control logic, indicating that the main CPU (Central Processing Unit) is completing its secure boot checks (e.g., verifying KM, BPM, and IBB regions). When the ProT receives the PLTRST_SYNC#signal, it temporarily holds off (i.e., suppresses or delays) sending the RESET# signal. In the context of server startup, the RESET# signal allows or triggers the main CPU to continue the boot process. By suppressing this signal, the ProT ensures that the system will not be allowed to continue booting until Boot Guard checks or other security checks have fully passed.

[0058] S412, PRoT releases the RESET# signal to the CPU, initiating the WDT (Wait Timer) (recommended 2 minutes). Specifically, after security checks (such as Intel Boot Guard checks) pass, PRoT releases the previously suppressed RESET# signal. This signal allows the CPU to continue executing the boot process. During the security check phase, PRoT holds off the RESET# signal until the integrity and authenticity of all critical firmware components (such as KM, BPM, IBB, etc.) are confirmed. Once all checks pass, PRoT no longer suppresses the RESET# signal, and the CPU can continue executing subsequent boot instructions, such as loading the operating system. Simultaneously or after PRoT releases the RESET# signal, it initiates a WDT. The WDT is a timer mechanism used to monitor and ensure the normal operation of the system or application. In server boot scenarios, the WDT's role is to ensure that the CPU can complete the subsequent boot process within a reasonable time after the security boot check passes.

[0059] S414, Ucode loads ACM, ACM verifies KM / BPM / IBB; specifically, Ucode is firmware embedded in the CPU used to perform critical initialization and verification tasks. At this stage, Ucode is responsible for loading and executing ACM, a digitally signed code module used to implement Intel Boot Guard security policies.

[0060] S416 verifies the result (if Fail, the system will not continue booting until WDT is triggered). If the verification result passes, S418 is executed, entering the BIOS code, sending BG varify pass SEL, which means entering the BIOS code execution stage, and sending a system event record of Boot Guard verification passing; the above process ends.

[0061] If the verification result fails, S420 is executed, triggering WDT. PRoT reads MSR 0x138 to confirm the verification failure point. It should be noted that MSR is a register used by the CPU to store specific configuration and status information. MSR 0x138 is usually used to record status information during the Intel Boot Guard verification process.

[0062] Further execute S422, Boot Guard Varify Fail.BMC update SEL.

[0063] This application achieves the following: First, upon receiving a boot command, the server determines the target information based on the target address obtained by the BMC from the BIOS flash memory and performs a hash calculation on the target information to obtain first verification data. Next, the pre-stored verification information obtained from the BIOS firmware is decrypted using the target public key. If the decryption result of the verification information matches the first verification data, in response to a second verification notification sent by the BMC, a second verification process is performed on the reference configuration data at the reference address based on the key hash data in the target information. Here, the key hash data is the hash value of the data used to encrypt and sign the reference configuration data. This enables the secure booting of the server's operating system when the second verification result meets the target conditions, ensuring the validity of the firmware digital signature and thus ensuring that the application and data have not been tampered with. This solves the problems of poor verification effect and low efficiency in the verification data during the server boot process in related technologies, and achieves the purpose of complete Intel Boot Guard verification without enabling the Intel PFR feature.

[0064] In one optional implementation, before determining the target information based on the target address obtained from the BIOS flash memory by the BMC and performing a hash calculation on the target information to obtain the first verification data, upon receiving a boot command from the server, the following steps are included:

[0065] S1, perform hash calculation on the target information to obtain the target hash information;

[0066] S2, obtain the target private key that matches the target public key, and perform encryption and signature processing on the target hash information based on the target private key to obtain the verification information.

[0067] Optionally, in this embodiment, before starting the server, the stored target information is hashed to obtain target hash information; the target private key matching the target public key is obtained, and the target hash information is encrypted and signed according to the target private key to obtain verification information. That is, the FIT4 table data is hashed in advance, and the generated target private key is used to encrypt and sign it to obtain the FIT4 signature, which is then stored in the BIOS flash memory.

[0068] Through the above-described embodiments of this application, target hash information is obtained by hashing the target information; a target private key matching the target public key is obtained, and the target hash information is encrypted and signed based on the target private key to obtain verification information. Hash processing and signing of table data during the pre-configuration phase ensures the correctness of the initial data, thereby ensuring the validity of the data after decryption of the signature during the server startup phase. Comparison of the hash value of this data with potentially tampered data ensures the correctness of the verification result and improves the efficiency of data verification.

[0069] In one optional implementation, in response to a second verification notification sent by the BMC, a second verification process is performed on the reference configuration data in the reference address based on the key hash data in the target information, including:

[0070] S1, perform hash calculation on the first reference data in the first sub-address of the first reference address range to obtain the first reference hash data;

[0071] S2, if the key hash data in the target information is the same as the first reference hash data, obtain the second hash data in the second sub-address of the first reference address range;

[0072] S3, perform hash calculation on the second reference data of the first sub-address of the second reference address range to obtain the second reference hash data, wherein the first reference data is used to perform cryptographic signature processing on the second reference data;

[0073] S4, if the second hash data is the same as the second reference hash data, obtain the second signature data in the second sub-address of the second reference address range;

[0074] S5, decrypt the second signature data according to the second reference data to obtain the reference decryption data;

[0075] S6, perform hash calculation on the third reference data in the third reference address to obtain the third reference hash data, and verify the third reference hash data and the reference decryption data.

[0076] In step S1 above, the first reference data in the first sub-address of the first reference address range is hashed to obtain the first reference hash data. Specifically, the first reference data (e.g., the KM key) in the Key Manifest area of ​​the BIOS Flash can be obtained, and the first reference data is hashed to obtain the first reference hash data (e.g., the HASH of the KM key).

[0077] Then, in step S2, if the key hash data in the target information is the same as the first reference hash data, the second hash data in the second sub-address of the first reference address range is obtained. That is, if the hash value of the KM key stored in the FIT4 table (i.e., the aforementioned key hash data) is the same as the hash value obtained by hashing the KM key stored in the KM area in S1, the hash value of the BPM key stored in the KM area (i.e., the aforementioned second hash data) is further obtained, which verifies that the KM area has not been tampered with and further determines the correctness of the BPM area.

[0078] Further execute step S3, perform hash calculation on the second reference data of the first sub-address of the second reference address range to obtain the second reference hash data, wherein the first reference data is used to perform encryption signature processing on the second reference data; that is, perform hash calculation on the BPM key (i.e. the above-mentioned second reference data) stored in the Boot Policy Manifest area of ​​the BIOS flash to obtain the second reference hash data.

[0079] In step S4, if the second hash data is the same as the second reference hash data, the second signature data in the second sub-address of the second reference address range is obtained. Specifically, if the hash value of the BPM key calculated in S3 is equal to the hash value of the BPM key stored in the KM area in S2, it is determined that the BPM area has not been tampered with. To further verify the correctness of the IBB area, the second signature data (e.g., BPM Signature) needs to be obtained.

[0080] Further execute S5-S6: decrypt the second signature data based on the second reference data to obtain reference decryption data; perform hash calculation on the third reference data in the third reference address to obtain third reference hash data; and verify the third reference hash data and the reference decryption data.

[0081] As an optional implementation, the second signature data (BPM Signature) is first decrypted using the BPM key (i.e., the second reference data mentioned above) to obtain the IBM hash. Then, the information in the IBB area is further hashed, and the hash value obtained is compared with the hash value obtained from decryption.

[0082] The following diagram illustrates the process. Figure 5 The above process will be explained using an example:

[0083] The BMC first decrypts the FIT4 Table Sig stored in the BIOS FLASH. It then retrieves the FIT4 Table stored in the BIOS FLASH and performs a hash calculation on it. If the hash value obtained from decryption matches the calculated hash value, the BMC calls Intel ACM to verify the KM, BPM, and IBB regions in the order of retrieving the KMSignature from the KEY Manifest region, the BPM KEY HASH from the BPM Signature from the Boot Policy Manifest region. After successful verification, the Startup program is executed. It should be noted that the signature is obtained during the compilation process by encrypting and signing the hashed key and region information data.

[0084] Through the above-described implementation method of this application, after verifying the FTI4 table data, the KM key is verified by calling ACM to read the KM key HASH in the PCH configuration; then, ACM reads the hash value of the BPM key in the KM to verify the BPM area; and then ACM reads the BPM key in the BPM to verify the IBB area. This ensures that the firmware corresponding to each stage and area of ​​the BIOS firmware is reliable and has not been tampered with during the boot process, and provides security protection for different parts of the firmware. Even if a small part of the firmware is attacked, the abnormal area can be located immediately and fault recovery measures can be taken, thereby improving the security and verification effect of the verification data during the server boot process.

[0085] In one optional implementation, after obtaining verification information by encrypting and signing the target hash information based on the target private key, the process includes:

[0086] S1, store the verification information at the first address of the BIOS firmware;

[0087] S2, store the first address in the target pointer, where the target pointer is used to indicate the configuration information for starting the server.

[0088] As an optional implementation, in steps S1-S2, the verification information is stored in the first address of the BIOS firmware; the first address is also stored in a target pointer, where the target pointer indicates the configuration information for booting the server. It is understood that to facilitate quick access to this verification information by the BMC (Baseboard Management Controller) or PRoT (Platform Root of Trust), these signatures are stored at the very beginning of the BIOS firmware, i.e., the first address. This is because BIOS firmware loading begins at the first address, ensuring that the PRoT can access the verification information at the earliest stage of the boot process for rapid security verification. The target pointer, typically referring to the FIT Pointer stored in the BIOS, indicates the storage location of the configuration information in the BIOS firmware. In the server, the configuration information may include critical data such as boot policies, firmware versions, and security verification information. Storing the first address containing the verification information in the target pointer allows the BMC or PRoT to quickly locate the beginning of the firmware and read the stored verification information when the server boots.

[0089] By implementing the above steps of this application, the verification information is stored at the first address of the BIOS firmware, and the address information is stored in the target pointer (such as the FIT Pointer). The server can quickly locate the signature file when the system starts up, without having to traverse the entire BIOS flash to find the signature information, which greatly improves the efficiency and speed of verification. This enables efficient execution of secure boot verification, ensures that the firmware has not been tampered with, and improves the security and reliability of the system boot.

[0090] In one optional implementation, after performing a hash calculation on the third reference data in the third reference address to obtain the third reference hash data, the process includes:

[0091] S1, respectively obtain the data description information that matches the third reference hash data and the reference decryption data, wherein the data description information is used to indicate the data partition mark, the data timestamp mark and the data chain tail value;

[0092] S2, verifying the third reference hash data and reference decryption data based on the data description information includes at least one of the following:

[0093] Method 1: If the data partition labels of the corresponding partitions of the third reference hash data and the reference decryption data are the same, determine that the second verification processing result meets the target condition.

[0094] Method 2: If the timestamps corresponding to the third reference hash data and the reference decryption data are the same, determine that the second verification result meets the target condition.

[0095] Method 3: If the tail values ​​of the data chains corresponding to the third reference hash data and the reference decryption data are the same, it is determined that the second verification processing result meets the target condition.

[0096] In step S1 above, data description information matching the third reference hash data and the reference decryption data is first obtained. This data description information indicates the data partition marker, the data timestamp marker, and the data chain tail value. It should be noted that the data partition marker can be obtained by partitioning or segmenting the hash value, with each partition matched with a marker value. The timestamp marker is used to append a timestamp when generating the hash value, thereby verifying the freshness of the data while comparing the hash values ​​and preventing replay attacks, i.e., attackers using the hash value of old data to impersonate the integrity of new data. The generation process of the data chain tail value is as follows: the hash value corresponding to each data block is used as the input for the next data block, ultimately generating a chain tail hash value. When verifying data integrity, only the chain tail hash value needs to be compared.

[0097] Optionally, in Method 1, if the data partition labels of the corresponding partitions of the third reference hash data and the reference decryption data are the same, it is determined that the verification processing result meets the target condition. Specifically, for example, if the third reference hash data is "111222333" divided into three partitions "111", "222", and "333", which are labeled "A", "B", and "C" respectively, and if the reference decryption data also has three partitions, and the partition labels are "A", "B", and "C" respectively, it is determined that the hash values ​​are equal, and the second verification processing result meets the target condition.

[0098] As an alternative implementation, in Method 2, if the timestamps corresponding to the third reference hash data and the reference decryption data are the same, the second verification result is determined to meet the target condition. Specifically, the system compares the timestamps of the two sets of data and checks if they are consistent. If the timestamps are the same, it means that the two sets of data are synchronized in terms of creation or last modification time, indicating that they have not been modified or updated without authorization.

[0099] It should be noted that Method 2 can be used in combination with Method 1 to determine that the second verification result meets the target condition when both the timestamp mark and the partition mark match.

[0100] Optionally, in Method 3, if the tail values ​​of the data chains corresponding to the third reference hash data and the reference decryption data are the same, the result of the second verification process is determined to meet the target condition. Specifically, the corresponding tail values ​​of the data chains are obtained from the third reference hash data and the reference decryption data. If the tail values ​​are the same, it means that the current data block and the previous data block maintain continuity and consistency in the chained verification structure. In particular, if the calculated tail value of the current data block matches the actual tail value of the previous data block, it indicates that the data has not been tampered with or illegally inserted / deleted.

[0101] For example, the third reference hash data "111222333" is divided into three partitions: "111", "222", and "333". The partitions match "A", "B", and "C". The tag value of the next partition is related to the data information of the previous partition. Finally, a chain tail value is generated. By constructing a chain verification structure for the data, even if there are many data blocks, the integrity of the entire data stream can be effectively verified.

[0102] The above-described embodiments described in this application enable rapid matching of hash values ​​of different data using different methods such as data partition markers, data timestamp markers, and data chain tail values. This reduces the time required to match each data item in the hash value. For example, due to the mismatch between the hash value change and the timestamp marker, tampering behavior can be quickly identified, improving the hash value comparison efficiency and thus improving the efficiency and accuracy of data verification.

[0103] In one optional implementation, after performing a second verification process on the reference configuration data in the reference address based on the key hash data in the target information, the process includes:

[0104] S1, if the second verification result meets the target conditions, send a verification success notification;

[0105] S2, if no successful verification notification is received before the first moment, the BMC performs a fault confirmation task. The time interval between the first moment and the moment when the BMC sends the second verification notification is the target time interval. The fault confirmation task is used to read register information to locate the fault location and generate fault description information.

[0106] In steps S1-S2 above, if the second verification result meets the target condition, a verification success notification is sent; if no verification success notification is received before the first time point, the BMC executes a fault confirmation task. The time interval between the first time point and the time when the BMC sends the second verification notification is the target time interval. The fault confirmation task is used to read register information to locate the fault location and generate fault description information. The verification success notification can be a SystemEvent Log (SEL) notification. It is understood that the target time interval can be dynamically adjusted according to the server load.

[0107] In other words, if the system does not receive a successful verification notification before the first moment, it's possible that a problem occurred during system startup, the verification failed to complete, or the verification module encountered an exception during execution. In this case, the BMC will perform a fault confirmation task. The BMC will access specific hardware registers to obtain detailed information about the firmware verification status. These registers may contain error codes, the specific location of the verification failure, and other critical hardware status information. The fault description information mentioned above can record the reason for the verification failure, the location of the fault, and possible solution suggestions.

[0108] Through the above-described implementation method of this application, even in the event of BIOS / UEFI verification failure, the BMC can proactively intervene, collect critical fault information, and help quickly locate the problem and take corresponding measures for repair. This not only enhances system security but also improves the efficiency of troubleshooting.

[0109] The present application is described below with reference to a complete embodiment:

[0110] S1. A new set of private and public keys is generated. During the BIOS compilation process, the FIT4 table data is hashed using the openssl tool using SHA384, and then the hash value is encrypted using the private key to generate the encrypted signature of the FIT4 table. A possible command is: openssl.exe dgst -sha384 -sign private.pem -out Fit4.sigFit4.bin.

[0111] S2. Insert the generated Fit4.sig into a fixed address in the BIOS flash FV_OEM area and store this address in the BIOS FIT Pointer so that the BMC can quickly find the signature file from the flash for verification.

[0112] S3, the first step after the system powers on, is for the BMC to first obtain read and write control of the BIOS Flash, find the FIT Pointer in the BIOS Flash, then locate the address of the FIT4 table and the FIT4 signature, read the FIT4 signature data, and then decrypt the signature using the public key in S1. Then, it reads the data of the FIT4 table and performs SHA384 HASH calculation, and compares it with the decrypted data. If they match, it proves that the data is valid and has not been changed.

[0113] S4. After the verification in step S3 is successful, the BMC releases the system RESET# signal, and the CPU's S3M starts calling ACM to verify the KM, BPM, and IBB regions, completing the Boot Guard's integrity verification of the BIOS binary.

[0114] Specifically, after successful verification, the BIOS code is executed, and a SEL message is sent to the BMC bootguard to indicate that the verification passed. If the verification fails, since the system control is now dominated by the S3M, neither the PRoT nor the BIOS can detect the verification failure. Therefore, the BMC needs to set a timer (CRB setting). The timer is triggered after the release RESET# signal. When the timer count is complete and no verification success message is received from the BIOS, it indicates that an error occurred during the verification of the KM, BPM, and IBB regions by the S3M. The BMC then actively reads the CPU MSR register to confirm the location of the error and generates an SEL log.

[0115] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0116] According to another aspect of the embodiments of this application, a secure boot device for implementing the above-described secure boot method is also provided. For example... Figure 6 As shown, the device includes:

[0117] The determining unit 602, upon receiving a boot command from the server, determines the target information based on the target address obtained from the BIOS flash memory by the BMC, and performs a hash calculation on the target information to obtain the first verification data;

[0118] The decryption unit 604 decrypts the pre-stored verification information obtained from the BIOS firmware using the target public key;

[0119] The processing unit 606, in response to the second verification notification sent by the BMC, performs a second verification process on the reference configuration data in the reference address based on the key hash data in the target information, provided that the decryption result of the verification information and the first verification data meet the matching conditions. The key hash data is the hash value of the data for which the reference configuration data has been encrypted and signed.

[0120] The startup unit 608 starts the server's operating system if the second verification processing result meets the target conditions.

[0121] Optionally, the determining unit 602 includes: an encryption module, used to perform hash calculation on the target information to obtain target hash information; obtain a target private key that matches the target public key; and perform encryption signature processing on the target hash information based on the target private key to obtain verification information.

[0122] Optionally, the processing unit 606 includes: a verification module, configured to perform a hash calculation on the first reference data in the first sub-address of the first reference address range to obtain first reference hash data; if the key hash data in the target information is the same as the first reference hash data, obtain second hash data in the second sub-address of the first reference address range; perform a hash calculation on the second reference data in the first sub-address of the second reference address range to obtain second reference hash data, wherein the first reference data is used to perform encryption signature processing on the second reference data; if the second hash data is the same as the second reference hash data, obtain second signature data in the second sub-address of the second reference address range; decrypt the second signature data according to the second reference data to obtain reference decryption data; perform a hash calculation on the third reference data in the third reference address to obtain third reference hash data, and verify the third reference hash data and the reference decryption data.

[0123] Optionally, the encryption module is also used to: store the verification information in the first address of the BIOS firmware; and store the first address in the target pointer, wherein the target pointer is used to indicate the configuration information of the boot server.

[0124] Optionally, the above verification module includes: a second determining module configured to: acquire data description information matching the third reference hash data and the reference decryption data respectively, wherein the data description information is used to indicate the data partition marker, the data timestamp marker, and the data chain tail value; verifying the third reference hash data and the reference decryption data based on the data description information includes at least one of the following: if the data partition markers of the corresponding partitions of the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition; if the timestamp markers corresponding to the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition; if the data chain tail values ​​corresponding to the third reference hash data and the reference decryption data are the same, determine that the second verification processing result satisfies the target condition.

[0125] Optionally, the processing unit 606 is further configured to: send a verification success notification when the second verification processing result meets the target conditions; and perform a fault confirmation task when no verification success notification is received before the first time, wherein the time interval between the first time and the time when the BMC sends the second verification notification is the target time interval, and the fault confirmation task is used to read register information to locate the fault location and generate fault description information.

[0126] According to another aspect of the embodiments of this application, an electronic device for implementing the above-described secure boot method is also provided. This electronic device may be... Figure 1 The terminal device or server shown. This embodiment uses a mobile phone or computer as an example for illustration. Figure 7 As shown, the electronic device includes a memory 702 and a processor 704. The memory 702 stores a computer program, and the processor 704 is configured to execute the steps in any of the above method embodiments via the computer program.

[0127] Optionally, in this embodiment, the aforementioned electronic device may be located in at least one of a plurality of network devices in a computer network.

[0128] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0129] S1, upon receiving the boot command, the server determines the target information based on the target address obtained from the BIOS flash memory by the BMC, and performs a hash calculation on the target information to obtain the first verification data;

[0130] S2, decrypt the pre-stored verification information obtained from the BIOS firmware using the target public key;

[0131] S3, if the decryption result of the verification information and the first verification data meet the matching condition, in response to the second verification notification sent by the BMC, the reference configuration data in the reference address is subjected to second verification processing according to the key hash data in the target information, wherein the key hash data is the hash value of the data for which the reference configuration data has been encrypted and signed.

[0132] S4, if the second verification result meets the target conditions, start the server's operating system.

[0133] Alternatively, as those skilled in the art will understand, Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, etc.), or having the same Figure 7 The different configurations shown.

[0134] The memory 702 can be used to store software programs and modules, such as the program instructions / modules corresponding to the secure boot method and apparatus in this embodiment. The processor 704 executes various functional applications and secure boot by running the software programs and modules stored in the memory 702, thereby implementing the aforementioned secure boot method. The memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 702 may further include memory remotely located relative to the processor 704, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Specifically, the memory 702 may be used, but is not limited to, to store information such as GPU specifications. As an example, such as... Figure 7 As shown, the memory 702 may include, but is not limited to, the determining unit 602, decryption unit 604, processing unit 606, and startup unit 608 of the aforementioned secure boot device. Furthermore, it may include, but is not limited to, other module units of the aforementioned secure boot device, which will not be elaborated upon in this example.

[0135] Optionally, the transmission device 706 described above is used to receive or send data via a network. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 706 includes a Network Interface Controller (NIC), which can be connected to other network devices and a router via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 706 is a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0136] In addition, the aforementioned electronic device also includes: a display 708 for displaying server startup-related information; and a connection bus 710 for connecting the various module components in the aforementioned electronic device.

[0137] In other embodiments, the aforementioned terminal device or server can be a node in a distributed system, wherein the distributed system can be a blockchain system, which is a distributed system formed by connecting multiple nodes through network communication. The nodes can form a point-to-point network, and any form of computing device, such as a server, terminal, or other electronic device, can become a node in the blockchain system by joining this point-to-point network.

[0138] According to one aspect of this application, a computer-readable storage medium is provided, wherein a processor of a computer device reads computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described above;

[0139] Optionally, in this embodiment, the computer-readable storage medium may be configured to store a computer program for performing the following steps:

[0140] S1, upon receiving the boot command, the server determines the target information based on the target address obtained from the BIOS flash memory by the BMC, and performs a hash calculation on the target information to obtain the first verification data;

[0141] S2, decrypt the pre-stored verification information obtained from the BIOS firmware using the target public key;

[0142] S3, if the decryption result of the verification information and the first verification data meet the matching condition, in response to the second verification notification sent by the BMC, the reference configuration data in the reference address is subjected to second verification processing according to the key hash data in the target information, wherein the key hash data is the hash value of the data for which the reference configuration data has been encrypted and signed.

[0143] S4, if the second verification result meets the target conditions, start the server's operating system.

[0144] Optionally, in embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0145] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0146] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods of the various embodiments of this application.

[0147] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0149] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0150] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0151] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

[0152] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0153] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0154] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0155] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0156] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0157] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0158] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0159] The embodiments described herein also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0160] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0161] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0162] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A secure boot method, characterized in that, comprising: in the case that the server receives a boot instruction, determining target information based on a target address obtained by the BMC from the BIOS flash memory, and performing a hash calculation on the target information to obtain first verification data; decrypting the pre-stored verification information obtained from the BIOS firmware through a target public key; in the case that the decryption result of the verification information and the first verification data satisfy a matching condition, in response to a second verification notification sent by the BMC, performing second verification processing on reference configuration data in a reference address according to key hash data in the target information, wherein the key hash data is a hash value of data that is subject to encryption signature processing on the reference configuration data; in the case that the second verification processing result satisfies a target condition, booting the operating system of the server.

2. The method of claim 1, characterized in that, before the case that the server receives a boot instruction, determining target information based on a target address obtained by the BMC from the BIOS flash memory, and performing a hash calculation on the target information to obtain first verification data, comprising: performing the hash calculation on the target information to obtain target hash information; obtaining a target private key matching the target public key, and performing the encryption signature processing on the target hash information according to the target private key to obtain the verification information.

3. The method of claim 2, characterized in that, in response to the second verification notification sent by the BMC, performing second verification processing on reference configuration data in a reference address according to key hash data in the target information, comprising: performing a hash calculation on first reference data in a first sub-address of a first reference address interval to obtain first reference hash data; in the case that the key hash data in the target information is the same as the first reference hash data, obtaining second hash data in a second sub-address of the first reference address interval; performing a hash calculation on second reference data of a first sub-address of a second reference address interval to obtain second reference hash data, wherein the first reference data is used to perform the encryption signature processing on the second reference data; in the case that the second hash data is the same as the second reference hash data, obtaining second signature data in a second sub-address of the second reference address interval; decrypting the second signature data according to the second reference data to obtain reference decryption data; performing a hash calculation on third reference data in a third reference address to obtain third reference hash data, and performing a verification on the third reference hash data and the reference decryption data.

4. The method of claim 2, characterized in that, after the encryption signature processing on the target hash information according to the target private key to obtain the verification information, comprising: storing the verification information in a first address of the BIOS firmware; storing the first address in a target pointer, wherein the target pointer is used to indicate configuration information for booting the server.

5. The method of claim 3, characterized in that, After the third reference data in the third reference address is hashed to obtain third reference hash data, the method comprises: Respectively acquiring data description information matching the third reference hash data and the reference decryption data, wherein the data description information is used to indicate data partition marks, data timestamp marks and data chain tail values; The checking of the third reference hash data and the reference decryption data based on the data description information comprises at least one of the following: In the case that the data partition marks of the third reference hash data and the reference decryption data corresponding to the respective partitions are the same, it is determined that the second checking result satisfies the target condition; In the case that the timestamp marks of the third reference hash data and the reference decryption data corresponding to the respective partitions are the same, it is determined that the second checking result satisfies the target condition; In the case that the data chain tail values of the third reference hash data and the reference decryption data corresponding to the respective partitions are the same, it is determined that the second checking result satisfies the target condition.

6. The method of claim 1, wherein, after the second checking processing of the reference configuration data in the reference address according to the key hash data in the target information, the method comprises: In the case that the second checking result satisfies the target condition, a checking success notification is sent; In the case that the checking success notification is not received before a first time, the BMC performs a fault confirmation task, wherein the time interval between the first time and the time when the BMC sends the second checking notification is a target time interval, and the fault confirmation task is used to read register information to locate a fault position and generate fault description information.

7. A secure boot apparatus, comprising: A determination unit, in the case that a server receives a boot instruction, determines target information based on a target address obtained by a BMC from a BIOS flash memory, and performs a hash calculation on the target information to obtain first checking data; A decryption unit, which decrypts pre-stored checking information obtained from a BIOS firmware by a target public key; A processing unit, in the case that the decryption result of the checking information and the first checking data satisfy a matching condition, in response to a second checking notification sent by the BMC, performs a second checking processing of reference configuration data in a reference address according to key hash data in the target information, wherein the key hash data is a hash value of data subjected to an encryption signature processing of the reference configuration data; A boot unit, in the case that a second checking processing result satisfies a target condition, boots an operating system of the server.

8. A computer readable storage medium, comprising: The computer readable storage medium stores a computer program, wherein the computer program is executed by a processor to implement the steps of the method in any one of claims 1 to 6.

9. An electronic device, comprising a memory, a processor and a computer program stored on the memory and executable on the processor, wherein ​ ​ The processor, when executing the computer program, realizes the steps of the method described in any one of claims 1 to 6.

10. A computer program product comprising a computer program, characterized in that, The processor, when executing the computer program, realizes the steps of the method described in any one of claims 1 to 6.

Images