Firmware security starting method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of servers, and discloses a firmware security starting method and device, computer equipment and a storage medium, and the method comprises the following steps: when a server is started, obtaining a firmware package from a firmware storage area; the firmware package is analyzed, firmware and an authentication block are obtained, the authentication block comprises a plurality of public keys and a plurality of digital signatures corresponding to the firmware, and the digital signatures are generated based on the firmware through a plurality of manufacturers generating the server by utilizing root keys of the manufacturers; obtaining any to-be-verified public key which is not verified in the plurality of public keys, and verifying the to-be-verified public key; if the to-be-verified public key passes verification, verifying the plurality of digital signatures by using the to-be-verified public key; and if the public key to be verified passes verification of any digital signature in the plurality of digital signatures, determining that the firmware is safe, and starting the firmware. According to the invention, on the basis of ensuring the security of the firmware, the compatibility of the firmware is enhanced.

Description

Technical Field

[0001] The present invention relates to the technical field of servers, and in particular to a firmware secure boot method, device, computer equipment, storage medium and program product. Background Art

[0002] At present, enterprises that purchase a large number of servers will choose multiple suppliers to supply servers in order to reduce costs and ensure a stable supply chain. In this case, when multiple suppliers are selected for server supply, the Joint Design Manufacture (JDM) model is often used for customized development of server products. In this model, one manufacturer takes the lead in designing server products, and multiple manufacturers copy and produce server products.

[0003] With the development of information technology, computer system security has received more attention, and secure boot has become an important technology to protect the system boot process from malware. In related technologies, the secure boot solution only supports the root key of one manufacturer as the basis for secure booting of server firmware.

[0004] In the JDM mode, multiple manufacturers use their own root keys as the basis for secure booting of server firmware, resulting in the same server products and firmware generated by multiple manufacturers, but different secure boot firmware digitally signed with the root key. The compatibility of firmware secure boot is poor, making firmware maintenance difficult. Summary of the invention

[0005] In view of this, the present invention provides a firmware secure boot method, apparatus, computer equipment and storage medium to solve the problem that the compatibility of firmware secure boot is poor in JDM mode, which leads to difficulty in firmware maintenance.

[0006] In a first aspect, the present invention provides a firmware secure boot method, the method comprising:

[0007] When the server starts, the firmware package is obtained from the firmware storage area;

[0008] Parsing the firmware package to obtain firmware and an authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers generating the server using their own root keys;

[0009] Obtain any unverified public key to be verified among the multiple public keys, and verify the public key to be verified;

[0010] If the public key to be verified is verified successfully, the multiple digital signatures are verified using the public key to be verified;

[0011] If the public key to be verified successfully verifies any of the multiple digital signatures, the firmware is determined to be secure and the firmware is started.

[0012] The firmware secure boot method provided in this embodiment parses the firmware package to obtain the firmware and the authentication block, which includes multiple public keys and multiple digital signatures corresponding to the firmware. The multiple digital signatures are generated based on the firmware by multiple manufacturers of the generation server using their own root keys. When any one of the multiple public keys verifies any one of the multiple digital signatures, the firmware is determined to be secure and the firmware is booted. The secure boot of the firmware is made compatible with the digital signatures generated by the firmware based on the different root keys of each manufacturer, which enhances the compatibility and usability of the system while ensuring the security of the firmware, and makes it easy to maintain the firmware, reducing the complexity of system integration.

[0013] In an optional embodiment, the method further includes:

[0014] If the public key to be verified fails to verify any of the multiple digital signatures, the firmware is determined to be abnormal, and the firmware is refused to be started or enter the safe recovery mode.

[0015] The firmware secure boot method provided in this embodiment determines that the firmware is abnormal when the public key to be verified fails to verify any of the multiple digital signatures. The system immediately refuses to boot the firmware or switches to a secure recovery mode to prevent the damaged firmware from being executed, reduce potential damage, and facilitate rapid recovery measures.

[0016] In an optional implementation manner, verifying the public key to be verified includes:

[0017] Reading a root certificate from a root certificate storage area and obtaining a target public key from the root certificate;

[0018] Compare the public key to be verified with the target public key to obtain a comparison result;

[0019] If the comparison result shows that the public key to be verified is consistent with the target public key, determining that the verification of the public key to be verified is successful;

[0020] When the comparison result is that the public key to be verified is inconsistent with the target public key, it is determined that the public key to be verified has failed verification, and it is determined that the public key to be verified is a verified public key.

[0021] The firmware secure boot method provided in this embodiment compares the public key to be verified with the target public key in the root certificate to determine whether the public key to be verified is valid, ensuring that only valid public keys can be used to verify digital signatures, thereby further strengthening security control during firmware startup and preventing the execution of unauthorized software or malicious code.

[0022] In an optional embodiment, the method further includes:

[0023] If the verification of the public key to be verified fails, returning to the step of obtaining any public key to be verified that has not been verified among the multiple public keys;

[0024] If multiple public keys fail to be verified, the firmware will be refused to be started or enter the safe recovery mode.

[0025] The firmware secure boot method provided in this embodiment attempts to verify multiple public keys in a loop until a verified public key is found or all public keys are confirmed to be unavailable. This method significantly increases the difficulty for attackers to forge or tamper with public keys, thereby improving the system's anti-attack capabilities.

[0026] In an optional implementation manner, the verifying multiple digital signatures using the public key to be verified includes:

[0027] Performing hash calculation on the firmware to obtain a first hash value corresponding to the firmware;

[0028] For any digital signature, decrypt the digital signature using the public key to be verified to obtain a second hash value;

[0029] Compare the first Hash value with the second Hash value to obtain a comparison result;

[0030] If the comparison result is that the first hash value is consistent with the second hash value, determining that the public key to be verified has passed the verification of the digital signature;

[0031] When the comparison result is that the first hash value is inconsistent with the second hash value, it is determined that the public key to be verified fails to verify the digital signature.

[0032] The firmware secure boot method provided in this embodiment performs hash calculation on the firmware and compares the two hash values. This process can ensure that the firmware content has not been tampered with. The hash values ​​will only match when the actual data of the firmware is completely consistent with the data when it was originally signed, thereby ensuring the integrity of the firmware. In this way, before the firmware is started, it is accurately determined whether the firmware is legally signed, effectively blocking the execution of firmware that carries malicious code or is illegally modified, thereby improving the security of the entire system.

[0033] In an optional implementation, before obtaining the firmware package from the firmware storage area, the method further includes:

[0034] Generate authentication block;

[0035] The firmware and the authentication block are packaged to obtain a firmware package;

[0036] The firmware package is stored in the firmware storage area.

[0037] The firmware secure boot method provided in this embodiment packages the firmware and the authentication block to obtain a firmware package, thereby improving the overall security of firmware management.

[0038] In an optional implementation, generating an authentication block includes:

[0039] Get the firmware to be released;

[0040] Based on the firmware, determining multiple manufacturers that produce the firmware;

[0041] Performing hash calculation on the firmware to obtain a third hash value corresponding to the firmware;

[0042] Using the first root key of the first manufacturer to sign the third hash value to generate a first digital signature;

[0043] Using the second root key of the second manufacturer to sign the third hash value to generate a second digital signature;

[0044] Using a third root key of a third manufacturer to sign the third hash value to generate a third digital signature;

[0045] Obtaining a public key corresponding to a first root key of a first manufacturer, a public key corresponding to a second root key of a second manufacturer, and a public key corresponding to a third root key of a third manufacturer;

[0046] Combine the public key corresponding to the first root key of the first manufacturer and the first digital signature to obtain a first combination, combine the public key corresponding to the second root key of the second manufacturer and the second digital signature to obtain a second combination, and combine the public key corresponding to the third root key of the third manufacturer and the third digital signature to obtain a third combination;

[0047] The first combination, the second combination and the third combination are arranged in a preset order to generate the authentication block.

[0048] The firmware secure boot method provided in this embodiment uses multiple manufacturers' respective root keys to digitally sign the same firmware, combines the digital signatures and public keys generated by the multiple manufacturers using their respective root keys based on the firmware, and arranges them in a preset order to generate an authentication block, so that the firmware can be applied to hardware products with different root keys of various manufacturers in JDM mode. On the basis of ensuring the security of the firmware, the compatibility, usability and flexibility of the firmware are enhanced, and the firmware is easy to maintain.

[0049] In a second aspect, the present invention provides a firmware secure boot device, the device comprising:

[0050] A first acquisition module, used to acquire a firmware package from a firmware storage area when the server is started;

[0051] A second acquisition module is used to parse the firmware package to obtain firmware and an authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers generating the server using their own root keys;

[0052] A first verification module is used to obtain any unverified public key to be verified among the multiple public keys, and verify the public key to be verified;

[0053] A second verification module, configured to verify multiple digital signatures using the public key to be verified if the public key to be verified passes the verification;

[0054] The startup module is used to determine that the firmware is safe and start the firmware if the public key to be verified successfully verifies any digital signature among the multiple digital signatures.

[0055] In a third aspect, the present invention provides a computer device, comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the firmware secure boot method of the above-mentioned first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0056] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the firmware secure boot method of the above-mentioned first aspect or any corresponding embodiment thereof.

[0057] In a fifth aspect, the present invention provides a computer program product, comprising computer instructions, wherein the computer instructions are used to enable a computer to execute the firmware secure boot method of the above-mentioned first aspect or any corresponding embodiment thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in the related technologies, the drawings required for use in the specific embodiments or the related technical descriptions will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0059] Figure 1 is a schematic diagram of producing a server product in a JDM mode according to an embodiment of the present invention;

[0060] Figure 2 is a schematic diagram of the principle of a firmware secure boot method according to an embodiment of the present invention;

[0061] Figure 3 is a flowchart of a firmware secure boot method according to an embodiment of the present invention;

[0062] Figure 4 is a flowchart of another firmware secure boot method according to an embodiment of the present invention;

[0063] Figure 5 is a schematic diagram of the architecture of firmware secure boot according to an embodiment of the present invention;

[0064] Figure 6 is a flowchart of another firmware secure boot method according to an embodiment of the present invention;

[0065] Figure 7 is a schematic diagram of joint digital signature by multiple manufacturers according to an embodiment of the present invention;

[0066] Figure 8 is a structural block diagram of a firmware secure boot device according to an embodiment of the present invention;

[0067] Fig. 9 It is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0068] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0069] At present, enterprises that purchase a large number of servers often choose multiple suppliers to supply servers in order to reduce costs and ensure a stable supply chain. It is understandable that establishing stable relationships with multiple suppliers can reduce the risk caused by problems with a single supplier, such as supplier bankruptcy or quality issues.

[0070] In the case of selecting multiple suppliers for server supply, that is, when a large number of servers need to be purchased, enterprises tend to adopt the JDM model for customized development of server products. The JDM model is not that server manufacturers simply sell server products to customers, but that they cooperate with customers to allow customers to participate in the research and development, production, and delivery of server products. In the JDM model, one manufacturer takes the lead in completing the design of server products, and multiple manufacturers replicate and produce server products. Suppliers are manufacturers, and manufacturers are manufacturers.

[0071] Figure 1 FIG. 1 is a schematic diagram of producing a server product in a JDM mode according to an embodiment of the present invention. Figure 1 As shown in the figure, the end user is an enterprise that purchases a large number of servers. It uses the JDM model to let the original equipment manufacturer (OEM) 1, namely manufacturer 1, take the lead in designing and developing a server product. After the server product is designed, it will be replicated and produced and verified by manufacturer 2 and manufacturer 3. Finally, the server product is jointly produced by manufacturer 1, manufacturer 2 and manufacturer 3.

[0072] Manufacturer 2 and Manufacturer 3 copied the design of Manufacturer 1, and in principle they should be exactly the same. However, some contents are unique to the manufacturer and cannot be completely consistent. For example, secure boot requires the use of their own root certificates. If you use the root certificates of other manufacturers, you will lose control of the hardware product and will not be able to update the firmware.

[0073] With the rapid development of information technology, the security of computer systems has received increasing attention. As an important technology to protect the system startup process from malware, secure boot has become a standard configuration of modern computing platforms. However, most current secure boot solutions are limited to the private key system of a single manufacturer. In other words, the current secure boot solution only supports the root key of one manufacturer as the basis for secure booting of server firmware, resulting in compatibility problems in a multi-vendor environment, namely in JDM mode.

[0074] In the JDM mode, since each server vendor uses its own root key as the basis for secure boot, each root key is different. This will result in different secure boot firmware after digitally signing with the root key even though the product and firmware are the same. The compatibility of the firmware secure boot is poor, causing trouble for the production and maintenance of the firmware.

[0075] Moreover, the secure boot method in the related technology usually only supports the private key signature verification of one manufacturer, which limits the update flexibility in the scenario of multi-manufacturer cooperation, that is, in the JDM mode. How to support the signature verification of multiple manufacturers at the same time has become a problem that needs to be solved at present.

[0076] In order to solve the above problems, an embodiment of the present invention provides a firmware secure boot method, which parses the firmware package to obtain the firmware and the authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers of the generation server using their own root keys. When any one of the multiple public keys verifies any one of the multiple digital signatures, the firmware is determined to be secure, and the firmware is booted to achieve the effect of enhancing the compatibility and ease of use of the system and reducing the complexity of system integration on the basis of ensuring the security of the firmware.

[0077] Figure 2 FIG. 1 is a schematic diagram showing the principle of a firmware secure boot method according to an embodiment of the present invention. Figure 2 As shown in the figure, when the same server product is supplied by three server manufacturers, each manufacturer uses its own root key to sign the server firmware. The firmware is developed by manufacturer 1 and copied and produced by manufacturer 2 and manufacturer 3. Manufacturer 1 generates firmware signed by key1, where key1 is the root key of manufacturer 1. Firmware signed by key1 cannot be used on server products of manufacturer 2 and manufacturer 3. Similarly, if manufacturer 2 generates a firmware signed by key2, it can only be used on server products produced by itself. If manufacturer 3 generates a firmware signed by key3, it can only be used on server products produced by itself.

[0078] The embodiment of the present invention generates a firmware jointly signed by key1, key2, and key3, so that the firmware can be applied to server products of various manufacturers, that is, the generated firmware can simultaneously support the secure boot of server products of multiple server manufacturers. In this way, by supporting the root keys of multiple manufacturers, one firmware can be used by three manufacturers, which promotes the openness and cooperation of the technology ecosystem.

[0079] According to an embodiment of the present invention, a firmware secure boot method embodiment is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0080] In this embodiment, a firmware secure boot method is provided, which can be used in mobile terminals, such as servers, etc. Figure 3 is a flowchart of a firmware secure boot method according to an embodiment of the present invention. Figure 3 As shown, the process includes the following steps:

[0081] Step S301, when the server is started, a firmware package is obtained from a firmware storage area.

[0082] Among them, this embodiment is aimed at the server generated in the JDM mode. When the server is started, the firmware package is read from the firmware storage area of ​​the server. Firmware (Firmware, abbreviated as: FW) is the server firmware. Server firmware refers to the low-level software installed on the server hardware. It contains programs for basic functions such as controlling server startup, initializing hardware components, and loading the operating system.

[0083] Step S302, parse the firmware package to obtain the firmware and the authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers of the generation server using their own root keys.

[0084] After the firmware package is obtained from the firmware storage area, the firmware package is parsed to extract the firmware and the authentication block therein. It should be noted that the extracted firmware is a firmware image. Exemplarily, the firmware package can be composed of an original firmware image (Firmware Image) and an authentication block as shown in Table 1.

[0085] Table 1

[0086] Firmware Image Firmware Signature and key block

[0087] The authentication block includes a public key (key block) and a digital signature (Firmware Signature).

[0088] It can be understood that the multiple public keys are multiple public keys corresponding to the root keys of multiple manufacturers that generate the server.

[0089] Multiple manufacturers use their own root keys to generate multiple digital signatures based on the firmware and the firmware to form a firmware package, so that the firmware can be applied to server products produced by multiple manufacturers.

[0090] Step S303: obtaining any unverified public key to be verified among the multiple public keys, and verifying the public key to be verified.

[0091] After obtaining the authentication block, any unverified public key to be verified is randomly selected from the multiple public keys in the authentication block, and the public key to be verified is verified.

[0092] It should be noted that the purpose of verifying the public key to be verified is mainly to verify whether the public key to be verified is valid, that is, whether it is the public key corresponding to the root key of the manufacturer of the current server.

[0093] Step S304: If the public key to be verified passes the verification, multiple digital signatures are verified using the public key to be verified.

[0094] Among them, if the public key to be verified passes the verification, it means that the public key to be verified is the public key corresponding to the root key of the manufacturer of the current server, and the public key to be verified is valid. The public key to be verified can be used to verify the multiple digital signatures included in the authentication block, that is, verify the signature.

[0095] Step S305: If the public key to be verified successfully verifies any of the multiple digital signatures, the firmware is determined to be safe and the firmware is started.

[0096] Among them, this embodiment ensures the compatibility of the firmware by having multiple manufacturers jointly digitally sign the firmware. Therefore, when the public key to be verified is successfully verified, each of the multiple digital signatures is verified using the public key to be verified. When the public key to be verified is successfully verified for any one of the multiple digital signatures, it is determined that the firmware security has not been tampered with, and the firmware is started.

[0097] The firmware secure boot method provided in this embodiment parses the firmware package to obtain the firmware and the authentication block, which includes multiple public keys and multiple digital signatures corresponding to the firmware. The multiple digital signatures are generated based on the firmware by multiple manufacturers of the generation server using their own root keys. When any one of the multiple public keys verifies any one of the multiple digital signatures, the firmware is determined to be secure and the firmware is booted. The secure boot of the firmware is made compatible with the digital signatures generated by the firmware based on the different root keys of each manufacturer, which enhances the compatibility and usability of the system while ensuring the security of the firmware, and makes it easy to maintain the firmware, reducing the complexity of system integration.

[0098] In this embodiment, a firmware secure boot method is provided, which can be used in mobile terminals, such as servers, etc. Figure 4 is a flowchart of a firmware secure boot method according to an embodiment of the present invention. Figure 4As shown, the process includes the following steps:

[0099] Step S401, when the server is started, obtain the firmware package from the firmware storage area. Figure 3 Step S301 of the illustrated embodiment will not be described in detail here.

[0100] Step S402: parse the firmware package to obtain the firmware and the authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated by multiple manufacturers of the generation server using their own root key base firmware. For details, please refer to Figure 3 Step S302 of the illustrated embodiment will not be described in detail here.

[0101] Step S403: obtaining any unverified public key to be verified among the multiple public keys, and verifying the public key to be verified.

[0102] Specifically, the above step S403 includes:

[0103] Step S4031, read the root certificate from the root certificate storage area, and obtain the target public key from the root certificate.

[0104] Figure 5 FIG. 1 is a schematic diagram of the architecture of firmware secure boot according to an embodiment of the present invention. Figure 5 As shown, the server includes an internal boot read-only memory (Internal Boot Rom, referred to as: IBR) area, which can only be read but not modified. Figure 5 The hardware (HW) boot read-only memory in the IBR is IBR. After the IBR code runs, it will read the root certificate from the root certificate storage area and use the root certificate to authenticate the firmware image. When the firmware image authentication passes, the firmware image is started; when the firmware image authentication fails, the firmware image is not started to prevent the firmware image from being tampered with, and wait for fault recovery.

[0105] It should be noted that the firmware signature authentication area is the authentication block storage area.

[0106] The authentication of the firmware image includes the verification of the public key to be verified and the verification of multiple digital signatures. After reading the root certificate, the target public key is obtained from the root certificate. It can be understood that the target public key is the public key corresponding to the root key of the manufacturer of the current server.

[0107] Figure 6 FIG. 1 is a flow chart of a firmware secure boot method according to an embodiment of the present invention. Figure 6As shown, any unverified public key to be verified among multiple public keys is obtained, that is, IBR will search for public keys and digital signatures in the authentication block of the firmware in sequence, and if a public key is found, the validity of the public key is judged. The validity judgment of the public key is to verify the public key to be verified.

[0108] The method for judging the validity of the public key is to judge whether the public key is consistent with the public key in the root certificate. If they are consistent, the public key is judged to be valid, that is, the public key to be verified has passed the verification.

[0109] It should be noted that secure boot ensures a trust chain from power-on to firmware so that only firmware with the correct digital signature is executed. In secure mode, the read-only memory (ROM) code that follows the secure boot flow is first executed to verify the firmware before the boot loader can execute. It is understood that verifying the firmware includes verifying the public key to be verified in the firmware package and verifying multiple digital signatures.

[0110] Step S4032, compare the public key to be verified with the target public key to obtain a comparison result.

[0111] After obtaining the target public key, the public key to be verified is compared with the target public key to obtain a comparison result.

[0112] Step S4033: When the comparison result shows that the public key to be verified is consistent with the target public key, it is determined that the verification of the public key to be verified is successful.

[0113] The comparison result is that the public key to be verified is consistent with the target public key, and it is determined that the public key to be verified has passed the verification and is valid.

[0114] Step S4034: when the comparison result shows that the public key to be verified is inconsistent with the target public key, it is determined that the public key to be verified has failed verification, and the public key to be verified is determined to be a verified public key.

[0115] Among them, the comparison result is that the public key to be verified is inconsistent with the target public key, and it is determined that the public key to be verified has failed the verification and is invalid.

[0116] It can be understood that regardless of whether the public key to be verified is consistent with the target public key, the public key to be verified is determined to be a verified public key to avoid inconsistency between the public key to be verified and the target public key. When filtering any unverified public key to be verified from multiple public keys, the verified public key is filtered out.

[0117] Step S404: If the public key to be verified passes the verification, multiple digital signatures are verified using the public key to be verified.

[0118] Specifically, the above step S404 includes:

[0119] Step S4041, performing hash calculation on the firmware to obtain a first hash value corresponding to the firmware.

[0120] Among them, Figure 6 As shown, if the public key to be verified passes the verification, that is, the public key is valid, the digital signature is verified using this public key. If the verification passes, the system is started. In other cases, the system fails to start and enters recovery mode.

[0121] Verifying the digital signature using the verified public key to be verified includes determining whether the signature decrypted HASH matches the file HASH, that is, determining whether the first hash value corresponding to the firmware is consistent with the second hash value obtained by decrypting the digital signature using the public key to be verified.

[0122] When the firmware, ie, the firmware image, is obtained from the firmware package, a hash calculation is performed on the firmware to obtain a first hash value corresponding to the firmware.

[0123] It should be noted that in this embodiment, multiple manufacturers use the same hash algorithm when generating digital signatures of firmware.

[0124] The hash algorithm used to hash the firmware is the same as the hash algorithm used to generate the digital signature of the firmware.

[0125] Step S4042: For any digital signature, decrypt the digital signature using the public key to be verified to obtain a second hash value.

[0126] Among them, for any one of the multiple digital signatures, the digital signature is decrypted using the public key to be verified to obtain the second hash value, which is actually a process of verifying the signature.

[0127] Step S4043: compare the first Hash value with the second Hash value to obtain a comparison result.

[0128] The obtained first hash value is compared with the second hash value to determine whether the firmware has been tampered with.

[0129] Step S4044: When the comparison result shows that the first hash value is consistent with the second hash value, it is determined that the digital signature verification of the public key pair to be verified has passed.

[0130] Among them, the first hash value is consistent with the second hash value, that is, the first hash value and the second hash value match successfully, it is determined that the firmware has not been tampered with, and the current digital signature verification of the public key to be verified is successful.

[0131] Step S4045: When the comparison result is that the first hash value and the second hash value are inconsistent, it is determined that the digital signature verification of the public key to be verified has failed.

[0132] Among them, the first hash value is inconsistent with the second hash value, that is, the first hash value and the second hash value fail to match, it is determined that the firmware is abnormal, and the public key to be verified fails to verify the current digital signature.

[0133] It is understandable that each digital signature is verified to determine the verification result of the public key to be verified on each digital signature. The verification result indicates that if the public key to be verified passes the verification of any digital signature among the multiple digital signatures, the firmware is determined to be safe and the firmware is started.

[0134] Step S405: If the public key to be verified passes verification of any of the multiple digital signatures, the firmware is determined to be secure and the firmware is started. Figure 3 Step S305 of the illustrated embodiment will not be described in detail here.

[0135] The firmware secure boot method provided in this embodiment compares the public key to be verified with the target public key in the root certificate to determine whether the public key to be verified is valid, ensuring that only valid public keys can be used to verify digital signatures, thereby further strengthening security control during firmware startup and preventing the execution of unauthorized software or malicious code.

[0136] By hashing the firmware and comparing the two hash values, the process can ensure that the firmware content has not been tampered with. The hash values ​​will only match when the actual data of the firmware is exactly the same as the data when it was originally signed, thus ensuring the integrity of the firmware. In this way, before the firmware is started, it can be accurately determined whether the firmware is legally signed, effectively blocking the execution of firmware that carries malicious code or has been illegally modified, and improving the security of the entire system.

[0137] In addition, this embodiment only uses one root certificate, and the firmware's secure boot program will have multiple digital signatures. As long as one of the digital signatures is correct, the verification is passed, and the firmware can be started and run normally.

[0138] In some optional implementations, the firmware secure boot method further includes:

[0139] Step a1: If the public key to be verified fails to verify any of the multiple digital signatures, it is determined that the firmware is abnormal, and the firmware is refused to be started or enter the safe recovery mode.

[0140] Among them, when the public key to be verified passes the verification, the public key to be verified verifies multiple digital signatures. If the public key to be verified fails to verify multiple digital signatures, that is, the public key to be verified fails to verify any of the multiple digital signatures, it is determined that the firmware is abnormal, for example, the firmware is at risk of being tampered with.

[0141] like Figure 6 As shown, if the public key to be verified fails to verify the currently found digital signature and the previously verified digital signature and the next digital signature cannot be found, it is determined that the public key to be verified fails to verify any of the multiple digital signatures.

[0142] In the case of firmware abnormality, the firmware is refused to start, that is, the startup fails. Or, in the case of firmware abnormality, enter the safe recovery mode.

[0143] The firmware secure boot method provided in this embodiment determines that the firmware is abnormal when the public key to be verified fails to verify any of the multiple digital signatures. The system immediately refuses to boot the firmware or switches to a secure recovery mode to prevent the damaged firmware from being executed, reduce potential damage, and facilitate rapid recovery measures.

[0144] In some optional implementations, the firmware secure boot method further includes:

[0145] Step b1: If the verification of the public key to be verified fails, return to the step of obtaining any public key to be verified that has not been verified among the multiple public keys.

[0146] Among them, for any public key to be verified that has not been verified among the multiple public keys, if the verification of the public key to be verified fails, it means that the public key to be verified is invalid and is not the public key corresponding to the root key of the manufacturer of the current server, then the process returns to execute the steps of obtaining any public key to be verified that has not been verified among the multiple public keys and subsequent steps, so as to continue to verify any public key to be verified that has not been verified among the multiple public keys before the verified public key to be verified is obtained.

[0147] like Figure 6 As shown, when the public key is invalid, that is, the public key to be verified is invalid, return to the step of searching for the next public key and signature.

[0148] Step b2: If multiple public keys fail to be verified, the firmware is refused to be started or enter the safe recovery mode.

[0149] If multiple public keys are verified before a verified public key is obtained, and all the public keys fail to pass the verification, it means that there is no public key corresponding to the root key of the manufacturer of the current server among the multiple public keys, and the firmware is determined to be abnormal. In the case of firmware abnormality, the firmware is refused to be started or enter the safe recovery mode.

[0150] The firmware secure boot method provided in this embodiment attempts to verify multiple public keys in a loop until a verified public key is found or all public keys are confirmed to be unavailable. This method significantly increases the difficulty for attackers to forge or tamper with public keys, thereby improving the system's anti-attack capabilities.

[0151] In some optional implementations, before step S401, the firmware secure boot method further includes:

[0152] Step c1, generate an authentication block.

[0153] Before the server is started, a firmware package needs to be generated. First, an authentication block in the firmware package needs to be generated.

[0154] Step c2: package the firmware and the authentication block to obtain a firmware package.

[0155] After the authentication block is generated, the firmware image and the authentication block are packaged to obtain a firmware package.

[0156] Step c3, storing the firmware package in the firmware storage area.

[0157] After the firmware package is obtained, the firmware package is stored in the firmware storage area of ​​the server, that is, the firmware package is placed in the firmware storage area of ​​the server to release the firmware.

[0158] The firmware secure boot method provided in this embodiment packages the firmware and the authentication block to obtain a firmware package, thereby improving the overall security of firmware management.

[0159] In some optional implementations, the above step c1 includes:

[0160] Step c11, obtaining the firmware to be released.

[0161] It should be noted that the firmware not stored in the firmware storage area of ​​the server is the firmware to be released, and the firmware stored in the firmware storage area of ​​the server is the released firmware.

[0162] Step c12: Based on the firmware, determine multiple manufacturers that produce the firmware.

[0163] According to the firmware to be released, multiple manufacturers that produce the firmware are determined. This embodiment is described with three manufacturers. Of course, more or fewer manufacturers may jointly produce the firmware. This embodiment is only an exemplary description, and the number of manufacturers is not specifically limited.

[0164] It should be noted that, assuming there are three manufacturers, the three manufacturers need to jointly sign the firmware to achieve firmware compatibility. The three manufacturers provide the public key corresponding to their own root key, and provide their own root key to the firmware hash digital signature, and store the public keys and digital signatures of the three manufacturers as part of the firmware package.

[0165] Step c13: perform hash calculation on the firmware to obtain a third hash value corresponding to the firmware.

[0166] The firmware to be released is hashed to obtain a third hash value corresponding to the firmware, wherein the hashing is to transform an input of any length into an output of a fixed length through a hashing algorithm or a hashing algorithm.

[0167] Step c14: Sign the third hash value using the first root key of the first manufacturer to generate a first digital signature.

[0168] After obtaining the third hash value corresponding to the firmware, the third hash value is signed using the first root key of the first manufacturer to generate a first digital signature.

[0169] Step c15: Use the second root key of the second manufacturer to sign the third hash value to generate a second digital signature.

[0170] After obtaining the third hash value corresponding to the firmware, the third hash value is signed using the second root key of the second manufacturer to generate a second digital signature.

[0171] Step c16: Use the third root key of the third manufacturer to sign the third Hash value to generate a third digital signature.

[0172] After obtaining the third hash value corresponding to the firmware, the third hash value is signed using a third root key of a third manufacturer to generate a third digital signature.

[0173] Step c17, obtaining a public key corresponding to the first root key of the first manufacturer, a public key corresponding to the second root key of the second manufacturer, and a public key corresponding to the third root key of the third manufacturer.

[0174] Step c18, combine the public key and the first digital signature corresponding to the first root key of the first manufacturer to obtain a first combination, combine the public key and the second digital signature corresponding to the second root key of the second manufacturer to obtain a second combination, and combine the public key and the third digital signature corresponding to the third root key of the third manufacturer to obtain a third combination.

[0175] Step c19: Arrange the first combination, the second combination and the third combination in a preset order to generate an authentication block.

[0176] The preset order is set by the technicians and is not specifically limited here. For example, the authentication blocks are arranged in the order of the first combination, the second combination, and the third combination corresponding to the first manufacturer, the second manufacturer, and the third manufacturer as shown in Table 2.

[0177] Table 2

[0178] Public key1 Firmware hash, signed with private key (private key) 1 Public key 2 Firmware hash, signed with privatekey 2 … … Public key N Firmware hash, signed with private key N

[0179] Among them, Public key 1 is the public key corresponding to the first root key of the first manufacturer, Firmware hash, signed with private key 1 is the first digital signature corresponding to the first root key of the first manufacturer; Public key 2 is the public key corresponding to the second root key of the second manufacturer, Firmware hash, signed with private key 2 is the second digital signature corresponding to the second root key of the second manufacturer; Public key N is the public key corresponding to the Nth root key of the Nth manufacturer, Firmware hash, signed with private key N is the Nth digital signature corresponding to the Nth root key of the Nth manufacturer.

[0180] It should be noted that the specific operation of generating a digital signature uses the following steps:

[0181] 1. Use the hash command to generate firmware hash

[0182] Hash–f<firmware.fw>-o<fw.hash>

[0183] 2. Use encryption tools (such as openssl tools) to digitally sign the hash value

[0184] openssl rsoutl-sign-in<fw.hash>-inkey privatekey.pem-out sas4fw_hash.s<fwhash.signed>

[0185] 3. Then (using the insert command) insert the digital signature together with the public key .pem<firmware_sgined.fw> Firmware package

[0186] insert-f<firmware.fw> -s<fwhash.signed> -p<public.pem> -o<firmwaresigned.fw>

[0187] The above-mentioned steps are simplified by using a sign command to complete the digital signature of the first manufacturer.

[0188] fwutils.exe sign -f<firmware.fw> -p<oemPriviteKey1.pem> -o<firmware_signedwithkey1.bin>

[0189] Based on the firmware signed by the first manufacturer, a second digital signature is performed using the second manufacturer's key2.

[0190] fwutils.exe sign -f<firmware_signedwithkey1.bin> -p<oemPriviteKey2.pem> -o<firmware_signedwithkey1_2.bin>

[0191] Based on the firmware signed by the second manufacturer, the third manufacturer key3 is used for the third digital signature. In this way, we get the secure boot firmware jointly signed by the three manufacturers.

[0192] fwutils.exe sign -f<firmware_signedwithkey1_2.bin> -p<oemPriviteKey3.pem> -o<firmware_signedwithkey1_2_3.bin>

[0193] Figure 7 FIG. 1 is a schematic diagram of a joint digital signature performed by multiple manufacturers according to an embodiment of the present invention. Figure 7As shown, compared with the single signature of a single manufacturer in the related art, that is, a single digital signature, this embodiment adopts a joint signature of multiple manufacturers, that is, a joint digital signature. Among them, when a specific manufacturer is debugging the firmware, it can use its own key to single-sign the firmware. At this time, the single-signed firmware can only be used on the manufacturer's own hardware. The release version of the firmware provided to the end user needs to be jointly signed by various manufacturers. This jointly signed firmware can be run on the hardware systems of various manufacturers. It can be understood that the firmware after the joint digital signature is the above-mentioned firmware package, and the joint digital signature includes the above-mentioned first digital signature, second digital signature, third digital signature, etc.

[0194] It should be noted that, in the JDM mode, compared with the single key management for digital signatures by a single manufacturer in the related art, the embodiment of the present invention needs to adopt multiple key management. Specifically, for any specific OEM, it is still only necessary to maintain its own set of keys, including private keys, i.e., root keys, and public keys. End users will use server products from multiple manufacturers, and there will be keys from multiple manufacturers in the server products. End users need to establish a key management database to store public key information (private keys will not be stored) to confirm that the server products are from multiple manufacturers, and to confirm that the firmware that has passed the signature verification using these public keys is legal.

[0195] Furthermore, compared to the single secure boot in the related art, that is, the firmware is started when a single signature verification is passed, in this embodiment, the firmware is started when any matching boot, that is, any digital signature in the joint digital signature is verified. Specifically, when the device starts, the firmware package is read from the firmware storage area, and the public key and digital signature are extracted from the firmware package. The digital signature in the firmware package is verified using the public key to determine the integrity and legitimacy of the firmware package. As long as any set of verifications passes, the device is started according to the firmware file in the firmware package, otherwise, the device will refuse to start or enter the secure recovery mode.

[0196] The firmware secure boot method provided in this embodiment generates secure boot firmware by using multiple manufacturers to digitally sign the same firmware using their respective root keys, combines the digital signatures and public keys generated by the multiple manufacturers using their respective root keys based on the firmware, and arranges them in a preset order to generate an authentication block, so that the firmware can be applied to hardware products with different root keys from various manufacturers in JDM mode. On the basis of ensuring the security of the firmware, the compatibility, usability and flexibility of the firmware are enhanced, and the firmware is easy to maintain.

[0197] In some optional implementations, the firmware secure boot method further includes:

[0198] If multiple public keys fail verification, an alarm will be issued to remind the user that there is a security issue with the firmware.

[0199] If multiple public keys fail to be verified, it indicates that the firmware may have serious security issues. At this time, the alarm mechanism is triggered, and an alarm message can be sent to the user to warn the user that the firmware has security issues. The alarm message can be conveyed in a variety of ways, such as email, SMS, system pop-up window, etc.

[0200] It should be noted that the event that multiple public keys fail to be verified can also be recorded in the system log for subsequent audit and analysis.

[0201] The firmware secure boot method provided in this embodiment can promptly issue an alarm when multiple public keys fail verification, so that the user can promptly realize that there may be security issues with the firmware and take corresponding measures to improve the security and reliability of the system.

[0202] In some optional implementations, the firmware secure boot method further includes:

[0203] When the public key to be verified fails to verify any of the multiple digital signatures, an alarm is issued to remind the user that there is a security problem in the firmware.

[0204] It is understandable that the warning can be sent to the user to remind the user that there is a security problem with the firmware. The warning information can be conveyed in a variety of ways, such as email, text message, system pop-up window, etc.

[0205] It should be noted that the event that the public key to be verified fails to verify any of the multiple digital signatures can also be recorded in the system log for subsequent audit and analysis.

[0206] The firmware secure boot method provided in this embodiment can promptly issue an alarm when the public key to be verified fails to verify any of the multiple digital signatures, so that the user can promptly realize that there may be security issues in the firmware, and thus take corresponding measures to improve the security and reliability of the system.

[0207] At the same time, detailed event records also help with subsequent firmware security management.

[0208] In this embodiment, a firmware secure boot device is also provided, which is used to implement the above embodiments and preferred implementations, and will not be repeated here. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0209] This embodiment provides a firmware secure boot device, such as Figure 8 As shown, including:

[0210] The first acquisition module 801 is used to acquire a firmware package from a firmware storage area when the server is started.

[0211] The second acquisition module 802 is used to parse the firmware package to obtain the firmware and the authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers of the generation server using their own root keys.

[0212] The first verification module 803 is used to obtain any unverified public key to be verified among the multiple public keys, and verify the public key to be verified.

[0213] The second verification module 804 is used to verify multiple digital signatures using the public key to be verified if the public key to be verified passes the verification.

[0214] The startup module 805 is used to determine that the firmware is safe and start the firmware if the public key to be verified successfully verifies any digital signature among the multiple digital signatures.

[0215] In some optional implementations, the firmware secure boot device further includes:

[0216] The first determination module is used to determine that the firmware is abnormal and refuse to start the firmware or enter the safe recovery mode if the public key to be verified fails to verify any of the multiple digital signatures.

[0217] In some optional implementations, the first verification module 803 includes:

[0218] The first acquisition unit is used to read the root certificate from the root certificate storage area and acquire the target public key from the root certificate.

[0219] The second acquisition unit is used to compare the public key to be verified with the target public key to obtain a comparison result.

[0220] The first determining unit is used to determine that the verification of the public key to be verified is successful when the comparison result shows that the public key to be verified is consistent with the target public key.

[0221] The second determining unit is used to determine that the public key to be verified has failed verification and that the public key to be verified is a verified public key when the comparison result shows that the public key to be verified is inconsistent with the target public key.

[0222] In some optional implementations, the firmware secure boot device further includes:

[0223] The execution module is returned to execute the step of obtaining any unverified public key to be verified among the multiple public keys if the verification of the public key to be verified fails.

[0224] The boot rejection module is used to reject the boot of the firmware or enter the secure recovery mode if multiple public keys fail to be verified.

[0225] In some optional implementations, the second verification module 804 includes:

[0226] The third acquisition unit is used to perform hash calculation on the firmware to obtain a first hash value corresponding to the firmware.

[0227] The fourth acquisition unit is used to decrypt any digital signature using the public key to be verified to obtain a second hash value.

[0228] The fifth acquiring unit is configured to compare the first Hash value with the second Hash value to obtain a comparison result.

[0229] The third determining unit is configured to determine that the digital signature verification of the public key pair to be verified passes when the comparison result is that the first hash value is consistent with the second hash value.

[0230] The fourth determining unit is used to determine that the digital signature verification of the public key to be verified fails when the comparison result is that the first hash value and the second hash value are inconsistent.

[0231] In some optional implementations, the firmware secure boot device further includes:

[0232] Generate module, used to generate authentication blocks.

[0233] The third acquisition module is used to package the firmware and the authentication block to obtain a firmware package.

[0234] The storage module is used to store the firmware package in the firmware storage area.

[0235] In some optional implementations, the generation module includes:

[0236] The sixth obtaining unit is used to obtain the firmware to be released.

[0237] The fifth determining unit is used to determine multiple manufacturers that produce the firmware based on the firmware.

[0238] The seventh acquisition unit is used to perform hash calculation on the firmware to obtain a third hash value corresponding to the firmware.

[0239] The first generating unit is used to sign the third hash value by using the first root key of the first manufacturer to generate a first digital signature.

[0240] A second generating unit, configured to perform a signing process on the third hash value using a second root key of the second manufacturer to generate a second digital signature;

[0241] The third generating unit is used to sign the third hash value by using the third root key of the third manufacturer to generate a third digital signature.

[0242] The eighth acquisition unit is used to acquire the public key corresponding to the first root key of the first manufacturer, the public key corresponding to the second root key of the second manufacturer, and the public key corresponding to the third root key of the third manufacturer.

[0243] The combination unit is used to combine the public key and the first digital signature corresponding to the first root key of the first manufacturer to obtain a first combination, combine the public key and the second digital signature corresponding to the second root key of the second manufacturer to obtain a second combination, and combine the public key and the third digital signature corresponding to the third root key of the third manufacturer to obtain a third combination.

[0244] The fourth generating unit is used to arrange the first combination, the second combination and the third combination in a preset order to generate an authentication block.

[0245] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0246] The firmware secure boot device in this embodiment is presented in the form of a functional unit, where the unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0247] The embodiment of the present invention also provides a computer device having the above Figure 8 The firmware shown is a secure boot device.

[0248] See also Fig. 9 , Fig. 9 is a schematic diagram of the structure of a computer device provided by an optional embodiment of the present invention, such as Fig. 9As shown, the computer device includes: one or more processors 901, memory 902, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Each component utilizes different buses to communicate with each other, and can be installed on a common mainboard or installed in other ways as required. The processor can process the instructions executed in the computer device, including instructions stored in the memory or on the memory to display the graphical information of the GUI on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Fig. 9 A processor 901 is taken as an example.

[0249] The processor 901 may be a central processing unit, a network processor or a combination thereof. The processor 901 may further include an integrated circuit. The integrated circuit may be a dedicated integrated circuit, a programmable logic device or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable logic gate array, a general purpose array logic or any combination thereof.

[0250] The memory 902 stores instructions executable by at least one processor 901 so as to enable at least one processor 901 to implement the method shown in the above embodiment.

[0251] The memory 902 may include a program storage area and a data storage area, wherein the program storage area may store an operating system, an application required for at least one function; the data storage area may store data created according to the use of the computer device, etc. In addition, the memory 902 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 902 may optionally include a memory remotely arranged relative to the processor 901, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0252] The memory 902 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid state drive; the memory 902 may also include a combination of the above types of memory.

[0253] The computer device also includes a communication interface 903, which is used for the computer device to communicate with other devices or a communication network.

[0254] The embodiment of the present invention also provides a computer-readable storage medium. The method according to the embodiment of the present invention can be implemented in hardware, firmware, or can be implemented as a computer code that can be recorded in a storage medium, or can be implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and will be stored in a local storage medium through a network download, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state hard disk, etc.; further, the storage medium can also include a combination of the above types of memories. It can be understood that a computer, a processor, a microprocessor controller, or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor, or hardware, the method shown in the above embodiment is implemented.

[0255] A part of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the existence of the computer program instruction in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc., and accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium accessible to the computer.

[0256] Although the embodiments of the present invention have been described in conjunction with the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A firmware secure boot method, characterized in that: The method comprises: When the server starts, the firmware package is obtained from the firmware storage area; Parsing the firmware package to obtain firmware and an authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers generating the server using their own root keys; Obtain any unverified public key to be verified among the multiple public keys, and verify the public key to be verified; If the public key to be verified is verified, the multiple digital signatures are verified using the public key to be verified; If the public key to be verified successfully verifies any of the multiple digital signatures, the firmware is determined to be secure and the firmware is started.

2. The method according to claim 1, characterized in that The method further comprises: If the public key to be verified fails to verify any of the multiple digital signatures, the firmware is determined to be abnormal, and the firmware is refused to be started or enter the safe recovery mode.

3. The method according to claim 1, characterized in that The verifying the public key to be verified includes: Reading a root certificate from a root certificate storage area and obtaining a target public key from the root certificate; Compare the public key to be verified with the target public key to obtain a comparison result; If the comparison result shows that the public key to be verified is consistent with the target public key, determining that the verification of the public key to be verified is successful; When the comparison result is that the public key to be verified is inconsistent with the target public key, it is determined that the public key to be verified has failed verification, and it is determined that the public key to be verified is a verified public key.

4. The method according to claim 1, characterized in that: The method further comprises: If the verification of the public key to be verified fails, returning to the step of obtaining any public key to be verified that has not been verified among the multiple public keys; If multiple public keys fail to be verified, the firmware will be refused to be started or enter the safe recovery mode.

5. The method according to claim 1, characterized in that The verifying of multiple digital signatures using the public key to be verified includes: Performing hash calculation on the firmware to obtain a first hash value corresponding to the firmware; For any digital signature, decrypt the digital signature using the public key to be verified to obtain a second hash value; Compare the first Hash value with the second Hash value to obtain a comparison result; If the comparison result is that the first hash value is consistent with the second hash value, determining that the public key to be verified has passed the verification of the digital signature; When the comparison result is that the first hash value is inconsistent with the second hash value, it is determined that the public key to be verified fails to verify the digital signature.

6. The method according to claim 1, characterized in that Before obtaining the firmware package from the firmware storage area, the method further includes: Generate authentication block; The firmware and the authentication block are packaged to obtain a firmware package; The firmware package is stored in the firmware storage area.

7. The method according to claim 6, characterized in that The generating of the authentication block comprises: Get the firmware to be released; Based on the firmware, determining multiple manufacturers that produce the firmware; Performing hash calculation on the firmware to obtain a third hash value corresponding to the firmware; Using the first root key of the first manufacturer to sign the third hash value to generate a first digital signature; Using the second root key of the second manufacturer to sign the third hash value to generate a second digital signature; Using a third root key of a third manufacturer to sign the third hash value to generate a third digital signature; Obtaining a public key corresponding to a first root key of a first manufacturer, a public key corresponding to a second root key of a second manufacturer, and a public key corresponding to a third root key of a third manufacturer; Combine the public key corresponding to the first root key of the first manufacturer and the first digital signature to obtain a first combination, combine the public key corresponding to the second root key of the second manufacturer and the second digital signature to obtain a second combination, and combine the public key corresponding to the third root key of the third manufacturer and the third digital signature to obtain a third combination; The first combination, the second combination and the third combination are arranged in a preset order to generate the authentication block.

8. A firmware secure boot device, characterized in that: The device comprises: A first acquisition module, used to acquire a firmware package from a firmware storage area when the server is started; A second acquisition module is used to parse the firmware package to obtain firmware and an authentication block, wherein the authentication block includes multiple public keys and multiple digital signatures corresponding to the firmware, and the multiple digital signatures are generated based on the firmware by multiple manufacturers generating the server using their own root keys; A first verification module is used to obtain any unverified public key to be verified among the multiple public keys, and verify the public key to be verified; A second verification module, configured to verify multiple digital signatures using the public key to be verified if the public key to be verified passes the verification; The startup module is used to determine that the firmware is safe and start the firmware if the public key to be verified successfully verifies any digital signature among the multiple digital signatures.

9. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the firmware secure boot method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the firmware secure boot method according to any one of claims 1 to 7.

Images