A federated distributed trusted reference value management method and system

Abstract

Embodiments of the present application relate to a kind of joint distributed trusted reference value management method and system, comprising: obtaining trusted reference value file, wherein, trusted reference value file is generated when target firmware updates, trusted reference value file carries at least file identification and firmware identification;Obtain the storage index information obtained when reference value file is stored in distributed manner;File identification and storage index information are associated and stored to joint distributed trusted system, and the key storage information corresponding to firmware reference value file is generated, wherein, key storage information includes transaction information;Non-balanced hash block tree is constructed based on key storage information, and non-balanced hash block tree is used to verify any one transaction information of joint distributed trusted system, whereby, the correctness of the index value of the reference value file obtained can be verified quickly, to further guarantee the correctness of reference value, reduce the security risk caused by single manufacturer centralized management private key leakage.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of information security technology, and in particular to a joint distributed trusted benchmark management method and system. Background Technology

[0002] Trusted computing technology is a security solution for protecting system integrity. It involves measuring, storing, and verifying the integrity values ​​of system components. Security modules ensure the trustworthiness of integrity value measurement and storage. During verification, the actual measured values ​​of components are compared with trusted benchmark values ​​to determine the system's trustworthiness. Trusted benchmark values ​​are crucial in trusted verification.

[0003] Although the Trusted Computing Organization has proposed a set of management specifications for trusted benchmarks, integration with existing systems is difficult, the specifications lack applicability, and there is no consideration of using distributed methods to enhance benchmark security. Existing work related to trusted benchmark management mainly involves providing hash values ​​and digital signature verification for downloaded programs. Some programs for open platforms provide a hash value along with the program for download, primarily for users to verify the correctness and tamper-proof status of the installer after downloading. Typically, downloaded programs are compressed or installer packages, and their correctness is only guaranteed before decompression or installation. After installation, it's difficult to use this hash value to verify whether the running program has been tampered with or corrupted. The widely used package management tool dpkg on Linux systems creates a corresponding md5sums file after firmware is installed. This file stores a list of MD5 hash values ​​for the firmware's binary programs and archive files. Based on this hash value list, dpkg –verify can be used to verify whether the installed program has been corrupted. If an attacker tampers with the binary program or archive file, they can also tamper with the corresponding hash value. To enhance security, some systems provide digital signature verification mechanisms for programs. For example, 64-bit Windows mandates signature verification for drivers, and iOS requires signature verification for apps. In 64-bit Windows, all drivers must obtain an official WHQL signature, which Windows verifies when loading the driver. iOS apps only receive an official signature after passing a review process before being released in the App Store. When users download and install iOS apps, the system verifies the correctness of the signature and checks the permission list in the signature to determine if the app has engaged in any unauthorized behavior that violates its promises.

[0004] Digital signatures enhance the security of baseline values, but currently, signature management is primarily centralized and closed by system vendors. If a vendor's private key is leaked, it poses a significant security risk to their signature baseline values. Furthermore, there is currently no unified mechanism for signature management across different vendors. Typically, a security center verifies the trustworthiness of all different types and vendors' systems within its security domain. This requires the security center to collect and manage trusted baseline values ​​from each vendor. Currently, the Linux integrity protection tool IMA uses the HMAC value or digital signature of the program file measurement during system initialization as the baseline for local verification. The IBM ACS trusted computing certification open-source project also uses IMA digital signatures as the verification baseline. However, this approach is insufficient to meet the requirements of security centers; a unified management of trusted baseline values ​​for systems of the same type is necessary. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems or some of the technical problems, embodiments of the present invention provide a joint distributed trusted benchmark value management method and system.

[0006] In a first aspect, embodiments of the present invention provide a joint distributed trusted benchmark value management method, comprising:

[0007] Obtain a trusted baseline value file, wherein the trusted baseline value file is generated during the update of the target firmware, and the trusted baseline value file carries at least a file identifier and a firmware identifier;

[0008] Obtain the storage index information of the trusted baseline value file during distributed storage;

[0009] The file identifier and the storage index information are associated and stored in the joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, wherein the key storage information includes transaction information;

[0010] An unbalanced hash block tree is constructed based on the key storage information. This unbalanced hash block tree is used to verify any transaction information in the distributed trusted system.

[0011] In one possible implementation, the method further includes:

[0012] The target distributed storage location of the trusted benchmark value file is determined by using a preset distributed hash table.

[0013] The trusted benchmark file is stored in the target distributed storage location.

[0014] In one possible implementation, the method further includes:

[0015] The file identifier is used as the key value of the database of the joint distributed trusted system, and the storage index information is used as the value value of the database of the joint distributed trusted system.

[0016] Using the Key and Value values, a key-value pair corresponding to the trusted benchmark file is constructed in the database of the federated distributed trusted system, and a transaction block corresponding to the key-value pair is created in the federated distributed trusted system, wherein the transaction block stores the transaction information corresponding to the trusted benchmark file;

[0017] The key-value pair and the transaction block are identified as the key storage information.

[0018] In one possible implementation, the method further includes:

[0019] The transaction block that meets the preset conditions in at least one transaction block in the key storage information is determined as the root node of the unbalanced hash block tree, and it is determined whether the tree rooted at the root node is a full binary tree.

[0020] If not, iteratively determine the right child node of the root node until a tree with the target node as the root is found to be a full binary tree;

[0021] Based on the full binary tree, an empty leaf node is generated, block header information is added to the empty leaf node, and the Value field value of the empty leaf node is calculated. The block header information is the root node hash value of the unbalanced hash tree before the empty leaf node is added.

[0022] Based on the full binary tree, an empty intermediate node is generated, and the Value field value of the empty intermediate node is calculated, wherein the left node of the empty intermediate node is the target node, and the right node is the empty leaf node.

[0023] Starting from the empty intermediate node, update the node hash value upwards until the root node to obtain the updated unbalanced hash block tree.

[0024] Secondly, embodiments of the present invention provide a joint distributed trusted benchmark value management method, comprising:

[0025] Obtain a trusted proof report, wherein the trusted proof report carries at least the target firmware identifier;

[0026] The target firmware identifier is used to obtain the corresponding target trusted benchmark value file, and the target file identifier is obtained from the target trusted benchmark value file;

[0027] Query the target key storage information corresponding to the target firmware identifier from the joint distributed trusted system;

[0028] The target key storage information is proved using an unbalanced hash block tree to obtain target proof information, and the target proof information is used to verify the trusted proof report to obtain a verification result, wherein the verification result is used to indicate whether the trusted proof report is correct.

[0029] In one possible implementation, the method further includes:

[0030] The system retrieves target key-value pairs corresponding to the target firmware identifier from the database of the joint distributed trusted system, retrieves target storage index information from the target key-value pairs, and retrieves the corresponding target blocks from the joint distributed trusted system.

[0031] The target storage index information and the target block are identified as the target key storage information.

[0032] In one possible implementation, the method further includes:

[0033] Obtain the target transaction block from the target key storage information;

[0034] Determine whether the target transaction block carries transaction information corresponding to the target file identifier to obtain first proof information, and determine whether the target transaction block exists in the unbalanced hash block tree to obtain second proof information;

[0035] The target proof information is determined based on the first proof information and the second proof information.

[0036] In one possible implementation, the method further includes:

[0037] Based on the proof information, the hash value of the root node of the transaction tree is constructed and compared with the field in the corresponding block. If the comparison is successful, the hash value of the root node of the block tree is constructed and compared with the value of the root field of the block tree in the latest block header of the joint distributed trusted system. If they match, it means that the obtained trusted benchmark metric file index is correct.

[0038] Thirdly, embodiments of the present invention provide a joint distributed trusted benchmark management system, comprising: a distributed storage module and a joint distributed trusted system network module;

[0039] The joint distributed trusted system network module includes a database module, a trusted system module, and an organization management module;

[0040] The distributed storage module is used to store trusted benchmark value files;

[0041] The database module is used to store key-value pairs corresponding to the trusted baseline value file stored in the distributed storage module;

[0042] The joint distributed trusted system module is used to store the transaction blocks corresponding to the key-value pairs.

[0043] Optionally, the organization management module is used to manage multiple embedded automation devices.

[0044] The joint distributed trusted benchmark management scheme provided in this invention obtains a trusted benchmark file, which is generated during the update of the target firmware and carries at least a file identifier and a firmware identifier. It then obtains storage index information obtained during distributed storage of the trusted benchmark file; associates and stores the file identifier and the storage index information in a joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, where the key storage information includes transaction information; and constructs an unbalanced hash block tree based on the key storage information. This unbalanced hash block tree is used to verify any transaction information in the joint distributed trusted system. Compared to existing trusted computing technologies, which are difficult to integrate with existing systems and lack sufficient standard applicability, and existing trusted benchmark management specifications that cannot determine whether the program has been tampered with during installation, this scheme can obtain benchmark values ​​from firmware from all joint vendors within a single system. It can quickly verify the correctness of the obtained benchmark file index value, thereby ensuring the correctness of the benchmark value and reducing the security risks caused by the leakage of private keys in centralized management by a single vendor. This scheme is applicable to trusted verification scenarios for embedded automated equipment.

[0045] The joint distributed trusted benchmark management system provided in this invention includes: a distributed storage module and a joint distributed trusted system module; the joint distributed trusted system module includes a database module, a trusted system module, and an organization management module; the distributed storage module is used to store trusted benchmark files; the database module is used to store key-value pairs corresponding to the trusted benchmark files stored in the distributed storage module; the trusted system module is used to store transaction blocks corresponding to the key-value pairs; the organization management module is used to manage multiple embedded automation devices. Compared to existing systems where various manufacturers do not form a joint mechanism for program signature management, typically a security center needs to verify the trustworthiness of all different types and manufacturers' systems within its security domain. This requires the security center to collect and manage trusted benchmarks from various manufacturers, which is difficult to meet the requirements of the security center. This system enables unified management of trusted benchmarks for the same type of system, allowing the security center to obtain benchmarks from firmware from all joint manufacturers within a single system. Attached Figure Description

[0046] Figure 1 This is a flowchart illustrating a joint distributed trusted benchmark value management method according to an embodiment of the present invention;

[0047] Figure 2 A flowchart illustrating another joint distributed trusted benchmark value management method is provided for embodiments of the present invention;

[0048] Figure 3 A schematic diagram of a reliable benchmark value file provided in an embodiment of the present invention;

[0049] Figure 4 A schematic diagram illustrating the construction of an unbalanced hash block tree, provided as an embodiment of the present invention;

[0050] Figure 5 A flowchart illustrating yet another method for managing jointly distributed trusted benchmark values ​​is provided for embodiments of the present invention;

[0051] Figure 6 A flowchart illustrating another method for managing jointly distributed trusted benchmark values ​​is provided for embodiments of the present invention.

[0052] Figure 7 This invention provides a schematic diagram of a multi-value verification path for an unbalanced hash tree in a jointly distributed trusted system.

[0053] Figure 8 This is a schematic diagram illustrating the verification of a transaction block corresponding to a trusted benchmark value, provided in an embodiment of the present invention.

[0054] Figure 9 This is a schematic diagram of the structure of a joint distributed trusted benchmark management system provided in an embodiment of the present invention. Detailed Implementation

[0055] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] To facilitate understanding of the embodiments of the present invention, further explanations and descriptions will be provided below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of the present invention.

[0057] Figure 1 This is a flowchart illustrating a joint distributed trusted benchmark value management method according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method specifically includes:

[0058] S11. Obtain a trusted baseline value file, wherein the trusted baseline value file is generated by the target firmware during the update, and the trusted baseline value file carries at least a file identifier and a firmware identifier.

[0059] In this embodiment of the invention, each time a firmware developer releases a firmware version or an update patch, a trusted baseline value file is generated. This file contains a unique file identifier for the trusted baseline value file, the firmware name, firmware version, patch version, platform type, operating system, creation time, signature value, file path name and hash value list, firmware developer's public key digital certificate, etc. The file identifier is the hash value of the trusted baseline value file.

[0060] S12. Obtain the storage index information of the firmware baseline value file when it is stored in a distributed manner.

[0061] Distributing trusted baseline value files can prevent file loss due to single points of failure. The storage index information obtained when the firmware baseline value files are distributed can be used to determine the storage location of the distributed storage.

[0062] S13. The file identifier and the storage index information are associated and stored in the joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, wherein the key storage information includes transaction information.

[0063] The chaincode is invoked to write the trusted benchmark value file information from distributed storage to the joint distributed trusted system and database. The key-value database of the joint distributed trusted system stores the file identifier of the trusted benchmark value file as the key, and the index value of the trusted benchmark value file in distributed storage as the value. Each trusted benchmark value key-value record in the joint distributed trusted system's database has a corresponding transaction record in the chain block.

[0064] S14. Construct an unbalanced hash block tree based on the key storage information. The unbalanced hash block tree is used to verify any transaction information in the distributed trusted system.

[0065] An unbalanced hash block tree is constructed based on key storage information. The block header hash value is used as the leaf node to construct the unbalanced hash block tree. Each block stores the root node hash value of the unbalanced hash block tree before the block was added. The unbalanced hash block tree is used to verify any transaction information in the distributed trusted system.

[0066] The joint distributed trusted benchmark management method provided in this invention obtains a trusted benchmark file, which is generated during the update of the target firmware and carries at least a file identifier and a firmware identifier; obtains storage index information obtained during distributed storage of the trusted benchmark file; associates and stores the file identifier and the storage index information in a joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, wherein the key storage information includes transaction information; and constructs an unbalanced hash block tree based on the key storage information. The unbalanced hash block tree is used to verify any transaction information in the joint distributed trusted system. Compared with existing trusted computing technologies, which are difficult to integrate with existing systems and have insufficient standard applicability, and existing trusted benchmark management specifications cannot determine whether the program has been tampered with during installation, this method can obtain the benchmark values ​​of firmware from all joint vendors in one system, quickly verify the correctness of the obtained benchmark file index value, thereby ensuring the correctness of the benchmark value and reducing the security risk caused by the leakage of private keys in centralized management by a single vendor.

[0067] Figure 2 A flowchart illustrating another joint distributed trusted benchmark value management method is provided for embodiments of the present invention, as follows: Figure 2 As shown, the method specifically includes:

[0068] S21. Determine the target distributed storage location of the trusted benchmark value file using a preset distributed hash table.

[0069] S22. Store the trusted benchmark value file in the target distributed storage location.

[0070] In this embodiment of the invention, after obtaining the trusted baseline value file corresponding to the target firmware deployed in the embedded automation device, the target distributed storage location of the trusted baseline value file is queried based on a preset distributed hash table. The trusted baseline value file is then stored in the target distributed storage location. Storage index information obtained during the distributed storage of the trusted baseline value file is then acquired. This storage index information can be the storage location of the distributed storage. The trusted baseline value file information is as follows: Figure 3 As shown:

[0071] id, the hash value of all content in the file except id; name, firmware name; ver, firmware version; patchVer, patch version; arch, the CPU architecture of the system on which the firmware is located; os, the name and specific version number of the operating system on which the firmware is located; time, file creation time; sign, the digital signature value of all content in the file except id and sign, signed by the firmware developer using their private key; file, the path name and hash value of the files contained in the firmware, which can have multiple values; cert, the firmware developer's public key digital certificate, which is the same as the digital certificate used in the federated distributed trusted system.

[0072] The installed firmware also has a trusted baseline file. When performing trusted computing remote proof, the reported measurement log contains the baseline ID. When patching and updating the installed firmware, the corresponding trusted baseline file is also updated.

[0073] S23. Use the file identifier as the Key value of the database of the joint distributed trusted system, and use the storage index information as the Value value of the database of the joint distributed trusted system.

[0074] S24. Using the Key value and the Value value, construct the key-value pair corresponding to the trusted benchmark value file in the database of the federated distributed trusted system, and create the transaction block corresponding to the key-value pair in the federated distributed trusted system, wherein the transaction block stores the transaction information corresponding to the trusted benchmark value file.

[0075] The chaincode is invoked to write the trusted benchmark value file information from distributed storage to the joint distributed trusted system and database. The key-value database of the joint distributed trusted system stores the file identifier of the trusted benchmark value file as the key, and the index value of the trusted benchmark value file in distributed storage as the value. Each trusted benchmark value key-value record in the joint distributed trusted system's database has a corresponding transaction record in the chain block.

[0076] S25. The key-value pair and the transaction block are identified as the key storage information.

[0077] S26. Determine the transaction block that meets the preset conditions in at least one transaction block of the key storage information as the root node of the unbalanced hash block tree, and determine whether the tree rooted at the root node is a full binary tree.

[0078] S27. If not, iteratively determine the right child node of the root node until a tree with the target node as the root is found to be a full binary tree.

[0079] S28. Based on the full binary tree, generate empty leaf nodes, add block header information to the empty leaf nodes, and calculate the Value field value of the empty leaf nodes, wherein the block header information is the root node hash value of the unbalanced hash tree before the empty leaf nodes are added.

[0080] S29. Based on the full binary tree, generate an empty intermediate node and calculate the Value field value of the empty intermediate node, wherein the left node of the empty intermediate node is the target node and the right node is the empty leaf node.

[0081] S210. Starting from the empty intermediate node, update the node hash value upwards until the root node to obtain the updated unbalanced hash block tree.

[0082] The following provides a unified explanation of S25 to S210:

[0083] In embodiments of the present invention, such as Figure 4 The diagram illustrates a method for constructing an unbalanced hash block tree according to an embodiment of the present invention. Key-value pairs and transaction blocks are identified as key storage information. The tree comprises 11 blocks (B0 to B10), each storing the root hash value of the unbalanced hash tree before the block was added. The root value of the tree is stored in the block header of block B10. When a new block needs to be linked, the following steps are performed:

[0084] 1) Starting from the root node of the unbalanced hash tree, determine whether the tree rooted at this node is a full binary tree. If not, continue iterating through its right child nodes until a node N that meets the condition is found. temp Assuming the tree rooted at a leaf node is a full tree, a node that meets the conditions can definitely be found.

[0085] 2) Generate an empty leaf node N. leaf Add block header information B as needed n Calculate N leaf The value N of the val field leaf .val = Hash(B n );

[0086] 3) Generate an empty intermediate node N mid Its left child node is N temp The right child node is N leaf Calculate and populate node N mid The value N mid .val←Hash(N temp .val||N leaf .val);

[0087] 4) From the intermediate node N midStart by updating the hash values ​​of the nodes upwards until the root node is reached, resulting in an updated unbalanced hash block tree.

[0088] Figure 5 A flowchart illustrating another joint distributed trusted benchmark value management method is provided for embodiments of the present invention, as follows: Figure 5 As shown, the method specifically includes:

[0089] S51. Obtain a trusted proof report, wherein the trusted proof report carries at least the target firmware identifier.

[0090] In this embodiment of the invention, the security center reads user nodes for lightweight benchmark values ​​in the system and obtains trusted proof reports sent by embedded automation devices, wherein the trusted proof reports carry at least the target firmware identifier.

[0091] S52. Obtain the corresponding target trusted benchmark file using the target firmware identifier, and obtain the target file identifier from the target trusted benchmark file.

[0092] S53. Query the target key storage information corresponding to the target firmware identifier from the joint distributed trusted system.

[0093] A sampling method can be used to connect to an honest firmware developer node with a block data chain. Based on the firmware identifier in the proof report, the corresponding key-value record is read from the federated distributed trusted system database as the key value. The system will also return the transaction corresponding to the key-value record, the proof information of the transaction in a certain block, the header of the block in which the transaction is located, and the proof information of the block in the unbalanced hash block tree.

[0094] S54. The target key storage information is proved using an unbalanced hash block tree to obtain target proof information, and the target proof information is used to verify the trusted proof report to obtain a verification result, wherein the verification result is used to indicate whether the trusted proof report is correct.

[0095] After obtaining the information, the security center first calculates the transaction hash. Then, based on the sibling node information of the path nodes, it constructs the root node hash value of the transaction tree and compares it with the corresponding field in the block. If the comparison is successful, it continues to construct the root node hash value of the unbalanced hash block tree and compares it with the root field value of the block tree in the latest block header of the federated distributed trusted system. If they match, it means that the obtained Key-Value record is correct. Then, it uses the index value in the Value to read the corresponding trusted benchmark value file in the distributed storage and reads the corresponding benchmark hash value from the file to determine whether the terminal's trusted proof report is correct.

[0096] Compared with existing benchmark management methods, this invention has the following advantages: The same trusted benchmark file has different unique identifiers on different systems, with different CPU architectures, and with different patches; benchmark files with different identifiers contain different file path names, hash value lists, and signature values; it features distributed decentralization, is not easily tampered with, and can be publicly verified, ensuring the secure storage of benchmark values ​​and reducing the security risks caused by the leakage of private keys in centralized management by a single vendor; the security center can obtain benchmark values ​​from firmware of all cooperating vendors in one system; and it can quickly verify the correctness of the obtained benchmark file index values, thereby ensuring the correctness of the benchmark values.

[0097] Figure 6 A flowchart illustrating another method for managing jointly distributed trusted benchmark values ​​is provided as an embodiment of the present invention, such as... Figure 6 As shown, the method specifically includes:

[0098] S61. Obtain the target key-value pair corresponding to the target firmware identifier from the database of the joint distributed trusted system, obtain the target storage index information from the target key-value pair, and obtain the corresponding target block from the joint distributed trusted system.

[0099] S62. The target storage index information and the target block are determined as the target key storage information.

[0100] S63. Obtain the target transaction block from the target key storage information.

[0101] S64. Determine whether the target transaction block carries the transaction information corresponding to the target file identifier to obtain first proof information, and determine whether the target transaction block exists in the unbalanced hash block tree to obtain second proof information.

[0102] S65. Based on the first proof information and the second proof information, determine the target proof information.

[0103] S66. Based on the proof information, construct the hash value of the root node of the transaction tree and compare it with the field in the corresponding block. If the comparison is successful, continue to construct the hash value of the root node of the block tree and compare it with the value of the root field of the block tree in the latest block header of the joint distributed trusted system. If they match, it means that the obtained trusted benchmark metric file index is correct.

[0104] The following provides a unified explanation of S61 to S66:

[0105] In this embodiment of the invention, the verifier is a lightweight reading user node in the system. Based on the firmware identifier in the proof report, it reads the corresponding Key-Value record in the joint distributed trusted system database as the Key value. The system also returns the transaction tx0 corresponding to the Key-Value record, the proof information of the transaction in a certain block, the header of the block in which the transaction is located, and proof information proving that the block is in the unbalanced hash block tree. For example... Figure 8 As shown, Figure 8 The shaded area represents the proof information required to verify transaction tx0. After receiving the response message, the verifier first calculates the hash of transaction tx0, then constructs the root node hash value of the transaction tree based on the proof information. This hash value is compared with the corresponding field in the block. If the comparison passes, the verifier continues to construct the root node hash value of the block tree and compares it with the block tree root field value mmrRoot in the latest block header of the joint distributed trusted system. If they match, it indicates that the obtained trusted benchmark metric file index is correct.

[0106] Optionally, the verifier may obtain multiple trusted benchmark files simultaneously. The system further improves efficiency by generating a multi-value verification path (mp), such as... Figure 7 As shown, the process of generating a multi-value validation path iterates from the leaf node level of the tree all the way to the root node, and the steps are as follows:

[0107] 1) In layer 0, the node numbers corresponding to block nodes B0, B1, B2, and B6 in layer 0 are 0, 1, 2, and 6, respectively. Add an adjacent number to each of these numbers to generate number pairs, where the first element of each pair is even and the second element is odd. The resulting number pairs are [0, 1], [0, 1], [2, 3], and [6, 7]. Remove duplicates from these number pairs to obtain [0, 1], [2, 3], and [6, 7]. Remove numbers 0, 1, 2, and 6 from these number pairs, leaving node numbers 3 and 7. Since there is no node 7 in layer 0, add the node corresponding to the number after removing the invalid node 7 to mp. At this point, mp = {N0, 3}. Divide the left endpoint of each number pair by 2 to obtain the node numbers 0, 1, and 3 corresponding to layer 1.

[0108] 2) In layer 1, the corresponding node numbers are 0, 1, and 3. Generate number pairs for these nodes and remove duplicates to obtain [0, 1] and [2, 3]. Add the node corresponding to the remaining node number 2 after removing the numbers 0, 1, and 3 from the number pairs to mp. At this time, mp = {N0, 3, N1, 2}. Divide the left endpoint of each number pair by 2 to obtain the node numbers 0 and 1 corresponding to layer 2.

[0109] 3) In layer 2, the corresponding node numbers are 0 and 1. Generate numbered pairs for these nodes and remove duplicates to obtain [0, 1]. At this point, there are no nodes left in the numbered pairs after removing 0 and 1, and the iteration ends. The final generated mp = {N0, 3, N1, 2}.

[0110] MP can prove that any block header exists in an unbalanced hash tree, which also proves that the block exists in a federated distributed trusted system.

[0111] The joint distributed trusted benchmark management method provided in this invention involves: acquiring a trusted benchmark file, wherein the trusted benchmark file is generated during the update of the target firmware, and the trusted benchmark file carries at least a file identifier and a firmware identifier; acquiring storage index information obtained when the trusted benchmark file is distributed for storage; associating and storing the file identifier and the storage index information in a joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, wherein the key storage information includes transaction information; and constructing an unbalanced hash block tree based on the key storage information, wherein the unbalanced hash block tree is used to verify any transaction information in the joint distributed trusted system. This method allows for the acquisition of benchmark values ​​from all joint vendor firmware within a single system, enabling rapid verification of the correctness of the acquired benchmark file index value, thereby ensuring the correctness of the benchmark value and reducing the security risks caused by the leakage of private keys in centralized management by a single vendor.

[0112] Figure 9 This invention provides a schematic diagram of the structure of a joint distributed trusted benchmark management system, as shown in the embodiment of the invention. Figure 9 As shown, the joint distributed trusted benchmark management system includes: a distributed storage module and a joint distributed trusted system module; wherein, the joint distributed trusted system module includes a database module, a trusted system module, and an organization management module; the distributed storage module is used to store trusted benchmark files; the database module is used to store key-value pairs corresponding to the trusted benchmark files stored in the distributed storage module; the trusted system module is used to store transaction blocks corresponding to the key-value pairs; and the organization management module is used to manage multiple embedded automated devices.

[0113] Optionally, the initiator performs system initialization configuration. The initiator of the entire system consists of several organizations, each containing several firmware developer members. Each organization sets its own key certificate configuration file and permission configuration file. The key certificate configuration file sets the organization name, domain name, number of firmware developers and baseline value users within the organization, etc. The system can automatically generate the required key and certificate files in batches according to the configuration file for identity authentication and access control. The permission configuration file defines the permissions of firmware developers and baseline value users to call system chaincode, including read and write permissions, etc. The chaincode is mapped to the security policy.

[0114] The system generates a genesis block, and the permission configuration files of all organizations form a tree structure, with the root node hash value being a part of the genesis block data.

[0115] When a new firmware developer needs to join the firmware data processing system, the permission configuration file is modified, including adding an organization. This requires the vote and signature of a majority of the organization's administrators. The configuration is then re-encoded and submitted to the system as a transaction. When an existing firmware developer in the system does not meet the rules, the system performs a deletion operation. The permission configuration file is modified, requiring the vote and signature of a majority of the organization's administrators. The configuration is then re-encoded and submitted to the federated system as a transaction via chaincode calls.

[0116] Specifically, the federated distributed trusted system mainly comprises a channel and numerous organizations. These organizations are divided into two categories: organizations composed of firmware developers (Organization 1 and Organization 2); and organizations composed of verifiers (Organization 3). Firmware developers have the authority to call relevant chaincode to write records to the federated distributed trusted system's Key-Value database, thereby conducting transactions and writing the transaction records into blocks. Verifiers have strictly limited permissions, possessing only read and query rights. Access control is based on PKI signature authentication; when firmware developers release trusted benchmark values, they must obtain endorsement and signature authentication managed by a majority of organizations. The Key-Value database stores trusted benchmark value identifiers and distributed storage indexes. Verifiers can read the trusted benchmark value file in distributed storage through the storage index based on the obtained firmware identifier.

[0117] The joint distributed trusted benchmark management system provided in this invention includes: a distributed storage module and a joint distributed trusted system module; the joint distributed trusted system module includes a database module, a trusted system module, and an organization management module; the distributed storage module is used to store trusted benchmark files; the database module is used to store key-value pairs corresponding to the trusted benchmark files stored in the distributed storage module; the trusted system module is used to store transaction blocks corresponding to the key-value pairs; the organization management module is used to manage multiple embedded automation devices. Compared to existing systems where various manufacturers do not form a joint mechanism for program signature management, typically a security center needs to verify the trustworthiness of all different types and manufacturers' systems within its security domain. This requires the security center to collect and manage trusted benchmarks from various manufacturers, which is difficult to meet the requirements of the security center. This system enables unified management of trusted benchmarks for the same type of system, allowing the security center to obtain benchmarks from firmware from all joint manufacturers within a single system.

Claims

1. A joint distributed trusted benchmark value management method, characterized in that, include: Obtain a trusted baseline value file, wherein the trusted baseline value file is generated during the update of the target firmware, and the trusted baseline value file carries at least a file identifier and a firmware identifier; Obtain the storage index information of the trusted baseline value file during distributed storage; The file identifier and the storage index information are associated and stored in the joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file, wherein the key storage information includes transaction information; An unbalanced hash block tree is constructed based on the key storage information. The unbalanced hash block tree is used to verify any transaction information in the distributed trusted system. The step of associating and storing the file identifier and the storage index information in the joint distributed trusted system to generate key storage information corresponding to the trusted benchmark file includes: The file identifier is used as the key value of the database of the joint distributed trusted system, and the storage index information is used as the value value of the database of the joint distributed trusted system. Using the Key and Value values, a key-value pair corresponding to the trusted benchmark file is constructed in the database of the federated distributed trusted system, and a transaction block corresponding to the key-value pair is created in the federated distributed trusted system, wherein the transaction block stores the transaction information corresponding to the trusted benchmark file; The key-value pair and the transaction block are identified as the key storage information; The construction of an unbalanced hash block tree based on the key storage information includes: The transaction block that meets the preset conditions in at least one transaction block in the key storage information is determined as the root node of the unbalanced hash block tree, and it is determined whether the tree rooted at the root node is a full binary tree. If not, iteratively determine the right child node of the root node until a tree with the target node as the root is found to be a full binary tree; Based on the full binary tree, an empty leaf node is generated, block header information is added to the empty leaf node, and the Value field value of the empty leaf node is calculated. The block header information is the root node hash value of the unbalanced hash tree before the empty leaf node is added. Based on the full binary tree, an empty intermediate node is generated, and the Value field value of the empty intermediate node is calculated, wherein the left node of the empty intermediate node is the target node, and the right node is the empty leaf node. Starting from the empty intermediate node, update the node hash value upwards until the root node to obtain the updated unbalanced hash block tree.

2. The method according to claim 1, characterized in that, After obtaining the trusted baseline value file corresponding to the target firmware deployed on the embedded automation device, the method further includes: The target distributed storage location of the trusted benchmark value file is determined by using a preset distributed hash table. The trusted benchmark file is stored in the target distributed storage location.

3. A joint distributed trusted benchmark value management method, characterized in that, include: Obtain a trusted proof report, wherein the trusted proof report carries at least the target firmware identifier; The target firmware identifier is used to obtain the corresponding target trusted benchmark value file, and the target file identifier is obtained from the target trusted benchmark value file; Query the target key storage information corresponding to the target firmware identifier from the joint distributed trusted system; The target key storage information is proved using an unbalanced hash block tree to obtain target proof information, and the target proof information is used to verify the trusted proof report to obtain a verification result, wherein the verification result is used to indicate whether the trusted proof report is correct; The step of querying the target key storage information corresponding to the target firmware identifier from the federated distributed trusted system includes: The system retrieves target key-value pairs corresponding to the target firmware identifier from the database of the joint distributed trusted system, obtains target storage index information from the target key-value pairs, and obtains corresponding target blocks from the joint distributed trusted system; the target storage index information and the target blocks are determined as the target key storage information, wherein the key-value pairs include the key value and the value value of the database of the joint distributed trusted system, the key is used to represent the file identifier, the value is used to represent the storage index information, and the storage index information is obtained when the trusted baseline value file is distributedly stored; The construction process of the unbalanced hash block tree includes: The transaction block that meets the preset conditions in at least one transaction block in the key storage information is determined as the root node of the unbalanced hash block tree, and it is determined whether the tree rooted at the root node is a full binary tree. If not, iteratively determine the right child node of the root node until a tree with the target node as the root is found to be a full binary tree; Based on the full binary tree, an empty leaf node is generated, block header information is added to the empty leaf node, and the Value field value of the empty leaf node is calculated. The block header information is the root node hash value of the unbalanced hash tree before the empty leaf node is added. Based on the full binary tree, an empty intermediate node is generated, and the Value field value of the empty intermediate node is calculated, wherein the left node of the empty intermediate node is the target node, and the right node is the empty leaf node. Starting from the empty intermediate node, update the node hash value upwards until the root node to obtain the updated unbalanced hash block tree.

4. The method according to claim 3, characterized in that, The step of using an unbalanced hash block tree to prove the target key storage information to obtain target proof information includes: Obtain the target transaction block from the target key storage information; Determine whether the target transaction block carries transaction information corresponding to the target file identifier to obtain first proof information, and determine whether the target transaction block exists in the unbalanced hash block tree to obtain second proof information; The target proof information is determined based on the first proof information and the second proof information.

5. The method according to claim 4, characterized in that, The step of verifying the credible proof report using the target proof information to obtain the verification result includes: Based on the proof information, the hash value of the root node of the transaction tree is constructed and compared with the field in the corresponding block. If the comparison is successful, the hash value of the root node of the block tree is constructed and compared with the value of the root field of the block tree in the latest block header of the joint distributed trusted system. If they match, it means that the obtained trusted benchmark metric file index is correct.

6. A joint distributed trusted benchmark management system, characterized in that, include: Distributed storage module, joint distributed trusted system module; The joint distributed trusted system module includes a database module, a trusted module, and an organization management module; The distributed storage module is used to store trusted benchmark value files; The database module is used to store key-value pairs corresponding to the trusted benchmark value file stored by the distributed storage module. The key-value pairs include the key value of the database of the joint distributed trusted system and the value value of the database of the joint distributed trusted system. The key is used to represent the file identifier, and the value value is used to represent the storage index information. The file identifier is carried by the trusted benchmark value file, and the storage index information is obtained when the trusted benchmark value file is distributed and stored. The joint distributed trusted system module is used to store the transaction blocks corresponding to the key-value pairs; the key-value pairs and the transaction blocks are used to generate key storage information, the key storage information is used to construct an unbalanced hash block tree, the unbalanced hash block tree is used to verify any transaction information in the joint distributed trusted system, and the construction process of the unbalanced hash block tree includes: The transaction block that meets the preset conditions in at least one transaction block in the key storage information is determined as the root node of the unbalanced hash block tree, and it is determined whether the tree rooted at the root node is a full binary tree. If not, iteratively determine the right child node of the root node until a tree with the target node as the root is found to be a full binary tree; Based on the full binary tree, an empty leaf node is generated, block header information is added to the empty leaf node, and the Value field value of the empty leaf node is calculated. The block header information is the root node hash value of the unbalanced hash tree before the empty leaf node is added. Based on the full binary tree, an empty intermediate node is generated, and the Value field value of the empty intermediate node is calculated, wherein the left node of the empty intermediate node is the target node, and the right node is the empty leaf node. Starting from the empty intermediate node, update the node hash value upwards until the root node to obtain the updated unbalanced hash block tree.

7. The system according to claim 6, characterized in that, The organization management module is used to manage multiple embedded automation devices.

Images