CN114726567A - Node interaction method, certificate verification method, device and related equipment - Google Patents

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

Info

Publication number
CN114726567A
CN114726567A CN202110005432.1A CN202110005432A CN114726567A CN 114726567 A CN114726567 A CN 114726567A CN 202110005432 A CN202110005432 A CN 202110005432A CN 114726567 A CN114726567 A CN 114726567A
Authority
CN
China
Prior art keywords
node
voting
certificate
alliance
terminal
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202110005432.1A
Other languages
Chinese (zh)
Inventor
陈佳
黄静
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Communications Ltd Research Institute
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Communications Ltd Research Institute
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Communications Ltd Research Institute filed Critical China Mobile Communications Group Co Ltd
Priority to CN202110005432.1A priority Critical patent/CN114726567A/en
Publication of CN114726567A publication Critical patent/CN114726567A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

The invention provides a node interaction method, a certificate verification device and related equipment. The node interaction method comprises the following steps: the first CA node joins in a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node stores the block chain. Therefore, aiming at the CA node trusted by the terminal, the CA node is added into the certificates issued by other CA nodes in the same mutual trust alliance for other terminals, the terminal can verify the CA node certificate in the mutual trust alliance in a hash tree mode and then verify the legality of the terminal certificates of other terminals through the CA node certificate, so that all the certificates issued by the CA nodes in the mutual trust alliance are also trusted, and the mutual trust problem between any CA nodes is solved at lower cost.

Description

Node interaction method, certificate verification method, device and related equipment
Technical Field
The embodiment of the invention relates to the technical field of communication, in particular to a node interaction method, a certificate verification method, a device and related equipment.
Background
Certificates provide proof of identity for an entity, and a certificate trust model is required to verify the validity of an entity certificate. In a traditional root Certificate Authority (CA) trust model, a root CA issues a medium-level CA1 and a CA2 Certificate, and a CA1 and a CA2 issue certificates 1 to 4, respectively. The device stores the root CA certificate as a trust anchor, and can verify the legitimacy of certificates 1 to 4 by means of a certificate chain.
In order to make up for the defects of the traditional tree-shaped certificate chain, three trust models, namely a cross certification trust model, a bridge CA trust model and a list trust model, are created. Where the cross certification trust model and the bridge CA trust model are costly and not flexible enough. While the list trust model requires multiple trust anchors to be stored 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 to maintain multiple trust anchors is high. The above four traditional trust models fail to solve the certificate trust verification problem.
Therefore, the existing traditional trust model cannot solve the problem of certificate trust verification.
Disclosure of Invention
The embodiment of the invention provides a node interaction method, a certificate verification device and related equipment, and aims to solve the problem that the existing trust model cannot solve certificate trust verification.
In order to solve the problems, the invention is realized as follows:
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:
and joining a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutually trusted alliance stores the block chain.
In a second aspect, an embodiment of the present invention provides a certificate verification method, which is performed by a first terminal, and includes:
applying for a terminal certificate to a trusted first CA node, wherein the first CA node is any node in a mutual trust alliance;
receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node and a path hash node required for verifying the terminal certificate;
and sending the terminal certificate, the node certificate of the first CA node and the path hash node to a second terminal so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node and the root hash value of the mutual trust alliance returned by the path hash node and the second CA node, wherein the second CA node is a CA node which is trusted by the second terminal and is located in the mutual trust alliance, and the second terminal trusts the second CA node.
In a third aspect, an embodiment of the present invention provides a certificate verification method, which is executed by a second terminal, and includes:
requesting a second CA node in the mutual trust alliance to acquire a real-time root hash value;
receiving 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 for verifying the terminal certificate of the first terminal;
and verifying the validity 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.
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:
sending a block chain 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;
acquiring a real-time block chain of the mutual trust alliance, and verifying the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and a voting process tree are both legal;
and if the validity of the block chain is not verified, sending alarm information to any CA node in the mutual trust alliance.
In a fifth aspect, an embodiment of the present invention further provides a node interaction apparatus, including a first processor, configured to:
and joining a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutually trusted alliance stores the block chain.
In a sixth aspect, an embodiment of the present invention further provides a certificate verification apparatus, including a first transceiver, configured to:
applying for a terminal certificate to a trusted first CA node, wherein the first CA node is located in a mutual trust alliance;
receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node and a path hash node required for verifying the terminal certificate;
and sending the terminal certificate, the node certificate of the first CA node and the path hash node to a second terminal so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node and the root hash value of the mutual trust alliance returned by the path hash node and the second CA node, wherein the second CA node is a CA node which is trusted by the second terminal and is located in the mutual trust alliance, and the second terminal trusts the second CA node.
In a seventh aspect, an embodiment of the present invention provides a certificate verification apparatus, including:
the second transceiver is used for requesting a second CA node in a mutual trust alliance to acquire a real-time root hash value, receiving 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 for verifying the terminal certificate of the first terminal;
and the second processor is used for verifying the validity 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.
In an eighth aspect, an embodiment of the present invention provides a node interaction apparatus, including:
a third transceiver, configured to send a block chain supervision request to a first CA node in a mutual trust alliance, where the first CA node is any CA node in the mutual trust alliance;
the third processor is configured to acquire a real-time blockchain of the mutual trust alliance, and verify the validity of the blockchain, where the validity of the blockchain indicates that a root hash value stored in the blockchain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and both the CA state tree and the voting process tree are valid;
and the third transceiver is also used for sending alarm information to any CA node in the mutual trust alliance if the validity of the block chain is not verified.
In a ninth aspect, an embodiment of the present invention further provides a communication device, including: a transceiver, a memory, a processor, and a program stored on the memory and executable on the processor; wherein the processor is configured to read a program in the memory to implement the steps of the method according to the first aspect; or, a step in a method as described in the second aspect above; or, a step in the method according to the aforementioned third aspect; or, a step in a method according to the fourth aspect.
In a tenth aspect, embodiments of the present invention further provide a readable storage medium, for storing a program, where the program, when executed by a processor, implements the steps in the method according to the foregoing first aspect, or implements the steps in the method according to the foregoing second aspect; or, a step in the method according to the aforementioned third aspect; or, a step in a method according to the fourth aspect.
In the embodiment of the invention, mutually trusted CA nodes are added into the same mutual trust alliance, a block chain of the mutual trust alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutual trust alliance stores the block chain. Therefore, aiming at the CA node trusted by the terminal, the CA node is added into the certificates issued by other CA nodes in the same mutual trust alliance for other terminals, the terminal can verify the CA node certificate in the mutual trust alliance in a hash tree mode and then verify the legality of the terminal certificates of other terminals through the CA node certificate, so that all the certificates issued by the CA nodes in the mutual trust alliance are also trusted, and the mutual trust problem between any CA nodes is solved at lower cost.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments of the present invention will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other drawings can be obtained according to these drawings without inventive exercise.
Fig. 1 is a schematic structural diagram of a network system to which an embodiment of the present invention is applicable;
fig. 2 is a schematic flowchart of a node interaction method according to an embodiment of the present invention;
fig. 3 is a schematic diagram of a creating block involved in the node interaction method according to the embodiment of the present invention;
fig. 4 is a schematic diagram of a CA state tree involved in the node interaction method provided in the embodiment of the present invention;
fig. 5 is a schematic diagram of a block chain involved in a node interaction method according to an embodiment of the present invention;
fig. 6 is a schematic diagram of voting blocks involved in the node interaction method according to the embodiment of the present invention;
fig. 7 is a flowchart illustrating a certificate verification method according to an embodiment of the present invention;
fig. 8 is a second flowchart illustrating a certificate verification method according to an embodiment of the present invention;
fig. 9 is a second flowchart illustrating a node interaction method according to an embodiment of the present invention;
FIG. 10 is a schematic structural diagram of a node interaction apparatus provided in the present invention;
FIG. 11 is a schematic diagram of a certificate verification apparatus according to an embodiment of the present invention;
FIG. 12 is a second schematic structural diagram of a certificate verification apparatus provided in the present invention;
FIG. 13 is a second schematic structural diagram of a node interaction device according to the present invention;
fig. 14 is a schematic structural diagram of a communication device provided in the implementation of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
The terms "first," "second," and the like in the embodiments of the present invention are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. Moreover, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Further, as used herein, "and/or" means at least one of the connected objects, e.g., a and/or B and/or C, means 7 cases including a alone, B alone, C alone, and both a and B present, B and C present, both a and C present, and A, B and C present.
Referring to fig. 1, fig. 1 is a block diagram of a network system to which an embodiment of the present invention is applicable, and as shown in fig. 1, includes at least two CA nodes 11 and terminal devices 12 in a mutual trust federation. Wherein communication is possible between the CA node 11 and the terminal device 12.
In practical applications, the CA node 11 may be any CA node in the mutual trust alliance, such as the first CA node or the second CA node described below; the terminal device 12 may be, but is not limited to, a terminal device, a first terminal, or a second terminal that performs the method described below.
The following describes a node interaction method and a certificate verification method provided by an embodiment of the present invention.
Referring to fig. 2, fig. 2 is a flowchart illustrating a node interaction method according to an embodiment of the present invention. The node interaction method provided by this embodiment is executed by any CA node in a mutually trusted alliance, which includes a plurality of mutually trusted CA nodes, and CA node validity verification and other interaction behaviors are performed between CA nodes. For convenience of description, all CA nodes in the mutual trust alliance are distinguished into a first CA node and a second CA node, the first CA node may represent a CA node that initiates a behavior actively, and the second CA node may represent a CA node that interacts a behavior passively, of course, the same CA node may be the first CA node or the second CA node in different situations, and the first and second nodes are only used for functional distinction. The node interaction method shown in fig. 2 is a node interaction method performed by the first CA node, and may be performed by the second CA node.
As shown in fig. 2, the node interaction method may include the following steps:
step 201, joining a mutual trust alliance, wherein the mutual trust alliance comprises a plurality of CA nodes mutually trusting with the first CA node, a block chain of the mutual trust alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutual trust alliance stores the block chain.
In this embodiment, the first CA node is defined to join a mutual trust federation, which is a federation including mutually trusted CA nodes. The first CA node may join the mutual trust alliance in a variety of ways, for example, as an initial node to participate in creating the mutual trust alliance, or as a subsequent node to join an established mutual trust alliance.
As shown in fig. 3, the interconnection union corresponds to a block chain, and the block chain includes a real-time CA state Tree and a root hash value, where the CA state Tree is a Tree structure for representing the relevant state of each CA node, and here, it is preferable to construct a hash Tree in the form of Merkle Patricia Tree (Merkle Patricia Tree), and calculate the root hash value according to each leaf node of the CA state Tree. In storing, the root hash value may be stored at the chunk header and the CA state tree may be stored at the chunk body.
The CA state tree comprises a plurality of leaf nodes, each leaf node is used for storing a node certificate of a corresponding CA node and a node trust score value, and the node trust score value is a value used for expressing the trust degree of the CA node in the mutual trust alliance.
Each CA node in the mutual trust alliance stores the blockchain, and therefore any CA node can search for contents such as node certificates, node trust score values and the like of other CA nodes in the mutual trust alliance from the blockchain. Because the CA nodes trust each other, the certificates issued by the CA nodes can also be trusted by nodes, namely, the terminal trusting the first CA node can verify the legality of the terminal certificate issued by any other CA node to the terminal through the root hash value of the block chain.
In the node interaction method of the embodiment of the invention, CA nodes which trust each other are added into the same mutual trust alliance, a block chain of the mutual trust alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutual trust alliance stores the block chain. Therefore, aiming at the CA node trusted by the terminal, the CA node is added into the certificates issued by other CA nodes in the same mutual trust alliance for other terminals, the terminal can verify the CA node certificate in the mutual trust alliance in a hash tree mode and then verify the legality of the terminal certificates of other terminals through the CA node certificate, so that all the certificates issued by the CA nodes in the mutual trust alliance are also trusted, and the mutual trust problem between any CA nodes is solved at lower cost.
On the basis of the foregoing embodiment, according to a specific implementation manner of the present disclosure, the block chain includes a created block, and the step of joining a mutual trust union includes:
acquiring node certificates of all CA nodes which are initially trusted;
determining a node trust score value of each CA node;
generating an initial CA state tree, wherein each leaf node of the initial CA state tree comprises a node certificate and a node trust score value of a CA node;
calculating a root hash value according to the node certificates and the node trust score values of all CA nodes;
creating an founding block of the mutual trust alliance, and storing the root hash value and an initial CA state tree into the founding block;
the founder block is synchronously sent to all CA nodes.
In this embodiment, a scheme for creating a mutual trust alliance for an initial node by a first CA node is specifically defined. When creating a mutual trust federation, first a first block of a chain of blocks is created, i.e., a founder block, which includes an initial CA state tree, i.e., a state tree containing CA nodes that are initially mutually trusted to participate in the creation.
In specific implementation, the step of generating the CA status tree may include:
and constructing the CA state tree in the Merkelpatrie format according to leaf nodes corresponding to all CA nodes by taking the binary group comprising the node certificate of one CA node and the node trust score value as a leaf node of the CA state tree.
Specifically, the mutually trusted CA1, CA2 … CAn establish a federation chain. Each node takes the certificate of CA1-CAn and the initial Trust score binary [ CA Cert, Trust Level ] as leaf nodes, establishes a CA state Tree in a lexicographic order variant format (MPT for short), and calculates a Root Hash value. And each node writes the Root Hash into a Block Header of the founding Block, writes a CA state tree and a leaf node CA1-CAn certificate into a Block Body, and discloses the Root Hash.
The created block, in addition to the default contents of the blockchain, includes at least the following contents:
block Header: root Hash of CA state tree;
block Body: CA State Tree, i.e. each leaf node [ CA ]1 Cert，Trust Level1]，[CA2Cert，Trust Level2]…[CAn Cert，Trust Leveln]. The initial value of the Trust Level can be set according to specific requirements, the default value is a value {1, 2 … 5}, the Trust Level of the initial participant of the CA union can be set to be the highest value 5, and the number of nodes added subsequently is 3. When the CA node runs in compliance for a long time or carries out illegal operation, the Trust level of the CA node can be improved and reduced through voting in the alliance.
The device may set a Trust threshold k, and no Trust is granted when the Trust level of the CA node is < k. When the Trust Level of the CA node is 0, the CA node is ejected out of the alliance, cannot participate in and initiate other active operations in the mutual Trust alliance, and cannot be trusted by equipment.
Fig. 3 is a schematic diagram of the structure of the created block. The initial node is CA1、CA2、CA3And CA4The initial CA state tree may be created by any of the four initial nodes and then synchronized to all CA nodes and stored. The CA status tree includes 4 leavesEach leaf node is used for storing a node certificate CA Cert of the corresponding CA node and a node Trust grade value Trust Level. The initial Root Hash value Root Hash is obtained as follows:
h1 ═ Hash (leaf 1), H2 ═ Hash (leaf 2), H3 ═ Hash (leaf 3), H4 ═ Hash (leaf 4);
H5＝Hash(H1|H2)，H6＝Hash(H3|H4)；
Root Hash＝Hash(H5|H6)。
correspondingly, as shown in fig. 4, after the Root Hash is disclosed, when the entity owns the trusted Root Hash, the correctness of the leaf 1 data needs to be verified, and the following operation formula can be calculated:
hash (Hash (Hash (leaf 1) | H2) | H6)
And judging whether the result of the operation expression is equal to Root Hash or not to verify the correctness of the leaf 1.
The left side is the verification operation path from leaf 1 to Root Hash, and H2 and H6 are Hash path nodes required for verification. And verifying that the operation complexity of the leaf nodes is the depth of the Merkle Tree, namely Log (n), and n is the number of the leaf nodes.
The A entity can obtain path Hash values of H2, H6 and the like from any node to match with leaf 1, and verify whether two sides of the equation are true. If the equation is true, leaf 1 is in the Merkle Tree and has not been tampered with.
If any of the data in H2, H6, and leaf 1 is incorrect, the equation will be not be satisfied, and the tampered leaf 1 will not be identified as a trusted node. The method can use the lexicographic order variation of the Merkle Tree, is consistent with the verification mode of the classic Merkle Tree, can ensure that the trees generated by the same leaf node set are necessarily the same, and avoids the difference of Root Hash of independent operation of each node in a block chain.
According to another embodiment of the present disclosure, as shown in fig. 5, the block chain includes a voting block located after the founding block; the method further comprises the following steps:
executing voting behaviors corresponding to all CA nodes in the mutual trust alliance, wherein the voting behaviors comprise any one of node new-adding voting, node rewarding voting, node penalty voting and certificate updating voting;
and adding a voting block for the block chain, wherein the voting block comprises a voting process tree corresponding to the voting behavior and a CA state tree corresponding to the real-time CA node state, and each leaf node of the voting process tree comprises a node name, node voting data and a node signature of a CA node.
In this embodiment, after the creation of the creation block is limited, specific behaviors such as addition, reward, penalty, and certificate update for CA nodes may be initiated in the mutual trust alliance, where the specific behaviors need to be supported and synchronized by all CA nodes in the mutual trust alliance, and are mainly performed in voting behaviors, and the corresponding voting behaviors may 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 be used as a host node to initiate voting behaviors to other CA nodes. Of course, the first CA node may also accept voting behaviors initiated by other CA nodes, so that effective decentralized management may be achieved.
In specific implementation, the generating step of the voting process tree may include:
and constructing the voting process tree in the Meckels Patriella tree format according to the leaf nodes corresponding to all the CA nodes by taking a triple comprising the node name of one CA node, the node voting data and the node signature as a leaf node of the voting process tree.
Specifically, after a voting behavior initiated by a first CA node to another CA node, a voting process tree and a real-time CA state tree corresponding to the voting behavior are generated according to the node name, the node voting data, and the node signature fed back by each CA node, as shown in fig. 6, each leaf node of the voting process tree stores the node name, the node voting data, and the node signature of one CA node. The first CA node then creates a voting block corresponding to the voting activity, connects the voting block into a block chain, and synchronizes to each CA node. Therefore, all CA nodes in the mutual trust alliance can check the voting data of all CA nodes in the voting behavior, and inquire the node certificate and the node trust score value of all current CA nodes through the latest CA state tree. Each voting block represents a voting behavior, including a CA state tree and a voting process tree. Each vote, whether or not the issue passes, will add a voting block after the latest block.
Further, the step of executing voting behaviors corresponding to all CA nodes in the mutual trust alliance includes:
initiating voting requests corresponding to preset behavior requests to all second CA nodes in the mutual trust alliance, wherein the voting requests at least comprise the preset behavior requests, and the second CA nodes are CA nodes except the first CA node in the mutual trust alliance;
receiving voting data returned by the second CA node after verifying the validity of the preset behavior request, wherein the voting data comprises the node name and the voting result of the second CA node;
the step of adding a voting block to the block chain includes:
obtaining a comprehensive voting result according to the voting results of all the second CA nodes;
and creating a voting process tree corresponding to the voting behaviors according to the comprehensive voting result, and synchronously sending voting blocks containing the voting process tree to all CA nodes so that all CA nodes store the voting blocks into the block chain.
In the embodiment, the voting process is specifically limited, and the first CA node initiates a voting behavior to all the second CA nodes to request to acquire voting data of other second CA nodes to the preset behavior request. After receiving the voting request of the first CA node, the second CA node verifies the validity of the preset action request, and after verifying the validity of the preset action request, the second CA node can provide voting data. In particular, the second CA node may generate corresponding voting data by presetting relevant parameters of the action request or factors such as certificate validity, and the voting data generally includes any one of agreement and objection.
And after receiving the voting data returned by the second CA nodes, the first CA node calculates by using the voting results of all the second CA nodes to obtain a comprehensive voting result, and synchronizes to all the CA nodes in the mutual trust alliance in the form of voting blocks by using the comprehensive voting result.
On the basis of the above embodiments, the method further includes:
carrying out validity verification on the received latest block, wherein the latest block is a creation block or a voting block;
and after the validity of the latest block is verified, storing the latest block.
In this embodiment, the first CA node is defined to be able to receive the block transmitted from another CA node, and is defined as the latest block. If the creation is initial, the newest block may be the created block. If the current block is the voting block, the latest block is the voting block. After receiving the latest block, the first CA node firstly verifies the validity of the latest block and verifies whether the source node of the latest block is valid. The received latest block is stored after the validity of the latest block is verified.
Further, the step of creating a voting process tree corresponding to the voting behavior according to the comprehensive voting result, and synchronously sending the voting blocks containing the voting process tree to all CA nodes includes:
if the comprehensive voting result is agreement, generating the voting process tree and the latest CA state tree, and sending a voting block comprising the voting process tree and the latest CA state tree to all CA nodes;
and if the comprehensive voting result is against, generating a voting process tree, and sending a voting block containing the voting process tree and the current CA state tree to all CA nodes.
Considering the actual voting behavior, when the overall voting result is agreement, the CA node composition, the node trust score value of the CA node, the node certificate, etc. in the mutual trust alliance are usually changed, and at this time, the latest CA status tree needs to be generated. The comprehensive voting result is against, so that the change of the data in the mutual trust alliance is not involved, the latest CA state tree does not need to be generated, and the current real-time CA state tree is directly used as the latest CA state tree. The voting process tree is used for recording, backing up and tracking each voting behavior, so that each voting behavior generates a voting block for updating the voting process and the latest CA state tree.
In addition, the voting data further 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:
and verifying the legality of the voting data according to the node signature, and obtaining a comprehensive voting result according to the voting results of all the second CA nodes after the legality of the voting data is verified.
The embodiment limits the validity verification of the voting process terminal, and in specific implementation, after receiving data each time, the node certificate of a data source side and the data can be subjected to validity verification so as to avoid being tampered.
Of course, the first CA node may also receive voting behaviors initiated by other CA nodes, in this case, the method may further include:
receiving a voting request which is initiated by a second CA node in the mutual trust alliance and corresponds to a preset behavior request, wherein the voting request at least comprises the preset behavior request;
verifying the validity of the preset behavior request;
after verifying the validity 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, wherein the voting data comprises the node name and the voting result of the first CA node, and each leaf node of the voting process tree comprises the node name, the node voting data and the node signature of one CA node;
and receiving the voting block which is sent by the second CA node and contains the voting process tree, and storing the voting block into a block chain corresponding to the mutual trust alliance.
In this embodiment, the first CA node receives a screen-casting request initiated by a second CA node in the mutual trust alliance, and returns corresponding voting data after passing the validity verification. For a specific process, reference may be made to the specific implementation process of initiating the voting process, which is not described in detail.
The method further comprises the following steps:
if the node trust score value of the first CA node is greater than or equal to the trust threshold value, allowing the voting behaviors corresponding to all CA nodes in the mutual trust alliance to be executed;
and if the node trust score value of the first CA node is smaller than the trust threshold value, prohibiting the voting behaviors corresponding to all CA nodes in the mutual trust alliance.
In this embodiment, the authority is restricted according to the node trust score 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, the voting behavior may be initiated or the voting behavior may be received, otherwise, the voting behavior may not be initiated or the voting behavior may not be received. For example, the device may set a Trust threshold k, and no Trust is granted when the Trust level of the CA node is < k. When the Trust Level of the CA node is 0, the CA node is evicted from the alliance, cannot participate in and initiate other active operations in the mutual Trust alliance, and cannot be trusted by equipment.
The voting process corresponding to different preset behavior requests will be described in detail below.
In a first aspect, 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 alliance joining request sent by an external CA node, wherein the alliance joining request comprises a node name, a node certificate, an application joining time, a guarantee signature and a private key signature of the external CA node, and the external CA node is a CA node which does not join the mutual trust alliance;
verifying the private key signature using a 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 the private key signature is verified, voting requests corresponding to the federate joining requests are sent to all second CA nodes in the mutual trust alliance, wherein the voting requests comprise the federate joining requests of the external CA nodes and the signature of the federate joining requests of the first CA node.
Second, when a certain node in the CA alliance is CAk(k e {1, 2 … n }) behavior is misleading, any other node can be directed to CAkInitiating a downward penalty voting request comprising the CAkEvidence of misbehavior, an intent to lower trust score, and a signature of the initiator. Voting by the whole alliance to decide whether to reduce CAkTrust score of Trust level. The voting process is joined with the new node.
Third, when in CA alliance, a CAkAnd (k is equal to {1, 2 … n }) the adding time exceeds a certain time T, or exceeds T from the last time of scoring, the adding time has the right of promoting the trust score, and a voting request for promoting the trust score is initiated to the full CA alliance. The CA needs to be included in the requestkThe time length of the compliance operation in the alliance (only one time can be promoted in each application), other nodes can trace the whole block chain, and the CA is ensuredkIt is claimed that the time duration of compliance operation in a federation corresponds to reality and votes taking into account other factors. The voting process is joined with the new node.
In the fourth aspect, when CAkWhen the (k ∈ {1, 2 … n }) node updates the certificate due to the certificate expiration and the like, a certificate update voting request needs to be sent to all CA nodes in the federation. Including at least a triplet [ CA ] in the requestkNew certificate of (C), CAKOld certificate, update time, update affair]And a triplet signed with the new certificate private key. The voting process is joined with the new node. The old certificate is still used as an identity signature in the voting process, and when the voting process is finished, the CAkThe new certificate of (2) is valid.
It should be noted that, the impact of the decision sequence on the result is avoided. Only one topic is taken at a time when a vote is initiated. When a plurality of blocks initiate voting at the same time, each block can only carry out one topic, and the time of initiating the voting first is used as the priority. If there is a new issue, a vote is initiated in the next block after the current issue has agreed. Each time the CA nodes above 2/3 agree, the voting issue passes. Here 2/3 is the common voting proportion in the block chain, representing the premise that most nodes agree on the voting process: all nodes use the existing alliance chain technology to complete the block synchronization of each node, and the block chains stored by each node are consistent during voting.
In the embodiment, the voting process is briefly described by taking the addition of a new node as an example. The voting process of the two issues of punishment and reward is the same as the new node adding, so the details are not repeated.
When the external node CAn +1 is ready to join the alliance, any alliance member CA is addedk(k e {1, 2 … n }) sends a join request, here defining the requested CA node as the first CA node. The request at least comprises the following contents:
[ [ CAn +1Name, CAn +1 certificate, application time, voting evidence (in the process of adding a new node, the content is CA qualification certification, such as a root CA certificate, an offline protocol copy, content for certifying self CA qualification such as a guarantor signature) ], and signing the quadruplet by using a CAn +1 certificate private key ].
CAkResponding to the request, verifying the signature of the CAn +1 join request by using a CAn +1 certificate, confirming that the source of the request is reliable and has not been tampered, and then initiating a new node join voting request to all nodes in the alliance, wherein the request at least comprises the following voting issues:
[ CAn +1 join request, CAkSignature on CAn +1 join request]。
All CA nodes in the alliance receive the voting request and inquire the CA in the CA state tree in the latest blockkCorresponding leaf node [ CA ]k Cert，Trust Levelk]Determining Trust Levelk>0, i.e. CAkHaving authority to initiate votes, and using CAkCert verifies voting requests, CAkThe source of the voting request is reliable and is not tampered with, and the voting request is verifiedAnd verifying the signature and qualification certificate in the CAn +1 adding request and then sending the verification to the CAkAnd returning voting feedback:
[ [ CA Name, CA vote result (0 or 1), vote request, vote description (interpretation of voting behavior, reason for disapproval and approval of vote, may be empty)]The CA node signs the private key of the above quadruple. CAkObtaining voting feedback from CAi (i belongs to {1, 2 … N } and i is not equal to N), firstly reading [ CAi Cert, Trust level i ] in leaf nodes in the CA state tree]Checking Trust level i>And 0, the CAi node has the voting right, and then the signature in the voting feedback is verified by using the CAi Cert to ensure that the voting feedback source is reliable and is not tampered. CAkBy adopting the mode, voting feedback from all nodes in the alliance is processed, the number of approved nodes is calculated, and if the number of approved nodes does not exceed 2/3, the approval is not passed through, CAkAnd constructing a voting process tree. If the number of approved nodes exceeds 2/3, only the voting process tree is reconstructed.
The CAk reconstructs the CA state tree. CAkBinary group of certificate and Trust score of CAn +1, namely [ CAn +1Cert, Trust level +1]Adding leaf nodes, reconstructing a CA state tree in an MPT format, and calculating Root Hash.
Whether the voting passes or not, each voting process needs to be written into the block in a voting process tree for retrospective tracing. Where the vote fails, there is no need to regenerate the CA state tree.
CAkAnd constructing a voting process tree, constructing the voting process tree in an MPT format by taking the voting feedback of each node as a leaf node, and calculating Root Hash to record the voting process. The CA state tree and voting process tree and the Root Hash of the two trees are written into the block. Finally, Root Hash of the final CA state tree is disclosed. And sends the new block to all nodes.
The new block, in addition to the original contents of the existing blockchain system, at least comprises the following contents:
block header: root hash of voting process tree, Root hash of CA state tree.
Block body: voting process tree, CA state tree.
Taking a federation of four CA nodes as an example, the voting blocks are shown in fig. 3 and 6.
Certainly, in another embodiment, the first CA node may also apply for joining the mutual trust federation in the role of the external CA node, and the specific process may include:
sending a join alliance application to a second CA node in the mutual trust alliance, wherein the join alliance request comprises a node name, a node certificate, an application join time, a guarantee signature and a private key signature of the first CA node, so that the second CA node verifies that the second CA node passes the private key signature by using the node certificate of the first CA node, and after the verification is passed, initiating a voting request corresponding to the join alliance request to all the second CA nodes in the mutual trust alliance, wherein the voting request comprises the join alliance request of the first CA node and the signature of the second CA node on the join alliance request;
and if the comprehensive voting result obtained by the second CA node based on the voting request is agreement, the second CA node joins the mutual trust alliance.
All CA nodes receive the block of the newly added node, based on the existing mechanism of the block chain of the alliance, the validity of the block is checked, the voting process tree is checked, each leaf node is confirmed to be credible, namely, the signature in the voting feedback of each CA node is verified, and the voting process tree is confirmed to be correct to construct. The CA status tree is checked, and the block is accepted after no error is confirmed and stored locally. The round of voting formally ends.
In another specific implementation manner, the step of verifying, by the blockchain, the validity of the certificate issued by the second CA node in the mutual trust alliance includes:
receiving a block chain supervision request sent by terminal equipment or an external CA node;
returning a real-time block chain of the mutual trust alliance to the terminal equipment so that the terminal equipment can judge the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value obtained by calculation of all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and the voting process tree are both legal;
and if receiving alarm information initiated by the terminal equipment based on the validity verification of the block chain, initiating a voting request corresponding to the penalty request to all CA nodes in the mutual trust alliance.
In the implementation, any entity can download the whole alliance chain from any CA node in the alliance, compare whether the Root Hash of the CA state trees published by different CA nodes are consistent or not, know each round of voting process, and verify the legality of each block and the legality of the CA state trees and the voting process trees through Hash pointers among the blocks. The terminal device corresponding to the arbitrary entity may or may not be in the alliance.
When any entity verifies that the published block or Root Hash of a CA is illegal, alarm information can be sent to any node in the alliance chain, wherein the alarm information comprises the following steps: violation CA name, violation evidence, and the alarm's own signature. And processing the alarm information by the CA nodes of the alliance, and determining that the evidence is true, so that any CA node can initiate penalty voting and enter a voting process.
Referring to fig. 7, fig. 7 is a flowchart of a certificate verification method according to an embodiment of the present invention. The certificate verification method of the embodiment of the invention can be executed by the first terminal, and the first terminal trusts the first CA node in the mutual trust alliance.
As shown in fig. 7, the certificate verification method may include the steps of:
step 701, applying for a terminal certificate to a trusted first CA node, wherein the first CA node is any node in a mutual trust alliance;
the first terminal B applies for an identity certificate Cert B at the first node CA 1.
Step 702, receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node, and a path hash node required for verifying the terminal certificate;
the first terminal downloads the CA1 certificate from the first CA node and verifies the required path Hash.
Step 703, sending the terminal certificate, the node certificate of the first CA node, and the path hash node to a second terminal, so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node, the path hash node, and a root hash value of a mutual trust union returned by the second CA node, where the second CA node is a CA node trusted by the second terminal and located in the mutual trust union, and the second terminal trusts the second CA node.
The first terminal trusts the second CA node and regularly accesses the CA to acquire Root Hash of the latest CA state tree.
Optionally, the device a sets a Trust threshold k, where Trust Level > k CA in the Trust union. If the device A does not set the Trust threshold, the CA with Trust Level >0 in the Trust union is trusted, so that dynamic Trust is achieved.
The first terminal sends the signature information of a terminal certificate Cert b to the second terminal, and attaches a CA2 certificate and a Trust Level two-tuple [ CA2Cert, Trust Level2] of a CA2, and a Hash node of a path required by verification.
And the second terminal verifies that the two-tuple [ CA2cert, TL ] is legal and credible by using the Root Hash to match with the Hash path node sent by the first terminal, and then judges that the Trust Level2> of the CA2 is k, and then judges that the CA2cert is credible.
The second terminal verifies Cert b by using the CA2 certificate, confirms that the identity certificate is legal, continuously verifies the signature of the first device, and confirms that the source of the message sent by the first device is reliable.
Referring to fig. 8, fig. 8 is a flowchart of a certificate verification method according to an embodiment of the present invention. The certificate verification method of the embodiment of the invention can be executed by the second terminal, and the second terminal trusts the first CA node in the mutual trust alliance.
As shown in fig. 8, the certificate verification method may include the steps of:
step 801, requesting a second CA node in the mutual trust alliance to acquire a real-time root hash value;
step 802, receiving 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 for verifying the terminal certificate of the first terminal;
and 803, verifying the validity 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.
Optionally, the step of verifying the validity 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:
verifying the validity of the first CA node certificate according to the root hash value and the path hash node;
and after the validity of the node certificate of the first CA node is verified, verifying the validity of the terminal certificate of the first terminal by using the node certificate of the first CA node.
In this embodiment, from the perspective of the second terminal, the second terminal is interpreted to verify the validity of the terminal certificate issued by other CA nodes in the same mutual trust alliance for the first terminal according to the root hash value of the mutual trust alliance.
Specifically, the second terminal downloads the latest root hash value of the mutual trust alliance from the second CA node in real time, and is used for verifying the validity of the certificates issued by other CA nodes in the mutual trust alliance for other terminals. Specifically, the second CA node verifies the validity of the node certificate of the first CA node by using the root hash value and the path hash node in combination with the verification scheme in fig. 4 in the foregoing method embodiment. After verifying the validity of the node certificate of the first CA node, the node certificate of the first CA node is used to verify the validity of the terminal certificate of the first terminal.
Therefore, the provided cross-node certificate verification mode only needs to sequentially carry out CA verification and terminal verification according to the latest root hash value, the verification scheme is simple and convenient, and the verification efficiency is high.
Referring to fig. 9, fig. 9 is a second flowchart of a node interaction method according to the embodiment of the present invention. The node interaction method of the embodiment of the invention can be executed by the terminal equipment, and the terminal equipment can trust the first CA node in the mutual trust alliance or not trust any CA node in the mutual trust alliance.
As shown in fig. 9, the node interaction method may include the following steps:
step 901, sending a block chain 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;
step 902, obtaining a real-time block chain of the mutual trust alliance, and verifying the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and the voting process tree are both valid;
and 903, if the validity of the block chain is not verified, sending alarm information to any CA node in the mutual trust alliance.
The scheme for the terminal device to supervise the block chain provided in this embodiment may refer to the relevant explanation about supervision in the node interaction method executed by the first CA node in the foregoing embodiment, and is not described again.
On the basis of the foregoing embodiments, the certificate verification method provided in this embodiment may further be extended as follows:
the related CA nodes include not only the CA (i.e., Certificate Authority) in the PKI system, but also any trusted third party capable of binding an entity and its owned identity (e.g., public and private key pair, shared secret, physical unclonable function, etc.), and the binding mode includes, but is not limited to, Certificate chain-based, identifier-based, etc.;
the Trust Level >0 of the CA node in the default alliance is the right to vote and the right to initiate the vote. When the method is used specifically, the voting right threshold value and the voting initiation threshold value can be set according to requirements. The CA node with Trust Level higher than the threshold value can vote and initiate voting operation;
the device may or may not set the Trust threshold, and if not, the default Trust Level >0 CA may be trusted. The Trust Level range of the CA alliance can be changed according to requirements and is not limited to the value range of {1, 2 … 5 }.
The initial Trust level scores of the CA alliance initial CA nodes and the subsequently added CA nodes can be set according to specific requirements and are not limited to 5 and 3.
The CA alliance vote passage ratio is not fixed at 2/3 and may be set to other values as appropriate.
The CA alliance internal voting method mentioned here is only one implementation method of the proposal, and other methods such as intelligent contracts can be used for voting.
In order to avoid that the attacker frequently initiates the voting, the CA alliance cannot respond to the normal voting request. A CA node can only initiate a vote once in a period of time. And a CA applies for adding or reporting a CA violation behavior, and only one CA node can be requested within a period of time.
The CA node joining the alliance must commit the legitimacy of issuing the certificate, when the certificate is overdue, or become invalid, should upgrade the revocation list of the certificate in time, otherwise will be voted for and reduced as the violation.
In summary, the voting process tree, the CA state tree and the corresponding root Hash are recorded in the form of a block chain, so as to record the decision process of the federation CA and disclose the decision process to the outside, thereby achieving the effect of centerless external supervision.
The various optional implementations described in the embodiments of the present invention may be implemented in combination with each other or implemented separately without conflict, and the embodiments of the present invention are not limited thereto.
Referring to fig. 10, fig. 10 is a diagram illustrating one of the structures of a node interaction apparatus according to an embodiment of the present invention. As shown in fig. 10, the node interaction apparatus 1000 includes a first processor 1001 for:
and joining a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutually trusted alliance stores the block chain.
Optionally, the block chain includes a founder block, and the first processor 1001 is configured to:
acquiring node certificates of all CA nodes which are initially trusted;
determining a node trust score value of each CA node;
generating an initial CA state tree, wherein each leaf node of the initial CA state tree comprises a node certificate and a node trust score value of a CA node;
calculating a root hash value according to the node certificates and the node trust score values of all CA nodes;
creating an founding block of the mutual trust alliance, and storing the root hash value and an initial CA state tree into the founding block;
the founder block is synchronously sent to all CA nodes.
Optionally, the first processor 1001 is further configured to:
executing voting behaviors corresponding to all CA nodes in the mutual trust alliance, wherein the voting behaviors comprise any one of node new-adding voting, node rewarding voting, node penalty voting and certificate updating voting;
and adding a voting block for the block chain, wherein the voting block comprises a voting process tree corresponding to the voting behavior and a CA state tree corresponding to the real-time CA node state, and each leaf node of the voting process tree comprises a node name, node voting data and a node signature of a CA node.
Optionally, the first processor 1001 is further configured to:
using a binary group containing a node certificate of a CA node and a node trust score value as a leaf node of a CA state tree, and constructing the CA state tree in a Merkel patricia tree format according to the leaf nodes corresponding to all CA nodes;
and/or the presence of a gas in the gas,
the generation step of the voting process tree comprises the following steps:
and constructing the voting process tree in the Merkel patricia tree format according to the leaf nodes corresponding to all the CA nodes by taking the triple including the node name, the node voting data and the node signature of one CA node as one leaf node of the voting process tree.
Optionally, the first processor 1001 is further configured to:
initiating a voting request corresponding to a preset behavior request to all second CA nodes in the mutual trust alliance, wherein the voting request at least comprises the preset behavior request, and the second CA nodes are CA nodes in the mutual trust alliance except the first CA node;
receiving voting data returned by the second CA node after verifying the validity of the preset behavior request, wherein the voting data comprises the node name and the voting result of the second CA node;
the step of adding a voting block to the block chain includes:
obtaining a comprehensive voting result according to the voting results of all the second CA nodes;
and creating a voting process tree corresponding to the voting behaviors according to the comprehensive voting result, and synchronously sending voting blocks containing the voting process tree to all CA nodes so that all CA nodes store the voting blocks into the block chain.
Optionally, the first processor 1001 is further configured to:
if the comprehensive voting result is agreement, generating the voting process tree and the latest CA state tree, and sending a voting block comprising the voting process tree and the latest CA state tree to all CA nodes;
and if the comprehensive voting result is against, generating a voting process tree, and sending a voting block containing the voting process tree and the current CA state tree to all CA nodes.
Optionally, the voting data further includes a node signature of a second CA node, and the first processor 1001 is further configured to:
and verifying the legality of the voting data according to the node signature, and obtaining a comprehensive voting result according to the voting results of all the second CA nodes after the legality of the voting data is verified.
Optionally, the first processor 1001 is further configured to:
carrying out validity verification on the received latest block, wherein the latest block is a creation block or a voting block;
and after the validity of the latest block is verified, storing the latest block.
Optionally, the preset action request is a new node adding request, and the first processor 1001 is further configured to:
receiving a alliance joining request sent by an external CA node, wherein the alliance joining request comprises a node name, a node certificate, an application joining time, a guarantee signature and a private key signature of the external CA node, and the external CA node is a CA node which does not join the mutual trust alliance;
verifying the private key signature using a node certificate of the external CA node;
after the signature of the private key of the external CA node is verified, a voting request corresponding to a join alliance request is sent to all second CA nodes in the mutual trust alliance, wherein the voting request comprises the join alliance request of the external CA node and the signature of the first CA node on the join alliance request.
Optionally, the first processor 1001 is further configured to:
sending a federation joining request to a second CA node in the mutual trust federation, wherein the federation joining request comprises a node name, a node certificate, an application joining time, a guarantee signature and a private key signature of the first CA node, so that the second CA node verifies that the private key signature passes by using the node certificate of the first CA node, and initiates a voting request corresponding to the federation joining request to all the second CA nodes in the mutual trust federation after the verification passes, wherein the voting request comprises the federation joining request of the first CA node and the signature of the second CA node on the federation joining request;
and if the comprehensive voting result obtained by the second CA node based on the voting request is agreement, the second CA node joins the mutual trust alliance.
Optionally, the first processor 1001 is further configured to:
receiving a block chain supervision request sent by terminal equipment or an external CA node;
returning a real-time block chain of the mutual trust alliance to the terminal equipment so that the terminal equipment can judge the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value obtained by calculation of all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and the voting process tree are both legal;
and if receiving alarm information initiated by the terminal equipment based on the validity verification of the block chain, initiating a voting request corresponding to the penalty request to all CA nodes in the mutual trust alliance.
Optionally, the first processor 1001 is further configured to:
if the node trust score value of the first CA node is greater than or equal to the trust threshold value, allowing the voting behaviors corresponding to all CA nodes in the mutual trust alliance to be executed;
and if the node trust score value of the first CA node is smaller than the trust threshold value, prohibiting the voting behaviors corresponding to all CA nodes in the mutual trust alliance.
Optionally, the first processor 1001 is further configured to:
receiving a voting request which is initiated by a second CA node in the mutual trust alliance and corresponds to a preset behavior request, wherein the voting request at least comprises the preset behavior request;
verifying the validity of the preset behavior request;
after verifying the validity 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, wherein the voting data comprises the node name and the voting result of the first CA node, and each leaf node of the voting process tree comprises the node name, the node voting data and the node signature of one CA node;
and receiving the voting block which is sent by the second CA node and contains the voting process tree, and storing the voting block into a block chain corresponding to the mutual trust alliance.
The certificate verifying apparatus 1000 can implement each process of the method embodiment of fig. 2 in the embodiment of the present invention, and achieve the same beneficial effects, and is not described herein again to avoid repetition.
Referring to fig. 11, fig. 11 is a block diagram of a certificate verification apparatus according to an embodiment of the present invention. As shown in fig. 11, the certificate verification apparatus 1100 includes a first transceiver 1101 for:
applying for a terminal certificate to a trusted first CA node, wherein the first CA node is located in a mutual trust alliance;
receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node and a path hash node required for verifying the terminal certificate;
and sending the terminal certificate, the node certificate of the first CA node and the path hash node to a second terminal so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node and the root hash value of the mutual trust alliance returned by the path hash node and the second CA node, wherein the second CA node is a CA node which is trusted by the second terminal and is located in the mutual trust alliance, and the second terminal trusts the second CA node.
The certificate verifying apparatus 1100 is capable of implementing each process of the method embodiment of fig. 7 in the embodiment of the present invention and achieving the same beneficial effects, and is not described herein again to avoid repetition.
Referring to fig. 12, fig. 12 is a second structural diagram of a certificate verification apparatus according to an embodiment of the present invention. As shown in fig. 12, the certificate verification apparatus 1200 includes:
a second transceiver 1201, configured 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;
a second processor 1202, configured to verify validity of the terminal certificate of the first terminal according to a root hash value, the node certificate of the first CA node, the path hash node, and the root hash value.
Optionally, the second processor 1202 is specifically configured to:
verifying the validity of the first CA node certificate according to the root hash value and the path hash node;
and after the validity of the node certificate of the first CA node is verified, verifying the validity of the terminal certificate of the first terminal by using the node certificate of the first CA node.
The certificate verifying apparatus 1200 can implement each process of the method embodiment in fig. 8 in the embodiment of the present invention, and achieve the same beneficial effects, and for avoiding repetition, details are not described here again.
Referring to fig. 13, fig. 13 is a second structural diagram of a node interaction device according to an embodiment of the present invention. As shown in fig. 13, the certificate verification apparatus 1300 includes:
a third transceiver 1301, configured to send a block chain supervision request to a first CA node in a mutual trust alliance, where the first CA node is any CA node in the mutual trust alliance;
a third processor 1302, configured to obtain a real-time blockchain of the mutual trust alliance, and verify validity of the blockchain, where the validity of the blockchain indicates that a root hash value stored in the blockchain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and both the CA state tree and the voting process tree are valid;
the third transceiver 1301 is further configured to send alarm information to any CA node in the mutual trust alliance if the validity of the block chain is not verified.
The certificate verifying apparatus 1300 can implement each process of the method embodiment in fig. 9 in the embodiment of the present invention, and achieve the same beneficial effects, and for avoiding repetition, details are not described here again.
The embodiment of the invention also provides communication equipment. Referring to fig. 14, a communication device may include a processor 1401, a memory 1402, and a program 14021 stored on the memory 1402 and operable on the processor 1401.
In the case that the communication device is the first CA node, when being executed by the processor 1401, the program 14021 may implement any step in the method embodiment corresponding to fig. 2 and achieve the same beneficial effect, and will not be described herein again.
In the case that the communication device is the first terminal, when being executed by the processor 1401, the program 14021 may implement any steps in the method embodiment corresponding to fig. 7 and achieve the same advantageous effects, and will not be described herein again.
In the case that the communication device is a second terminal, when being executed by the processor 1401, the program 14021 may implement any steps in the method embodiment corresponding to fig. 8 and achieve the same beneficial effects, and will not be described herein again.
In the case that the communication device is a terminal device, when the program 14021 is executed by the processor 1401, any step in the method embodiment corresponding to fig. 9 may be implemented and the same beneficial effect may be achieved, which is not described herein again.
Those skilled in the art will appreciate that all or part of the steps of the method according to the above embodiments may be implemented by hardware related to program instructions, and the program may be stored in a readable medium. An embodiment of the present invention further provides a readable storage medium, where a computer program is stored on the readable storage medium, and when the computer program is executed by a processor, any step in the method embodiments corresponding to fig. 2, fig. 7, fig. 8, or fig. 9 may be implemented, and the same technical effect may be achieved, and in order to avoid repetition, details are not repeated here.
The storage medium may be a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk.
While the foregoing is directed to the preferred embodiment of the present invention, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims (23)

1. A node interaction method, performed by a first CA node, the method comprising:
and joining a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutually trusted alliance stores the block chain.
2. The method of claim 1, wherein the block chain comprises a founder block, and wherein the step of joining a mutual trust federation comprises:
acquiring node certificates of all CA nodes which are initially trusted;
determining a node trust score value of each CA node;
generating an initial CA state tree, wherein each leaf node of the initial CA state tree comprises a node certificate and a node trust score value of a CA node;
calculating a root hash value according to the node certificates and the node trust score values of all CA nodes;
creating an founding block of the mutual trust alliance, and storing the root hash value and an initial CA state tree into the founding block;
the founder block is synchronously sent to all CA nodes.
3. The method of claim 2, wherein the block chain comprises a voting block located after the foundational block; the method further comprises the following steps:
executing voting behaviors corresponding to all CA nodes in the mutual trust alliance, wherein the voting behaviors comprise any one of node new-adding voting, node rewarding voting, node penalty voting and certificate updating voting;
and adding a voting block for the block chain, wherein the voting block comprises a voting process tree corresponding to the voting behavior and a CA state tree corresponding to the real-time CA node state, and each leaf node of the voting process tree comprises a node name, node voting data and a node signature of a CA node.
4. The method of claim 3, wherein the step of generating the CA status tree comprises:
the node certificate containing a CA node and the binary group of the node trust score value are used as leaf nodes of the CA state tree, and the CA state tree in the Merkelpatrier tree format is constructed according to the leaf nodes corresponding to all the CA nodes;
and/or the presence of a gas in the gas,
the generation step of the voting process tree comprises the following steps:
and constructing the voting process tree in the Merkel patricia tree format according to the leaf nodes corresponding to all the CA nodes by taking the triple including the node name, the node voting data and the node signature of one CA node as one leaf node of the voting process tree.
5. The method of claim 3, wherein the step of performing voting behavior for all CA nodes in the mutual trust federation comprises:
initiating voting requests corresponding to preset behavior requests to all second CA nodes in the mutual trust alliance, wherein the voting requests at least comprise the preset behavior requests, and the second CA nodes are CA nodes except the first CA node in the mutual trust alliance;
receiving voting data returned by the second CA node after verifying the validity of the preset behavior request, wherein the voting data comprises the node name and the voting result of the second CA node;
the step of adding a voting block to the block chain includes:
obtaining a comprehensive voting result according to the voting results of all the second CA nodes;
and creating a voting process tree corresponding to the voting behaviors according to the comprehensive voting result, and synchronously sending voting blocks containing the voting process tree to all CA nodes so that all CA nodes store the voting blocks into the block chain.
6. The method of claim 5, wherein the step of creating a voting process tree corresponding to the voting behavior according to the comprehensive voting result and synchronously sending voting blocks containing the voting process tree to all CA nodes comprises:
if the comprehensive voting result is agreement, generating the voting process tree and the latest CA state tree, and sending a voting block comprising the voting process tree and the latest CA state tree to all CA nodes;
and if the comprehensive voting result is against, generating a voting process tree, and sending a voting block containing the voting process tree and the current CA state tree to all CA nodes.
7. The method of claim 5, wherein the voting data further comprises node signatures of second CA nodes, and the step of obtaining a composite voting result according to the voting results of all the second CA nodes comprises:
and verifying the legality of the voting data according to the node signature, and obtaining a comprehensive voting result according to the voting results of all the second CA nodes after the legality of the voting data is verified.
8. The method of claim 5, further comprising:
carrying out validity verification on the received latest block, wherein the latest block is a creation block or a voting block;
and after the validity of the latest block is verified, storing the latest block.
9. The method according to claim 5, wherein the predetermined behavior request is a new node request, and before the step of initiating the voting request corresponding to the predetermined behavior request to all the second CA nodes in the mutual trust alliance, the method further comprises:
receiving a alliance joining request sent by an external CA node, wherein the alliance joining request comprises a node name, a node certificate, an application joining time, a guarantee signature and a private key signature of the external CA node, and the external CA node is a CA node which does not join the mutual trust alliance;
verifying the private key signature using a 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 the signature of the private key of the external CA node is verified, a voting request corresponding to a join alliance request is sent to all second CA nodes in the mutual trust alliance, wherein the voting request comprises the join alliance request of the external CA node and the signature of the first CA node on the join alliance request.
10. The method of claim 5, wherein the step of joining a mutual trust federation comprises:
sending a federation joining request to a second CA node in the mutual trust federation, wherein the federation joining request comprises a node name, a node certificate, an application joining time, a guarantee signature and a private key signature of the first CA node, so that the second CA node verifies that the private key signature passes by using the node certificate of the first CA node, and initiates a voting request corresponding to the federation joining request to all the second CA nodes in the mutual trust federation after the verification passes, wherein the voting request comprises the federation joining request of the first CA node and the signature of the second CA node on the federation joining request;
and if the comprehensive voting result obtained by the second CA node based on the voting request is agreement, the second CA node joins the mutual trust alliance.
11. The method of claim 1, further comprising:
receiving a block chain supervision request sent by terminal equipment or an external CA node;
returning a real-time block chain of the mutual trust alliance to the terminal equipment so that the terminal equipment can judge the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value obtained by calculation of all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and the voting process tree are both legal;
and if receiving alarm information initiated by the terminal equipment based on the validity verification of the block chain, initiating voting requests corresponding to the penalty requests to all CA nodes in the mutual trust alliance.
12. The method of claim 3, further comprising:
if the node trust score value of the first CA node is greater than or equal to the trust threshold value, allowing the voting behaviors corresponding to all CA nodes in the mutual trust alliance to be executed;
and if the node trust score value of the first CA node is smaller than the trust threshold value, prohibiting the voting behaviors corresponding to all CA nodes in the mutual trust alliance.
13. The method of claim 1, further comprising:
receiving a voting request which is initiated by a second CA node in the mutual trust alliance and corresponds to a preset behavior request, wherein the voting request at least comprises the preset behavior request;
verifying the validity of the preset behavior request;
after verifying the validity 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, wherein the voting data comprises the node name and the voting result of the first CA node, and each leaf node of the voting process tree comprises the node name, the node voting data and the node signature of one CA node;
and receiving the voting block which is sent by the second CA node and contains the voting process tree, and storing the voting block into a block chain corresponding to the mutual trust alliance.
14. A certificate verification method, performed by a first terminal, the method comprising:
applying for a terminal certificate to a trusted first CA node, wherein the first CA node is any node in a mutual trust alliance;
receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node and a path hash node required for verifying the terminal certificate;
and sending the terminal certificate, the node certificate of the first CA node and the path hash node to a second terminal so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node and the root hash value of the mutual trust alliance returned by the path hash node and the second CA node, wherein the second CA node is a CA node which is trusted by the second terminal and is located in the mutual trust alliance, and the second terminal trusts the second CA node.
15. A certificate verification method, performed by a second terminal, the method comprising:
requesting a second CA node in the mutual trust alliance to acquire a real-time root hash value;
receiving 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 for verifying the terminal certificate of the first terminal;
and verifying the validity 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.
16. The method according to claim 15, wherein the step of verifying the validity of the terminal certificate of the first terminal based on the root hash value, the node certificate of the first CA node, and the path hash node comprises:
verifying the validity of the first CA node certificate according to the root hash value and the path hash node;
and after the validity of the node certificate of the first CA node is verified, verifying the validity of the terminal certificate of the first terminal by using the node certificate of the first CA node.
17. A node interaction method, performed by a terminal device, the method comprising:
sending a block chain 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;
acquiring a real-time block chain of the mutual trust alliance, and verifying the validity of the block chain, wherein the validity of the block chain means that a root hash value stored in the block chain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and the CA state tree and a voting process tree are both legal;
and if the validity of the block chain is not verified, sending alarm information to any CA node in the mutual trust alliance.
18. A node interaction apparatus, comprising a first processor configured to:
and joining a mutually trusted alliance, wherein the mutually trusted alliance comprises a plurality of CA nodes mutually trusted with the first CA node, a block chain of the mutually trusted alliance comprises a real-time CA state tree and root hash values corresponding to all leaf nodes of the CA state tree, each leaf node of the CA state tree comprises a node certificate and a node trust score value of one CA node, and each CA node in the mutually trusted alliance stores the block chain.
19. A certificate verification apparatus, comprising a first transceiver configured to:
applying for a terminal certificate to a trusted first CA node, wherein the first CA node is located in a mutual trust alliance;
receiving a terminal certificate returned by the first CA node, a node certificate of the first CA node and a path hash node required for verifying the terminal certificate;
and sending the terminal certificate, the node certificate of the first CA node and the path hash node to a second terminal so that the second terminal verifies the validity of the terminal certificate of the first terminal according to the node certificate of the first CA node and the root hash value of the mutual trust alliance returned by the path hash node and the second CA node, wherein the second CA node is a CA node which is trusted by the second terminal and is located in the mutual trust alliance, and the second terminal trusts the second CA node.
20. A certificate verification apparatus, comprising:
the second transceiver is used for requesting a second CA node in a mutual trust alliance to acquire a real-time root hash value, receiving 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 for verifying the terminal certificate of the first terminal;
and the second processor is used for verifying the validity 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.
21. A node interaction apparatus, comprising:
a third transceiver, configured to send a block chain supervision request to a first CA node in a mutual trust alliance, where the first CA node is any CA node in the mutual trust alliance;
the third processor is configured to acquire a real-time blockchain of the mutual trust alliance, and verify the validity of the blockchain, where the validity of the blockchain indicates that a root hash value stored in the blockchain is the same as a root hash value calculated by all leaf nodes in the CA state tree, hash pointers between blocks are matched, and both the CA state tree and the voting process tree are valid;
and the third transceiver is also used for sending alarm information to any CA node in the mutual trust alliance if the validity of the block chain is not verified.
22. A communication device, comprising: a transceiver, a memory, a processor, and a program stored on the memory and executable on the processor; processor, configured to read a program in a memory to implement the steps of the node interaction method according to any one of claims 1 to 13, or the steps of the certificate verification method according to claim 14, or the steps of the certificate verification method according to claim 15 or 16, or the steps of the node interaction method according to claim 17.
23. A readable storage medium storing a program, characterized in that the program, when executed by a processor, implements the steps of the node interaction method of any one of claims 1 to 13, or the steps of the certificate verification method of claim 14, or the steps of the certificate verification method of claim 15 or 16, or the steps of the node interaction method of claim 17.
CN202110005432.1A 2021-01-05 2021-01-05 Node interaction method, certificate verification method, device and related equipment Pending CN114726567A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110005432.1A CN114726567A (en) 2021-01-05 2021-01-05 Node interaction method, certificate verification method, device and related equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110005432.1A CN114726567A (en) 2021-01-05 2021-01-05 Node interaction method, certificate verification method, device and related equipment

Publications (1)

Publication Number Publication Date
CN114726567A true CN114726567A (en) 2022-07-08

Family

ID=82234981

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110005432.1A Pending CN114726567A (en) 2021-01-05 2021-01-05 Node interaction method, certificate verification method, device and related equipment

Country Status (1)

Country Link
CN (1) CN114726567A (en)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107769925A (en) * 2017-09-15 2018-03-06 山东大学 Public key infrastructure system and its certificate management method based on block chain
CN108696348A (en) * 2017-04-06 2018-10-23 中国移动通信有限公司研究院 A kind of method, apparatus, system and electronic equipment for realizing CA mutual trusts
US20190317924A1 (en) * 2018-04-12 2019-10-17 ISARA Corporation Constructing a Multiple Entity Root of Trust
CN111611315A (en) * 2020-05-25 2020-09-01 辽宁大学 Financial big data-oriented multi-branch tree structure block chain integrated optimization storage method
CN111935674A (en) * 2020-08-17 2020-11-13 重庆邮电大学 Vehicle networking hierarchical authentication method based on block chain technology

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108696348A (en) * 2017-04-06 2018-10-23 中国移动通信有限公司研究院 A kind of method, apparatus, system and electronic equipment for realizing CA mutual trusts
CN107769925A (en) * 2017-09-15 2018-03-06 山东大学 Public key infrastructure system and its certificate management method based on block chain
US20190317924A1 (en) * 2018-04-12 2019-10-17 ISARA Corporation Constructing a Multiple Entity Root of Trust
CN111611315A (en) * 2020-05-25 2020-09-01 辽宁大学 Financial big data-oriented multi-branch tree structure block chain integrated optimization storage method
CN111935674A (en) * 2020-08-17 2020-11-13 重庆邮电大学 Vehicle networking hierarchical authentication method based on block chain technology

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
张健毅;王志强;徐治理;欧阳雅菲;杨涛;: "基于区块链的可监管数字货币模型", 计算机研究与发展, no. 10, 15 October 2018 (2018-10-15) *

Similar Documents

Publication Publication Date Title
CN109327528B (en) Node management method and device based on block chain
CN110599069B (en) Application evaluation method and device based on block chain network
US20200382326A1 (en) Digital certificate verification method and apparatus, computer device, and storage medium
TW201943250A (en) Cross-blockchain authentication method and apparatus, and electronic device
CN112055025A (en) Privacy data protection method based on block chain
CN110177124B (en) Identity authentication method based on block chain and related equipment
CN112311735A (en) Credible authentication method, network equipment, system and storage medium
CN109660330B (en) Method and system for identity authentication on block chain
CN112508566A (en) Alliance chain-based cross-chain private transaction method and equipment
CN113328997B (en) Alliance chain crossing system and method
CN111339116A (en) Block chain-based method for sharing open bank data
CN112861090B (en) Information processing method, device, equipment, storage medium and computer program product
CN110851877B (en) Data processing method and device, block chain node equipment and storage medium
Abraham et al. Qualified eID derivation into a distributed ledger based IdM system
CN114760071B (en) Zero-knowledge proof based cross-domain digital certificate management method, system and medium
CN114240433A (en) Data processing method and system based on block chain
CN114691669A (en) Electronic certificate storage method and device, electronic equipment and storage medium
CN114039733B (en) Certificate storage service transfer method, device and equipment for alliance chains
CN115174570A (en) Cross-chain consensus method and system based on dynamic committee
CN109960512B (en) Software deployment method and system
CN114186288A (en) PKI certificate system model based on block chain and certificate management method
CN113992526A (en) Credibility calculation-based alliance chain cross-chain data fusion method
CN110706102B (en) Multistage signature method with anonymity for alliance block chain
CN114726567A (en) Node interaction method, certificate verification method, device and related equipment
CN114092092B (en) Decentralized digital certificate management system based on threshold signature and use method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination