Node interaction method, certificate verification method, device and related equipment

Abstract

The present invention provides a node interaction method, a certificate verification method, an apparatus and related equipment. The node interaction method includes: a first CA node joins a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that trust each other with the first CA node, and the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate of a CA node and a node trust score value, and each CA node stores a blockchain. In this way, for the CA node trusted by the terminal to join other CA nodes in the same mutual trust alliance to issue certificates to other terminals, the terminal can first verify the CA node certificate in the mutual trust alliance by means of a hash tree, and then verify the legitimacy of the terminal certificates of other terminals by means of the CA node certificate, so as to realize that all certificates issued by the CA nodes in the mutual trust alliance are also trusted, and solve the mutual trust problem between any CA nodes at a lower cost.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of communication technology, and in particular to a node interaction method, a certificate verification method, an apparatus, and related equipment. Background Art

[0002] Certificates provide proof of identity for entities, and to verify the legitimacy of the entity certificate itself, a certificate trust model is required. In the traditional root certificate authority (CA) trust model, the root CA issues intermediate CA1 and CA2 certificates, and CA1 and CA2 issue certificates 1 to 4 respectively. If the device stores the root CA certificate as a trust anchor, the legitimacy of certificates 1 to 4 can be verified through the certificate chain.

[0003] In order to make up for the defects of the traditional tree-like certificate chain, three trust models have been born: the cross-certification trust model, the bridge CA trust model, and the list trust model. Among them, the cross-certification trust model and the bridge CA trust model are costly and not flexible enough. The list trust model requires storing multiple trust anchors on the device side. For example, a web browser will have multiple CA certificates built in as trust anchors. For resource-constrained devices, the cost of storing and updating multiple trust anchors is high. The above four traditional trust models cannot solve the certificate trust verification problem.

[0004] It can be seen that the existing traditional trust model cannot solve the problem of certificate trust verification. Summary of the invention

[0005] The embodiments of the present invention provide a node interaction method, a certificate verification method, an apparatus and related equipment to solve the problem that the existing trust model cannot solve the certificate trust verification problem.

[0006] To solve the above problems, the present invention is achieved as follows:

[0007] In a first aspect, an embodiment of the present invention provides a node interaction method, which is performed by a first CA node, and the method includes:

[0008] Join a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that trust each other with the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain.

[0009] In a second aspect, an embodiment of the present invention provides a certificate verification method, which is performed by a first terminal, and the method includes:

[0010] Apply for a terminal certificate from a trusted first CA node, where the first CA node is any node in the mutual trust alliance;

[0011] Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate;

[0012] The terminal certificate, the node certificate of the first CA node and the path hash node are sent to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

[0013] In a third aspect, an embodiment of the present invention provides a certificate verification method, which is performed by a second terminal, and the method includes:

[0014] Request the second CA node in the mutual trust alliance to obtain the real-time root hash value;

[0015] Receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal;

[0016] The legitimacy of the terminal certificate of the first terminal is verified according to the root hash value, the node certificate of the first CA node and the path hash node.

[0017] In a fourth aspect, an embodiment of the present invention provides a node interaction method, which is executed by a terminal device, and the method includes:

[0018] Sending a blockchain supervision request to a first CA node in the mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance;

[0019] Obtain the real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated through all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and voting process tree are both legal;

[0020] If the legitimacy of the blockchain fails to be verified, an alarm message is sent to any CA node in the mutual trust alliance.

[0021] In a fifth aspect, an embodiment of the present invention further provides a node interaction device, including a first processor, configured to:

[0022] Join a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that trust each other with the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain.

[0023] In a sixth aspect, an embodiment of the present invention further provides a certificate verification device, comprising a first transceiver, configured to:

[0024] Applying for a terminal certificate from a trusted first CA node, wherein the first CA node is located in a mutual trust alliance;

[0025] Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate;

[0026] The terminal certificate, the node certificate of the first CA node and the path hash node are sent to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

[0027] In a seventh aspect, an embodiment of the present invention provides a certificate verification device, including:

[0028] A second transceiver is used to request a second CA node in the mutual trust alliance to obtain a real-time root hash value, receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal;

[0029] The second processor is used to verify the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node, the path hash node and the root hash value.

[0030] In an eighth aspect, an embodiment of the present invention provides a node interaction device, including:

[0031] A third transceiver, configured to send a blockchain supervision request to a first CA node in the mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance;

[0032] a third processor, configured to obtain a real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain refers to that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA state tree, the hash pointers between blocks match, and the CA state tree and the voting process tree are both legal;

[0033] The third transceiver is also used to send an alarm message to any CA node in the mutual trust alliance if the legitimacy of the blockchain is not verified.

[0034] In the ninth aspect, an embodiment of the present invention further provides a communication device, comprising: a transceiver, a memory, a processor, and a program stored in the memory and executable on the processor; characterized in that the processor is used to read the program in the memory to implement the steps in the method described in the first aspect above; or, the steps in the method described in the second aspect above; or, the steps in the method described in the third aspect above; or, the steps in the method described in the fourth aspect above.

[0035] In the tenth aspect, an embodiment of the present invention further provides a readable storage medium for storing a program, wherein the program, when executed by a processor, implements the steps in the method described in the first aspect, or implements the steps in the method described in the second aspect; or, the steps in the method described in the third aspect; or, the steps in the method described in the fourth aspect.

[0036] In an embodiment of the present invention, mutually trusted CA nodes join the same mutual trust alliance, and the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree. Each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain. In this way, for the CA node trusted by the terminal to join other CA nodes in the same mutual trust alliance to issue certificates to other terminals, the terminal can first verify the CA node certificate in the mutual trust alliance through a hash tree, and then verify the legitimacy of the terminal certificate of other terminals through the CA node certificate, so as to achieve that all certificates issued by CA nodes in the mutual trust alliance are also trusted, and solve the mutual trust problem between any CA nodes at a lower cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings required for use in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the accompanying drawings in the following description are only some embodiments of the present invention. For ordinary technicians in this field, other accompanying drawings can be obtained based on these accompanying drawings without paying creative labor.

[0038] Figure 1 is a schematic diagram of the structure of a network system to which an embodiment of the present invention can be applied;

[0039] Figure 2 This is one of the flowcharts of the node interaction method provided by an embodiment of the present invention;

[0040] Figure 3 is a schematic diagram of a genesis block involved in a node interaction method provided in an embodiment of the present invention;

[0041] Figure 4 is a schematic diagram of a CA state tree involved in a node interaction method provided in an embodiment of the present invention;

[0042] Figure 5 is a schematic diagram of a blockchain involved in the node interaction method provided in an embodiment of the present invention;

[0043] Figure 6 is a schematic diagram of a voting block involved in the node interaction method provided in an embodiment of the present invention;

[0044] Figure 7 This is one of the flow charts of the certificate verification method provided by the embodiment of the present invention;

[0045] Figure 8 This is a second flow chart of the certificate verification method provided by an embodiment of the present invention;

[0046] Fig. 9 This is the second flowchart of the node interaction method provided by the embodiment of the present invention;

[0047] Fig.10 It is one of the structural schematic diagrams of the node interaction device provided by the implementation of the present invention;

[0048] Fig.11 It is one of the structural schematic diagrams of the certificate verification device provided by the implementation of the present invention;

[0049] Fig.12 This is the second structural diagram of the certificate verification device provided by the present invention;

[0050] Fig.13 This is the second structural diagram of the node interaction device provided by the embodiment of the present invention;

[0051] Fig.14 It is a schematic diagram of the structure of the communication device provided by the implementation of the present invention. DETAILED DESCRIPTION

[0052] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0053] The terms "first", "second" etc. in the embodiments of the present invention are used to distinguish similar objects, and need not be used to describe a specific order or sequential order. In addition, the terms "include" and "have" and any variation thereof are intended to cover non-exclusive inclusions, for example, the process, method, system, product or equipment comprising a series of steps or units need not be limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or equipment. In addition, "and / or" is used in the present application to represent at least one of the connected objects, such as A and / or B and / or C, which represents 7 situations including single A, single B, single C, and A and B all exist, B and C all exist, A and C all exist, and A, B and C all exist.

[0054] See also Figure 1 , Figure 1 is a structural diagram of a network system to which an embodiment of the present invention can be applied, such as Figure 1 As shown, at least two CA nodes 11 and a terminal device 12 are included in the mutual trust alliance. The CA node 11 and the terminal device 12 can communicate with each other.

[0055] In practical applications, the CA node 11 may be any CA node within the mutual trust alliance, such as the first CA node or the second CA node described below; the terminal device 12 may be a terminal device, a first terminal or a second terminal for executing the method described below, but is not limited thereto.

[0056] The node interaction method and certificate verification method provided by the embodiments of the present invention are described below.

[0057] See also Figure 2 , Figure 2It is one of the flow charts of the node interaction method provided by the embodiment of the present invention. The node interaction method provided in this embodiment is executed by any CA node in the mutual trust alliance. The mutual trust alliance includes multiple mutually trusted CA nodes, and the CA nodes perform CA node legitimacy verification and other interactive behaviors. For the convenience of description, all CA nodes in the mutual trust alliance are divided into a first CA node and a second CA node. The first CA node can represent a CA node that actively initiates behavior, and the second CA node can represent a CA node that passively interacts. Of course, the same CA node may be the first CA node or the second CA node in different situations. The first and second here are only used for functional distinction. Figure 2 The node interaction method shown is a node interaction method executed by the first CA node, and can certainly also be executed by the second CA node.

[0058] like Figure 2 As shown, the node interaction method may include the following steps:

[0059] Step 201: Join a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that trust each other with the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain.

[0060] In this embodiment, the first CA node is limited to join a mutual trust alliance, which is an alliance including mutually trusted CA nodes. There are many ways for the first CA node to join the mutual trust alliance, for example, participating in the creation of a mutual trust alliance as an initial node, or joining an already established mutual trust alliance as a subsequent node.

[0061] like Figure 3 As shown, the interconnection alliance corresponds to a blockchain, which includes a real-time CA status tree and a root hash value. The CA status tree is a tree structure used to characterize the relevant status of each CA node. Here, it is preferred to construct a hash tree in the Merkle Patricia Tree format, and calculate the root hash value based on each leaf node of the CA status tree. When storing, the root hash value can be stored in the block header, and the CA status tree can be stored in the block body.

[0062] The CA status tree includes multiple leaf nodes, each of which is used to store a node certificate and a node trust score value of a corresponding CA node. The node trust score value is a value used to indicate the degree of trust of the CA node within the mutual trust alliance.

[0063] Each CA node in the mutual trust alliance stores the blockchain, so any CA node can search the blockchain for node certificates, node trust scores, and other content of other CA nodes in the mutual trust alliance. Since CA nodes trust each other, certificates issued by CA nodes can also be trusted across nodes, that is, a terminal that trusts the first CA node can verify the legitimacy of a terminal certificate issued to the terminal by any other CA node through the root hash value of the blockchain.

[0064] In the node interaction method of the embodiment of the present invention, mutually trusted CA nodes join the same mutual trust alliance, and the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, and each leaf node of the CA status tree includes a node certificate of a CA node and a node trust score value, and each CA node in the mutual trust alliance stores the blockchain. In this way, for the CA node trusted by the terminal to join other CA nodes in the same mutual trust alliance to issue certificates to other terminals, the terminal can first verify the CA node certificate in the mutual trust alliance by means of a hash tree, and then verify the legitimacy of the terminal certificate of other terminals by means of the CA node certificate, so as to achieve that all certificates issued by CA nodes in the mutual trust alliance are also trusted, and solve the mutual trust problem between any CA nodes at a lower cost.

[0065] On the basis of the above embodiment, according to a specific implementation of the present disclosure, the blockchain includes a genesis block, and the step of joining the mutual trust alliance includes:

[0066] Obtain node certificates of all initially trusted CA nodes;

[0067] Determine the node trust score value of each CA node;

[0068] Generate an initial CA status tree, each leaf node of the initial CA status tree includes a node certificate and a node trust score value of a CA node;

[0069] Calculate the root hash value based on the node certificates and node trust scores of all CA nodes;

[0070] Creating a genesis block of the mutual trust alliance, and storing the root hash value and the initial CA state tree in the genesis block;

[0071] The genesis block is synchronously sent to all CA nodes.

[0072] This implementation method specifically defines the scheme for the first CA node to create a mutual trust alliance as the initial node. When creating a mutual trust alliance, the first block of the blockchain, namely the genesis block, is first created. The genesis block includes an initial CA state tree, namely, a state tree of the initial mutually trusted CA nodes involved in the creation.

[0073] In specific implementation, the steps for generating the CA status tree may include:

[0074] Taking the binary tuple containing the node certificate and the node trust score value of a CA node as a leaf node of the CA status tree, and constructing the CA status tree in the format of a Merkle Patricia tree based on the leaf nodes corresponding to all CA nodes.

[0075] Specifically, mutually trusted CAs CA1, CA2... CAn establish a consortium chain. Each node takes the certificates of CA1 - CAn and the initial trust score binary tuple [CA Cert, Trust Level] as leaf nodes, establishes a CA status tree in the format of a lexicographical variant format (Merkle Patricia Tree, abbreviated as MPT), and calculates the root hash value Root Hash. Each node writes the RootHash into the block header Block Header of the genesis block, writes the CA status tree and the certificates of leaf nodes CA1 - CAn into the block body Block Body, and makes the Root Hash public.

[0076] In addition to the default content of the blockchain, the genesis block contains at least the following content:

[0077] Block Header: Root Hash of the CA status tree;

[0078] Block Body: CA status tree, that is, each leaf node [CA1 Cert, Trust Level1], [CA2 Cert, Trust Level2]... [CAn Cert, Trust Leveln]. The initial value of Trust Level can be set according to specific requirements, and the default is the numerical values {1, 2... 5}. The initial participants of the CA consortium can set the Trust Level to the highest value 5, and the subsequent joined nodes are 3. When a CA node operates in compliance for a long time or performs illegal operations, the Trust level of the CA node can be increased or decreased through internal voting within the consortium.

[0079] The device can set a trust threshold k, and when the Trust level of the CA node < k, it is not trusted. When the Trust Level of the CA node is 0, the CA node is expelled from the consortium, cannot participate in and initiate other active operations within the mutual trust consortium, and is not trusted by the device.

[0080] Such as Figure 3The structure diagram of the provided genesis block is shown in FIG. The initial nodes are CA1, CA2, CA3 and CA4. The initial CA status tree can be created by any CA node among the four initial nodes, and then synchronized to all CA nodes and stored. The CA status tree includes 4 leaf nodes, each of which is used to store the node certificate CA Cert of the corresponding CA node and the node trust score Trust Level. The process of obtaining the initial root hash value Root Hash is as follows:

[0081] H1 = Hash(leaf 1), H2 = Hash(leaf 2), H3 = Hash(leaf 3), H4 = Hash(leaf 4);

[0082] H5=Hash(H1|H2), H6=Hash(H3|H4);

[0083] Root Hash=Hash(H5|H6).

[0084] Correspondingly, such as Figure 4 As shown, after the Root Hash is made public, when the entity has a trusted Root Hash, it needs to verify the correctness of the leaf 1 data, which can be calculated as follows:

[0085] Hash(Hash(Hash(Leaf1)|H2)|H6)

[0086] Determine whether the result of the operation is equal to the Root Hash to verify the correctness of Leaf 1.

[0087] The left side is the verification operation path from leaf 1 to the Root Hash, and H2 and H6 are the Hash path nodes required for verification. The operation complexity of verifying the leaf node is the depth of the Merkle Tree, that is, Log(n), where n is the number of leaf nodes.

[0088] Entity A can obtain the path hash values ​​of H2, H6, etc. from any node and verify whether both sides of the equation are true with leaf 1. If the equation is true, leaf 1 is in the Merkle Tree and has not been tampered with.

[0089] If any data in H2, H6 and leaf 1 is wrong, the equation will be invalid and the tampered leaf 1 will not be recognized as a trusted node. This solution can use the dictionary order variant of Merkle Tree, which is consistent with the verification method of the classic Merkle Tree, and can ensure that the trees generated by the same leaf node set must be the same, avoiding different Root Hash calculated independently by each node in the blockchain.

[0090] According to another specific embodiment of the present disclosure, Figure 5 As shown, the blockchain includes a voting block located after the genesis block; the method further includes:

[0091] Execute voting actions corresponding to all CA nodes in the mutual trust alliance, wherein the voting actions include any one of node addition voting, node reward voting, node penalty voting and certificate renewal voting;

[0092] A voting block is added to the blockchain, the voting block includes a voting process tree corresponding to the voting behavior and a CA status tree corresponding to the real-time CA node status, and each leaf node of the voting process tree includes a node name, node voting data and node signature of a CA node.

[0093] In this implementation, it is limited that after the creation of the genesis block, the mutual trust alliance can initiate specific actions such as adding, rewarding, punishing and updating certificates for CA nodes. These specific actions require the support and synchronization of all CA nodes in the mutual trust alliance, and are mainly carried out in the form of voting. The corresponding voting actions can include node addition voting, node reward voting, node penalty voting and certificate update voting. After joining the mutual trust alliance, the first CA node can act as a host node and initiate voting to other CA nodes. Of course, the first CA node can also accept voting initiated by other CA nodes, so that decentralized and effective management can be achieved.

[0094] In specific implementation, the steps for generating the voting process tree may include:

[0095] The triplet containing the node name, node voting data and node signature of a CA node is taken as a leaf node of the voting process tree, and the voting process tree in the Merkle Patricia tree format is constructed according to the leaf nodes corresponding to all CA nodes.

[0096] Specifically, after the first CA node initiates a voting behavior to other CA nodes, it generates a voting process tree and a real-time CA status tree corresponding to the voting behavior based on the node name, node voting data and node signature fed back by each CA node, such as Figure 6 As shown, each leaf node of the voting status tree stores the node name, node voting data and node signature of a CA node. Afterwards, the first CA node creates a voting block corresponding to this voting behavior, connects the voting block to the blockchain, and synchronizes it to each CA node. In this way, each CA node in the mutual trust alliance can view the voting data of each CA node in this voting behavior, and query the node certificate and node trust score value of each CA node through the latest CA status tree. Each voting block represents a voting behavior, including a CA status tree and a voting process tree. For each vote, regardless of whether the issue is passed or not, a voting block will be added after the latest block.

[0097] Furthermore, the step of executing the voting behavior corresponding to all CA nodes in the mutual trust alliance includes:

[0098] Initiating a voting request corresponding to the preset behavior request to all second CA nodes in the mutual trust alliance, wherein the voting request at least includes the preset behavior request, and the second CA node is a CA node other than the first CA node in the mutual trust alliance;

[0099] receiving voting data returned by the second CA node after verifying the legitimacy of the preset action request, wherein the voting data includes a node name of the second CA node and a voting result;

[0100] The step of adding a voting block to the blockchain includes:

[0101] Obtaining a comprehensive voting result according to the voting results of all the second CA nodes;

[0102] A voting process tree corresponding to the voting behavior is created according to the comprehensive voting result, and the voting block containing the voting process tree is synchronously sent to all CA nodes, so that all CA nodes store the voting block in the blockchain.

[0103] This implementation method specifically defines the voting process. The first CA node initiates a voting behavior to all second CA nodes to request the voting data of other second CA nodes for the preset behavior request. After receiving the voting request from the first CA node, the second CA node will first verify the legitimacy of the preset behavior request, and can provide the voting data after verifying the legitimacy of the preset behavior request. In specific implementation, the second CA node can generate the corresponding voting data based on the relevant parameters of the preset behavior request or the legitimacy of the certificate and other factors. The voting data usually includes either approval or disapproval.

[0104] After receiving the voting data returned by the second CA node, the first CA node uses the voting results of all the second CA nodes to calculate a comprehensive voting result, and then uses the comprehensive voting result to synchronize to all CA nodes in the mutual trust alliance in the form of a voting block.

[0105] Based on the above embodiments, the method further includes:

[0106] Verify the legitimacy of the latest block received, where the latest block is a genesis block or a voting block;

[0107] After verifying the legitimacy of the latest block, the latest block is stored.

[0108] In this implementation, it is limited that the first CA node can receive blocks sent by other CA nodes, which are defined as the latest blocks. If it is the initial creation stage, the latest block can be the genesis block. If it is the subsequent use stage, the latest block is the voting block. After receiving the latest block, the first CA node will first verify the legitimacy of the latest block to verify whether the source node of the latest block is legal. Only after the legitimacy of the latest block is verified, the received latest block will be stored.

[0109] Furthermore, the step of creating a voting process tree corresponding to the voting behavior according to the comprehensive voting result, and synchronously sending the voting block containing the voting process tree to all CA nodes includes:

[0110] If the comprehensive voting result is approval, generate the voting process tree and the latest CA status tree, and send the voting block containing the voting process tree and the latest CA status tree to all CA nodes;

[0111] If the comprehensive voting result is negative, a voting process tree is generated, and a voting block including the voting process tree and the current CA status tree is sent to all CA nodes.

[0112] Considering the actual voting behavior, when the comprehensive voting result is approval, it usually involves changes in the composition of CA nodes, the node trust score of CA nodes, node certificates, etc. within the mutual trust alliance, and the latest CA status tree needs to be generated at this time. If the comprehensive voting result is opposition, it does not involve changes in the above data within the mutual trust alliance, so there is no need to generate the latest CA status tree, and the current real-time CA status tree can be directly used as the latest CA status tree. The voting process tree is used to record, back up and track each voting behavior, so each voting behavior will generate a voting block to update the voting process and the latest CA status tree.

[0113] In addition, the voting data also includes a node signature of the second CA node, and the step of obtaining a comprehensive voting result according to the voting results of all the second CA nodes includes:

[0114] The legitimacy of the voting data is verified according to the node signature, and after the legitimacy of the voting data is verified, a comprehensive voting result is obtained according to the voting results of all the second CA nodes.

[0115] This implementation method limits the legitimacy verification of the voting process terminal. In specific implementation, the legitimacy of the node certificate of the data source and the data itself can be verified after each data is received to avoid tampering.

[0116] Of course, the first CA node can also receive voting actions initiated by other CA nodes. In this case, the method may further include:

[0117] Receiving a voting request corresponding to a preset behavior request initiated by a second CA node within the mutual trust alliance, where the voting request at least includes the preset behavior request;

[0118] Verifying the legality of the preset behavior request;

[0119] After verifying the legality of the preset behavior request, returning voting data to the second CA node so that the second CA node generates a voting process tree based on the voting data. Among them, the voting data includes the node name and voting result of the first CA node, and each leaf node of the voting process tree includes the node name, node voting data, and node signature of a CA node;

[0120] Receiving a voting block containing the voting process tree sent by the second CA node and storing it in the blockchain corresponding to the mutual trust alliance.

[0121] In this embodiment, the first CA node receives a screen projection request initiated by a second CA node within the mutual trust alliance. After verifying the legality, it returns corresponding voting data. The specific process can refer to the specific implementation process of the above-mentioned voting process and will not be elaborated here.

[0122] The method further includes:

[0123] If the node trust score value of the first CA node is greater than or equal to the trust threshold, allowing the execution of voting actions for all CA nodes within the mutual trust alliance;

[0124] If the node trust score value of the first CA node is less than the trust threshold, prohibiting the execution of voting actions for all CA nodes within the mutual trust alliance.

[0125] In this embodiment, permission restrictions are imposed according to the node trust score value of the CA node. Specifically, if the node trust score value of the first CA node is greater than or equal to the trust threshold, it can initiate or receive voting actions. Otherwise, it cannot initiate or receive voting actions. For example, the device can set a trust threshold k, and when the Trust level of the CA node < k, it is not trusted. When the Trust Level of the CA node is 0, the CA node is expelled from the alliance and cannot participate in or initiate other active operations within the mutual trust alliance, nor is it trusted by the device.

[0126] Next, the voting processes corresponding to different preset behavior requests will be specifically described.

[0127] In a first aspect, the preset behavior request is a request for adding a new node. Before the step of initiating a voting request corresponding to the preset behavior request to all the second CA nodes in the mutual trust alliance, the method further includes:

[0128] Receiving a request to join the alliance sent by an external CA node, wherein the request to join the alliance includes the node name, node certificate, application time, guarantee signature and private key signature of the external CA node, and the external CA node is a CA node that has not joined the mutual trust alliance;

[0129] Verifying the private key signature using the node certificate of the external CA node;

[0130] The step of initiating a voting request corresponding to a preset behavior request to all the second CA nodes in the mutual trust alliance includes:

[0131] After verifying the private key signature, a voting request corresponding to the alliance joining request is initiated to all second CA nodes in the mutual trust alliance, wherein the voting request includes the alliance joining request of the external CA node and the signature of the first CA node on the alliance joining request.

[0132] Second, when a node CA in the CA alliance k When (k∈{1,2…n}) misbehaves, any other node can target CA k Initiate a penalty voting request, which includes CA k Evidence of misconduct, the trust score to be lowered, and the signature of the initiator. The entire alliance votes to decide whether to lower the CA k The voting process is the same as for new nodes.

[0133] Third, when a CA in the CA alliance k (k∈{1,2…n}) has the right to increase the trust score and initiate a vote request to the CA Alliance to increase the trust score. The request must include the CA k The length of time that the alliance operates in compliance (each application can only increase one point), and other nodes can trace the entire blockchain to ensure that CA k The claimed length of time of compliance in the alliance corresponds to the actual length of time, and other factors are considered in the voting process. The voting process is the same as that of new nodes.

[0134] Fourth, when CA kWhen a (k∈{1,2…n}) node updates its certificate due to certificate expiration or other reasons, it needs to send a certificate update voting request to all CA nodes in the alliance. The request must include at least a triplet [CA k New certificate from CA K The voting process is the same as the new node joining. The old certificate is still used for identity signature during the voting process. When the voting process is over, CA k The new certificate is valid.

[0135] It should be noted that in order to avoid the impact of decision-making order on the results. Each time a vote is initiated, only one issue is considered. When multiple blocks initiate voting at the same time, each block can only have one issue, based on the order of the first voting. If there is a new issue, it is necessary to initiate voting in the next block after consensus is reached on the current issue. For each vote, if more than 2 / 3 of the CA nodes agree, the voting issue is passed. The 2 / 3 here is a common voting pass ratio in the blockchain, which means that the majority of nodes agree to the voting process under the premise that all nodes have used the existing alliance chain technology to complete the block synchronization of each node, ensuring that the blockchain stored by each node is consistent each time a vote is cast.

[0136] This implementation takes the addition of a new node as an example to briefly describe the voting process. The voting process for the two issues of punishment and reward is the same as that for the addition of a new node, so it will not be repeated.

[0137] When the external node CAn+1 is ready to join the alliance, it sends a request to any member CA k (k∈{1, 2…n}) sends a join request, where the requested CA node is limited to the first CA node. The request contains at least the following content:

[0138] [[CAn+1Name, CAn+1 certificate, application time, voting evidence (in the process of new node joining, this content is the CA qualification certificate, such as root CA certificate, offline agreement copy, guarantor signature, etc. to prove its own CA qualification)], signature of the above four-tuple with the private key of CAn+1 certificate].

[0139] CA k In response to the request, the CAn+1 certificate is used to verify the signature of the CAn+1 joining request, confirming that the request source is reliable and has not been tampered with, and then a new node joining voting request is initiated to all nodes in the alliance. The request contains at least the following voting topics:

[0140] [CAn+1 join request, CA k Signature of CAn+1 join request].

[0141] All CA nodes in the alliance receive the voting request and query the CA in the CA status tree in the latest block. k The corresponding leaf node [CA k Cert, Trust Levelk], determine Trust Level k >0, i.e. CA k Have the power to initiate voting, and then use CA k Cert verification voting request, CA k The voting request is reliable and has not been tampered with, and the signature and qualification certificate in the CAn+1 joining request are verified and reviewed before submitting it to CA k Return voting feedback:

[0142] [[CA Name, CA voting result (0 or 1), voting request, voting description (explanation of voting behavior, reasons for negative and positive votes, can be empty)], CA node signs the private key of the above four-tuple. k Get voting feedback from CAi (i∈{1, 2…n} and i≠N), first read the leaf node [CAi Cert, Trust Leveli] in the CA status tree, check Trust leveli>0, CAi node has voting rights, and then use CAi Cert to verify the signature in the voting feedback to ensure that the voting feedback source is reliable and has not been tampered with. k Using the above method, we process the voting feedback from all nodes in the alliance and calculate the number of nodes that agree. If the number of nodes that agree does not exceed 2 / 3, the issue will not be passed, and CA k Build the voting process tree. If the number of nodes that agree exceeds 2 / 3, only rebuild the voting process tree.

[0143] CAk rebuilds the CA state tree. k Add the certificate and trust score tuple of CAn+1, i.e. [CAn+1Cert, Trust Leveln+1], to the leaf node, reconstruct the CA status tree in MPT format, and calculate the Root Hash.

[0144] Regardless of whether the vote is passed or not, for the purpose of tracing back, each voting process needs to be written into the block as a voting process tree. If the vote is not passed, there is no need to regenerate the CA state tree.

[0145] CA kConstruct a voting process tree, take the voting feedback of each node as a leaf node, construct a voting process tree in MPT format, calculate the Root Hash to record the voting process. Write the CA status tree and the voting process tree and the Root Hash of the two trees into the block. Finally, make the Root Hash of the final CA status tree public. And send the new block to all nodes.

[0146] In addition to the original content of the existing blockchain system, the new block contains at least the following content:

[0147] Block header: Root hash of the voting process tree, Root hash of the CA status tree.

[0148] Block body: voting process tree, CA status tree.

[0149] Take the alliance of four CA nodes as an example, its voting block is as follows Figure 3 and Figure 6 shown.

[0150] Of course, in another implementation, the first CA node may also apply to join the mutual trust alliance as an external CA node. The specific process may include:

[0151] Sending an alliance joining application to a second CA node in the mutual trust alliance, wherein the alliance joining request includes the node name, node certificate, application joining time, guarantee signature and private key signature of the first CA node, so that the second CA node verifies the private key signature using the node certificate of the first CA node, and after the verification is passed, initiates a voting request corresponding to the alliance joining request to all second CA nodes in the mutual trust alliance, wherein the voting request includes the alliance joining request of the first CA node and the signature of the second CA node on the alliance joining request;

[0152] If the comprehensive voting result obtained by the second CA node based on the voting request is approval, the second CA node joins the mutual trust alliance.

[0153] All CA nodes receive the blocks of the newly added nodes. Based on the existing mechanism of the alliance blockchain, they check the legitimacy of the blocks themselves, and then check the voting process tree to confirm that each leaf node is credible, that is, verify the signature in the voting feedback of each CA node, and then confirm that the voting process tree is constructed correctly. Check the CA status tree, and after confirmation, accept the block and store it locally. Then the round of voting is officially over.

[0154] In another specific implementation, the terminal device trusts the first CA node in the mutual trust alliance, and the step of verifying the legitimacy of the certificate issued by the second CA node in the mutual trust alliance through the blockchain includes:

[0155] Receive blockchain supervision requests sent by terminal devices or external CA nodes;

[0156] Returning the real-time blockchain of the mutual trust alliance to the terminal device so that the terminal device can determine the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and the voting process tree are both legal;

[0157] If an alarm message is received from the terminal device based on the legitimacy verification of the blockchain, a voting request for the corresponding penalty request is initiated to all CA nodes in the mutual trust alliance.

[0158] In this implementation, any entity can download the entire alliance chain from any CA node in the alliance, compare the Root Hash of the CA status tree published by different CA nodes to see if they are consistent, understand the voting process of each round, and verify the legitimacy of each block, as well as the legitimacy of the CA status tree and the voting process tree through the Hash pointer between blocks. The terminal device corresponding to the arbitrary entity may be in the alliance or not in the alliance.

[0159] When any entity verifies that a block or Root Hash published by a CA is illegal, it can send an alarm message to any node in the alliance chain. The alarm message includes: the name of the illegal CA, evidence of the violation, and the signature of the alarmist. The alliance CA node processes the alarm message and confirms that the evidence is true. Then any CA node can initiate a penalty vote and enter the voting process.

[0160] See also Figure 7 , Figure 7 This is one of the flow charts of the certificate verification method provided by the embodiment of the present invention. The certificate verification method of the embodiment of the present invention can be executed by a first terminal, and the first terminal trusts a first CA node in the mutual trust alliance.

[0161] like Figure 7 As shown, the certificate verification method may include the following steps:

[0162] Step 701: Apply for a terminal certificate from a trusted first CA node, wherein the first CA node is any node in a mutual trust alliance;

[0163] The first terminal B applies for an identity certificate Cert b at the first node CA1.

[0164] Step 702: Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate;

[0165] The first terminal downloads the CA 1 certificate from the first CA node, as well as the path Hash required for verification.

[0166] Step 703: Send the terminal certificate, the node certificate of the first CA node, and the path hash node to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal based on the node certificate of the first CA node, the path hash node, and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

[0167] The first terminal trusts the second CA node, and periodically accesses the CA to obtain the latest Root Hash of the CA status tree.

[0168] Optionally, device A sets a trust threshold k and trusts CAs with Trust Level>=k in the alliance. If device A does not set a trust threshold, it trusts CAs with Trust Level>0 in the alliance, thereby achieving dynamic trust.

[0169] The first terminal sends the signature information of the terminal certificate Cert b to the second terminal, and attaches the CA2 certificate and the CA2 Trust Level two-tuple [CA2 cert, Trust Level2], as well as the path Hash node required for verification.

[0170] The second terminal uses the Root Hash and the Hash path node sent by the first terminal to verify that the two-tuple [CA2cert, TL] is legal and credible, and then determines that the Trust Level2 of CA2>=k, and then determines that CA2cert is credible.

[0171] The second terminal uses the CA2 certificate to verify Cert b, confirms that the identity certificate is legitimate, and continues to verify the signature of the first device to confirm that the source of the message sent by the first device is reliable.

[0172] See also Figure 8 , Figure 8 This is one of the flow charts of the certificate verification method provided by the embodiment of the present invention. The certificate verification method of the embodiment of the present invention can be executed by the second terminal, and the second terminal trusts the first CA node in the mutual trust alliance.

[0173] like Figure 8 As shown, the certificate verification method may include the following steps:

[0174] Step 801: Request a second CA node in the mutual trust alliance to obtain a real-time root hash value;

[0175] Step 802: Receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal;

[0176] Step 803: Verify the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node, the path hash node, and the root hash value.

[0177] Optionally, the step of verifying the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node, and the path hash node specifically includes:

[0178] Verifying the legitimacy of the first CA node certificate according to the root hash value and the path hash node;

[0179] After verifying the legitimacy of the node certificate of the first CA node, the legitimacy of the terminal certificate of the first terminal is verified using the node certificate of the first CA node.

[0180] In this implementation, from the perspective of the second terminal, it is explained that the second terminal verifies the legitimacy of the terminal certificate issued to the first terminal by other CA nodes in the same mutual trust alliance according to the root hash value of the mutual trust alliance.

[0181] Specifically, the second terminal downloads the latest root hash value of the mutual trust alliance from the second CA node in real time to verify the legitimacy of certificates issued by other CA nodes in the mutual trust alliance to other terminals. Specifically, the second CA node first uses the root hash value and the path hash node, combined with the above method embodiment Figure 4 The verification scheme involved verifies the legitimacy of the node certificate of the first CA node. After verifying the legitimacy of the node certificate of the first CA node, the node certificate of the first CA node is used to verify the legitimacy of the terminal certificate of the first terminal.

[0182] In this way, the cross-node certificate verification method provided only needs to remember CA verification and terminal verification in sequence according to the latest root hash value. The verification scheme is relatively simple and the verification efficiency is high.

[0183] See also Fig. 9 , Fig. 9 This is the second flowchart of the node interaction method provided by the embodiment of the present invention. The node interaction method of the embodiment of the present invention can be executed by a terminal device, and the terminal device can trust the first CA node in the mutual trust alliance, or not trust any CA node in the mutual trust alliance.

[0184] like Fig. 9 As shown, the node interaction method may include the following steps:

[0185] Step 901: Send a blockchain supervision request to a first CA node in a mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance;

[0186] Step 902: Obtain the real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and the voting process tree are both legal;

[0187] Step 903: If the legitimacy of the blockchain fails to be verified, an alarm message is sent to any CA node in the mutual trust alliance.

[0188] The scheme for the terminal device to supervise the blockchain provided in this embodiment can refer to the relevant explanations about supervision in the node interaction method executed by the first CA node in the above embodiment, and will not be repeated here.

[0189] Based on the above implementations, the certificate verification method provided in this embodiment can also be expanded as follows:

[0190] The CA nodes involved include not only the CA (i.e. Certificate Authority) in the PKI system, but also any trusted third party that is capable of binding an entity to its identity (such as public-private key pairs, shared secrets, physically unclonable functions, etc.). The binding modes include but are not limited to modes based on certificate chains and identities.

[0191] By default, the Trust Level of the CA node in the alliance is > 0, which means that it has the right to vote and initiate voting. When using it, you can set the voting right threshold and the threshold for initiating voting according to your needs. Only CA nodes with a Trust Level higher than the threshold can vote and initiate voting operations;

[0192] The device can set a trust threshold or not. If not set, all CAs with Trust Level>0 are trusted by default. The Trust Level range of the CA alliance can be changed according to needs and is not limited to the value range of {1, 2...5}.

[0193] The initial Trust level scores of the initial CA node of the CA alliance and the subsequent CA nodes can be set according to specific needs and are not limited to 5 and 3.

[0194] The CA Alliance's voting approval ratio is not fixed at 2 / 3 and can be set to other values ​​as appropriate.

[0195] The CA Alliance internal voting method mentioned here is only one way to implement the proposal. Other methods such as smart contracts can also be used for voting.

[0196] In order to prevent attackers from initiating votes too frequently, which would cause the CA alliance to be unable to respond to normal voting requests, a CA node can only initiate one vote within a period of time. And when a CA applies to join or reports a CA violation, it can only initiate a request to one CA node within a period of time.

[0197] CA nodes that join the alliance must commit to the legitimacy of issuing certificates. When a certificate expires or becomes invalid, the certificate revocation list should be updated in a timely manner, otherwise it will be voted down as a violation.

[0198] In summary, the voting process tree, CA status tree and corresponding root Hash are recorded in the form of blockchain, so as to record the decision-making process of the alliance CA and make it public to achieve the effect of decentralized external supervision.

[0199] The various optional implementation modes introduced in the embodiments of the present invention may be implemented in combination with each other or may be implemented separately if they do not conflict with each other, and the embodiments of the present invention are not limited to this.

[0200] See also Fig.10 , Fig.10 This is one of the structural diagrams of the node interaction device provided by the embodiment of the present invention. Fig.10 As shown, the node interaction device 1000 includes a first processor 1001, which is used to:

[0201] Join a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that trust each other with the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain.

[0202] Optionally, the blockchain includes a genesis block, and the first processor 1001 is used to:

[0203] Obtain node certificates of all initially trusted CA nodes;

[0204] Determine the node trust score value of each CA node;

[0205] Generate an initial CA status tree, each leaf node of the initial CA status tree includes a node certificate and a node trust score value of a CA node;

[0206] Calculate the root hash value based on the node certificates and node trust scores of all CA nodes;

[0207] Creating a genesis block of the mutual trust alliance, and storing the root hash value and the initial CA state tree in the genesis block;

[0208] The genesis block is synchronously sent to all CA nodes.

[0209] Optionally, the first processor 1001 is further configured to:

[0210] Execute voting actions corresponding to all CA nodes in the mutual trust alliance, wherein the voting actions include any one of node addition voting, node reward voting, node penalty voting and certificate renewal voting;

[0211] A voting block is added to the blockchain, the voting block includes a voting process tree corresponding to the voting behavior and a CA status tree corresponding to the real-time CA node status, and each leaf node of the voting process tree includes a node name, node voting data and node signature of a CA node.

[0212] Optionally, the first processor 1001 is further configured to:

[0213] A tuple including a node certificate of a CA node and a node trust score value is used as a leaf node of the CA status tree, and a CA status tree in a Merkle Patricia tree format is constructed according to the leaf nodes corresponding to all CA nodes;

[0214] and / or,

[0215] The steps to generate the voting process tree include:

[0216] The triplet containing the node name, node voting data and node signature of a CA node is taken as a leaf node of the voting process tree, and the voting process tree in the Merkle Patricia tree format is constructed according to the leaf nodes corresponding to all CA nodes.

[0217] Optionally, the first processor 1001 is further configured to:

[0218] Initiating a voting request corresponding to the preset behavior request to all second CA nodes in the mutual trust alliance, wherein the voting request at least includes the preset behavior request, and the second CA node is a CA node other than the first CA node in the mutual trust alliance;

[0219] receiving voting data returned by the second CA node after verifying the legitimacy of the preset action request, wherein the voting data includes a node name of the second CA node and a voting result;

[0220] The step of adding a voting block to the blockchain includes:

[0221] Obtaining a comprehensive voting result according to the voting results of all the second CA nodes;

[0222] A voting process tree corresponding to the voting behavior is created according to the comprehensive voting result, and the voting block containing the voting process tree is synchronously sent to all CA nodes, so that all CA nodes store the voting block in the blockchain.

[0223] Optionally, the first processor 1001 is further configured to:

[0224] If the comprehensive voting result is approval, generate the voting process tree and the latest CA status tree, and send the voting block containing the voting process tree and the latest CA status tree to all CA nodes;

[0225] If the comprehensive voting result is negative, a voting process tree is generated, and a voting block including the voting process tree and the current CA status tree is sent to all CA nodes.

[0226] Optionally, the voting data further includes a node signature of the second CA node, and the first processor 1001 is further configured to:

[0227] The legitimacy of the voting data is verified according to the node signature, and after the legitimacy of the voting data is verified, a comprehensive voting result is obtained according to the voting results of all the second CA nodes.

[0228] Optionally, the first processor 1001 is further configured to:

[0229] Verify the legitimacy of the latest block received, where the latest block is a genesis block or a voting block;

[0230] After verifying the legitimacy of the latest block, the latest block is stored.

[0231] Optionally, the preset behavior request is a new node request, and the first processor 1001 is further configured to:

[0232] Receiving a request to join the alliance sent by an external CA node, wherein the request to join the alliance includes the node name, node certificate, application time, guarantee signature and private key signature of the external CA node, and the external CA node is a CA node that has not joined the mutual trust alliance;

[0233] Verifying the private key signature using the node certificate of the external CA node;

[0234] After verifying the private key signature of the external CA node, a voting request corresponding to the request to join the alliance is initiated to all second CA nodes in the mutual trust alliance, wherein the voting request includes the request to join the alliance of the external CA node and the signature of the first CA node on the request to join the alliance.

[0235] Optionally, the first processor 1001 is further configured to:

[0236] Sending a request to join the alliance to a second CA node in the mutual trust alliance, wherein the request to join the alliance includes the node name, node certificate, application time, guarantee signature and private key signature of the first CA node, so that the second CA node verifies the private key signature using the node certificate of the first CA node, and after the verification is passed, initiates a voting request corresponding to the request to join the alliance to all second CA nodes in the mutual trust alliance, wherein the voting request includes the request to join the alliance of the first CA node and the signature of the second CA node on the request to join the alliance;

[0237] If the comprehensive voting result obtained by the second CA node based on the voting request is approval, the second CA node joins the mutual trust alliance.

[0238] Optionally, the first processor 1001 is further configured to:

[0239] Receive blockchain supervision requests sent by terminal devices or external CA nodes;

[0240] Returning the real-time blockchain of the mutual trust alliance to the terminal device so that the terminal device can determine the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and the voting process tree are both legal;

[0241] If an alarm message is received from the terminal device based on the legitimacy verification of the blockchain, a voting request for the corresponding penalty request is initiated to all CA nodes in the mutual trust alliance.

[0242] Optionally, the first processor 1001 is further configured to:

[0243] If the node trust score value of the first CA node is greater than or equal to the trust threshold, the voting behavior of all CA nodes in the mutual trust alliance is allowed to be executed;

[0244] If the node trust score value of the first CA node is less than the trust threshold, the voting behavior of all CA nodes in the mutual trust alliance is prohibited.

[0245] Optionally, the first processor 1001 is further configured to:

[0246] receiving a voting request corresponding to a preset behavior request initiated by a second CA node in the mutual trust alliance, wherein the voting request at least includes the preset behavior request;

[0247] Verifying the legitimacy of the preset action request;

[0248] After verifying the legitimacy of the preset action request, returning voting data to the second CA node, so that the second CA node generates a voting process tree based on the voting data, wherein the voting data includes a node name and voting results of the first CA node, and each leaf node of the voting process tree includes a node name, node voting data, and node signature of a CA node;

[0249] Receive the voting block containing the voting process tree sent by the second CA node, and store it in the blockchain corresponding to the mutual trust alliance.

[0250] The certificate verification device 1000 can implement the embodiment of the present invention Figure 2 The various processes of the method embodiment and the same beneficial effects are achieved, and will not be described again here to avoid repetition.

[0251] See also Fig.11 , Fig.11 FIG. 1 is one of the structural diagrams of the certificate verification device provided by the embodiment of the present invention. Fig.11 As shown, the certificate verification device 1100 includes a first transceiver 1101, which is used to:

[0252] Applying for a terminal certificate from a trusted first CA node, wherein the first CA node is located in a mutual trust alliance;

[0253] Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate;

[0254] The terminal certificate, the node certificate of the first CA node and the path hash node are sent to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

[0255] The certificate verification device 1100 can implement the embodiment of the present invention Figure 7The various processes of the method embodiment and the same beneficial effects are achieved, and will not be described again here to avoid repetition.

[0256] See also Fig.12 , Fig.12 This is the second structural diagram of the certificate verification device provided by the embodiment of the present invention. Fig.12 As shown, the certificate verification device 1200 includes:

[0257] The second transceiver 1201 is used to request a second CA node in the mutual trust alliance to obtain a real-time root hash value, receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal;

[0258] The second processor 1202 is used to verify the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node, the path hash node and the root hash value.

[0259] Optionally, the second processor 1202 is specifically configured to:

[0260] Verifying the legitimacy of the first CA node certificate according to the root hash value and the path hash node;

[0261] After verifying the legitimacy of the node certificate of the first CA node, the legitimacy of the terminal certificate of the first terminal is verified using the node certificate of the first CA node.

[0262] The certificate verification device 1200 can implement the embodiment of the present invention Figure 8 The various processes of the method embodiment and the same beneficial effects are achieved, and will not be described again here to avoid repetition.

[0263] See also Fig.13 , Fig.13 This is the second structural diagram of the node interaction device provided by the embodiment of the present invention. Fig.13 As shown, the certificate verification device 1300 includes:

[0264] The third transceiver 1301 is used to send a blockchain supervision request to a first CA node in the mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance;

[0265] The third processor 1302 is used to obtain the real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA state tree, the hash pointers between blocks match, and the CA state tree and the voting process tree are both legal;

[0266] The third transceiver 1301 is also used to send an alarm message to any CA node in the mutual trust alliance if the legitimacy of the blockchain is not verified.

[0267] The certificate verification device 1300 can implement the embodiment of the present invention Fig. 9 The various processes of the method embodiment and the same beneficial effects are achieved, and will not be described again here to avoid repetition.

[0268] The embodiment of the present invention also provides a communication device. Fig.14 , the communication device may include a processor 1401, a memory 1402, and a program 14021 stored in the memory 1402 and executable on the processor 1401.

[0269] When the communication device is the first CA node, the program 14021 can be executed by the processor 1401 to achieve Figure 2 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0270] When the communication device is a first terminal, the program 14021 can be executed by the processor 1401 to achieve Figure 7 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0271] When the communication device is a second terminal, the program 14021 can be executed by the processor 1401 to achieve Figure 8 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0272] When the communication device is a terminal device, the program 14021 can be executed by the processor 1401 to achieve Fig. 9 Any steps in the corresponding method embodiments and achieving the same beneficial effects will not be repeated here.

[0273] A person skilled in the art can understand that all or part of the steps of implementing the above-mentioned embodiment method can be completed by hardware related to program instructions, and the program can be stored in a readable medium. The embodiment of the present invention also provides a readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the above-mentioned Figure 2 , Figure 7 , Figure 8 or Fig. 9 Any steps in the corresponding method embodiments can achieve the same technical effect and will not be repeated here to avoid repetition.

[0274] The storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0275] The above is a preferred implementation of the embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.

Claims

1. A node interaction method, characterized in that: Executed by a first CA node, the method includes: Joining a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; The initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and node trust score value of the initially trusted CA node.

2. The method according to claim 1, characterized in that The blockchain includes a genesis block, and the steps of joining the mutual trust alliance include: Obtain node certificates of all initially trusted CA nodes; Determine the node trust score value of each CA node; Generate an initial CA status tree, each leaf node of the initial CA status tree includes a node certificate and a node trust score value of a CA node; Calculate the root hash value based on the node certificates and node trust scores of all CA nodes; Creating a genesis block of the mutual trust alliance, and storing the root hash value and the initial CA state tree in the genesis block; The genesis block is synchronously sent to all CA nodes.

3. The method according to claim 2, characterized in that The blockchain includes a voting block located after the genesis block; and the method further includes: Execute voting actions corresponding to all CA nodes in the mutual trust alliance, wherein the voting actions include any one of node addition voting, node reward voting, node penalty voting and certificate renewal voting; A voting block is added to the blockchain, the voting block includes a voting process tree corresponding to the voting behavior and a CA status tree corresponding to the real-time CA node status, and each leaf node of the voting process tree includes a node name, node voting data and node signature of a CA node.

4. The method according to claim 3, characterized in that The steps to generate the CA status tree include: A tuple including a node certificate of a CA node and a node trust score value is used as a leaf node of the CA status tree, and a CA status tree in a Merkle Patricia tree format is constructed according to the leaf nodes corresponding to all CA nodes; and / or, The steps to generate the voting process tree include: The triplet containing the node name, node voting data and node signature of a CA node is taken as a leaf node of the voting process tree, and the voting process tree in the Merkle Patricia tree format is constructed according to the leaf nodes corresponding to all CA nodes.

5. The method according to claim 3, characterized in that: The step of executing voting behavior corresponding to all CA nodes in the mutual trust alliance includes: Initiating a voting request corresponding to the preset behavior request to all second CA nodes in the mutual trust alliance, wherein the voting request at least includes the preset behavior request, and the second CA node is a CA node other than the first CA node in the mutual trust alliance; receiving voting data returned by the second CA node after verifying the legitimacy of the preset action request, wherein the voting data includes a node name of the second CA node and a voting result; The step of adding a voting block to the blockchain includes: Obtaining a comprehensive voting result according to the voting results of all the second CA nodes; A voting process tree corresponding to the voting behavior is created according to the comprehensive voting result, and the voting block containing the voting process tree is synchronously sent to all CA nodes, so that all CA nodes store the voting block in the blockchain.

6. The method according to claim 5, characterized in that The step of creating a voting process tree corresponding to the voting behavior according to the comprehensive voting result, and synchronously sending the voting block containing the voting process tree to all CA nodes includes: If the comprehensive voting result is approval, generate the voting process tree and the latest CA status tree, and send the voting block containing the voting process tree and the latest CA status tree to all CA nodes; If the comprehensive voting result is negative, a voting process tree is generated, and a voting block including the voting process tree and the current CA status tree is sent to all CA nodes.

7. The method according to claim 5, characterized in that The voting data also includes a node signature of a second CA node, and the step of obtaining a comprehensive voting result according to the voting results of all the second CA nodes includes: The legitimacy of the voting data is verified according to the node signature, and after the legitimacy of the voting data is verified, a comprehensive voting result is obtained according to the voting results of all the second CA nodes.

8. The method according to claim 5, characterized in that The method further comprises: Verify the legitimacy of the latest block received, where the latest block is a genesis block or a voting block; After verifying the legitimacy of the latest block, the latest block is stored.

9. The method according to claim 5, characterized in that The preset behavior request is a request for adding a new node. Before the step of initiating a voting request corresponding to the preset behavior request to all the second CA nodes in the mutual trust alliance, the method further includes: Receiving a request to join the alliance sent by an external CA node, wherein the request to join the alliance includes the node name, node certificate, application time, guarantee signature and private key signature of the external CA node, and the external CA node is a CA node that has not joined the mutual trust alliance; Verifying the private key signature using the node certificate of the external CA node; The step of initiating a voting request corresponding to a preset behavior request to all the second CA nodes in the mutual trust alliance includes: After verifying the private key signature of the external CA node, a voting request corresponding to the request to join the alliance is initiated to all second CA nodes in the mutual trust alliance, wherein the voting request includes the request to join the alliance of the external CA node and the signature of the first CA node on the request to join the alliance.

10. The method according to claim 5, characterized in that The steps of joining the mutual trust alliance include: Sending a request to join the alliance to a second CA node in the mutual trust alliance, wherein the request to join the alliance includes the node name, node certificate, application time, guarantee signature and private key signature of the first CA node, so that the second CA node verifies the private key signature using the node certificate of the first CA node, and after the verification is passed, initiates a voting request corresponding to the request to join the alliance to all second CA nodes in the mutual trust alliance, wherein the voting request includes the request to join the alliance of the first CA node and the signature of the second CA node on the request to join the alliance; If the comprehensive voting result obtained by the second CA node based on the voting request is approval, the second CA node joins the mutual trust alliance.

11. The method according to claim 1, characterized in that: The method further comprises: Receive blockchain supervision requests sent by terminal devices or external CA nodes; Returning the real-time blockchain of the mutual trust alliance to the terminal device so that the terminal device can determine the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and the voting process tree are both legal; If an alarm message is received from the terminal device based on the legitimacy verification of the blockchain, a voting request for the corresponding penalty request is initiated to all CA nodes in the mutual trust alliance.

12. The method according to claim 3, characterized in that The method further comprises: If the node trust score value of the first CA node is greater than or equal to the trust threshold, the voting behavior of all CA nodes in the mutual trust alliance is allowed to be executed; If the node trust score value of the first CA node is less than the trust threshold, the voting behavior of all CA nodes in the mutual trust alliance is prohibited.

13. The method according to claim 1, characterized in that The method further comprises: receiving a voting request corresponding to a preset behavior request initiated by a second CA node in the mutual trust alliance, wherein the voting request at least includes the preset behavior request; Verifying the legitimacy of the preset action request; After verifying the legitimacy of the preset action request, returning voting data to the second CA node, so that the second CA node generates a voting process tree based on the voting data, wherein the voting data includes a node name and voting results of the first CA node, and each leaf node of the voting process tree includes a node name, node voting data, and node signature of a CA node; Receive the voting block containing the voting process tree sent by the second CA node, and store it in the blockchain corresponding to the mutual trust alliance.

14. The method according to claim 1, characterized in that The method further comprises: Receiving a terminal certificate application initiated by a first terminal; Return the terminal certificate, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate to the first terminal, so that the first terminal sends the terminal certificate, the node certificate of the first CA node, and the path hash node to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node, and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

15. A certificate verification method, characterized in that: The method is performed by a first terminal and includes: Applying for a terminal certificate from a trusted first CA node, wherein the first CA node is any node in a mutual trust alliance; the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate; The terminal certificate, the node certificate of the first CA node and the path hash node are sent to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

16. A certificate verification method, characterized in that: The method is performed by the second terminal, and includes: Request the second CA node in the mutual trust alliance to obtain the real-time root hash value; Receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal; wherein the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; The legitimacy of the terminal certificate of the first terminal is verified according to the root hash value, the node certificate of the first CA node and the path hash node.

17. The method according to claim 16, characterized in that The step of verifying the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node and the path hash node includes: Verifying the legitimacy of the first CA node certificate according to the root hash value and the path hash node; After verifying the legitimacy of the node certificate of the first CA node, the legitimacy of the terminal certificate of the first terminal is verified using the node certificate of the first CA node.

18. A node interaction method, characterized in that: Executed by a terminal device, the method includes: Sending a blockchain supervision request to a first CA node in a mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance, the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; Obtain the real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain means that the root hash value stored in the blockchain is the same as the root hash value calculated through all leaf nodes in the CA status tree, the hash pointers between blocks match, and the CA status tree and voting process tree are both legal; If the legitimacy of the blockchain fails to be verified, an alarm message is sent to any CA node in the mutual trust alliance.

19. A node interaction device, characterized in that: The invention comprises a first processor configured to: Joining a mutual trust alliance, wherein the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; The initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and node trust score value of the initially trusted CA node.

20. A certificate verification device, characterized in that: The invention comprises a first transceiver configured to: Applying for a terminal certificate from a trusted first CA node, wherein the first CA node is located in a mutual trust alliance, the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; Receive the terminal certificate returned by the first CA node, the node certificate of the first CA node, and the path hash node required to verify the terminal certificate; The terminal certificate, the node certificate of the first CA node and the path hash node are sent to the second terminal, so that the second terminal verifies the legitimacy of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node and the root hash value of the mutual trust alliance returned by the second CA node, wherein the second CA node is a CA node located in the mutual trust alliance and trusted by the second terminal, and the second terminal trusts the second CA node.

21. A certificate verification device, characterized in that: include: A second transceiver is used to request a second CA node in a mutual trust alliance to obtain a real-time root hash value, and receive a terminal certificate sent by a first terminal, a node certificate of a first CA node trusted by the first terminal, and a path hash node required to verify the terminal certificate of the first terminal; wherein the mutual trust alliance includes a plurality of CA nodes mutually trusted by the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; The second processor is used to verify the legitimacy of the terminal certificate of the first terminal according to the root hash value, the node certificate of the first CA node, the path hash node and the root hash value.

22. A node interaction device, characterized in that: include: A third transceiver is used to send a blockchain supervision request to a first CA node in a mutual trust alliance, wherein the first CA node is any CA node in the mutual trust alliance, the mutual trust alliance includes multiple CA nodes that mutually trust the first CA node, the blockchain of the mutual trust alliance includes a real-time CA status tree and root hash values ​​corresponding to all leaf nodes of the CA status tree, each leaf node of the CA status tree includes a node certificate and a node trust score value of a CA node, and each CA node in the mutual trust alliance stores the blockchain; the initial root hash value corresponding to the leaf node of the CA status tree is calculated based on the node certificate and the node trust score value of the initially trusted CA node; a third processor, configured to obtain a real-time blockchain of the mutual trust alliance and verify the legitimacy of the blockchain, wherein the legitimacy of the blockchain refers to that the root hash value stored in the blockchain is the same as the root hash value calculated by all leaf nodes in the CA state tree, the hash pointers between blocks match, and the CA state tree and the voting process tree are both legal; The third transceiver is also used to send an alarm message to any CA node in the mutual trust alliance if the legitimacy of the blockchain is not verified.

23. A communication device comprising: A transceiver, a memory, a processor, and a program stored in the memory and executable on the processor; characterized in that the processor is used to read the program in the memory to implement the steps of the node interaction method as described in any one of claims 1 to 14, or the steps of the certificate verification method as described in claim 15, or the steps of the certificate verification method as described in claim 16 or 17, or the steps of the node interaction method as described in claim 18.

24. A readable storage medium for storing a program, characterized in that: When the program is executed by the processor, it implements the steps of the node interaction method as described in any one of claims 1 to 14, or the steps of the certificate verification method as described in claim 15, or the steps of the certificate verification method as described in claim 16 or 17, or the steps of the node interaction method as described in claim 18.

Images