Basic input and output system security protection method, device, equipment and medium

Abstract

The present application discloses a basic input / output system security protection method, apparatus, device and medium, relating to the field of computer system security technology. The method comprises extracting a firmware capsule file from a basic input / output system image file to achieve independent verification of the update content, so that the system can seamlessly adapt to dynamic firmware updates and avoid compatibility issues caused by changes in signature rules. The firmware capsule file includes a first signature and a signature file, and the signature file includes a core code file and a second signature. This layered design allows for dynamic adjustment of verification strategies based on security requirements at different levels. The first layer verifies the integrity of the signature file to ensure that the firmware capsule file has not been tampered with. The second layer verifies the integrity of the core code file to ensure that the core functions have not been tampered with, thereby enhancing dynamic adaptation capabilities.

Description

Technical Field

[0001] The present application relates to the field of computer system security technology, and in particular to a basic input and output system security protection method, device, equipment and medium. Background Art

[0002] In the field of computer system security, the Basic Input Output System (BIOS), as the first firmware to run at system startup, assumes the critical responsibility of initializing hardware devices and loading the operating system. Its security plays a fundamental and decisive role in the safe and stable operation of the entire system, serving as a crucial line of defense for ensuring trusted system startup and defending against malicious attacks. Traditionally, manufacturers have established a firmware integrity verification mechanism by applying a one-time signature during the BIOS compilation phase.

[0003] However, as the network security environment becomes increasingly complex and various new attack methods continue to emerge, traditional static signature schemes have gradually exposed obvious flaws. Due to the lack of sufficient perfection and flexibility in the design of the one-time signature mechanism, it is difficult to dynamically adjust it to different application scenarios, hardware configurations, or security requirements. As a result, the signature verification protection capabilities are insufficient in the face of diverse attacks, and it is unable to effectively cope with complex network security environments and new attack methods. When the BIOS firmware needs to be updated, the traditional signature verification scheme needs to rely on the manufacturer to regenerate the signature and push it. The user-side signature verification logic cannot autonomously adapt to the updated signature rules. If there are delays or compatibility issues in the signature verification during the update process, the legitimate firmware may be mistakenly judged as tampered, or maliciously tampered firmware may bypass verification through outdated signature verification rules, affecting system stability and security. Summary of the Invention

[0004] The present application provides a basic input and output system security protection method, device, equipment and medium to at least solve the problems that the related technical signature mechanism lacks dynamic adaptation capability and static verification cannot cope with the dynamic firmware update scenario.

[0005] The present application provides a basic input / output system security protection method, comprising: extracting a firmware capsule file from a basic input / output system image file; the firmware capsule file includes a signature file and a first signature, and the signature file includes a core code file and a second signature; performing signature verification on the first signature according to the content of the signature file; if the first signature verification passes, performing signature verification on the second signature according to the content of the core code file; if the second signature verification passes, determining that the image file has not been tampered with.

[0006] The present application also provides a basic input and output system security protection device, comprising:

[0007] A file extraction module is used to extract a firmware capsule file from a basic input and output system image file; the firmware capsule file includes a signature file and a first signature, and the signature file includes a core code file and a second signature;

[0008] A first signature verification module, configured to verify the first signature based on the content of the signature file;

[0009] The second signature verification module is used to verify the second signature according to the content of the core code file if the first signature verification passes; if the second signature verification passes, it is determined that the image file has not been tampered with.

[0010] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the above-mentioned basic input and output system security protection method when executing the computer program.

[0011] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the basic input and output system security protection method are implemented.

[0012] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned basic input and output system security protection method when executed by a processor.

[0013] This application extracts the firmware capsule file from the basic input and output system image file to achieve independent verification of the update content, so that the system can seamlessly adapt to dynamic firmware updates and avoid compatibility issues caused by changes in signature rules; the firmware capsule file contains a first signature and a signature file, and the signature file contains a core code file and a second signature. This layered design allows dynamic adjustment of the verification strategy according to security requirements at different levels. The first layer verifies the integrity of the signature file to ensure that the firmware capsule file has not been tampered with; the second layer verifies the integrity of the core code file to ensure that the core functions have not been tampered with, thereby enhancing the dynamic adaptation capability. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0015] Figure 1 A flowchart of a basic input / output system security protection method provided in an embodiment of the present application;

[0016] Figure 2AA flowchart of a basic input / output system security protection method in the signature phase provided in an embodiment of the present application;

[0017] Figure 2B A flowchart of another basic input / output system security protection method in the signature phase provided in an embodiment of the present application;

[0018] Figure 3 A schematic diagram of the structure of a basic input / output system security protection device provided in an embodiment of the present application;

[0019] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0020] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0021] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0022] In order to more clearly illustrate the embodiments of the present application, the following briefly introduces the technical terms used in the embodiments:

[0023] The Basic Input Output System (BIOS) is a firmware program embedded on the computer motherboard. It is the low-level software that runs first during the computer startup process. It is responsible for initializing and detecting system hardware (such as the processor, memory, hard disk, graphics card, etc.), establishing an interface between the hardware and the operating system, and loading the operating system kernel from the storage device into the memory. It provides the most basic hardware management and service support for the normal startup and operation of the computer system, and is the key bridge connecting computer hardware and the operating system.

[0024] Basic Input / Output System (BIOS) Read-Only Memory (ROM) refers to the read-only memory that stores the BIOS program.

[0025] Boot Guard is a boot integrity verification mechanism embedded in Intel processor chipsets. It establishes a hardware-level root of trust for the platform, preventing unauthorized firmware loading and ensuring platform boot security. During motherboard production, the original equipment manufacturer (OEM) permanently burns the public key into the platform controller hub and configures the BIOS platform module (BPM) to specify the firmware signature areas and verification method.

[0026] Secure flash is a technology that ensures the security of firmware updates for BIOS, baseboard management controllers, and other devices. During the firmware update process, it ensures that the new firmware image meets the signature validity requirement, preventing malicious firmware from being flashed into the system, thereby ensuring the security and integrity of the system firmware. During the firmware update, signature verification is performed on the firmware image to be written to the flash memory. Only legitimate firmware that passes verification can be successfully written and updated. This prevents attackers from exploiting firmware update vulnerabilities to insert malicious code and launch attacks on the system.

[0027] The encryption / decryption tool (Cryptocon) is used to encrypt files or verify their signatures.

[0028] OpenSSL is an open-source cryptography tool used for key generation, hash calculations, and digital signatures. In the BIOS signing process, it is often used to generate key pairs, calculate hash values, and create certificates (such as .p12 files).

[0029] OpenSSL's key operation tool (OpenSSLpkeyutl) is used for signing, verifying, encrypting, and decrypting.

[0030] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0031] In combination with the specific application environment architecture or specific hardware architecture on which the execution of the basic input and output system security protection method depends, the specific application environment architecture or specific hardware architecture is described here.

[0032] The execution of the basic input and output system security protection method depends on the specific hardware architecture including: central processing unit (CPU) that supports boot protection and secure flash memory functions, chipset, BIOS ROM, etc.

[0033] The CPU, as the computing core of a computer, plays a key role in the signature verification process. Whether verifying the first signature or verifying the second signature against the core code file, the CPU is required to perform the relevant computing tasks. The CPU's performance and instruction set support affect the efficiency and speed of signature verification.

[0034] The chipset coordinates communication and data transfer between the computer's various hardware components. Interactions between the BIOS and other hardware devices are all handled by the chipset. It must support the normal startup and operation of the BIOS and ensure data integrity and security during data transmission.

[0035] The BIOS ROM stores the BIOS image file and is the source of the entire security protection method. It is typically a non-volatile memory, such as flash memory, that can retain the BIOS program and related data even after a power outage. Extracting the firmware capsule file from the BIOS ROM requires reliable data storage and retrieval capabilities to ensure the accuracy of the extracted data.

[0036] The embodiment of the present application provides a basic input and output system security protection method, and the method is described in detail in conjunction with the execution process of the basic input and output system security protection method. Figure 1 As shown, the method includes the following steps S101 to S104:

[0037] S101: Extracting a firmware capsule file from a basic input / output system image file.

[0038] The firmware capsule file, also known as the firmware encapsulation file (FWCAPSULE_FILE), is used for firmware security management and includes a signature file and a first signature (fwcap_serialized.hash.bin). The signature file includes a core code file (inputfile2.bin) and a second signature. The first signature can be generated by the user using a private key. The private key includes a security public key (i.e., the first public key SecPublicKey) and a security private key (i.e., the first private key SecPrivateKey) to meet specific user requirements. The second signature can be generated using the manufacturer's root trust key to ensure the trustworthiness of the core code file. The core code file inputfile2.bin corresponds to the BIOS code area of ​​the basic input / output system and includes code executed at system startup, including machine code such as the boot self-test, hardware initialization, and interrupt service routines.

[0039] By separating the signature file and the core code file into two layers, and applying the primary and secondary signatures separately, a cascaded verification mechanism is formed. This design allows for dynamic adjustment of verification strategies for different hardware configurations or application scenarios, enhancing dynamic adaptability. The primary signature is generated by the user using a private key (including a security public / private key pair). This supports self-definition of signature generation rules, and personalized verification is achieved by comparing the user's public key during signature verification. A dual-key system, combining the user's key with the manufacturer's root trust key, reduces the risk of a single key leak. Even if the manufacturer's root trust key is compromised, an attacker would still need to obtain the user's private key to tamper with the secondary signature of the core code file. This dual-signature mechanism makes the system more resilient to threats such as supply chain attacks and firmware tampering, shifting the credibility of the signature verification process from a single-vendor trust model to a multi-party mutual trust model.

[0040] In some embodiments, the signature file includes a first signature file (Bpm.sig) and a second signature file (Km.sig). The first signature file contains the BPM's digital signature, used to verify the integrity of the BIOS platform module; the second signature file contains the key manifest (KM)'s digital signature, used to verify the integrity of the key manifest. It is understood that the second signature includes both the BPM's digital signature and the key manifest's digital signature.

[0041] The above embodiment uses the BPM's digital signature and the KM's digital signature to form a cascaded verification of the hardware trust chain and the key trust chain, achieving decoupled verification between the hardware platform layer and the key management layer. Even if an attacker breaks through the BPM's digital signature, they still need to crack the second layer, the KM signature, to obtain the legitimate key, significantly increasing the cost of the attack.

[0042] S102: Verify the first signature according to the content of the signature file.

[0043] In some embodiments, the signature file can be a signature file (fwcap_serialized.p1.der) in the Public-Key Cryptography Standards #1 (PKCS#1) format using Distinguished Encoding Rules (DER). Signature files based on the PKCS#1 standard format contain complete metadata (such as the signature algorithm and certificate chain), making the signature verification process auditable. During signature verification of a first signature based on the contents of the signature file, the first public key is first obtained. A third signature is then generated based on the first public key and the contents of the signature file. The third signature is then compared with the first signature for identity. A third signature is then generated based on the first public key (such as SecPublicKey) and the contents of the signature file (fwcap_serialized.p1.der). The third signature is then compared with the first signature for identity. If they are identical, the first signature verification succeeds; if they are different, the first signature verification fails.

[0044] Optionally, the first signature can be verified using the Cryptocon tool. This verification of the first signature uses a deterministic algorithm that generates a third signature using the first public key and the signed file content, establishing a unique mapping between the file content and the signature. Even if an attacker tampers with a small amount of data in the signed file, such as the timestamp or version number, the generated third signature will be inconsistent with the original first signature, effectively detecting the tampering and improving the accuracy of tamper detection. Using the first public key, SecPublicKey, as the basis for verification avoids the security risks associated with decentralized key management in traditional solutions.

[0045] S103: If the first signature verification passes, perform signature verification on the second signature according to the content of the core code file.

[0046] In some embodiments, during the signature verification process of the second signature based on the contents of the core code file, a second public key is first obtained. The second public key includes the BPM's public key BpmPublicKey and the KM's public key KmPublicKey. A fourth signature is then generated based on the second public key and the contents of the core code file. Specifically, the first signature file Bpm.sig is signature-verified based on the BPM's public key BpmPublicKey, and the second signature file Km.sig is signature-verified based on the key list's public key KmPublicKey to generate a fourth signature. The fourth signature is then compared with the second signature to determine if they are identical.

[0047] The aforementioned verification of the second signature introduces a second public key (including the BPM public key BpmPublicKey and the KM public key KmPublicKey) to verify the first signature file Bpm.sig and the second signature file Km.sig separately and generate a fourth signature. This is then compared with the second signature, forming a layered verification and multi-public key collaborative verification logic, which solves the problem of rigid verification strategies in traditional solutions. By separating the verification of the BPM module from the key list (KM), verification rules can be independently adjusted for different components (such as hardware platform modules and key systems). Secondly, users can participate in the verification process through their own managed second public key, achieving customized trusted verification of the BIOS platform module. This breaks the passive situation in traditional solutions where users rely entirely on the manufacturer's public key and meets differentiated security needs. At the same time, the multi-public key system reduces the risk of single key leakage. Even if BpmPublicKey encounters a security issue, KmPublicKey can still ensure the validity of the key list verification.

[0048] S104: If the second signature verification passes, determine that the image file has not been tampered with.

[0049] The above-mentioned secondary signature verification enables BIOS security protection to maintain the manufacturer's basic verification of core components while being compatible with the user's personalized security policy.

[0050] In summary, the embodiment of the present application provides a security protection for a basic input and output system, which belongs to the signature verification stage. After the signature verification is completed, the system can start normally, and only signed legal firmware is loaded, thereby ensuring the feasibility of system startup. Specifically, by extracting the firmware capsule file, independent verification of the update content is achieved, so that the system can seamlessly adapt to dynamic firmware updates and avoid compatibility issues caused by changes in signature rules. The firmware capsule file contains a first signature and a signature file. The signature file contains a core code file and a second signature. This layered design allows for dynamic adjustment of verification strategies based on security requirements at different levels. The first layer verifies the integrity of the signature file to ensure that the firmware capsule file has not been tampered with; the second layer verifies the integrity of the core code file to ensure that the core functions have not been tampered with, thereby enhancing dynamic adaptation capabilities.

[0051] This application provides a basic input and output system security protection method belonging to the signature stage, such as Figure 2A As shown, the method includes the following steps S201 to S204:

[0052] S201: extracting metadata files, core code files, and extension files from an original image file of a basic input / output system.

[0053] In some embodiments, the BIOS ROM is separated into different areas, including a BIOS meta data area, a BIOS core code area, and a reserved area.

[0054] Among them, the BIOS meta data area includes basic BIOS information (such as version number, manufacturer, compilation date), checksums, module descriptions and other non-code data; the BIOS code area includes the code executed when the system starts, including machine code such as startup self-test, hardware initialization, and interrupt service routines; the reserved area is unused or manufacturer-defined storage space for future function expansion (such as adding new hardware support) or storing temporary data (such as intermediate variables during the startup process).

[0055] Accordingly, command-line tools (such as CutRom.exe) extract the metadata file (inputfile1.bin), core code file (inputfile2.bin), and extension file (inputfile3.bin) from the original BIOS image file based on a preset starting address and length. When only extended functionality needs to be updated, only the extension file (inputfile3.bin) needs to be extracted and verified, without re-signing the entire BIOS image. This changes the inefficient model of traditional static signatures, which require verification of the entire code.

[0056] The above-mentioned region separation and file extraction enable more flexible signing and verification operations.

[0057] S202: Perform a startup protection signature on the core code file to generate a signature file.

[0058] The signature file includes a first signature file and a second signature file.

[0059] In some embodiments, when performing a boot guard signature (btg resign), the boot guard signature interlock support (BOOT_GUARD_SIGNING_INTERLOCK_SUPPORT) function is first turned on, and the relevant interfaces of this function are enabled, realizing the transition from a fixed signature at compile time to a dynamically generated signature at runtime; and the core code file inputfile2.bin is compiled to ensure the ability to support the boot guard signature.

[0060] Next, obtain the BPM's public key, BpmPublicKey, and the KM's public key, KmPublicKey. Specifically, save the public key of the BPM's secret key index to the corresponding file, and save the public key of the KM's secret key index to the corresponding file. This completes the preparation of the public key file for signature verification. By separating the BPM and KM public / private key pairs, users can independently manage the BPM's public key, BpmPublicKey, and the corresponding second private key, BpmPrivateKey, thereby embedding local security policies, such as hardware binding and timestamp verification, into the signature generation process.

[0061] Then, the signature file generation process includes: encrypting and signing the core code file according to the BPM's public key BpmPublicKey and the corresponding second private key BpmPrivateKey to obtain the first signature file Bpm.sig, and encrypting and signing the core code file according to the KM's public key KmPublicKey and the manufacturer's signature platform interface to obtain the second signature file.

[0062] The above embodiment enables the protection signature interlocking mechanism and the hierarchical key system, thereby giving users the ability to customize security policies while maintaining the manufacturer's control over the basic platform.

[0063] In some embodiments, the process of generating the first signature file includes the following steps S301 to S303:

[0064] S301: Perform a signature regeneration operation on a core code file according to the BPM public key BpmPublicKey to generate a first intermediate file.

[0065] Specifically, execute the signature regeneration (BootGuardResign.bat) script, call the tool (BpmKmGen) provided by the manufacturer, sign the core code file according to the BPM public key BpmPublicKey, and generate a BPM file that does not contain a signature element, that is, the first intermediate file (BpmWithoutSigElement.bin).

[0066] S302: Calculate the hash value of the first intermediate file and encode it to obtain a second verification file.

[0067] Specifically, the open source cryptography tool (OpenSSL) is used to perform a Secure Hash Algorithm 256-bit (SHA-256) hash operation to calculate the hash value of the first intermediate file BpmWithoutSigElement.bin, generate an unsigned BPM hash value file in binary format, and then encode the unsigned BPM hash value file in binary format according to an encoding method based on 64 printable characters to represent binary data (i.e., Base64 encoding) to generate a second verification file (BpmWithoutSigElement.hash.base64).

[0068] OpenSSL is used here for SHA-256 hashing and Base64 encoding to ensure the standardization and cross-platform compatibility of the signature generation process, so that BIOS components from different manufacturers can adopt a unified verification standard, reducing system integration costs.

[0069] S303: Encrypt and sign the second verification file based on the second private key to generate a first signature file.

[0070] The second private key BpmPrivateKey can be managed by the user independently, such as being stored in a smart card, so that enterprises or advanced users can embed local security policies into the signature generation process.

[0071] Specifically, the second verification file BpmWithoutSigElement.hash.base64 is encrypted and signed based on the second private key BpmPrivateKey to generate the first signature file Bpm.sig.

[0072] Optionally, save the first signature file Bpm.sig to the same directory where the signature regenerates the BootGuardResign.bat script.

[0073] The above embodiment dynamically generates the first intermediate file by executing the signature regeneration script, breaking through the static and fixed signature generation mode, allowing the system to recalculate the hash value of the core code file and generate a new signature each time it is started or updated. The second verification file is generated by SHA-256 hash operation and Base64 encoding, and then encrypted and signed using the second private key, forming a triple protection of content hashing, encoding verification and private key encryption. This design requires attackers to break through the three layers of defense of hash calculation, encoding rules and private key encryption at the same time to forge a legal signature, which significantly improves the anti-tampering ability. Through layered calculation and encrypted signatures, while maintaining the manufacturer's control over the basic platform, users are given the ability to customize security policies.

[0074] In some embodiments, the process of generating the second signature file includes the following steps S401 to S403:

[0075] S401: Perform a signature regeneration operation on the core code file according to the public key in the key list to generate a second intermediate file.

[0076] Specifically, execute the signature regeneration BootGuardResign.bat script, call the BpmKmGen tool, sign the core code file inputfile2.bin according to the public key KmPublicKey of the key list, and generate a key list file that does not contain a signature element, that is, the second intermediate file (KmWithoutSigElement.bin).

[0077] S402: Calculate the hash value of the second intermediate file and encode it to generate a third verification file.

[0078] Specifically, an open-source cryptography tool (OpenSSL) is used to perform a SHA-256 hash operation to calculate the hash value of the second intermediate file, KmWithoutSigElement.bin, generating a binary unsigned Km hash value file. This binary unsigned Km hash value file is then Base64-encoded to generate the third verification file (KmWithoutSigElement.hash.base64).

[0079] S403: Call the manufacturer's signature platform interface to encrypt and sign the hash summary of the third verification file to generate a second signature file.

[0080] Specifically, the manufacturer's signature platform interface is called to encrypt and sign the third verification file KmWithoutSigElement.hash.base64 using a digest method to generate a second signature file (Km.sig).

[0081] Optionally, save the second signature file (Km.sig) to the same directory as the signature regeneration (BootGuardResign.bat) script.

[0082] The above embodiment invokes the BpmKmGen tool by executing a signature regeneration script, generating a second intermediate file based on KmPublicKey. This file is then hashed and Base64-encoded to generate a third verification file. Finally, the second signature file is encrypted and signed through the vendor signature platform interface, forming a complete chain of key list-driven, standardized hashing, and vendor interface encryption. This design overcomes the limitations of traditional static signatures, which are limited by their one-time fixation. The signature regeneration operation supports dynamic signature adaptation during core code file updates. Secondly, the layered signature logic separates key list verification from the core code file signature, allowing the vendor to independently manage the basic security verification of the core code file through the key list's public key system. This complements the user-managed first signature file, ensuring the vendor's control over underlying security while leaving room for users to customize security policies. This addresses the limitation of traditional solutions where a single signature entity cannot meet diverse security needs. Furthermore, the use of a standardized hash algorithm and encoding format ensures consistency and cross-platform compatibility in the signature generation process, avoiding the closed verification logic problem caused by vendor-proprietary formats in traditional static signatures.

[0083] After the boot protection signature is completed, the platform is started to prevent unauthorized BIOS loading and ensure the secure boot of the platform.

[0084] In some embodiments, when the signature regeneration script detects the first signature file and the second signature file, a startup protection signature log is saved to record the signature operation, error information, verification results, etc.

[0085] Traditional static signature schemes lack detailed records of the signing process. When verification fails or firmware anomalies occur, it's difficult to pinpoint the root cause, such as signature generation errors, file tampering, or key mismatches. Furthermore, the timing, subject, and results of the signature operation cannot be traced, resulting in inefficient security incident response and auditing. However, the above-described embodiment saves a boot protection signature log when the first and second signature files are detected, detailing the signature operation steps, error messages (such as hash mismatches and key expiration), and verification results. This allows for refined tracking of the entire signature process. When verification fails, the log can quickly identify whether the issue lies with the first signature file (user-side) or the second signature file (manufacturer-side), shortening troubleshooting time and improving security incident response efficiency and system compliance. Furthermore, logging can proactively detect potential signature anomalies, providing data support for proactive defense and further strengthening the integrity and reliability of BIOS security protection.

[0086] S203: Perform a secure flash signature on the core code file to generate a firmware capsule file.

[0087] In some embodiments, during secure flash resign, the process of generating a firmware capsule file includes the following steps S501 to S503:

[0088] S501: Convert the format of the core code file into which the first public key is inserted to obtain a serialized file.

[0089] In some embodiments, the first public key SecPublicKey is first inserted into the core code file inputfile2.bin, and then a format conversion operation is performed to generate a serialized file (fwcap_serialized). Alternatively, the first signature file and the second signature file inserted with the first public key are format converted to obtain a serialized file, and similar subsequent steps are performed to generate a firmware capsule file.

[0090] S502: Calculate a hash value of the serialized file, and encode the hash value of the serialized file to obtain a first verification file.

[0091] Specifically, an encryption / decryption tool (Cryptocon) is used to calculate a hash value of the serialized file fwcap_serialized to generate a hash value file of the serialized file, namely, a first verification file (fwcap_serialized.hash.bin).

[0092] S503: Encrypt and sign the first verification file according to the first private key corresponding to the first public key to generate a firmware capsule file.

[0093] Specifically, the OpenSSL key operation tool (OpenSSLpkeyutl) is used to encrypt and sign the first verification file fwcap_serialized.hash.bin using the first private key SecPrivateKey corresponding to the first public key SecPublicKey, generating a PKCS#1 formatted signature file (fwcap_serialized.p1) containing the private key. The encryption / decryption tool Cryptocon is then used to convert fwcap_serialized.p1 into a DER-encoded PKCS#1 signature file (fwcap_serialized.p1.der). The encryption / decryption tool Cryptocon is further used to sign fwcap_serialized.p1.der using the first public key SecPublicKey to generate the firmware capsule file (FWCAPSULE_FILE).

[0094] The above steps bind the public key to the firmware content by inserting the first public key into the core code file and converting it into a serialized file (fwcap_serialized). This ensures that the public key required for verification can be directly obtained from the serialized file during signature verification. The Cryptocon tool is used to calculate the hash value and generate the first verification file. The OpenSSL tool is then used to generate a PKCS#1-formatted signature file based on the first private key and convert it to DER encoding, ensuring the standardization and cross-platform compatibility of the signature format. Furthermore, the serialization process allows firmware updates to only require the regeneration of the firmware capsule file, eliminating the need to adjust the overall signature structure, making it suitable for dynamic update scenarios. This improves signature verification compatibility and increases the efficiency of signature generation for firmware updates. Furthermore, the binding of the public key to the firmware and the standardized signature format make the signature source traceable and the verification logic transparent, reducing the detection response time for firmware tampering to seconds and significantly enhancing the reliability and scalability of BIOS security protection.

[0095] S204: After the secure flash signature is completed, the firmware capsule file, the metadata file, and the extension file are merged to obtain a basic input and output system image file.

[0096] In some embodiments, a specific command line operation (e.g., the copy / b command) is used to merge the firmware capsule file, metadata file, and extension file into a BIOS image file (merged.bin) in a specified order. The copy / b command sequentially merges the firmware capsule file (including the dynamic signature), metadata file, and extension file, thereby achieving modular assembly of the BIOS image.

[0097] In some embodiments, the method further includes: finding the manufacturer public key hash value and its corresponding keyword from the boot protection signature log, and then replacing the boot policy key hash value and its corresponding keyword in the image file (merged.bin) with the manufacturer public key hash value (OEM public key hash) and its corresponding keyword.

[0098] By extracting the manufacturer's public key hash from the boot protection signature log and replacing the boot policy key hash in the image file (merged.bin), this approach dynamically updates the authentication basis during BIOS boot. This design allows the system to adapt to new security policies or key rotation requirements by updating the manufacturer's public key hash in the log without modifying the underlying code. This ensures the effective implementation of the boot protection feature during system boot, allowing the system to boot according to the expected process and only load signed, legitimate firmware, thus ensuring system boot feasibility.

[0099] The above-mentioned signing stage enhances the protection capability of the firmware by performing secondary signing operations of the boot protection signature and the secure flash signature, ensuring the integrity and reliability of the BIOS. This effectively prevents the loading and execution of illegal firmware during the system startup process. Even if an attacker can bypass one layer of signature verification, they still need to face the challenge of another layer of signature, reducing the risk of firmware tampering and improving system security.

[0100] For example, Figure 2B As shown, the process first extracts the metadata file, the core code file inputfile2.bin, and the extension file from the original BIOS image file. Then, a second public key, including the BPM's public keys BpmPublicKey and KmPrivateKey, is implanted into the core code file inputfile2.bin. The signature regeneration script BootGuardResign.bat is called to attempt a re-signature. If this fails, the process terminates. If successful, the process proceeds to the next step, generating the first intermediate file BpmWithoutSigElement.bin without a signature element for subsequent hash and signature verification. Based on this first intermediate file, the first signature file Bpm.sig is generated to verify the file's legitimacy. This process terminates if this fails, and continues if this succeeds. Similar logic is repeated to generate the second intermediate file KmWithoutSigElement.bin without a signature element. Based on this second intermediate file, the second signature file Km.sig is generated, ensuring security through layered verification. After generating the second signature file, Km.sig, the boot protection signing (btg resign) and secure flash signing (secure resign) are performed again. If all are successful, all signed files are merged to output a usable BIOS image. Failure at any stage terminates the process. This process ensures the legality of each signing and embedding step, preventing invalid or illegal signatures from being passed to subsequent steps. Multiple signatures and intermediate file generation create a multi-layered security verification process, ensuring that the re-signed BIOS boots normally and complies with security regulations. A strict verification branch ensures the legality of the BIOS signature, preventing device startup anomalies or security risks caused by signature issues.

[0101] Steps S201-S204 extract metadata, core code, and extension files from the original image, separating the core code and performing layered signing. First, a boot protection signature is performed to verify code integrity. This is hardware-level static protection, addressing the lack of dynamic flexibility in signature mechanisms in traditional solutions. After the boot protection signature is successful, a secure flash signature is performed to generate a firmware capsule file to verify code legitimacy, supplementing dynamic protection. Secondly, the separate extraction and processing of the core code file allows users to intervene in the signing process, breaking through the limitations of traditional vendor-only one-time signatures during the compilation phase and meeting customized policy requirements in different scenarios. Finally, layered signing utilizes hierarchical key management: the boot protection signature uses the vendor's root trusted key bound to the hardware, while the secure flash signature allows users to manage their own keys. This isolation reduces the risk of key leakage and strengthens the privacy of key management. Finally, the signed firmware capsule file is merged with the metadata and extension files to form the target image. Through multi-dimensional protection of integrity and legitimacy, a user-interactive modular process, and a hierarchical key system, this effectively addresses the technical issues of the traditional signature mechanism's lack of flexibility, the inability to customize policies, and the lack of key management privacy.

[0102] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0103] The embodiment of the present application also provides a basic input and output system security protection device, the device is as follows Figure 3 As shown, including:

[0104] The file extraction module 301 is used to extract a firmware capsule file from the image file of the basic input and output system; the firmware capsule file includes a signature file and a first signature, and the signature file includes a core code file and a second signature;

[0105] A first signature verification module 302 is used to verify the first signature according to the content of the signature file;

[0106] The second signature verification module 303 is used to verify the second signature according to the content of the core code file if the first signature verification passes; if the second signature verification passes, determine that the image file has not been tampered with.

[0107] As an optional implementation provided in an embodiment of the present application, the first signature verification module 302 is specifically used to: obtain a first public key; generate a third signature based on the first public key and the content of the signature file; and compare whether the third signature is the same as the first signature.

[0108] As an optional implementation provided in an embodiment of the present application, the device also includes a signature module, which is used to: convert the format of the core code file inserted with the first public key to obtain a serialized file; calculate the hash value of the serialized file, and encode the hash value of the serialized file to obtain a first verification file; and encrypt and sign the first verification file according to the first private key corresponding to the first public key to generate a firmware capsule file.

[0109] As an optional implementation provided in an embodiment of the present application, the second signature verification module 303 is specifically used to: obtain a second public key; the second public key includes the public key of the basic input / output system platform module and the public key of the key list; generate a fourth signature based on the second public key and the content of the core code file, the fourth signature includes the signature of the basic input / output system platform module and the signature of the key list; compare whether the fourth signature is the same as the second signature.

[0110] As an optional implementation method provided in an embodiment of the present application, the signature file includes a first signature file and a second signature file; the device also includes a signature module, which is used to: encrypt and sign the core code file according to the public key of the basic input and output system platform module and the corresponding second private key to obtain the first signature file; encrypt and sign the core code file according to the public key of the key list and the manufacturer signature platform interface to obtain the second signature file.

[0111] As an optional implementation method provided in an embodiment of the present application, the signature module encrypts and signs the core code file according to the public key of the basic input / output system platform module and the corresponding second private key to obtain a first signature file, and is specifically used to: perform a signature regeneration operation on the core code file according to the public key of the basic input / output system platform module to generate a first intermediate file; calculate the hash value of the first intermediate file, and encode the hash value of the first intermediate file to obtain a second verification file; and encrypt and sign the second verification file based on the second private key to obtain a first signature file.

[0112] As an optional implementation method provided in an embodiment of the present application, the signature module encrypts and signs the core code according to the public key of the key list to obtain a second signature file, and is specifically used to: perform a signature regeneration operation on the core code file according to the public key of the key list to generate a second intermediate file; calculate the hash value of the second intermediate file, and encode the hash value of the second intermediate file to obtain a third verification file; call the manufacturer's signature platform interface to encrypt and sign the hash summary of the third verification file to obtain a second signature file.

[0113] For the description of the features in the embodiments corresponding to the basic input and output system security protection device, please refer to the relevant description of the embodiments corresponding to the basic input and output system security protection method, which will not be repeated here.

[0114] The embodiment of the present application also provides an electronic device, such as Figure 4 As shown, it includes a memory 401 and a processor 402, wherein the memory 401 stores a computer program, and the processor 402 is configured to run the computer program to execute the steps in any of the above-mentioned basic input and output system security protection method embodiments.

[0115] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned basic input / output system security protection method embodiments when running.

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

[0117] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned basic input and output system security protection method embodiments are implemented.

[0118] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the steps of any of the above-mentioned basic input and output system security protection method embodiments.

[0119] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0120] The above is a detailed introduction to the basic input and output system security protection method, device, equipment and medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core ideas of the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A basic input and output system security protection method, characterized in that: include: Extract the firmware capsule file from the BIOS image file; The firmware capsule file includes a signature file and a first signature, the signature file includes a core code file and a second signature; wherein the first signature is generated by the user using a first public key and a first private key, and the second signature is generated by the manufacturer's root information key; Performing signature verification on the first signature according to the content of the signature file; If the first signature verification passes, performing signature verification on the second signature according to the content of the core code file; If the second signature verification passes, determining that the image file has not been tampered with; The performing signature verification on the first signature according to the content of the signature file includes: obtaining a first public key; generating a third signature according to the first public key and the content of the signature file; and comparing the third signature with the first signature to determine whether they are identical; The signature verification of the second signature based on the content of the core code file includes: obtaining a second public key, where the second public key includes the public key of the basic input and output system platform module and the public key of the key list; generating a fourth signature based on the second public key and the content of the core code file; and comparing the fourth signature with the second signature to determine whether they are the same.

2. The method according to claim 1, characterized in that The process of generating the firmware capsule file includes: Performing format conversion on the core code file into which the first public key is inserted to obtain a serialized file; Calculating a hash value of the serialized file, and encoding the hash value of the serialized file to obtain a first verification file; The first verification file is encrypted and signed according to a first private key corresponding to the first public key to generate the firmware capsule file.

3. The method according to claim 1, characterized in that The signature file includes a first signature file and a second signature file; The signature file generation process includes: Performing encryption and signing on the core code file according to the public key of the basic input / output system platform module and the corresponding second private key to obtain the first signature file; The core code file is encrypted and signed according to the public key of the key list and the manufacturer's signature platform interface to obtain the second signature file.

4. The method according to claim 3, characterized in that The step of encrypting and signing the core code file according to the public key of the basic input / output system platform module and the corresponding second private key to obtain the first signature file includes: Performing a signature regeneration operation on the core code file according to the public key of the basic input / output system platform module to generate a first intermediate file; Calculating a hash value of the first intermediate file, and encoding the hash value of the first intermediate file to obtain a second verification file; The second verification file is encrypted and signed based on the second private key to obtain the first signature file.

5. The method according to claim 3, characterized in that The step of encrypting and signing the core code according to the public key in the key list to obtain the second signature file includes: Perform a signature regeneration operation on the core code file according to the public key of the key list to generate a second intermediate file; Calculating a hash value of the second intermediate file, and encoding the hash value of the second intermediate file to obtain a third verification file; The manufacturer's signature platform interface is called to encrypt and sign the hash summary of the third verification file to obtain the second signature file.

6. A basic input and output system security protection device, characterized in that: include: A file extraction module, used for extracting a firmware capsule file from a basic input and output system image file; The firmware capsule file includes a signature file and a first signature, the signature file includes a core code file and a second signature; wherein the first signature is generated by the user using a first public key and a first private key, and the second signature is generated by the manufacturer's root information key; A first signature verification module, configured to perform signature verification on the first signature according to the content of the signature file; a second signature verification module, configured to, if the first signature verification passes, perform signature verification on the second signature according to the content of the core code file; and, if the second signature verification passes, determine that the image file has not been tampered with; The first signature verification module is specifically configured to obtain a first public key; generate a third signature based on the first public key and the content of the signature file; and compare the third signature with the first signature to determine whether they are identical. The second signature verification module is specifically used to obtain a second public key when the first signature verification passes, the second public key including the public key of the basic input and output system platform module and the public key of the key list; generate a fourth signature based on the second public key and the content of the core code file; and compare the fourth signature with the second signature to see whether they are the same.

7. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the basic input / output system security protection method according to any one of claims 1 to 5 when executing the computer program.

8. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the basic input / output system security protection method according to any one of claims 1 to 5 are implemented.

Images