Firmware trust verification method, chip and electronic equipment

Abstract

The invention relates to the technical field of information security, and particularly provides a firmware trust verification method, a chip and electronic equipment. According to the application, trust verification is carried out on the first trust base and the second trust base in the plurality of trust bases by using the target trusted root; wherein the target trusted root is determined based on the plurality of trust bases through a first preset algorithm, so that the target trusted root can perform trust verification on any trust base in the plurality of trust bases; when the first trust base passes trust verification, trust verification is carried out on first firmware to be verified based on the first trust base; and / or, when the second trust base passes the trust verification, performing trust verification on the to-be-verified second firmware based on the second trust base. In conclusion, according to the technical scheme provided by the invention, the trust verification problem of multiple trust bases and multiple trust chains derived from the multiple trust bases can be solved with relatively low trust root maintenance cost.

Description

Technical Field

[0001] The present application relates to the field of information security technology, and in particular to a firmware trust verification method, chip, and electronic device. Background Art

[0002] Firmware resilience is a key technology for protecting firmware. Firmware resilience requires the system (or server) to check whether the firmware has been tampered with when it is started. In related technologies, firmware checking is achieved through trusted roots and trust bases. Among them, the trusted root is a fixed value solidified in the electronic fuse (eFuse), which is generally a hash value obtained by hashing a trusted public key (as a trust base). In other words, a trusted root is associated with a trust base.

[0003] In this way, when it comes to scenarios where multiple trust bases are required for trust protection, mutual trust between multiple trust bases is required to achieve trust transfer based on one trusted root; or, trust verification of multiple trust bases can be achieved by maintaining multiple trusted roots, but this will increase the cost of trusted root maintenance and limit the number of trust bases, which is not conducive to expanded applications. Summary of the invention

[0004] In view of the above problems, the embodiments of the present application are proposed. The embodiments of the present application provide a firmware trust verification method, a chip, and an electronic device.

[0005] According to one aspect of an embodiment of the present application, a firmware trust verification method is provided, including:

[0006] Get the target trusted root;

[0007] Based on the target trusted root, a first trust base and a second trust base among the multiple trust bases are trust-verified; wherein the target trusted root is determined based on the multiple trust bases by a first preset algorithm, so that the target trusted root can trust-verify any one of the multiple trust bases;

[0008] In the case where the first trust base passes the trust verification, a trust verification is performed on the first firmware to be verified based on the first trust base; and / or, in the case where the second trust base passes the trust verification, a trust verification is performed on the second firmware to be verified based on the second trust base.

[0009] In the embodiments of the present application, a target trusted root is determined based on multiple trust bases through a first preset algorithm. In this way, there is no need for mutual trust between multiple trust bases, that is, a trusted root can be associated with multiple trust bases for security verification of multiple trust bases. Based on this mechanism, a target trusted root can be used for security verification of multiple trust bases. Thus, when it comes to scenarios that require trust protection using multiple trust bases, there is no need to incur additional trusted root maintenance costs, and it also avoids the limitation of the number of trusted roots on the number of trust bases, and breaks through the problem of limited expansion caused thereby, reducing the system implementation cost and having high scalability. The technical solution provided by the present application can solve the trust verification problem of multiple trust bases and their derived multiple trust chains with a relatively low trusted root maintenance cost.

[0010] In addition, in the embodiments of the present application, the trust verification of the first trust base among multiple trust bases based on the target trusted root includes:

[0011] Processing multiple trust bases including the first trust base through the first preset algorithm to obtain a first verification value;

[0012] When the first verification value matches the target trusted root, it is determined that the first trust base is trustworthy.

[0013] The embodiments of the present application can process multiple trust bases through the first preset algorithm and then compare them. By using a trustworthy target trusted root, it verifies whether each trust base is trustworthy, ensuring a trustworthy verification basis for subsequent possible trust verification processes.

[0014] In addition, in the embodiments of the present application, the first preset algorithm is implemented through one or more hash functions;

[0015] Among them, the first preset algorithm includes: a nested algorithm of an N-layer hash algorithm; the nested algorithm is that the hash result of the i-th layer hash algorithm is used as the content of the (i + 1)-th layer hash algorithm;

[0016] Among them, the i-th layer hash algorithm is the OR value of the following three hash results: the hash result based on the first trust base, the hash result based on the second trust base, and the hash result based on the first trust base and the second trust base.

[0017] In this embodiment, the first preset algorithm is implemented through a nested hash algorithm. This processing method can effectively increase the complexity and difficulty of the target trusted root being pieced together and calculated, and thus can improve the security of the target trusted root to a certain extent, ensuring that the core verification basis of the trust verification scheme is trustworthy and has high security.

[0018] In addition, in the embodiments of the present application, the multiple trust bases are trusted, untrusted, or partially trusted.

[0019] In addition, in the embodiments of the present application, one trust root is used to verify and protect one firmware; and / or, one trust root is used to verify and protect multiple firmwares; and / or, multiple trust roots are used to verify and protect one firmware. The embodiments of the present disclosure can be applied to various trust verification scenarios and have wide applicability.

[0020] In addition, in the embodiments of the present application, the multiple trust roots corresponding to the target trusted root are public keys; any one of the public keys uniquely corresponds to a private key;

[0021] The first firmware is protected by signature using the first private key corresponding to the first trust root; the second firmware is protected by signature using the second private key corresponding to the second trust root.

[0022] In addition, in the embodiments of the present application, the trust verification of the first firmware to be verified based on the first trust root includes:

[0023] Using the first trust root to decrypt the signature of the first firmware to obtain a second verification value;

[0024] Using a second preset algorithm to process the first firmware to obtain a third verification value;

[0025] In the case where the second verification value matches the third verification value, it is determined that the verification result of the first trust root for the first firmware is trustworthy.

[0026] In this embodiment, if the first trust root is trustworthy, the trust verification of the corresponding firmware can be achieved accordingly. This process has no requirement for mutual trust between trust roots and has a wide range of applicable scenarios.

[0027] In addition, in the embodiments of the present application, the multiple trust roots corresponding to the target trusted root include: the first trust root, the second trust root, and the third trust root;

[0028] The first firmware is further protected by signature using the third private key corresponding to the third trust root, and the second firmware is further protected by signature using the third private key corresponding to the third trust root;

[0029] The method further includes:

[0030] Performing trust verification on the first firmware to be verified based on the third trust root; in the case where the verification results of the first trust root and the third trust root for the first firmware are trustworthy, or, in the case where the verification result of at least one of the first trust root and the third trust root for the first firmware is trustworthy, it is determined that the first firmware is trustworthy;

[0031] and / or,

[0032] Perform a trust verification on the second firmware to be verified based on the third trust base; when the verification results of the second firmware by the second trust base and the third trust base are trustworthy, or when the verification results of the second firmware by at least one of the second trust base and the third trust base are trustworthy, determine that the second firmware is trustworthy.

[0033] In this embodiment, trust verification can be performed on multiple firmwares through multiple trust bases, which can solve the trust verification problem in the scenario where the owners of each trust base do not trust each other in the related art and ensure the security of the firmware.

[0034] In addition, in the embodiment of the present application, when the first firmware and the second firmware are the same firmware;

[0035] The performing a trust verification on the first firmware to be verified based on the first trust base when the first trust base passes the trust verification; and / or the performing a trust verification on the second firmware to be verified based on the second trust base when the second trust base passes the trust verification includes:

[0036] When the first trust base passes the trust verification, perform a trust verification on the first firmware to be verified based on the first trust base;

[0037] When the second trust base passes the trust verification, perform a trust verification on the first firmware to be verified based on the second trust base;

[0038] When the verification results of the first firmware by the first trust base and the second trust base are trustworthy, and / or when the verification results of the first firmware by at least one of the first trust base and the second trust base are trustworthy, determine that the first firmware is trustworthy.

[0039] In this embodiment, multiple trust verifications can be performed on one firmware through multiple trust bases, which can solve the trust verification problem in the scenario where the owners of each trust base do not trust each other in the related art and ensure the security of the firmware.

[0040] In addition, in the embodiment of the present application, the chip includes: a trusted root area and an identification area;

[0041] Wherein, the trusted root area is used for solidifying and storing the target trusted root;

[0042] Wherein, the identification area is used for storing identification information, and the identification information is used to indicate the current valid trust base;

[0043] Among them, the identification area includes a plurality of identification bits, and the identification area indicates the effective trust root through the assignment combination mode of each identification bit.

[0044] In this embodiment, through the identification area maintained in the chip, the effective trust root can be securely indicated, and this method also ensures the possibility of switching the effective trust root, with high security and high flexibility.

[0045] In addition, in the embodiment of the present application, a readable storage area is provided in the chip;

[0046] The readable storage area is provided with an electronic fuse;

[0047] The target trusted root is stored and solidified in the electronic fuse.

[0048] In this embodiment, through the superior anti-tampering ability of the electronic fuse, the security of the target trusted root is guaranteed.

[0049] According to another aspect of the present application, a firmware trust verification device is provided, including:

[0050] An acquisition unit, configured to acquire a target trusted root;

[0051] A first verification unit, configured to perform trust verification on a first trust root and a second trust root among a plurality of trust roots based on the target trusted root; wherein, the target trusted root is determined based on the plurality of trust roots through a first preset algorithm, so that the target trusted root can perform trust verification on any one of the plurality of trust roots;

[0052] A second verification unit, configured to perform trust verification on the first firmware to be verified based on the first trust root when the first trust root passes the trust verification; and / or, perform trust verification on the second firmware to be verified based on the second trust root when the second trust root passes the trust verification.

[0053] In the embodiment of the present application, a target trusted root is determined based on a plurality of trust roots through a first preset algorithm. In this way, there is no need for mutual trust among the plurality of trust roots, that is, a trusted root can be associated with a plurality of trust roots for the security verification of the plurality of trust roots. Based on this mechanism, a target trusted root can be used for the security verification of a plurality of trust roots. Thus, when it comes to scenarios that require trust protection using a plurality of trust roots, there is no need to pay an additional cost for maintaining the trusted root, and it also avoids the limitation of the number of trusted roots on the number of trust roots, and breaks through the resulting problem of limited expansion, reducing the implementation cost and having high scalability. The technical solution provided by the present application can solve the trust verification problem of multiple trust roots and their derived multiple trust chains with a relatively low cost of maintaining the trusted root.

[0054] In addition, in the embodiment of the present application, the first verification unit is specifically configured to:

[0055] Process a plurality of trust bases including the first trust base through the first preset algorithm to obtain a first verification value;

[0056] Determine that the first trust base is trustworthy when the first verification value matches the target trusted root.

[0057] The embodiment of the present application can process a plurality of trust bases through the first preset algorithm and then compare them. By using the trustworthy target trusted root, it verifies whether each trust base is trustworthy, ensuring that there is a trustworthy verification basis for subsequent possible trust verification processes.

[0058] In addition, in the embodiment of the present application, the first preset algorithm is implemented by one or more hash functions;

[0059] Wherein, the first preset algorithm includes: a nested algorithm of an N-layer hash algorithm; in the nested algorithm, the hash result of the i-th layer hash algorithm is used as the content of the (i + 1)-th layer hash algorithm;

[0060] Wherein, the i-th layer hash algorithm is an OR value of the following three hash results: the hash result based on the first trust base, the hash result based on the second trust base, and the hash result based on the first trust base and the second trust base.

[0061] In this embodiment, the first preset algorithm is implemented by a nested hash algorithm. This processing method can effectively increase the complexity and difficulty of calculating the target trusted root by piecing together, and thus can improve the security of the target trusted root to a certain extent, ensuring that the core verification basis of the trust verification scheme is trustworthy and has high security.

[0062] In addition, in the embodiment of the present application, the plurality of trust bases trust, distrust, or partially trust each other.

[0063] In addition, in the embodiment of the present application, one trust base is used to verify and protect one firmware; and / or, one trust base is used to verify and protect multiple firmwares; and / or, multiple trust bases are used to verify and protect one firmware. The embodiments of the present disclosure can be applied to various trust verification scenarios and have wide applicability.

[0064] In addition, in the embodiment of the present application, the plurality of trust bases corresponding to the target trusted root are public keys; any one of the public keys uniquely corresponds to a private key;

[0065] The first firmware is protected by a signature of the first private key corresponding to the first trust base; the second firmware is protected by a signature of the second private key corresponding to the second trust base.

[0066] In addition, in the embodiment of the present application, the second verification unit is specifically configured to:

[0067] Decrypt the signature of the first firmware by using the first trust base to obtain a second verification value;

[0068] Process the first firmware by using a second preset algorithm to obtain a third verification value;

[0069] When the second verification value matches the third verification value, determine that the verification result of the first trust base for the first firmware is trustworthy.

[0070] In this embodiment, if the first trust base is trustworthy, the trust verification of a corresponding firmware can be implemented accordingly. This process has no requirement on whether the trust bases trust each other and has a wide range of application scenarios.

[0071] In addition, in the embodiment of the present application, the multiple trust bases corresponding to the target trusted root include: the first trust base, the second trust base, and the third trust base;

[0072] The first firmware is also protected by a signature of a third private key corresponding to the third trust base, and the second firmware is also protected by the signature of the third private key corresponding to the third trust base;

[0073] The second verification unit is further configured to:

[0074] Perform trust verification on the first firmware to be verified based on the third trust base; when the verification results of the first trust base and the third trust base for the first firmware are trustworthy, or when the verification results of at least one of the first trust base and the third trust base for the first firmware are trustworthy, determine that the first firmware is trustworthy;

[0075] And / or

[0076] Perform trust verification on the second firmware to be verified based on the third trust base; when the verification results of the second trust base and the third trust base for the second firmware are trustworthy, or when the verification results of at least one of the second trust base and the third trust base for the second firmware are trustworthy, determine that the second firmware is trustworthy.

[0077] In this embodiment, trust verification of multiple firmwares can be implemented through multiple trust bases, which can solve the trust verification problem in the scenario where the owners of the trust bases do not trust each other in related technologies and ensure the security of the firmware.

[0078] In addition, in the embodiment of the present application, when the first firmware and the second firmware are the same firmware; the second verification unit is specifically configured to:

[0079] When the first trust root passes the trust verification, perform trust verification on the first firmware to be verified based on the first trust root;

[0080] When the second trust root passes the trust verification, perform trust verification on the first firmware to be verified based on the second trust root;

[0081] When the verification results of the first firmware by the first trust root and the second trust root are trustworthy, and / or when the verification results of the first firmware by at least one of the first trust root and the second trust root are trustworthy, determine that the first firmware is trustworthy.

[0082] In this embodiment, multiple trust roots can be used to perform multiple trust verifications on one firmware, which can meet the trust verification problems in scenarios where the owners of each trust root do not trust each other in the related art, and ensure the security of the firmware.

[0083] In addition, in the embodiment of the present application, the chip includes: a trusted root area and an identification area;

[0084] Among them, the trusted root area is used to fixedly store the target trusted root;

[0085] Among them, the identification area is used to store identification information, and the identification information is used to indicate the current effective trust root;

[0086] Among them, the identification area includes multiple identification bits, and the identification area indicates the effective trust root through the assignment combination method of each identification bit.

[0087] In this embodiment, through the identification area maintained in the chip, the effective trust root can be safely indicated, and this method also ensures the possibility of switching the effective trust root, with high security and high flexibility.

[0088] In addition, in the embodiment of the present application, a readable storage area is provided in the chip;

[0089] The readable storage area is provided with an electronic fuse;

[0090] The target trusted root is fixedly stored in the electronic fuse.

[0091] In this embodiment, through the excellent anti-tampering ability of the electronic fuse, the security of the target trusted root is ensured.

[0092] According to another aspect of the embodiments of the present application, a chip is provided, in which a target trusted root is stored in a solidified manner.

[0093] Wherein, the target trusted root is determined based on a plurality of trust bases through a first preset algorithm, so that the target trusted root can perform trust verification on any one of the plurality of trust bases.

[0094] In the embodiments of the present application, a trusted root is stored in a solidified manner in the chip. In a specific trust verification scenario, only one target trusted root is required to achieve the security verification of a plurality of associated trust bases, without requiring mutual trust among the trust bases, and has a wide range of applications. When it comes to scenarios that require trust protection using a plurality of trust bases, there is no need to pay additional trusted root maintenance costs, and it also avoids the limitation of the number of trusted roots on the number of trust bases, and breaks through the resulting expansion limitation problem, reducing the system implementation cost and having high scalability.

[0095] In addition, in the embodiments of the present application, a readable storage area is provided in the chip;

[0096] The readable storage area is provided with an electronic fuse;

[0097] The target trusted root is stored in a solidified manner in the electronic fuse.

[0098] In this embodiment, the security of the target trusted root is guaranteed by the excellent anti-tampering ability of the electronic fuse.

[0099] In addition, in the embodiments of the present application, the chip includes: a trusted root area and an identification area;

[0100] Wherein, the trusted root area is used to store the target trusted root in a solidified manner;

[0101] Wherein, the identification area is used to store identification information, and the identification information is used to indicate the current valid trust base;

[0102] Wherein, the identification area includes a plurality of identification bits, and the identification area indicates the valid trust base through the assignment combination mode of each identification bit.

[0103] In this embodiment, through the identification area maintained in the chip, the security indication of the valid trust base can be realized, and this method also guarantees the possibility of switching the valid trust base, with high security and high flexibility.

[0104] According to another aspect of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory, and the processor executes the computer program to implement the method described in any one of the above embodiments.

[0105] According to another aspect of the embodiments of the present application, there is provided a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method described in any one of the above embodiments is implemented.

[0106] According to another aspect of the embodiments of the present application, there is provided a computer program product, including a computer program, and when the computer program is executed by a processor, the method described in any one of the above embodiments is implemented.

[0107] As will be described in detail below, according to a firmware trust verification method, a chip, and an electronic device according to the embodiments of the present application, a target trusted root in the present application is determined based on a plurality of trust bases through a first preset algorithm. In this way, it is not necessary for the plurality of trust bases to trust each other, that is, a trusted root can be associated with the plurality of trust bases for security verification of the plurality of trust bases. Based on this mechanism, a target trusted root can be used for security verification of a plurality of trust bases. Thus, when it comes to scenarios that require trust protection using a plurality of trust bases, there is no need to incur additional trusted root maintenance costs, and it also avoids the limitation of the number of trusted roots on the number of trust bases, and breaks through the resulting problem of limited expansion, reducing the system implementation cost and having high scalability.

[0108] It should be understood that both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the claimed technology. BRIEF DESCRIPTION OF THE DRAWINGS

[0109] By describing the embodiments of the present application in more detail in conjunction with the accompanying drawings, the above and other objects, features, and advantages of the present application will become more apparent. The accompanying drawings are used to provide a further understanding of the embodiments of the present application, and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation to the present application. In the accompanying drawings, the same reference numerals generally represent the same components or steps.

[0110] Figure 1 FIG. is a schematic diagram of the association relationship between a trusted root and a trust base provided for the embodiments of the present application.

[0111] Figure 2 FIG. is a schematic diagram of the architecture of a chip provided for the embodiments of the present application.

[0112] Figure 3 FIG. is a schematic flowchart of a trust verification method provided for the embodiments of the present application.

[0113] Figure 4 FIG. is a schematic diagram of a trust verification method provided for the embodiments of the present application.

[0114] Figure 5 FIG. is a schematic diagram of another trust verification method provided for the embodiments of the present application.

[0115] Figure 6 Schematic diagram of another trust verification method provided by an embodiment of the present application.

[0116] Figure 7 Schematic diagram of a system storage relationship provided by an embodiment of the present application.

[0117] Figure 8 Schematic diagram of another trust verification method provided by an embodiment of the present application.

[0118] Figure 9 Schematic diagram of another trust verification method provided by an embodiment of the present application.

[0119] Figure 10 Block diagram of the structure of a firmware trust verification device provided by an embodiment of the present application.

[0120] Figure 11 Hardware block diagram of an electronic device provided by an embodiment of the present application.

[0121] Figure 12 Schematic diagram of a computer-readable storage medium provided by an embodiment of the present application. Detailed implementation manners

[0122] In order to make the objectives, technical solutions and advantages of the present application more obvious, exemplary embodiments according to the present application will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. It should be understood that the present application is not limited by the exemplary embodiments described herein.

[0123] The embodiments of the present application are applied to the trust verification scenario, and may also be specifically the firmware check (or referred to as firmware resilience check) scenario, which is used to perform trust verification on the security of the firmware to ensure that the firmware has not been tampered with and is secure and reliable.

[0124] Exemplarily, when the server system is started, the firmware installed in the system can be automatically subjected to trust verification. Exemplarily, when the system is updated, after the system update, the entire system or the firmware with local updates in the system can be automatically subjected to trust verification. Exemplarily, the system can perform trust verification based on user instructions. Exemplarily, the system can also be docked with other systems, and based on the access, call or application of the firmware in the present system by other systems, the firmware in the present system can be subjected to trust verification. Exemplarily, in the firmware development scenario, the system can also perform trust verification based on other arbitrary custom rules such as different development progress (for example, automatically performing trust verification when the firmware development is completed), changes in the development entity (for example, firmware 1 changes from developer A to developer B), etc. The embodiments of the present application have no special limitations and are not exhaustive.

[0125] The system involved here means a system that can manage and maintain the firmware. In actual scenarios, it can generally be the system where the firmware is located (or the system that runs the firmware) or the management system of the device where the firmware is located. In addition, the system referred to here can be a software and / or hardware system; from a hardware perspective, it can be a device or a collection of multiple devices, or the system can also be a software system that can perform trust verification on the firmware. The systems to which the present disclosure is applicable may include, but are not limited to: server systems. Hereinafter referred to as servers for specific explanation.

[0126] For the trust verification scenario, the embodiment of the present application proposes a new solution: a trusted root is stored in the chip, and a trusted root can be obtained by processing multiple trust bases using a preset algorithm. In this way, multiple trust bases can be verified to be trustworthy through a trusted root. Furthermore, for any trust base, when it is trusted, one or more subsequent verifications on the trust chain can be performed based on it. Under the premise of ensuring the security of the verification, the cost is low, and the resources stored in the chip can be consistent with the existing situation, without adding too many trusted root maintenance resources or maintenance costs. In addition, this solution does not require mutual trust between multiple trust bases. Trust bases can trust each other or not, which can meet the security verification needs of multinational cooperative enterprises under the premise of non-trust in existing scenarios. The following is a detailed explanation.

[0127] Specifically, a root of trust is fixedly stored in the chip provided in the embodiment of the present application, and the target root of trust is determined based on the multiple trust bases through a first preset algorithm, so that the target root of trust can perform trust verification on any one of the multiple trust bases.

[0128] The embodiments of the present application have no special restrictions on the type and purpose of the chip, and the actual scenario can be customized. Exemplarily, the chips involved in the embodiments of the present application may include, but are not limited to: encryption chips, non-encryption chips. Exemplarily, the chips involved in the embodiments of the present application may be specifically a security chip for simple trust verification, or it may be a comprehensive chip that can be used for other data processing and other functions. For example, the chip may include, but is not limited to, at least one of the following: a security chip, an image processing chip, a data processing chip, etc., without exhausting them.

[0129] For example, please refer to Figure 1 , Figure 1 A schematic diagram of the relationship between a trusted root and a trust base provided in an embodiment of the present application. Figure 1 As shown, a trusted root can be associated with multiple trust bases ( Figure 1Three trust bases are shown as an example. The embodiment of the present application has no special restrictions on their number and type, which will be described in detail later) associated matching. In other words, trust verification of the three trust bases can be achieved through a trusted root.

[0130] In addition, it should be noted that in actual scenarios, there may be one or more trusted roots stored in the chip, and the solution provided in the embodiment of the present application has no special restrictions on this. However, in general, considering the trusted root maintenance cost, even if only one trusted root is maintained in the chip, this solution can be implemented. For ease of explanation, the following text will take the case of one trusted root as an example for specific explanation.

[0131] In a specific scenario, the trusted root can be specifically a value (including but not limited to a hash value). The trusted root (i.e., the value stored in the chip) can be obtained by processing multiple trust bases (values) based on a first preset algorithm (the processing method is described in detail later). In this way, the trusted root can be associated with multiple trust bases and achieve unified verification of multiple trust bases. Based on this, when performing a specific trust verification, the multiple trust bases to be verified can be processed using the first preset algorithm (i.e., consistent with the processing method for obtaining the trusted root) to obtain a verification value (such as a hash value), which is then compared with the trusted root. If the two are consistent, it means that multiple trust bases have passed the verification.

[0132] In other words, the trusted root involved in the embodiment of the present application (and the target trusted root in the following text) refers to the data stored in the chip for trust verification. The trust base involved in the embodiment of the present application refers to the data that can directly obtain the trusted root through the first preset algorithm processing and can be used for trust verification. The embodiment of the present application has no special restrictions on the data types of the trusted root and the trust base. In the actual scenario, the value of the trusted root is related to the first preset algorithm. For example, if the first preset algorithm is a hash algorithm, the trusted root can be specifically a hash value. The trust base can be used for trust verification, which means data that can be used for trust verification of one or more of firmware, other types of trust verification data, and other hardware; in the actual scenario, the trust base can specifically include but is not limited to: public key, identification information (such as the name of the firmware owner, manager or user or other identification information) and one or more. It should be understood that based on the asymmetric encryption mechanism, the public key generally has a corresponding private key.

[0133] For example, if A, B, and C are processed through a first preset algorithm to obtain D, and D is stored in the chip in a fixed manner, then D is the trusted root, while A, B, and C are the trust bases. There are no special restrictions on the relationship among A, B, and C in the embodiments of the present application. Further, there are no special requirements on whether the multiple trust bases associated with the trusted root trust each other in the embodiments of the present application. In other words, the multiple trust bases associated with the trusted root in the embodiments of the present application can trust, distrust, or partially trust each other. For example, if a trusted root is associated with two trust bases, these two trust bases can trust each other or not trust each other. When performing trust verification, as long as the multiple trust bases can be processed according to the first preset algorithm and the verification value obtained is compared with the trusted root, it can be determined whether these two trust bases are trustworthy; in this process, whether these two trust bases trust each other does not prevent the implementation and application of the technical solution provided by the embodiments of the present application.

[0134] In the embodiments of the present application, the trusted root is generally stored in the chip in a fixed manner. Specifically, it can be stored in the readable storage area in the chip. Further, in order to ensure the immutability of the trusted root, a non-volatile storage device with one-time programmable capability can also be used to store the trusted root in a fixed manner. In an actual scenario, the trusted root can be stored and maintained by, but not limited to, using an electronic fuse (eFuse).

[0135] Please refer to Figure 2 , Figure 2 which is a schematic diagram of the architecture of a chip provided by the embodiments of the present application. As Figure 2 shown, a readable storage area 210 is provided in the chip 200; further, an electronic fuse 211 is provided in the readable storage area 210, and the trusted root is stored in the electronic fuse 211.

[0136] In addition, it should also be understood that in an actual implementation scenario, there may be more storage areas in the chip, or more data may be stored. There are no special restrictions on this in the embodiments of the present application. For example, the readable storage area in the chip may also store one or more of a chip identifier, chip attribute information, manufacturer information, etc., without exhaustive listing.

[0137] In addition, in an actual scenario, both the chip and the firmware can be within the scope of a server. From the perspective of the server, the storage relationship of the entire server, in addition to including the storage relationship in the chip as shown in Figure 2 , also involves storage areas other than Figure 2 . This part of the storage area can be used to store other arbitrary data such as firmware and trust bases that need to be stored. For ease of understanding, Figure 2 also shows the schematic storage architecture relationship of the storage areas other than the chip. As Figure 2As shown, in addition to the trusted root being stored in the chip in a fixed manner, the storage area of the server can also store firmware, and can also store the trust base of the firmware, that is, public key one, public key two, and public key three.

[0138] It should be noted that in the embodiments of the present application, the trust base associated with the trusted root can be any type of data. Exemplarily, the trust base can specifically include but is not limited to: public keys (such as Figure 2 as shown), custom codes, custom verification information, and any one or more types of data with trust verification functions. In actual scenarios, the maintenance entities of each firmware (such as the customization party, the production party, the user, etc.) can use their respective private keys to sign and protect the firmware, so that the public key can be directly used for verification and protection.

[0139] In the embodiments of the present application, one or more trust bases are used to verify and protect one or more firmwares, that is, trust verification of the firmware can be performed based on the trust base. Exemplarily, the private key in a pair of public-private keys can be used to sign the firmware. Thus, when performing trust verification on the firmware, the public key corresponding to the private key (that is, the public key in the public-private key pair) can be directly used to verify whether the firmware has been tampered with. Specifically, the signature of the firmware can be decrypted using the public key to obtain the verification parameters in the signature, and the verification parameters can be compared with the hash value of the firmware to determine whether the firmware has been tampered with.

[0140] It should be noted that in the embodiments of the present application, there is no special restriction on the corresponding relationship between the trust base and the firmware. In actual scenarios, the following possible situations may occur:

[0141] One trust base is used to verify and protect one firmware; and / or,

[0142] One trust base is used to verify and protect multiple firmwares; and / or,

[0143] Multiple trust bases are used to verify and protect one firmware.

[0144] For example. Taking the private key 1 and the public key 1, the private key 2 and the public key 2, and the private key 3 and the public key 3 as the corresponding public-private key pairs respectively, and the firmware is signed and protected by the private key, and the public key is used as the trust base to be associated with the trusted root and used to verify and protect the firmware as an example.

[0145] For example, in a possible embodiment, one trusted root can be associated with 2 public keys (that is, the trusted root is determined based on 2 public keys through a first preset algorithm). Among them, firmware 1 is signed and protected by private key 1, and firmware 2 is signed and protected by private key 2; thus, when performing trust verification, public key 1 can be used to perform trust verification on firmware 1, and public key 2 can be used to perform trust verification on firmware 2. That is, the situation where one trust base is used to verify and protect one firmware.

[0146] For another example, in another possible embodiment, a trusted root can be associated with two public keys (i.e., the trusted root is determined based on two public keys through a first preset algorithm); Firmware 1 is protected by signatures of private key 1 and private key 2 respectively; In this case, when performing trust verification, both public keys are used to perform trust verification on Firmware 1. That is, the situation where two trust bases are used to perform verification and protection on one firmware.

[0147] For another example, in another possible embodiment, a trusted root can be associated with two public keys (i.e., the trusted root is determined based on two public keys through a first preset algorithm); Firmware 1 is protected by the signature of private key 1, and Firmware 2 is also protected by the signature of private key 1; In this case, when performing trust verification, public key 1 can be used to perform trust verification on Firmware 1 and can also be used to perform trust verification on Firmware 2. That is, the situation where one trust base is used to perform verification and protection on multiple firmwares.

[0148] For another example, in another possible embodiment, a trusted root can be associated with three public keys (i.e., the trusted root is determined based on two public keys through a first preset algorithm); Firmware 1 is protected by signatures of private key 1 and private key 2 respectively, and Firmware 2 is protected by signatures of private key 2 and private key 3 respectively. In this case, public key 1 can be used to perform trust verification on Firmware 1; Public key 2 can be used to perform trust verification on both Firmware 1 and Firmware 2; Public key 3 can be used to perform trust verification on Firmware 2. That is, in one scenario, there can be a situation where one trust base is used to perform verification and protection on one firmware, such as public key 1 and public key 3, and there can also be a situation where multiple trust bases are used to perform verification and protection on multiple firmwares, such as public key 2.

[0149] As exemplified above, in the embodiments of the present application, there are no special restrictions on the verification and protection between the trust base and the firmware. It can adopt a single case of the above three possible situations, or a combined scheme. The embodiments of the present application do not limit this and do not list them exhaustively. Examples will be given later.

[0150] Based on the above design, the following specifically describes a trust verification method provided by the embodiments of the present application.

[0151] Please refer to Figure 3 , Figure 3 which is a schematic flowchart of a trust verification method provided by the embodiments of the present application. As Figure 3 shown, the method includes:

[0152] S302, obtain a target trusted root.

[0153] The target trusted root here is any one of the trusted roots fixedly stored in the chip.

[0154] S304. Perform trust verification on the first trust base and the second trust base among multiple trust bases based on the target trusted root. The target trusted root is determined based on multiple trust bases through a first preset algorithm, so that the target trusted root can perform trust verification on any one of the multiple trust bases.

[0155] The target trusted root is determined based on multiple trust bases through a first preset algorithm. The number of multiple trust bases here is not limited and can be arbitrarily customized. In this embodiment, it should be understood that at least the first trust base and the second trust base are included in the multiple trust bases. In an actual scenario, there can be a greater number of trust bases associated with the target trusted root. For example, in a possible embodiment, the target trusted root can be determined based on the first trust base, the second trust base, the third trust base, and the fourth trust base through a first preset algorithm. Thus, the target trusted root has the ability to perform trust verification on these 4 trust bases. However, in an actual application scenario, based on this ability, it can be used to perform trust verification on all the trust bases associated with the target trusted root, or it can also be used to perform trust verification on some of the trust bases. The present disclosure has no special restrictions on this.

[0156] In this step, the target trusted root is directly associated with multiple trust bases, and one-time verification of multiple trust bases can be achieved based on the target trusted root.

[0157] Specifically, the first preset algorithm can be used to process multiple trust bases (including the first trust base and the second trust base) to obtain a verification value. Then, compare whether the calculated verification value is consistent with the trusted root. If the two are consistent, it proves that none of the multiple trust bases have been tampered with and are trustworthy. Otherwise, it can be determined that the trust base is untrustworthy.

[0158] Taking the first trust base as an example, the purpose of verification in this step is to verify whether the first trust base is one of the multiple trust bases associated with the target trusted root. Thus, if the first trust base is one of the multiple trust bases associated with the target trusted root, it is determined that the first trust base is trustworthy. Therefore, further firmware verification can be performed based on the first trust base. Otherwise, if the first trust base is not one of the multiple trust bases associated with the target trusted root, it is determined that the first trust base is untrustworthy, and there is no need to perform subsequent trust verification processes, and the entire trust verification result is untrustworthy.

[0159] S306. When the first trust base passes the trust verification, perform trust verification on the first firmware to be verified based on the first trust base; and / or when the second trust base passes the trust verification, perform trust verification on the second firmware to be verified based on the second trust base.

[0160] When the trust root is trustworthy, the trustworthy trust root can be utilized to perform trust verification on the corresponding firmware. Among them, for any trust root, its corresponding firmware refers to the firmware encrypted and protected using the data related to the trust root (such as the private key corresponding to the public key). In the actual scenario, which data (such as the private key) is used to encrypt and protect the firmware has been maintained in the server during scenarios such as server installation and upgrade. One can directly perform verification and protection based on the public key corresponding to this private key. Taking this as an example, in one embodiment, the trust root can be a public key. Thus, the first firmware can be protected by being signed with the first private key corresponding to the first trust root. Correspondingly, when the first trust root passes the trust verification, the first firmware to be verified can be subjected to trust verification based on the first trust root. The situation of the second firmware is similar and will not be elaborated.

[0161] In one possible embodiment, the public key and the private key, as a pair of public-private key pairs, can, based on the principle of asymmetric encryption in the actual scenario, be used to sign and protect the firmware with the private key, and the public key, the signature, and the firmware are all stored in the server. Thus, when the server starts up (this is only for illustrative purposes here, and there can be other scenarios, refer to the previous text), when firmware inspection is required, it is possible to compare whether the verification value calculated from multiple public keys is consistent with the trusted root stored in the eFuse. If the two are consistent, it proves that none of the multiple public keys have been tampered with and are trustworthy. Furthermore, the signatures of the firmware are subjected to trust verification using these trustworthy public keys. If the verification passes, it indicates that the firmware has not been tampered with.

[0162] In addition, in actual scenarios, due to different requirements for trust verification, S306 can be implemented in different ways. In one way, it can be to perform trust verification on a specific firmware alone, that is, S306 is implemented in an "OR" manner, and trust verification is performed on the first firmware or the second firmware alone. For example, when the developer of the first firmware performs trust verification, they only focus on whether the first firmware passes the trust verification and do not care about the situation of the second firmware. Another example is that the first firmware is security-verified by the first trust root, and the first trust root belongs to developer A. Developer A only cares about whether the firmware protected by their own private key signature is trustworthy and does not care about whether other firmware (i.e., the second firmware) protected by the signature of others (such as the second trust root and its second private key corresponding to developer B) is trustworthy. Therefore, when executing S306, only the first firmware to be verified needs to be trust-verified based on the first trust root. Or, in another way, S306 can also be implemented in an "AND" manner to perform trust verification on both the first firmware and the second firmware. For example, after the server starts, by default, trust verification is performed on all the firmware installed on the server. At this time, trust verification needs to be performed on both the first firmware and the second firmware. Another example is that after the server is updated, trust verification needs to be performed on all the firmware associated with the target trusted root. In summary, based on different actual trust verification scenarios and requirements, S306 can have different implementation methods. It can perform trust verification on all or part of the firmware in the server, or on all or part of the firmware associated with a certain target trusted root, or on the firmware associated with one or more trust roots. This is not an exhaustive list.

[0163] In addition, it should also be noted that when using a trust root to perform trust verification on the corresponding firmware, for any one firmware, if the firmware uses multiple pieces of trust root-related data for encryption protection. Generally, for this firmware, it can be determined that the firmware is trustworthy only when the trust verification of all the trust roots corresponding to the firmware is trustworthy. Or, in some possible embodiments, since the maintenance entities of each trust root may be different, when different maintenance entities perform trust verification on the firmware, for the trust verification process of any one maintenance entity on the firmware, as long as the trust verification result of the trust root corresponding to the maintenance entity on the firmware is trustworthy, then for this maintenance entity, the firmware is trustworthy.

[0164] For example, if the firmware 1 is protected by signature using the private key 1 and the private key 2 respectively, where the private key 1 and the public key 1 are the public-private key pair corresponding to the manufacturer of the firmware 1, and the private key 2 and the public key 2 are the public-private key pair corresponding to the user of the firmware 1. In this way, in one possible case, when the verification result of the firmware 1 using the public key 1 is trustworthy and the result of the firmware 1 using the public key 2 is also trustworthy, it is determined that the firmware 1 is trustworthy; or, in another possible case, for example, when the user does not care about the verification result on the manufacturer side, for the user, when the result of the firmware 1 using the public key 2 is trustworthy, it can be determined that the firmware 1 is trustworthy. It should be understood that this is only an example. In the actual scenario, any maintenance entity can also perform trust verification on the firmware based on one or more other trust bases, which will not be elaborated here.

[0165] In summary, in the embodiment of the present application, a target trusted root is determined based on multiple trust bases through a first preset algorithm. In this way, there is no need for mutual trust between multiple trust bases, that is, a trusted root can be associated with multiple trust bases for security verification of multiple trust bases. Based on this mechanism, a target trusted root can be used for security verification of multiple trust bases. Thus, when it comes to scenarios that require using multiple trust bases for trust protection, on the one hand, there is no need to pay additional trusted root maintenance costs, and it also avoids the limitation of the trusted root data on the number of trust bases, and breaks through the resulting scalability limitation problem, reducing the server implementation cost and having high scalability; on the other hand, in the technical solution provided by the embodiment of the present application, there is no special requirement for whether the multiple trust bases associated with the target trusted root are mutually trusted. Even if they are not mutually trusted at all, it is still possible to safely perform trust verification on the trust bases and the firmware. In other words, the embodiment of the present application also breaks through the technical barrier that the traditional trust transfer scheme requires mutual trust between trust bases to achieve firmware inspection, broadens the applicable scenarios of trust verification, and can meet the firmware resilience requirements of different scenarios. Based on this, when implementing firmware inspection in the embodiment of the present application, a target trusted root can be directly used to achieve trust verification of multiple trust bases. Thus, when the trust base passes the verification (i.e., is trustworthy), the corresponding firmware is verified using this trust base. In this process, there is no need to consider whether the multiple trust bases corresponding to the firmware are mutually trusted, and there is no need to consider the influence of the number of trusted roots on the number of trust bases. Only by gradually performing trust verification can the firmware inspection be completed safely and efficiently.

[0166] In addition, as mentioned above, the trusted root is associated with multiple trust bases. Specifically, the trusted root is a value that can be obtained based on the processing of multiple trust bases. Therefore, based on the trusted root, unified trust verification can be performed on the multiple trust bases it is associated with.

[0167] In specific implementation, the first preset algorithm can be used to process multiple trust bases including the first trust base to obtain a first verification value. Thus, when the first verification value matches the target trusted root, it is determined that the first trust base is trustworthy.

[0168] For example. The trusted root can be associated with public key 1, public key 2, and public key 3. In this way, when performing trust verification on public key 1, the first preset algorithm is used to process the public key 1 to be verified together with public key 2 and public key 3 to obtain a first verification value and perform subsequent verification.

[0169] In the embodiments of the present application, the first preset algorithm is used to perform security processing on multiple trust bases. Among them, security processing means that based on multiple trust bases, processing is performed to prevent the original information from being tampered with, and finally a processed value (such as the trusted root and the first verification value mentioned above) is obtained. In actual scenarios, the first preset algorithm can include, but is not limited to, one or more of any existing or custom encryption algorithms, hash algorithms, etc.

[0170] In an exemplary embodiment, the first preset algorithm involved in the embodiments of the present application can include, but is not limited to, at least one of the following: direct hash processing, hash splicing processing, hash extension processing, and hybrid hash processing.

[0171] Among them, direct hash processing means directly performing hash processing on the concatenation result of multiple trust bases using a preset hash algorithm or hash function to obtain a target value (i.e., the trusted root or the first verification value). Hash splicing processing means first performing hash processing on each trust base, and then hashing the concatenated hash values again to obtain a target value. Hash extension processing means sequentially extending the hash value, first performing hash processing on the first trust base, and then concatenating the hash value with the second trust base and performing hash processing again. Through this extension operation, a target value is finally obtained. Hybrid hash processing means performing different hash processing on each trust base and then performing piecing and merging, and then performing hash processing to obtain a target value. Different hash processing includes, but is not limited to, the same hash method but different hashed values, different hash methods but the same hashed values, and different hash methods and hashed values, aiming to prevent attackers from accurately piecing together information.

[0172] In addition, in the actual implementation scenario, the first preset algorithm can be implemented by one or more hash functions, and further different first preset algorithms can be implemented by combining different hash functions.

[0173] Specifically, the first preset algorithm can include: a nested algorithm of an N-layer hash algorithm; the nested algorithm is that the hash result of the i-th layer hash algorithm is used as the content of the (i + 1)-th layer hash algorithm;

[0174] Among them, the hash algorithm of the i-th layer is the OR value of the following three hash results: the hash result based on the first trust base, the hash result based on the second trust base, and the hash result based on the first trust base and the second trust base.

[0175] Among them, the hashed content (which can also be called the content of the hash algorithm) can specifically be the data processed by the hash algorithm, and the hash result is the value obtained by processing the hashed content using the hash algorithm.

[0176] For example, the first preset algorithm can be expressed as: hash function 2(hash function 1(public key 1)), and this first preset algorithm is implemented through the nested combination of two layers of hash functions. During specific processing, the public key 1 (the public key 1 is the content of the hash algorithm) is processed using hash function 1 (i.e., the i-th layer hash function) to obtain the hash result 1 of hash function 1: hash function 1(public key 1). Then, this hash result 1 is used as the hashed content of hash function 2 (i.e., the i+1-th layer hash function) and substituted into hash function 2 to obtain the hash result 2 of hash function 2, that is: hash function 2(hash function 1(public key 1)), and hash function 2 is the final result obtained by the first preset algorithm. In this embodiment, the first preset algorithm is a nested algorithm that combines two layers of hash functions.

[0177] Among them, any layer of hash function combination includes at least one hash function. For example, the first preset algorithm can be expressed as: hash function 2(hash function 1(public key 1)||hash function 3(public key 2)). At this time, the hashed content of the second layer hash function has two, which are: hash function 1(public key 1) or hash function 3(public key 2). In other words, there are two first layer hash functions, and they can respectively perform hash processing on their own hashed content. In the actual scenario, the number of hash functions involved in a layer of hash function combination can be more or less, and they can be related or not related to each other.

[0178] Among them, in the case where a layer of hash function combination includes multiple hash functions, the multiple hash functions are the same, different, or partially the same, and / or, the hash contents of the multiple hash functions are the same, different, or partially the same. For example, in the first preset algorithm shown in the previous example, that is, hash function 2(hash function 1(public key 1)||hash function 3(public key 2)), in this embodiment, the two hash functions in the first layer are different, and the hash contents of the two hash functions (one is public key 1 and the other is public key 2) are also different. Another example, the first preset algorithm can be expressed as: hash function 2(hash function 1(public key 1)||hash function 1(public key 2)), in this embodiment, the two hash functions in the first layer are the same, both are hash function 1, but the hash contents of the two hash functions (one is public key 1 and the other is public key 2) are different. Another example, the first preset algorithm can be expressed as hash function 2(hash function 2(public key 1)||hash function 2(public key 2)), in this embodiment, the three hash functions involved in the two layers are the same, all are hash function 2, but the hash contents of the 3 hash functions (one is public key 1, one is public key 2, and one is the two hash results of the first layer) are different. In addition, the relationship between multiple hash functions in the same layer is not limited, and may include but is not limited to: AND relationship, OR relationship, custom algorithm relationship (such as addition, subtraction, multiplication, division or other custom functions), not exhaustive.

[0179] It should be understood that the above is only an exemplary description. In actual scenarios, there can be more complex designs to make the first preset algorithm less likely to be pieced together and cracked and more secure.

[0180] It should be noted that the present disclosure processes multiple trust bases using the first preset algorithm to obtain a trusted root. On this basis, among the multiple hash algorithms included in the first preset algorithm, there is at least one hash algorithm whose content is related to the trust base. For example, if N trust bases are involved, the first preset algorithm can be combined and nested through N hash algorithms to implement the processing of N trust bases. The layers of the hash algorithms where each trust base is located are not limited, and they can all be in the first layer or distributed among multiple levels.

[0181] In an exemplary embodiment, the i-th layer hash algorithm is the OR value of the following three hash results: the hash result based on the first trust base, the hash result based on the second trust base, and the hash result based on the first trust base and the second trust base. Among them, the OR value means that the data is in an "OR" relationship.

[0182] For ease of understanding, an example is given by taking the processing of public key 1, public key 2, and public key 3 with the first preset algorithm. It should be understood that the following example is only exemplary. In the actual scenario, the function algorithm of the hash function, the relationship between each public key in the hash function, the relationship between hash functions, etc. can all be custom-designed, and the embodiments of the present application have no special restrictions on this.

[0183] For example, when implementing the first preset algorithm in a direct hashing manner, at this time, the first preset algorithm method can be expressed as: hash function(public key 1 || public key 2 || public key 3). Among them, "||" represents "or". At this time, the first preset algorithm includes 1 layer of hash algorithm. The hash content of this first layer of hash algorithm is three trust bases, and the final result is the or-value hash result of the three trust bases.

[0184] Again, for example, when implementing the first preset algorithm in a hash concatenation manner, at this time, the first preset algorithm method can be expressed as: hash function(hash function(public key 1) || hash function(public key 2) || hash function(public key 3)). At this time, the first preset algorithm includes 2 layers of hash algorithms. Among them, the hash content of the first layer of hash algorithm is three trust bases; and the content of the second layer of hash algorithm is the or-value of the hash result of the previous layer.

[0185] Again, for example, the first preset algorithm can also be implemented in a hash extension manner. At this time, the first preset algorithm method can be expressed as: hash function(public key 1 || hash function(public key 2 || hash function(public key 1))). At this time, the first preset algorithm includes 3 layers of hash algorithms. Among them, the hash content of the first layer of hash algorithm is public key 1, and its hash result 1 is: hash function(public key 1); and the content of the second layer of hash algorithm is the or-value of the previous hash result 1 and public key 2, and its hash result 2 is: hash function(public key 2 || hash function(public key 1)); the content of the third layer of hash algorithm is the or-value of the previous hash result 2 and public key 1, and its hash result 3 is the final result, that is: hash function(public key 1 || hash function(public key 2 || hash function(public key 1))). In this embodiment, two public keys are located in hash algorithms at different levels.

[0186] For another example, the first preset algorithm can also be implemented by a mixed hash method. In this case, the first preset algorithm can be expressed as: hash function (hash function (hash function (public key one)||hash function (public key two)||hash function (public key three))||hash function (public key one||hash function (public key two||hash function (public key one)))); or, hash function (hash function A (hash function (public key one)||hash function (public key two))||hash function B (hash function (public key one)||hash function (public key two))); or, hash function (hash function (hash function (hash function (public key one)||hash function (public key two))||hash function (public key one||hash function (public key two))), etc., without exhaustive listing. In other words, the embodiment of the present application has no restrictions on the type of hash function used in the mixed hash process. For example, in the second case in the above example, hash function A and hash function B can be used simultaneously in the first preset algorithm, so that even if the attacker accurately pieces together the value of hash function A, it is difficult to keep the forged public key one and public key two under the action of hash function B, and their summary values ​​are still the same; and, the embodiment of the present application has no restrictions on the hash process of the hash function used in the mixed hash process, such as the third case in the above example, so that the attacker's accurate piecemeal can also be prevented by different hash processes. In the actual implementation scenario, in the mixed hash process (or the first preset algorithm), different hash functions and different hash processes can be used independently or in combination, and custom design can be used, without restrictions. In summary, the mixed hash method can prevent attackers from piecing together information to calculate the target value in a safer way, and prevent the trust verification scheme from being maliciously attacked, which also makes the result of the trust verification scheme more accurate and secure.

[0187] Based on this, when the trust verification for the first trust base described in S302 is specifically performed, it is only necessary to process the multiple trust bases with the first preset algorithm to obtain the first verification value; and correspondingly, the root of trust stored in the chip is obtained based on the multiple trust bases that are trusted and processed by the first preset algorithm; thus, it is only necessary to compare the two to obtain the verification result. That is, if the first verification value is consistent with the root of trust, it means that the multiple trust bases are all trustworthy.

[0188] It should be understood that in actual scenarios, the above S304 can implement trust verification of multiple trust bases through a trust verification process. For example, if the trusted root is associated with public key 1 and public key 2, when trust verification is required for both public key 1 and public key 2 in scenarios such as server restart, installation completion, or upgrade completion, both public key 1 and public key 2 can be used as trust bases to be verified, and public key 1 and public key 2 can be directly verified through a trust verification process to see if they are trustworthy.

[0189] When the first trust base (and / or the second trust base) is trustworthy, the corresponding firmware can be verified for trust accordingly. The implementation methods of the trust verification process of the first firmware using the first trust base and the trust verification process of the second firmware using the second trust base are the same; hereinafter, for the sake of simplicity, the implementation method of the trust verification process of the first firmware using the trustworthy first trust base will be taken as an example to illustrate it.

[0190] In a possible scenario, the multiple trust bases corresponding to the target trusted root are public keys; any one of the public keys uniquely corresponds to a private key; wherein, the first firmware is protected by signature using the first private key corresponding to the first trust base; the second firmware is protected by signature using the second private key corresponding to the second trust base. In this case, when verifying the trust of the first firmware using the trustworthy first trust base, it can be implemented through steps 1-3 shown below:

[0191] Step 1, decrypt the signature of the first firmware using the first trust base to obtain a second verification value.

[0192] As mentioned above, the relevant data of the trust base (such as the private key) is used to protect the firmware by signature. Thus, using the characteristics of the public-private key pair (i.e., the asymmetric encryption mechanism), when verifying the trust of the firmware, directly use the public key to decrypt its signature to obtain the second verification value therein.

[0193] Specifically, the value carried in the firmware signature for trust verification, that is, the second verification value, is generally a value obtained based on a second preset algorithm for the firmware. In addition, the second verification value is generally directly determined during the firmware installation stage or upgrade stage and is maintained as the trust verification information of the firmware in the firmware signature.

[0194] Step 2, process the first firmware using the second preset algorithm to obtain a third verification value.

[0195] The second preset algorithm is used to perform security processing on the firmware. Similar to the first preset algorithm, the second preset algorithm can also be implemented through one or more hash functions. The processing methods of the second preset algorithm can also include but are not limited to one or more of direct hash processing, hash splicing processing, hash extension processing, and hybrid hash processing. In the embodiments of the present application, both the second preset algorithm and the first preset algorithm can be preset in advance, and they can be the same or different. The embodiments of the present application have no special restrictions on this.

[0196] As described in step 1, the firmware signature generally carries the second verification value for trust verification. In order to verify whether the firmware stored in the current server has been tampered with, thus, the second preset algorithm can be processed based on the currently stored first firmware to obtain a third verification value, and by comparing whether the two are the same, it can be determined whether the firmware has been tampered with.

[0197] In addition, there is no restriction on the execution order of Step 1 and Step 2 in the embodiments of the present application. The two can be executed sequentially one after another, or can be executed in parallel, which will not be elaborated here.

[0198] Step 3, in the case where the second verification value matches the third verification value, determine that the verification result of the first trust root for the first firmware is trustworthy.

[0199] By comparing the second verification value with the third verification value, if the two match (or expressed as the two are consistent), then determine that the verification result of the first trust root for the first firmware is trustworthy.

[0200] In addition, as described above, for any firmware, assuming that the firmware is protected by signatures using the private keys corresponding to multiple trust roots, in order to specifically determine whether the first firmware is trustworthy, the following possible situations may exist:

[0201] In an exemplary embodiment of this scenario, if the first firmware is protected by signatures using the private keys of multiple trust roots, it is determined that the first firmware is trustworthy only when the verification results of each trust root for the first firmware are all trustworthy.

[0202] Or, in another exemplary embodiment of this scenario, if the first firmware is protected by signatures using the private keys of multiple trust roots, when the verification results of at least one trust root, or a specific one or more trust roots (preset in advance) for the first firmware are all trustworthy, it is determined that the firmware is trustworthy. Examples will be given later and will not be elaborated here.

[0203] For ease of understanding, the following takes the embodiments in a specific scenario as an example to illustrate the specific implementation manner of the present solution.

[0204] A possible embodiment is a multi-signature verification scheme based on non-mutually trusted trust roots. A trusted root matches multiple non-mutually trusted trust roots, and multiple trust chains are implemented through these trust roots.

[0205] The applicable scenario of this embodiment can refer to Figure 4 , Figure 4 is a schematic diagram of a trust verification method provided by the embodiments of the present application. That is, the first firmware is protected by a signature using the first private key corresponding to the first trust root; the second firmware is protected by a signature using the second private key corresponding to the second trust root. In this case, S306 is carried out as described above. In the case where the first trust root passes the trust verification, the first firmware to be verified is verified based on the first trust root; and / or, in the case where the second trust root passes the trust verification, the second firmware to be verified is verified based on the second trust root.

[0206] Specifically, Figure 4 As shown, a trusted root is maintained in the server, and the trusted root is associated with public key 1 and public key 2, which is determined based on public key 1 and public key 2 through a first preset algorithm. Among them, public key 1 and private key 1 are a pair of public-private key pairs, and public key 2 and private key 2 are a pair of public-private key pairs. Figure 4 As shown, firmware 1 is signed by private key 1, and firmware 2 is signed by private key 2. In this way, during the server installation or upgrade phase, the server will install public key 1, firmware 1, firmware 1 signature, public key 2, firmware 2, and firmware 2 signature.

[0207] When firmware verification is required, for example, in server startup or other scenarios where it is necessary to verify whether the firmware has been tampered with, firmware 1 and firmware 2 can be verified separately to determine whether they have been tampered with.

[0208] Specifically, checking whether firmware 1 has been tampered with can be achieved in the following ways:

[0209] S1A, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0210] S2A compares the hash value with the trusted root (i.e., the hash value stored in the chip, i.e., the target trusted root mentioned above); if they are consistent, it indicates that public key one has not been tampered with (i.e., public key one is trustworthy).

[0211] S3A, use hash function 2 (ie, the second preset algorithm) to process firmware 1 to obtain a hash value (ie, the third check value).

[0212] S4A, use public key one to decrypt firmware one signature and obtain the hash value (ie, the second verification value) in the firmware one signature.

[0213] S5A, compares the hash values ​​calculated by S3A and S4A (ie, the second check value and the third check value); if they are consistent, it indicates that the firmware one has not been tampered with (ie, the firmware one is trustworthy).

[0214] Similarly, the verification firmware 2 can be implemented as follows:

[0215] S1B, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0216] S2B compares the hash value with the trusted root (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key 2 has not been tampered with (i.e., public key 2 is trustworthy).

[0217] S3B, process Firmware 2 using hash function 3 (i.e., the second preset algorithm) to obtain a hash value (i.e., the third verification value).

[0218] S4B, decrypt the signature of Firmware 2 using public key 2 to obtain the hash value (i.e., the second verification value) in the signature of Firmware 2.

[0219] S5B, compare the hash values (i.e., the second verification value and the third verification value) calculated in S3B and S4B; if they are the same, it indicates that Firmware 2 has not been tampered with (i.e., Firmware 2 is trustworthy).

[0220] In the above processing, hash function 1, hash function 2, and hash function 3 can be the same, different, or partially different. In addition, in the actual scenario, the trust verification for Firmware 1 and Firmware 2 can be implemented separately (for example, in the case where the firmware maintenance entities are different, corresponding to the "or" implementation in S306 above), or can be implemented in combination (corresponding to the "and" implementation in S306 above). In the actual implementation scenario, if it is necessary to perform trust verification on both Firmware 1 and Firmware 2 simultaneously, then S1A and S1B, S2A and S2B only need to be executed once and do not need to be executed repeatedly.

[0221] In this embodiment, the target trusted root in the embodiment of the present application is determined based on two trust bases using hash function 1. The target trusted root can perform trust verification on 2 trust bases. This process has no mutual trust requirement for the 2 trust bases and can achieve trust verification based on non-mutually trusted trust bases, with low cost and a simple and fast implementation method.

[0222] As Figure 4 shown in the solution, in specific implementation, there may be the following possible specific implementation methods:

[0223] In the production stage of the firmware, the device customization party signs the device software firmware 2 with the private key 2 paired with the public key 2, and provides the public key 2, Firmware 2, and the signature of the software firmware 2 to the device production party. Thus, the device production party embeds the public key 1 and the public key 2 in the device, and calculates Hash(hash(public key 1||hash(public key 2)) (i.e., the first preset algorithm) based on this, and burns the calculated value onto the trusted silicon root; realizing the solidified storage of the trusted root. In addition, the device production party also signs the device software firmware 1 with the private key 1 paired with the public key 1; and pre-sets the software firmware 1 and the signature of the software firmware 1 into the device; and at the same time, pre-sets the software firmware 2 and the signature of the software firmware 2 into the device as well.

[0224] In the server secure boot stage, perform the trust verification process as Figure 4 shown. Specifically, it includes:

[0225] First, the server can read Public Key 1 and Public Key 2, and perform a first preset algorithm on them, that is, calculate Hash(hash(Public Key 1 || hash(Public Key 2))) to obtain a first verification value, and compare it with the trusted root; if the two are consistent, it indicates that Public Key 1 and Public Key 2 are not tampered with and can be trusted.

[0226] Secondly, the server also uses Public Key 1 to verify the signature of Firmware 1 to check whether Firmware 1 is complete and not tampered with.

[0227] In addition, the server also uses Public Key 2 to verify the signature of Firmware 2 to check whether Firmware 2 is complete and not tampered with.

[0228] Details are not described herein again.

[0229] Another possible embodiment is a multi-trust-chain multi-signature verification scheme based on untrusted trust bases. One trusted root matches multiple untrusted trust bases, and signature verification of the same firmware is achieved through these trust bases.

[0230] Exemplarily, when the first firmware and the second firmware are the same firmware, when performing S306 in the firmware trust verification method as Figure 3 shown, the following processing can be performed:

[0231] When the first trust base passes the trust verification, perform trust verification on the first firmware to be verified based on the first trust base;

[0232] When the second trust base passes the trust verification, perform trust verification on the first firmware to be verified based on the second trust base;

[0233] When the verification results of the first firmware by the first trust base and the second trust base are trustworthy, and / or when the verification results of the first firmware by at least one of the first trust base and the second trust base are trustworthy, determine that the first firmware is trustworthy.

[0234] For example. Please refer to Figure 5 , Figure 5 which is a schematic diagram of another trust verification method provided by an embodiment of the present application. As Figure 5 shown, a trusted root is maintained in the server, and the trusted root is associated with Public Key 1 and Public Key 2, and is determined based on performing a first preset algorithm on Public Key 1 and Public Key 2. Among them, Public Key 1 and Private Key 1 are a pair of public and private key pairs, and Public Key 2 and Private Key 2 are a pair of public and private key pairs. As Figure 5 shown, Firmware 1 is signed by Private Key 1 and Private Key 2 respectively (this is also equivalent to Figure 4In this way, during the server installation or upgrade phase, the server will install the signature of firmware one by public key one, firmware one, and private key one, and the signature of firmware one by public key two and private key two.

[0235] When firmware verification is required, for example, when the server is started or in other scenarios where it is necessary to verify whether the firmware has been tampered with, public key one and public key two can be used to verify whether firmware one has been tampered with.

[0236] Specifically, using the public key to verify whether the firmware has been tampered with can be achieved in the following ways:

[0237] S1A, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0238] S2A compares the hash value with the trusted root (i.e., the hash value stored in the chip, i.e., the target trusted root mentioned above); if they are consistent, it indicates that public key one has not been tampered with (i.e., public key one is trustworthy).

[0239] S3A, use hash function 2 (ie, the second preset algorithm) to process firmware 1 to obtain a hash value (ie, the third check value).

[0240] S4A, use public key one to decrypt the signature of firmware one with private key one, and obtain the hash value in the signature (ie, the second verification value).

[0241] S5A, compares the hash values ​​calculated by S3A and S4A (ie, the second verification value and the third verification value); if they are consistent, it indicates that the public key verification firmware has not been tampered with (ie, the public key verification firmware is trustworthy).

[0242] Similarly, using public key 2 to verify whether firmware 1 has been tampered with can be achieved in the following way:

[0243] S1B, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0244] S2B compares the hash value with the trusted root (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key 2 has not been tampered with (i.e., public key 2 is trustworthy).

[0245] S3B, use hash function 3 to process firmware 1 (ie, the second preset algorithm) to obtain a hash value (ie, the third check value).

[0246] S4B, use public key 2 to decrypt the signature of private key 2 on firmware 1, and obtain the hash value in the signature (ie, the second verification value).

[0247] S5B, compare the hash values obtained by calculating S3B and S4B (i.e., the second check value and the third check value); if they are the same, it indicates that the public key two check firmware one has not been tampered with (i.e., the public key two check firmware one is trustworthy).

[0248] In the above processing process, Hash function 1, Hash function 2, and Hash function 3 can be the same, different, or partially different. In addition, in the actual scenario, the trust verification of firmware one based on private key one and private key two can be implemented separately (for example, in the case where the public-private key pairs do not trust each other and do not pay attention), or can be implemented in combination. In the actual implementation scenario, if it is necessary to consider the trust verification of firmware one by private key one and private key two at the same time, then S1A and S1B, S2A and S2B only need to be executed once and do not need to be executed repeatedly.

[0249] In this embodiment, the target trusted root in the embodiment of the present application is determined based on two trust bases for Hash function 1, and the target trusted root can perform trust verification on 2 trust bases. This process has no mutual trust requirement for the 2 trust bases. Compared with the trust transfer scheme in the related art, this scheme can solve the problem that the trust verification of the firmware cannot be realized when the entity 1 providing public key 1 and the entity 2 providing public key 2 do not trust each other; and, compared with the multi-trusted root scheme in the related art, this scheme does not require multiple trusted roots and also breaks through the limitation of the number of trusted roots on the number of trust bases.

[0250] As Figure 5 shown in the scheme, in specific implementation, there may be the following possible specific implementation methods:

[0251] In the production stage of the firmware, the device user can provide the public key two to the device manufacturer. Thus, the device manufacturer can build the public key one and the public key two into the device, and calculate the trusted root based on the public key one and the public key two. For example, Hash(hash(public key one||hash(public key two)) (i.e., the first preset algorithm), and burn the calculated value to the trusted silicon root. In this way, the trusted root can be stored and solidified by the chip. In addition, the device manufacturer can also sign the soft firmware of the device (such as Figure 5 the firmware one in) with the private key one paired with the public key one; and preset the soft firmware and the soft firmware signature to the device, and reserve the signature position of the device user in the storage area.

[0252] Thus, in the firmware installation stage, the device user signs the device soft firmware with the private key B paired with the public key two, copies the signature to the position reserved by the device manufacturer, and sets the server parameter for multi-signature verification.

[0253] Furthermore, in the secure boot stage of the server, perform the trust verification process as Figure 5 shown.

[0254] Specifically, it includes:

[0255] First, the server can read the first public key and the second public key, process them through the first preset algorithm, and calculate the first verification value, that is, Hash(hash(the first public key || hash(the second public key))); and compare the first verification value with the trusted root; if the two are consistent, it indicates that the first public key and the second public key have not been tampered with.

[0256] Secondly, the server can also use the first public key to verify the signature of the software and firmware of the device manufacturer (that is, Figure 5 the signature of the first private key on the first firmware in Figure 5 ), and use the second public key to verify the signature of the software and firmware of the device user (that is,

[0257] the signature of the second private key on the first firmware in

[0258] If both signatures pass the verification, it indicates that the software and firmware are complete and have not been tampered with.

[0259] In another possible embodiment, a multi-trust-chain multi-signature verification scheme based on untrusted trust bases. One trusted root matches multiple untrusted trust bases, and multiple trust chains are realized through these trust bases, and the same firmware can be signed by multiple trust bases.

[0260] In this case, the trust verification method may further include the following steps:

[0261] Perform trust verification on the first firmware to be verified based on the third trust base; when the verification results of the first firmware by the first trust base and the third trust base are trustworthy, or when the verification results of the first firmware by at least one of the first trust base and the third trust base are trustworthy, determine that the first firmware is trustworthy;

[0262] And / or,

[0263] Perform trust verification on the second firmware to be verified based on the third trust base; when the verification results of the second firmware by the second trust base and the third trust base are trustworthy, or when the verification results of the second firmware by at least one of the second trust base and the third trust base are trustworthy, determine that the second firmware is trustworthy.

[0264] Exemplarily, please refer toFigure 6 , Figure 6 It is a schematic diagram of another trust verification method provided by an embodiment of this application. As Figure 6 shown, a trusted root is maintained in the server. The trusted root is associated with public key 1, public key 2, and public key 3, and is obtained by performing a first preset algorithm on public key 1, public key 2, and public key 3. Among them, public key 1 and private key 1 form a pair of public-private key pairs, public key 2 and private key 2 form a pair of public-private key pairs, and public key 3 and private key 3 form a pair of public-private key pairs. As Figure 6 shown, Firmware 1 is signed by private key 1 and private key 2 respectively; Firmware 2 is signed by private key 2 and private key 3 respectively. In this way, during the server installation stage or upgrade stage, the server will install public key 1, Firmware 1, the signature of Firmware 1 by private key 1, public key 2, the signature of Firmware 1 by private key 2, Firmware 2, the signature of Firmware 2 by private key 2, public key 3, and the signature of Firmware 2 by private key 3.

[0265] When firmware verification is required, for example, in scenarios where the server starts or other scenarios where it is necessary to verify whether the firmware has been tampered with, public key 1 and public key 2 can be used to verify whether Firmware 1 has been tampered with.

[0266] Specifically, to use public key 1 to verify whether Firmware 1 has been tampered with, it can be achieved through the following steps:

[0267] S1A, Use hash function 1 (i.e., the first preset algorithm) to process public key 1, public key 2, and public key 3 to obtain the hash value (i.e., the first verification value) jointly corresponding to public key 1, public key 2, and public key 3.

[0268] S2A, Compare this hash value with the trusted root (i.e., the hash value stored in the chip in a solidified manner); if they are consistent, it indicates that public key 1 has not been tampered with (i.e., public key 1 is trustworthy).

[0269] S3A, Use hash function 2 (i.e., the second preset algorithm) to process Firmware 1 to obtain a hash value (i.e., the third verification value).

[0270] S4A, Use public key 1 to decrypt the signature of Firmware 1 by private key 1 to obtain the hash value in the signature (i.e., the second verification value).

[0271] S5A, Compare the hash values calculated in S3A and S4A (i.e., the second verification value and the third verification value); if they are consistent, it indicates that public key 1 verifies that Firmware 1 has not been tampered with (i.e., public key 1 verifies that Firmware 1 is trustworthy).

[0272] Similarly, to use public key 2 to verify whether Firmware 1 has been tampered with, it can be achieved through the following steps:

[0273] S1B, use the hash function 1 (i.e., the first preset algorithm) to process public key one, public key two, and public key three, and obtain the hash value (i.e., the first check value) jointly corresponding to public key one, public key two, and public key three.

[0274] S2B, compare this hash value with the trusted root (i.e., the hash value stored in the chip in a solidified manner); if they are consistent, it indicates that public key two has not been tampered with (i.e., public key two is trustworthy).

[0275] S3B, use the hash function 3 (i.e., the second preset algorithm) to process firmware one, and obtain the hash value (i.e., the third check value).

[0276] S4B, use the private key two decrypted by public key two to decrypt the signature of firmware one, and obtain the hash value in the signature (i.e., the second check value).

[0277] S5B, compare the hash values calculated in S3B and S4B (i.e., the second check value and the third check value); if they are consistent, it indicates that public key two checks that firmware one has not been tampered with (i.e., public key two checks that firmware one is trustworthy).

[0278] Similarly, to check whether firmware two has been tampered with using public key two, it can be achieved through the following method:

[0279] S1C, use the hash function 1 to process public key one, public key two, and public key three (i.e., the first preset algorithm), and obtain the hash value (i.e., the first check value) jointly corresponding to public key one, public key two, and public key three.

[0280] S2C, compare this hash value with the trusted root (i.e., the hash value stored in the chip in a solidified manner); if they are consistent, it indicates that public key two has not been tampered with (i.e., public key two is trustworthy).

[0281] S3C, use the hash function 4 to process firmware two (i.e., the second preset algorithm), and obtain the hash value (i.e., the third check value).

[0282] S4C, use the private key two decrypted by public key two to decrypt the signature of firmware two, and obtain the hash value in the signature (i.e., the second check value).

[0283] S5C, compare the hash values calculated in S3C and S4C (i.e., the second check value and the third check value); if they are consistent, it indicates that public key two checks that firmware two has not been tampered with (i.e., public key two checks that firmware two is trustworthy).

[0284] Similarly, to check whether firmware two has been tampered with using public key three, it can be achieved through the following method:

[0285] S1D, use hash function 1 to process public key one, public key three and public key three (ie, the first preset algorithm) to obtain the hash value corresponding to public key one, public key three and public key three (ie, the first verification value).

[0286] S2D compares the hash value with the root of trust (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key three has not been tampered with (i.e., public key three is trustworthy).

[0287] S3D, use hash function 5 to process firmware 2 (ie, the second preset algorithm) to obtain a hash value (ie, the third check value).

[0288] S4D, use public key three to decrypt the signature of private key three on firmware two, and obtain the hash value in the signature (ie, the second verification value).

[0289] S5D, compares the hash values ​​calculated by S3D and S4D (ie, the second check value and the third check value); if they are consistent, it indicates that the public key three-verified firmware two has not been tampered with (ie, the public key three-verified firmware two is trustworthy).

[0290] In the above processing, hash functions 1-5 can be the same, different or partially different. In addition, in actual scenarios, the trust verification of firmware 1 and firmware 2 based on private key 1, private key 2, and private key 3 can be implemented separately or in combination. In actual implementation scenarios, if the trust verification of the above four processes needs to be implemented at the same time, S1A-S1D and S2A-S2D can be executed only once without repeated execution.

[0291] In this embodiment, the trusted root is associated with three trust bases in the embodiment of the present application, and there is no mutual trust requirement for the three trust bases. In general scenarios, when the manufacturer providing public key 1, the manufacturer providing public key 2, and the manufacturer providing public key 3 do not trust each other, different signature verifications will be required for the same firmware. Figure 1 The trust transfer scheme shown in FIG. 1 cannot solve the trust verification in this case. This scheme can solve the problem well and realize trust verification. Figure 2 The multi-trusted root solution shown in the figure does not require multiple trusted roots, has low maintenance costs, and is not limited by the number of trusted roots in the number of trust bases, which is conducive to expanding applications.

[0292] Based on the above processing, for Firmware 1, it is finally determined whether Firmware 1 is trustworthy based on all of the following conditions being met: verifying the trustworthiness of Firmware 1 using Public Key 1 and verifying the trustworthiness of Firmware 1 using Public Key 3; or, one of them being met; or, the verification result of a specific public key passing. For Firmware 2, it is finally determined whether Firmware 2 is trustworthy based on all of the following conditions being met: verifying the trustworthiness of Firmware 2 using the public key and verifying the trustworthiness of Firmware 2 using Public Key 3; or, one of them being met; or, the verification result of a specific public key passing.

[0293] As Figure 6 shown in the solution, in specific implementation, the following possible specific implementation methods may exist:

[0294] In the firmware production stage. First, the device user provides Public Key 2 to the device manufacturer; the device customizer signs the device soft firmware 2 using the private key 3 paired with Public Key 3, and provides Public Key 3, soft firmware 2, and the signature of soft firmware 2 to the device manufacturer. The device manufacturer embeds Public Key 1, Public Key 2, and Public Key 3 in the device; and calculates the trust root based on this, that is, Hash(hash(Public Key 1 || hash(Public Key 2) || hash(Public Key 3))), and burns the calculated value onto the trusted silicon root to achieve the solidified storage of the trust root. In addition, the device manufacturer can also sign the device soft firmware using the private key 1 paired with Public Key 1; and pre - set the soft firmware and the signature of the soft firmware into the device; at the same time, pre - set soft firmware 2 and the signature of soft firmware 2 into the device; and reserve a position for the signature of the device user in the storage area.

[0295] In the firmware installation stage. The device user signs the device soft firmware using the private key 2 paired with Public Key 2; and copies the signature to the position reserved by the device manufacturer, and sets the server parameter for multi - signature verification.

[0296] In the server secure boot stage, the trust verification process as Figure 6 shown is carried out. Specifically, it includes:

[0297] First, the server reads Public Key 1, Public Key 2, and Public Key 3; and calculates Hash(hash(Public Key 1 || hash(Public Key 2) || hash(Public Key 3))) to obtain the first verification value; the server compares the first verification value with the trust root; if the two are consistent, it indicates that Public Key 1, Public Key 2, and Public Key 3 have not been tampered with and are trustworthy.

[0298] Secondly, the server uses Public Key 1 to verify the signature of the device manufacturer's soft firmware 1, and uses Public Key 2 to verify the signature of the device user's soft firmware 1; if both signatures pass the verification, it indicates that the soft firmware 1 is complete.

[0299] In addition, the server uses the public key three to verify the soft firmware two signature of the device customizer, and uses the public key two to verify the soft firmware two signature of the device user. If both signatures pass the verification, it indicates that the soft firmware two is complete.

[0300] Details are not described again.

[0301] In addition, based on any of the above embodiments, further, among the multiple trust bases associated with the trusted root in the embodiments of the present application, there can be and only one valid trust base (or called the working trust base), and the other one or more trust bases serve as the backup trust bases for the valid trust base. In other words, the multiple trust bases associated with the trusted root may include: one valid trust base and at least one backup trust base.

[0302] Among them, the valid trust base means the trust base that is currently in an effective state. The valid trust base can be any one of the multiple trust bases associated with the trusted root. In an actual scenario, which trust base is the valid trust base and which trust base is the backup trust base can be indicated by identification information. In other words, the identification information is used to indicate the current valid trust base.

[0303] Exemplarily, the identification information can be maintained in the chip, or can also be maintained in other storage locations of the server. Preferably, the identification information of the valid trust base can be maintained in the chip; in this way, the immutability of the information maintained in the chip can be utilized to ensure the immutability of the information of the valid trust base, and then accurate trust verification can be achieved accordingly.

[0304] The embodiments of the present application have no special restrictions on the identification method of the identification information. In an actual scenario, the identification information can be maintained in the form of characters, names or any other custom methods.

[0305] Considering that the identification information directly affects the indication of the valid trust base and thus also has a significant impact on the trust verification scheme, the embodiments of the present application also provide a more secure way to maintain the identification information: maintaining the identification information in the eFuse of the chip.

[0306] Specifically, the chip (or the storage area of the chip, such as the readable storage area, eFuse, etc. mentioned above) may include but are not limited to: a trusted root area and an identification area; among them, the trusted root area is used to fixedly store the trusted root; the identification area is used to store the identification information, and the identification information is used to indicate the current valid trust base. In this embodiment, considering the immutability of the eFuse, in the embodiments of the present application, the identification area may include multiple identification bits, and the identification area indicates the valid trust base through the assignment combination method of each identification bit.

[0307] Figure 7 This situation is shown. Figure 7A schematic diagram of the storage relationship provided by the embodiments of this application is as follows Figure 7 As shown, the storage area of the server may include chip storage and firmware storage.

[0308] As Figure 7 shown, in the chip storage part, the eFuse in the chip is a one-time programmable storage mode. Thus, once the trusted root is written, it cannot be tampered with, and the trusted root maintained in the trusted root area does not need to be modified or adjusted. However, for the valid root public key identification part in the eFuse, that is, the part of the identification information, the assignment combination of each identification bit can be modified by writing data in this area, so as to realize the indication of the valid trust base.

[0309] For example. If there are three identification bits in the identification area, when all three identification bits are empty (for example, 000), this assignment combination of the identification bits is used to point to trust base 1. At this time, the valid trust base is trust base 1, and other trust bases associated with the trusted root are reserved. At this time, if it is necessary to switch the valid trust base, it can be achieved by making assignments in the three identification bits. For example, 001 can indicate trust base 2, 010 can be used to indicate trust base 3, 011 can be used to indicate trust base 4, and there can also be other assignment combinations, such as 110, 111, etc., which can all be used to indicate different trust bases. In this way, when it is necessary to switch trust base 2 to the valid trust base, only need to assign a value of 1 (that is, 001) to the first identification bit in the identification area, and the indication of switching the valid trust base can be achieved. It should be understood that once written in this maintenance mode, it cannot be switched back, unless the trust base can also correspond to other assignment combinations. In the actual scenario, the corresponding relationship between the assignment combination of each identification bit and the trust base can be preset customarily in advance, and the embodiments of this application have no special restrictions on this.

[0310] In addition, firmware storage, which can also be understood as other storage or non-chip storage, can be used to store firmware information or other information related to the server. For example, Figure 7 in the scenario shown, the firmware storage part stores a firmware header, firmware, and firmware signature information. The firmware storage part can also store more or less other information, which will not be elaborated. The firmware storage can be implemented by using any device with storage capabilities, such as flash memory, memory, and even in some scenarios, it can be further extended to cloud storage, and there is no limitation on this.

[0311] As mentioned above, the valid trust base can be switched. The embodiments of this application further provide a function for switching (or converting) the valid trust base. Therefore, in this embodiment, the method further includes:

[0312] When the first condition is satisfied, switch the valid trust base.

[0313] Among them, the first condition includes at least one of the following: the effective trust root is not trustworthy; the maintenance entity of the firmware is switched.

[0314] Among them, the untrustworthiness of the effective trust root may include, but is not limited to: the private key corresponding to the effective trust root or other encryption data is leaked. For example, after the private key used for encrypting the firmware signature is leaked, the public key is no longer trustworthy, and the result of the trust verification of the firmware based on the public key is also untrustworthy. In this case, it is necessary to switch the effective trust root.

[0315] The firmware is related to the maintenance entity of the firmware. Different maintenance entities can use different trust roots to verify and protect the firmware. Specifically, the maintenance entities of the firmware involved in the embodiments of the present application may include, but are not limited to: the user, the manufacturer, and the customizer. For example, after the firmware is delivered from the manufacturer to the user, the user does not need to trust the manufacturer mutually and can directly use its own trust root to verify and protect the firmware to prevent the firmware from being tampered with or other possible security risks.

[0316] In the actual scenario, there may be other situations where the trust root needs to be switched. For example, when the user requests to switch the trust root, the embodiments of the present application do not limit or enumerate this.

[0317] Specifically, when it is necessary to switch the effective trust root, one or more other alternative trust roots associated with the trusted root can be selected based on actual needs, and the identification information of the effective trust root maintained in the chip can be modified. For example, as described above, by performing a one-time assignment to the identification bits in the identification area of the eFuse, the combination mode of the identification bits is modified so that it points to other trust roots.

[0318] Illustrate with examples.

[0319] A possible embodiment is a trust root backup solution based on non-mutually trusted trust roots. Specifically, one trusted root matches multiple non-mutually trusted trust roots, and the server currently only uses one of the trust roots, and the other trust roots are in backup.

[0320] Please refer to Figure 8 , Figure 8 which is a schematic diagram of another trust verification method provided by the embodiments of the present application. As Figure 8 shown, a trusted root is maintained in the server. The trusted root is associated with public key one and public key two and is obtained by performing a first preset algorithm on public key one and public key two. Among them, public key one and private key one are a pair of public-private key pairs, and public key two and private key two are a pair of public-private key pairs. As Figure 8As shown, the current effective trust base is public key 1, and at this time, firmware 1 is signed by private key 1. In this way, during the server installation or upgrade phase, the server will install public key 1, firmware 1, the signature of the private key pair for firmware 1, public key 2, and set the current effective trust base (or effective public key) to public key 1.

[0321] In this way, when firmware verification is required, for example, when the server is started or in other scenarios where it is necessary to verify whether the firmware has been tampered with, public key 1 can be used to verify whether firmware 1 has been tampered with. The specific implementation method is as follows:

[0322] S1A, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0323] S2A compares the hash value with the root of trust (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key one has not been tampered with (i.e., public key one is trustworthy).

[0324] S3A, use hash function 2 (ie, the second preset algorithm) to process firmware 1 to obtain a hash value (ie, the third check value).

[0325] S4A, use public key one to decrypt the signature of firmware one with private key one, and obtain the hash value in the signature (ie, the second verification value).

[0326] S5A, compares the hash values ​​calculated by S3A and S4A (ie, the second verification value and the third verification value); if they are consistent, it indicates that the public key verification firmware has not been tampered with (ie, the public key verification firmware is trustworthy).

[0327] However, when private key 1 is leaked, public key 1 is no longer trustworthy. In this case, private key 2 is needed to sign firmware 1, and the signature of firmware 1 with private key 2 is installed on the server, and the current valid trust base is set to public key 2.

[0328] Therefore, when the server starts or needs to verify whether the firmware has been tampered with, the public key 2 will be used to verify whether the firmware 1 has been tampered with; the verification process is as follows:

[0329] S1B, use hash function 1 (ie, the first preset algorithm) to process public key 1 and public key 2 to obtain a hash value (ie, a first verification value) corresponding to public key 1 and public key 2.

[0330] S2B compares the hash value with the trusted root (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key 2 has not been tampered with (i.e., public key 2 is trustworthy).

[0331] S3B, use hash function 3 (ie, the second preset algorithm) to process firmware 1 to obtain a hash value (ie, the third check value).

[0332] S4B, use public key 2 to decrypt the signature of private key 2 on firmware 1, and obtain the hash value in the signature (ie, the second verification value).

[0333] S5B, compares the hash values ​​calculated by S3B and S4B (ie, the second check value and the third check value); if they are consistent, it indicates that the public key 2 verifies that the firmware 1 has not been tampered with (ie, the public key 2 verifies that the firmware 1 is trustworthy).

[0334] In this way, it is possible to switch the effective trust base when necessary (for example, when the first condition is met), solve the problem that the trust base corresponding to the trusted root cannot be revoked, further broaden the applicable scenarios of the solution, and meet objective needs.

[0335] In another possible embodiment, a trust base switching scheme based on non-mutually trusted trust bases is used. Specifically, a trusted root matches multiple non-mutually trusted trust bases, and the server currently uses only one of the trust bases, while the other trust bases are kept in reserve. When the firmware maintenance subject changes, it can switch to other trust bases to rebuild the trust chain.

[0336] Please refer to Figure 9 , Figure 9 A schematic diagram of another trust verification method provided in an embodiment of the present application. Figure 9 As shown, a trusted root is maintained in the server, and the trusted root is associated with public key 1 and public key 2, and is determined based on public key 1 and public key 2 through a first preset algorithm. Among them, public key 1 and private key 1 are a pair of public-private key pairs, and public key 2 and private key 2 are a pair of public-private key pairs. Figure 9 As shown, the current effective trust base is public key 1, and at this time, firmware 1 is signed by private key 1. In this way, during the server installation or upgrade phase, the server will install public key 1, firmware 1, the signature of the private key pair for firmware 1, public key 2, and set the current effective trust base (or effective public key) to public key 1.

[0337] In this way, when firmware verification is required, for example, when the server is started or in other scenarios where it is necessary to verify whether the firmware has been tampered with, public key 1 can be used to verify whether firmware 1 has been tampered with. The specific implementation method is as follows:

[0338] S1A, use hash function 1 to process public key 1 and public key 2 to obtain a hash value (ie, a first check value) corresponding to public key 1 and public key 2.

[0339] S2A compares the hash value with the root of trust (i.e., the hash value stored in the chip); if they are consistent, it indicates that public key one has not been tampered with (i.e., public key one is trustworthy).

[0340] S3A, process Firmware 1 using hash function 2 to obtain a hash value (i.e., the third check value).

[0341] S4A, decrypt the signature of Firmware 1 using Public Key 1 to obtain the hash value in the signature (i.e., the second check value).

[0342] S5A, compare the hash values calculated in S3A and S4A (i.e., the second check value and the third check value); if they are the same, it indicates that Firmware 1 has not been tampered with when verified using Public Key 1 (i.e., Firmware 1 can be trusted when verified using Public Key 1).

[0343] However, when the firmware maintenance entity is switched, for example, when Firmware 2 is developed by a new maintenance entity, Firmware 2 can be signed using Private Key 2, and Firmware 2 and its signature can be installed on the server, and the current valid public key is set to Public Key 2. In addition, in the actual scenario, considering space limitations, generally, Firmware 2 can also be used to replace Firmware 1, and the signature of Firmware 2 can replace the signature of Firmware 1 to implement the solution. There are no special restrictions in the embodiments of this application. Firmware 1 and its signature can be saved or replaced, either is acceptable.

[0344] Based on the switch of the maintenance entity, when the server starts or needs to verify whether the firmware has been tampered with, it will use Public Key 2 to verify whether Firmware 2 has been tampered with. The verification process is as follows:

[0345] S1B, process Public Key 1 and Public Key 2 using hash function 1 to obtain the hash value jointly corresponding to Public Key 1 and Public Key 2 (i.e., the first check value).

[0346] S2B, compare this hash value with the trusted root (i.e., the hash value stored in the chip in a fixed manner); if they are the same, it indicates that Public Key 2 has not been tampered with (i.e., Public Key 2 can be trusted).

[0347] S3B, process Firmware 2 using hash function 3 to obtain a hash value (i.e., the third check value).

[0348] S4B, decrypt the signature of Firmware 2 using Public Key 2 to obtain the hash value in the signature (i.e., the second check value).

[0349] S5B, compare the hash values calculated in S3B and S4B (i.e., the second check value and the third check value); if they are the same, it indicates that Firmware 2 has not been tampered with when verified using Public Key 2 (i.e., Firmware 2 can be trusted when verified using Public Key 2).

[0350] In this way, the embodiments of this application can solve the objective requirement that when the firmware maintenance entity changes, the firmware is no longer suitable to be signed using Private Key 1 and a new trust chain needs to be rebuilt, and under this requirement, realize the switch and indication of the effective trust base.

[0351] In summary, the technical solution provided by the embodiments of the present application can, on the premise that only one trusted root needs to be fixedly stored in the chip, based on the association relationship between the trusted root and multiple trust bases, use one trusted root to implement the trust verification of multiple trust bases, and further implement the trust verification of the corresponding firmware of the trust bases; in this process, the embodiments of the present application can also meet the switching and maintenance of effective trust bases in the actual scenario, ensuring the security and trustworthiness of the entire server.

[0352] To further illustrate this solution, the embodiments of the present application further combine the actual scenario and give the following specific embodiments that can be implemented.

[0353] In a possible embodiment, please refer to the foregoing Figure 7 , as Figure 7 shown, the server consists of a chip storage and a firmware storage (such as a flash memory). Among them, the firmware storage, also known as the firmware storage area, is used to store the firmware and its related data. And a readable storage area is set in the chip, and an electronic fuse (eFuse) is set in the readable storage area. As Figure 7 shown, the electronic fuse has two areas, one is the trusted root area and the other is the identification area. Among them, the trusted root area can be a 256-bit (bit) area, and a hash value (i.e., the trusted root) is burned at the factory; and the identification area can be a 2-bit area, and one of the bit positions has been assigned at the factory, indicating that the current effective root public key is the first root public key.

[0354] The firmware storage area stores a firmware header, firmware, and a firmware signature, where the firmware signature is a signature of the firmware by the private key corresponding to the working public key. The firmware header stores trust base information, which can specifically include: 2 trust bases, a working public key, and a working public key signature; among them, the 2 trust bases are respectively: the first public key (or called the first root public key) and the second public key (or called the second root public key). When the firmware or the server leaves the factory, the working public key signature can be signed and stored by the private key corresponding to the first public key (the current effective trust base) for the working public key.

[0355] In this embodiment, in addition to the trust base associated with the trusted root, there may also be other public keys, such as a working public key. The working public key can be protected by the private key signature corresponding to the effective trust base, and the private key corresponding to the working public key can also sign and protect the firmware. In this case, signing and protecting the firmware requires three steps: first, using the trusted root to verify whether the effective trust base is trustworthy; when the effective trust base is trustworthy, the working public key is regarded as the first firmware in the previous text, and the effective trust base is used to verify whether the working public key is trustworthy; when the working public key is trustworthy, the working public key is used to verify whether the firmware is trustworthy. In other words, in this embodiment, the first firmware may include: a public key. As described above, after the embodiment of the present application implements the trust verification of multiple trust bases (any one or at least one or all) through the target trusted root, the trusted trust base can be used to perform subsequent verification of the object to be verified, such as chain trust verification, and the subsequent object to be verified can be firmware, or other public keys or other information to be verified, and the embodiment of the present application does not limit or exhaust this.

[0356] In this embodiment, since the trusted root is a 256-bit area, SHA256 can be used as a hash function, and a mixed hash method (as the first preset algorithm) can be used to implement this solution. Specifically, public key one and public key two are processed by the first preset algorithm to obtain a trusted root, and the hash value on the trusted root can be specifically: SHA256(SHA256(public key one)||SHA256(public key two)||SHA256(public key one)&&SHA256(public key two)). Among them, in the first preset algorithm, the mixed hash process adopts a processing scheme with the same hash function and different hash value splicing processes. Specifically, one of the splicing elements is to perform an OR (||) operation with two hash values, and the other splicing element is to perform an AND (&&) operation with two hash values.

[0357] Based on this, in this embodiment, when the server starts or needs to verify whether the firmware has been tampered with, the following trust verification process can be used:

[0358] Step 1, perform a first preset algorithm processing on the public key 1 and the public key 2 in the firmware header to obtain a first check value. The first check value can be specifically expressed as: SHA256(SHA256(public key 1)||SHA256(public key 2)||SHA256(public key 1)&&SHA256(public key 2)).

[0359] Step 2: Compare the hash value with the hash value solidified on the trusted root; if they are consistent, it means that public key 1 and public key 2 have not been tampered with, and the two trust bases are trustworthy.

[0360] Step 3, read the valid root public key identifier (ie, identification information), and identify the current server's valid trust base as public key one based on the identification information.

[0361] Step 4: Use hash function 2 to calculate the hash value of the working public key (ie, the third check value).

[0362] Step 5, use public key 1 (i.e., effective trust base) to decrypt the working public key signature and obtain the hash value in the signature (i.e., second verification value); and compare it with the hash value calculated in step 4; if the two are consistent, it indicates that the working public key has not been tampered with.

[0363] Step 6, use hash function 3 to calculate the hash value of the firmware (which can be recorded as the fifth check value).

[0364] Step 7, use the working public key to decrypt the firmware signature and obtain the hash value in the signature (which can be recorded as the sixth check value); and compare it with the hash value calculated in step 6; if the two are consistent, it indicates that the firmware has not been tampered with, that is, the firmware is trustworthy.

[0365] In this embodiment, when private key one is leaked, public key one is no longer trustworthy, and the server needs to be upgraded. The upgrade will replace the working public key signature in the firmware header of the server with the signature of the working public key using private key two corresponding to public key two, and modify the identification information of the valid public key maintained in the chip; for example, the modification method can be to assign values ​​to both bits of the representation area, indicating that the current server valid public key is public key two. In this way, after the upgrade is completed, when the server starts or needs to verify whether the firmware has been tampered with, trust verification is implemented based on public key two, and the process is as follows:

[0366] Step 1: Perform a first preset algorithm on the public key 1 and the public key 2 in the firmware header to obtain a first check value. The first check value can be specifically expressed as: SHA256(SHA256(public key 1)||SHA256(public key 2)||SHA256(public key 1)&&SHA256(public key 2)).

[0367] Step 2: Compare the hash value with the hash value solidified on the trusted root; if they are consistent, it means that public key 1 and public key 2 have not been tampered with, and the two trust bases are trustworthy.

[0368] Step 3, read the valid root public key identifier (ie, identification information), and identify that the valid trust base of the current server is public key 2 according to the identification information.

[0369] Step 4: Use hash function 2 to calculate the hash value of the working public key (ie, the third check value).

[0370] Step 5: Use the public key 2 (i.e., the valid trust root) to decrypt the working public key signature, obtain the hash value in the signature (i.e., the second verification value); and compare it with the hash value calculated in Step 4. If the two are consistent, it indicates that the working public key has not been tampered with.

[0371] Step 6: Use the hash function 3 to calculate the hash value of the firmware (i.e., the fifth verification value).

[0372] Step 7: Use the working public key to decrypt the firmware signature, obtain the hash value in the signature (i.e., the sixth verification value); and compare it with the hash value calculated in Step 6. If the two are consistent, it indicates that the firmware has not been tampered with, that is, the firmware is trustworthy.

[0373] In summary, the embodiment of the present application only uses one trusted root to implement the trust verification of multiple trust roots and multiple trust chains derived therefrom. The maintenance cost of the trusted root is relatively low, and it can meet the complex trust root requirements of the server. Moreover, the embodiment of the present application decouples the relationship between the trusted root and the trust root, enabling one trusted root to support multiple trust roots, and can flexibly expand the trust root according to the server requirements, with high scalability and wide application range. In addition, the embodiment of the present application generates a trusted root by protecting and hiding the security of the multiple trust roots including the mixed hash, and can use different hash functions or the concatenation process of the hash functions to prevent attackers from accurately forging data to match the hash value, further ensuring the security and trustworthiness of the entire server.

[0374] The embodiment of the present application also provides a firmware trust verification device. Figure 10 As shown in the structural block diagram of a firmware trust verification device provided by the embodiment of the present application, Figure 10 the firmware trust verification device 1000 includes:

[0375] An acquisition unit 1010, configured to acquire a target trusted root;

[0376] A first verification unit 1020, configured to perform trust verification on a first trust root and a second trust root among multiple trust roots based on the target trusted root; wherein, the target trusted root is determined based on the multiple trust roots through a first preset algorithm, so that the target trusted root can perform trust verification on any one of the multiple trust roots;

[0377] A second verification unit 1030, configured to perform trust verification on the first firmware to be verified based on the first trust root when the first trust root passes the trust verification; and / or, perform trust verification on the second firmware to be verified based on the second trust root when the second trust root passes the trust verification.

[0378] In addition, in the embodiment of the present application, the first verification unit 1020 is specifically configured to:

[0379] Process a plurality of trust bases including the first trust base through the first preset algorithm to obtain a first verification value;

[0380] When the first verification value matches the target trusted root, determine that the first trust base is trustworthy.

[0381] In addition, in the embodiment of the present application, the first preset algorithm is implemented by one or more hash functions;

[0382] Wherein, the first preset algorithm includes: a nested algorithm of at least one layer of hash function combination; the nested algorithm is a nested algorithm in which the result of the first layer of hash function is the hash content of the second layer of hash function;

[0383] Wherein, any layer of hash function combination includes at least one hash function;

[0384] Wherein, when a layer of hash function combination includes a plurality of hash functions, the plurality of hash functions are the same, different or partially the same, and / or, the hash contents of the plurality of hash functions are the same, different or partially the same.

[0385] In addition, in the embodiment of the present application, the plurality of trust bases trust, distrust or partially trust each other.

[0386] In addition, in the embodiment of the present application,

[0387] One trust base is used to verify and protect one firmware; and / or,

[0388] One trust base is used to verify and protect a plurality of firmwares; and / or,

[0389] A plurality of trust bases are used to verify and protect one firmware.

[0390] In addition, in the embodiment of the present application, the plurality of trust bases corresponding to the target trusted root are public keys; any one of the public keys uniquely corresponds to a private key;

[0391] The first firmware is protected by signature using the first private key corresponding to the first trust base; the second firmware is protected by signature using the second private key corresponding to the second trust base.

[0392] In addition, in the embodiment of the present application, the second verification unit 1030 is specifically configured to:

[0393] Decrypt the signature of the first firmware using the first trust base to obtain a second verification value;

[0394] Process the first firmware through a second preset algorithm to obtain a third verification value;

[0395] In the case where the second verification value matches the third verification value, it is determined that the verification result of the first trust base for the first firmware is trustworthy.

[0396] In addition, in the embodiments of the present application, the multiple trust bases corresponding to the target trusted root include: the first trust base, the second trust base, and the third trust base;

[0397] The first firmware is also protected by signature using the third private key corresponding to the third trust base, and the second firmware is also protected by signature using the third private key corresponding to the third trust base;

[0398] The second verification unit 1030 is further configured to:

[0399] Perform trust verification on the first firmware to be verified based on the third trust base; in the case where the verification results of the first trust base and the third trust base for the first firmware are trustworthy, or, in the case where the verification result of at least one of the first trust base and the third trust base for the first firmware is trustworthy, determine that the first firmware is trustworthy;

[0400] And / or,

[0401] Perform trust verification on the second firmware to be verified based on the third trust base; in the case where the verification results of the second trust base and the third trust base for the second firmware are trustworthy, or, in the case where the verification result of at least one of the second trust base and the third trust base for the second firmware is trustworthy, determine that the second firmware is trustworthy.

[0402] In addition, in the embodiments of the present application, in the case where the first firmware and the second firmware are the same firmware; the second verification unit 1030 is specifically configured to:

[0403] In the case where the first trust base passes the trust verification, perform trust verification on the first firmware to be verified based on the first trust base;

[0404] In the case where the second trust base passes the trust verification, perform trust verification on the first firmware to be verified based on the second trust base;

[0405] In the case where the verification results of the first trust base and the second trust base for the first firmware are trustworthy, and / or, in the case where the verification result of at least one of the first trust base and the second trust base for the first firmware is trustworthy, determine that the first firmware is trustworthy.

[0406] In addition, in the embodiments of the present application, the chip includes: a trusted root area and an identification area;

[0407] Among them, the trusted root area is used to fixedly store the target trusted root;

[0408] Among them, the identification area is used to store identification information, and the identification information is used to indicate the current effective trust base;

[0409] Among them, the identification area includes a plurality of identification bits, and the identification area indicates the effective trust base by means of the assignment combination of each identification bit.

[0410] In addition, in the embodiment of the present application, a readable storage area is provided in the chip;

[0411] An electronic fuse is provided in the readable storage area;

[0412] The target trusted root is fixedly stored in the electronic fuse.

[0413] Figure 11 It is a hardware block diagram of an electronic device provided by an embodiment of the present application. The electronic device 1100 according to the embodiment of the present application at least includes a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the firmware trust verification method described in any of the above embodiments.

[0414] Figure 11 The illustrated electronic device 1100 specifically includes: a central processing unit (CPU) 1101, a graphics processing unit (GPU) 1102, and a memory 1103. These units are interconnected through a bus 1104. The central processing unit (CPU) 1101 and / or the graphics processing unit (GPU) 1102 can be used as the above-mentioned processor, and the memory 1103 can be used as the memory for storing the computer-readable instructions. In addition, the electronic device 1100 may further include a communication unit 1105, a storage unit 1106, an output unit 1107, an input unit 1108, and an external device 1109, and these units are also connected to the bus 1104.

[0415] In a possible embodiment, as Figure 11 The illustrated CPU 1101 may specifically be the chip involved in any of the previous embodiments of the present application. Further, the chip may specifically be a security chip.

[0416] Figure 12 It is a schematic diagram of a computer-readable storage medium provided by an embodiment of the present application. A computer program / instructions (including but not limited to computer-readable instructions) is stored on the computer-readable storage medium according to the embodiment of the present disclosure. For example Figure 12As shown, a computer-readable storage medium 1200 stores computer-readable instructions 1201 thereon. When the computer program / instructions are executed by a processor, the firmware trust verification method described in any of the foregoing embodiments of the present application is implemented. The computer-readable storage medium includes, but is not limited to, for example, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory, etc. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, optical disc, magnetic disk, etc.

[0417] An embodiment of the present application further provides a computer program product, including a computer program / instructions, which implement the firmware trust verification method described in any of the foregoing embodiments of the present application when executed by a processor.

[0418] The basic principles of the embodiments of the present application have been described above in conjunction with specific embodiments. However, it should be noted that the advantages, advantages, effects, etc. mentioned in the embodiments of the present application are only examples and not limitations, and it cannot be considered that these advantages, advantages, effects, etc. are essential for each embodiment of the present application. In addition, the above-disclosed specific details are only for the purpose of illustration and facilitating understanding, rather than limitations. The above details do not limit the embodiments of the present application to necessarily adopt the above specific details to implement.

[0419] The block diagrams of the devices, apparatuses, equipment, and systems involved in the embodiments of the present application are only illustrative examples and do not intend to require or imply that they must be connected, arranged, and configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, equipment, and systems can be connected, arranged, and configured in any manner. Words such as "including", "comprising", "having", etc. are open-ended words, meaning "including but not limited to", and can be used interchangeably with each other. The words "or" and "and" used herein refer to the word "and / or", and can be used interchangeably with each other unless the context clearly indicates otherwise. The word "such as" used herein refers to the phrase "such as but not limited to", and can be used interchangeably with each other.

[0420] In addition, as used herein, the "or" used in the listing of items starting with "at least one" indicates a separate listing, so that for example, the listing of "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). In addition, the term "exemplary" does not mean that the described examples are preferred or better than other examples.

[0421] It should also be noted that in the systems and methods of the present application, each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent solutions of the present application.

[0422] Various changes, substitutions, and alterations to the technology described herein can be made without departing from the teachings defined by the appended claims. In addition, the scope of the claims of this application is not limited to the specific aspects of the processes, machines, manufactures, compositions of events, means, methods, and acts described above. Processes, machines, manufactures, compositions of events, means, methods, or acts that are currently existing or later to be developed that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Accordingly, the appended claims include such processes, machines, manufactures, compositions of events, means, methods, or acts within their scope.

[0423] The foregoing description of the disclosed aspects is provided to enable any person skilled in the art to make or use this application. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects without departing from the scope of this application. Thus, this application is not intended to be limited to the aspects shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0424] The foregoing description has been presented for purposes of illustration and description. In addition, this description is not intended to limit the embodiments of this application to the form disclosed herein. Although several example aspects and embodiments have been discussed above, those skilled in the art will recognize some of their variations, modifications, alterations, additions, and subcombinations.

Claims

1. A firmware trust verification method, characterized in that: include: Get the target trusted root; Based on the target trusted root, a first trust base and a second trust base among the multiple trust bases are trust-verified; wherein the target trusted root is determined based on the multiple trust bases by a first preset algorithm, so that the target trusted root can trust-verify any one of the multiple trust bases; In the case where the first trust base passes the trust verification, a trust verification is performed on the first firmware to be verified based on the first trust base; and / or, in the case where the second trust base passes the trust verification, a trust verification is performed on the second firmware to be verified based on the second trust base.

2. The method according to claim 1, characterized in that: Based on the target trusted root, a trust verification is performed on a first trust base among the multiple trust bases, including: Processing a plurality of trust bases including the first trust base by using the first preset algorithm to obtain a first verification value; In a case where the first verification value matches the target trusted root, it is determined that the first trust base is trustworthy.

3. The method according to claim 2, characterized in that The first preset algorithm is implemented by one or more hash functions; The first preset algorithm includes: a nested algorithm of N-layer hashing algorithms; the nested algorithm is that the hashing result of the i-th layer hashing algorithm is used as the content of the i+1-th layer hashing algorithm; The i-th layer hash algorithm is the OR value of the following three hash results: a hash result based on the first trust base, a hash result based on the second trust base, and a hash result based on the first trust base and the second trust base.

4. The method according to any one of claims 1 to 3, characterized in that: The multiple trust bases are trusted, distrusted or partially trusted.

5. The method according to any one of claims 1 to 4, characterized in that: A trust base is used to verify and protect a firmware; and / or, A trust base is used to verify and protect multiple firmware; and / or, Multiple trust bases are used to verify and protect a firmware.

6. The method according to any one of claims 1 to 5, characterized in that: The multiple trust bases corresponding to the target trusted root are public keys; any one of the public keys uniquely corresponds to one private key; The first firmware is protected by a first private key signature corresponding to the first trust base; the second firmware is protected by a second private key signature corresponding to the second trust base.

7. The method according to claim 6, characterized in that The performing trust verification on the first firmware to be verified based on the first trust base includes: Decrypting the signature of the first firmware using the first trust base to obtain a second verification value; Processing the first firmware using a second preset algorithm to obtain a third check value; When the second verification value matches the third verification value, it is determined that the verification result of the first trust base on the first firmware is trustworthy.

8. The method according to claim 6 or 7, characterized in that: The multiple trust bases corresponding to the target trusted root include: the first trust base, the second trust base and the third trust base; The first firmware is also protected by a third private key signature corresponding to a third trust base, and the second firmware is also protected by a third private key signature corresponding to the third trust base; The method further comprises: Performing a trust check on the first firmware to be checked based on the third trust base; determining that the first firmware is trustworthy when the check results of the first trust base and the third trust base on the first firmware are trustworthy, or when the check results of at least one of the first trust base and the third trust base on the first firmware are trustworthy; and / or, A trust check is performed on the second firmware to be checked based on the third trust base; when the check results of the second firmware by the second trust base and the third trust base are trustworthy, or when the check results of the second firmware by at least one of the second trust base and the third trust base are trustworthy, it is determined that the second firmware is trustworthy.

9. The method according to any one of claims 6 to 8, characterized in that: In the case where the first firmware and the second firmware are the same firmware; performing trust verification on the first firmware to be verified based on the first trust base when the first trust base passes the trust verification; And / or, in a case where the second trust base passes the trust verification, performing a trust verification on the second firmware to be verified based on the second trust base, including: In a case where the first trust base passes the trust verification, performing a trust verification on the first firmware to be verified based on the first trust base; In a case where the second trust base passes the trust verification, performing a trust verification on the first firmware to be verified based on the second trust base; When the verification result of the first trust base and the second trust base on the first firmware is trustworthy, and / or when the verification result of at least one of the first trust base and the second trust base on the first firmware is trustworthy, it is determined that the first firmware is trustworthy.

10. A chip, characterized in that: The chip has a target trusted root stored in it. The target trusted root is determined based on multiple trust bases through a first preset algorithm, so that the target trusted root can perform trust verification on any one of the multiple trust bases.

11. An electronic device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement the method according to any one of claims 1 to 9.

Images