Ca consensus method, apparatus, and node

Abstract

Provided are a CA consensus method, an apparatus, and a node. The method comprises: obtaining a final voting result for a voting event on the basis of voting results of a plurality of first CAs; and when the final voting result indicates that the voting event passes, executing a first operation, wherein the first operation comprises registration of a CA, revocation of a CA, or update of a root certificate. In this way, a decision can be jointly made by a plurality of CAs without relying on a central CA, thereby improving the degree of decentralization of DPKI systems, and thus improving the overall security of the DPKI systems.

Description

CA consensus method, device and node

[0001] The present application claims priority to the Chinese patent application No. 202411082261.2, filed on August 7, 2024, and entitled "CA consensus method, device and node", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0002] The present application relates to the field of blockchain technology, in particular to a CA consensus method, device and node. BACKGROUND

[0003] The current digital certificate management architecture has significant centralization risks. With the development of the Internet, traditional centralized services have exposed various drawbacks, the most significant of which is the dependence on the centralization of rights. In order to solve this problem and seek a safer, more transparent and efficient data management method, DPKI (Decentralized / Distributed Public Key Infrastructure) technology has emerged. DPKI technology is a CA certificate management system based on a consortium chain. The consortium chain is a kind of blockchain technology. DPKI technology uses the decentralized characteristics of blockchain to reduce the dependence of certificate relying parties on a single CA. However, the degree of decentralization of the DPKI system is low.

[0004] Therefore, how to further improve the degree of decentralization of the DPKI system and improve the overall security of the DPKI system is crucial. SUMMARY

[0005] The present application provides a CA consensus method, device and node, which can improve the degree of decentralization of the DPKI system and thus improve the overall security of the DPKI system.

[0006] In a first aspect, the embodiments of the present application provide a CA consensus method, comprising:

[0007] obtaining a final voting result of the voting event based on the voting results of the plurality of first CAs;

[0008] performing a first operation in a case where the final voting result indicates that the voting event passes;

[0009] The first operation includes registering a CA, deregistering a CA or updating a root certificate.

[0010] According to the scheme, when some operations have an impact on the security of the DPKI system, such as registration of a CA, deregistration of a CA, or root certificate update, the final voting result of the voting event can be obtained through the voting results of multiple CAs in the DPKI system. When the final voting result is passed, the operation is performed. In this way, without excessive dependence on the central CA, the decentralization degree of the DPKI system is improved through the joint decision of multiple CAs, thereby improving the overall security of the DPKI system.

[0011] In a possible implementation, the voting event is obtained when the first request authentication and authorization are passed, and the voting result is obtained when the second request authentication and authorization are passed.

[0012] The first request is used to indicate a request to create a voting event, and the second request is used to indicate writing of the voting result into a block in the blockchain.

[0013] In this way, the requests in the DPKI system are performed only when the authentication and authorization are passed, thereby improving the security of the system.

[0014] In a possible implementation, the first request is signed by a second CA that initiates the first request, and the second request is signed by the first CA. The first request and the second request both carry a public key of the CA. The method comprises the following steps:

[0015] According to the signature of the second CA, the public key of the CA, and a preconfigured CA information list, the first request is authenticated and authorized.

[0016] According to the signature of the first CA, the public key of the CA, and the preconfigured CA information list, the second request is authenticated and authorized.

[0017] The CA information list includes the public key of the CA and the authority of the CA. The authority of the CA is used to indicate whether the CA has the authority to perform the first operation.

[0018] In this way, the requests in the DPKI system are performed only when the authentication and authorization are passed, thereby improving the security of the system.

[0019] In a possible implementation, when the number of votes in favor of the voting result is greater than a first threshold, the final voting result is that the voting event is passed. The first threshold is preconfigured.

[0020] Alternatively, the final voting result of the voting event is obtained based on the voting results of the multiple first CAs, and the method comprises the following steps:

[0021] The final voting result is obtained according to the voting result of each first CA in the multiple first CAs and the voting weight of each first CA.

[0022] In a case where the proportion of the approval in the final voting result is greater than the second threshold, the final voting result is that the voting event is passed, and the voting weight of the first CA and the second threshold are preconfigured.

[0023] In this way, whether to perform some operations can be determined by the one central CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0024] In a possible implementation, the method is applied after the DPKI system is initialized, and the initialization of the DPKI system includes:

[0025] The underlying configuration information of the blockchain is written into the genesis block;

[0026] The configuration information of the node is written into the node;

[0027] The underlying configuration information and the configuration information of the node are obtained based on configuration information of the DPKI system, and the configuration information of the DPKI system is created by a third CA, which is a CA initially registered to the DPKI system.

[0028] In this way, after the DPKI system is initialized, the CA consensus can be performed, whether to perform some operations can be determined by the one central CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0029] In a possible implementation,

[0030] The underlying configuration information of the blockchain includes a node trust list, a consensus authority list, an authority CA list, a DPKI key code or a hash value; and the DPKI application layer configuration includes a CA information list and a certificate information list.

[0031] The node trust list includes public keys of nodes allowed to access the blockchain.

[0032] The consensus authority list includes public keys used to verify the identity of a node.

[0033] The authority CA list is used to indicate a CA that can vote to determine a blockchain governance operation.

[0034] The CA information list includes information of the CA, and the information of the CA includes an identity of the CA, a state, a blockchain transaction key, and a permission of the CA.

[0035] The certificate information list includes certificates issued by each CA and metadata of the certificates.

[0036] The configuration information of the node includes a unique coding ID of the blockchain, a name of the blockchain, and an address of a starting node.

[0037] Therefore, after the DPKI system is initialized, the CA consensus can be performed, so that whether to perform some operations is determined by the plurality of CAs instead of a central CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0038] In a second aspect, the present application provides a CA consensus device, comprising:

[0039] The processing module is configured to obtain a final voting result of the voting event based on the voting results of the plurality of first CAs.

[0040] The execution module is configured to perform a first operation if the final voting result indicates that the voting event passes.

[0041] The first operation includes registering a CA, unregistering a CA, or updating a root certificate.

[0042] According to the present application, when some operations have an impact on the security of the DPKI system, such as registering a CA, unregistering a CA, or updating a root certificate, the final voting result of the voting event can be obtained based on the voting results of the plurality of CAs in the DPKI system. If the final voting result passes, the operation is performed. In this way, the DPKI system is not excessively dependent on a central CA, and the degree of decentralization of the DPKI system is improved, thereby improving the overall security of the DPKI system.

[0043] In a possible implementation, the voting event is obtained if a first request is authenticated and authorized, and the voting result is obtained if a second request is authenticated and authorized.

[0044] The first request is used to indicate a request to create a voting event, and the second request is used to indicate writing the voting result into a block in a block chain.

[0045] In this way, the requests in the DPKI system are performed only if they are authenticated and authorized, thereby improving the security of the system.

[0046] In a possible implementation, the first request is signed by a second CA that initiates the first request, the second request is signed by the first CA, and the first request and the second request both carry a public key of the CA. The device comprises:

[0047] The authentication and authorization module is configured to authenticate and authorize the first request based on the signature of the second CA, the public key of the CA, and a preconfigured CA information list.

[0048] The authentication and authorization module is further configured to authenticate and authorize the second request based on the signature of the first CA, the public key of the CA, and the preconfigured CA information list.

[0049] The CA information list includes a public key of the CA and a permission of the CA, and the permission of the CA is used to indicate whether the CA has the permission to perform the first operation.

[0050] In this way, the request in the DPKI system is performed under the condition of authentication and authorization, so that the security of the system can be improved.

[0051] In a possible implementation, when the number of votes in favor is greater than the first threshold, the final voting result is that the voting event is passed, and the first threshold is pre-configured.

[0052] Alternatively, the processing module is configured to obtain the final voting result according to the voting result of each first CA in the plurality of first CAs and the voting weight of each first CA.

[0053] In the final voting result, when the proportion of votes in favor is greater than the second threshold, the final voting result is that the voting event is passed, and the voting weight of the first CA and the second threshold are pre-configured.

[0054] In this way, it can be avoided to determine whether to perform some operations through a central CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0055] In a possible implementation, the apparatus is applied after the DPKI system is initialized, and the initialization of the DPKI system includes:

[0056] The underlying configuration information of the blockchain is written into the genesis block.

[0057] The configuration information of the node is written into the node.

[0058] The underlying configuration information and the configuration information of the node are obtained based on configuration information of the DPKI system, and the configuration information of the DPKI system is created by a third CA, which is a CA initially registered to the DPKI system.

[0059] In this way, after the DPKI system is initialized, the CA consensus can be performed, so that it can be avoided to determine whether to perform some operations through a central CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0060] In a possible implementation, the underlying configuration information of the blockchain includes a node trust list, a consensus authority list, an authority CA list, a DPKI key code or a hash value; and the DPKI application layer configuration includes a CA information list and a certificate information list.

[0061] The node trust list includes a public key of a node allowed to access the blockchain.

[0062] The consensus authority list includes a public key used to verify the identity of a node.

[0063] The authority CA list is used to indicate the CAs that can vote to decide the blockchain governance operation;

[0064] The CA information list includes the information of the CAs, and the information of the CAs includes the identity of the CAs, the state, the blockchain transaction key, and the permission of the CAs;

[0065] The certificate information list includes the certificates issued by the CAs and the metadata of the certificates;

[0066] The configuration information of the node includes the unique coding ID of the blockchain, the name of the blockchain, and the address of the starting node.

[0067] In this way, after the DPKI system is initialized, the CA consensus can be performed, so as to avoid deciding whether to perform some operations through a central CA, improve the degree of decentralization of the system, and thus improve the overall security of the system.

[0068] In a third aspect, the present application provides a DPKI system, including: at least one memory for storing a program; and at least one processor for executing the program stored in the memory, wherein the processor is configured to execute the method provided in the first aspect when the program stored in the memory is executed.

[0069] In a fourth aspect, the present application provides a node, wherein the device runs computer program instructions to execute the method provided in the first aspect. For example, the device can be a chip or a processor.

[0070] In one example, the device can include a processor which can be coupled with a memory, read instructions in the memory and execute the method provided in the first aspect according to the instructions. The memory can be integrated in the chip or the processor, or can be independent of the chip or the processor.

[0071] In a fifth aspect, the present application provides a computer storage medium, wherein the computer storage medium stores instructions, and when the instructions are run on a computer, the computer is caused to execute the method provided in the first aspect.

[0072] In a sixth aspect, the present application provides a computer program product including instructions, and when the instructions are run on a computer, the computer is caused to execute the method provided in the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0073] FIG. 1 is a system architecture diagram of a consortium chain provided by an embodiment of the present application;

[0074] FIG. 2a is a structural schematic diagram of a DPKI system provided by an embodiment of the present application;

[0075] Fig. 2b is a structural schematic diagram of an exemplary DPKI system according to an embodiment of the present application;

[0076] Fig. 2c is a flowchart of a DPKI system initialization method according to an embodiment of the present application;

[0077] Fig. 3a is a flowchart of a CA consensus method according to an embodiment of the present application;

[0078] Fig. 3b is a flowchart of a voting result acquisition method according to an embodiment of the present application;

[0079] Fig. 4 is a flowchart of an exemplary CA consensus method according to an embodiment of the present application;

[0080] Fig. 5 is a flowchart of a CA consensus method during CA registration according to an embodiment of the present application;

[0081] Fig. 6 is a flowchart of a CA consensus method during CA deregistration according to an embodiment of the present application;

[0082] Fig. 7 is a structural schematic diagram of a CA consensus apparatus according to an embodiment of the present application;

[0083] Fig. 8 is a structural schematic diagram of a computing device according to an embodiment of the present application. DETAILED DESCRIPTION

[0084] The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0085] Before the embodiments of the present application are described in detail, the terms involved in the present application are first explained.

[0086] 1. Digital certificate, a trusted digital file signed by a third-party certificate authority with authority, credibility and impartiality.

[0087] 2. Certificate authority (CA): also known as certificate issuing authority, is an authority responsible for issuing and managing digital certificates.

[0088] 3. Blockchain: A distributed database or data storage system that uses cryptographic principles to protect its integrity and synchronizes data among nodes through a decentralized network. Blockchain is used to record transaction information, which is packaged into blocks and linked to the previous block through a hash value to form a chain structure, hence the name blockchain.

[0089] Blockchain State: The data synchronized among nodes in a blockchain is referred to as the state of the blockchain. The blockchain state can be changed by transactions.

[0090] 4. Blockchain Account: A blockchain account is required to initiate transactions in a blockchain. The account contains a set of key pairs, and the private key is used to sign transactions when initiating a transaction to prove that the transaction was created by the private key holder.

[0091] 5. Blockchain Transaction: A transaction in a blockchain represents a state update operation initiated by a blockchain account. The transaction is submitted to a node by the client and then broadcast to other nodes. When a node packages this transaction into a block and the block is accepted by the blockchain network, the transaction takes effect, and the state update operation is executed by all nodes.

[0092] 6. Node: Refers to a computer or device connected to the blockchain and participating in maintaining and verifying transactions. Nodes receive transactions from clients and generate blocks through consensus mechanisms to form a blockchain while maintaining blockchain state information.

[0093] 7. Consensus: Consensus mechanism is a process in which nodes in a blockchain reach an agreement on data validity, transaction and block confirmation, etc. Consensus mechanism includes block generation and block confirmation.

[0094] 8. Genesis Block: The first block in a blockchain.

[0095] 9. Decentralized Application (dApp): Refers to an application deployed on a blockchain that can access and update the state of the blockchain. The interface provided by the dApp can be called by blockchain transactions. When the blockchain system processes transactions in the block, it will call the corresponding dApp interface to perform the corresponding state update operation.

[0096] Smart Contract: A decentralized application implementation, refers to an application that can be deployed or invoked through a blockchain transaction. Smart contracts have higher flexibility than the application logic in the node.

[0097] Voting: Also known as referendum, refers to the direct voting of all voting members on important issues.

[0098] Authentication: Refers to the process by which the system verifies the submitted identity proof to confirm the user's identity.

[0099] Authorization: Refers to the process by which the system grants users access to specific resources or the right to perform specific operations based on their identity.

[0100] In the context of the Internet, digital certificates play an important role in safeguarding data transmission security and ensuring information integrity. Their application fields are wide, covering various levels from individuals to enterprises, including but not limited to Secure Socket Layer (SSL) / Transfer Layer Security (TLS) certificates in the Web Public Key Infrastructure (PKI) system used by Internet website / application servers, security mechanisms for managing Internet domain names and routing, key components of system trusted boot, and authentication and authorization processes for enterprise services.

[0101] For users accessing the Internet, PKI plays a core role in maintaining network security. When a browser attempts to connect to a website protected by the Hyper-Text Transfer Protocol Secure (HTTPS) protocol, it requests a TLS certificate from the server. This certificate is issued by an authoritative third-party organization, the Certificate Authority (CA), and verifies its association with a specific domain name to ensure that the user's data is protected from man-in-the-middle attacks and data tampering during transmission. In short, the Web PKI system builds a bridge of trust between browsers and servers, laying the foundation for secure communication on the Internet.

[0102] However, the current digital certificate management architecture has significant centralization risks. With the development of the Internet, traditional centralized services have exposed various drawbacks, the most notable of which is the concentration of power. To address this issue and seek a safer, more transparent and efficient data management approach, blockchain technology has emerged.

[0103] Blockchain is generally divided into three types: public chain (Public Blockchain), private chain (Private Blockchain) and consortium chain (Consortium Blockchain). Among them, the consortium chain is a blockchain between the public chain and the private chain, which can realize "partial decentralization". Each node in the consortium chain usually has a corresponding entity organization or organization, such as CA, relying party. Participants join the node network by authorization and form an interest-related consortium to jointly maintain the operation of the blockchain.

[0104] The International Telecommunication Union Telecommunication Standard Bureau Research Group 17 (ITU-T SG17) proposes the X.DPKI standard draft. Among them, the X.DPKI standard draft is a standard series about the DPKI system, which involves running the DPKI system through the consortium chain, thereby improving the security and decentralization degree of the traditional PKI system. Among them, in the X.DPKI standard, the consortium chain running the DPKI, the node and the CA are one-to-one corresponding communication connection relationship. X.DPKI uses nodes in the blockchain network to verify and distribute digital certificates, eliminating the high dependence on a single CA organization, thereby enhancing the security, reliability and flexibility of the entire system. Although the X.DPKI standard improves the decentralization degree of the traditional PKI system, due to the dependence of the X.DPKI standard on centralized operation, the degree of decentralization is low, resulting in low overall security of the system and low credibility of the system. Therefore, it is crucial to further improve the decentralization degree of the DPKI system.

[0105] Based on this, the CA consensus method, device and node provided by the embodiments of the present application. In the method, when a transaction is received, and the operation requested in the transaction is associated with the security of the DPKI system, a voting event corresponding to the operation is created, and according to the voting results of the voting event by the plurality of CAs in the DPKI system, it is determined whether to execute the operation requested by the transaction request. In this way, when the operation involves the security of the DPKI system, it is not necessary to excessively rely on the central CA, and the operation can be determined by the plurality of CAs, thereby improving the decentralization degree of the DPKI system, and further improving the security of the DPKI system.

[0106] FIG. 1 is a schematic diagram of an architecture of a consortium chain according to an embodiment of the present application. As shown in FIG. 1, the consortium chain according to an embodiment of the present application includes CAs 1 to 8 and nodes 1 to 8. The connection lines between the nodes schematically represent a peer-to-peer (P2P) connection to form a node network. The nodes can store a full amount of a ledger, i.e., store all transactions. Each node in the consortium chain can generate the same state in the consortium chain by executing the same transaction, and each node in the consortium chain can store the same state database. It can be understood that although FIG. 1 shows that the consortium chain includes eight nodes, the embodiments of the present application are not limited thereto, but can include other numbers of nodes. In addition, the number of nodes in the consortium chain is large and widely distributed, and therefore, the connection between the nodes has high flexibility and dynamics. The number of nodes and the connection relationship between the nodes in FIG. 1 are only exemplary. In actual applications, the connection between the nodes can be adjusted according to actual conditions.

[0107] In the embodiments of the present application, the CAs in the consortium chain can form a communication connection with the node network. In some examples, in the consortium chain, the number of CAs is the same as the number of nodes, and the CAs and the nodes have a one-to-one correspondence in the communication connection relationship. For example, CA1 is in communication connection with node 1 to access the node network, CA2 is in communication connection with node 2 to access the node network, and so on, and CA8 is in communication connection with node 8 to access the node network. In other examples, one CA can be in communication connection with multiple nodes respectively. For example, the consortium chain includes CAs 1 to 3 and nodes 1 to 8, wherein CA1 is in communication connection with node 1, node 2, and node 3 respectively to access the node network, CA2 is in communication connection with node 4, node 5, and node 6 respectively to access the node network, and CA3 is in communication connection with node 7 and node 8 respectively to access the node network. In yet other examples, multiple CAs can be in communication connection with the same node. For example, the consortium chain includes CAs 1 to 3 and nodes 1 to 8, wherein CA1, CA2, and CA3 are all in communication connection with node 1. The number of CAs in FIG. 1 is only exemplary. In actual applications, the number of CAs and the connection relationship between the CAs and the nodes can be determined according to actual conditions.

[0108] In some embodiments, as shown in FIG. 2a, the consortium chain provided by the embodiments of the present application can include a CA management module 21 and a certificate management module 22. The CA management module is used to manage the update operations related to the CA, such as CA registration, CA deregistration and the like. The certificate management module is used to manage the update operations related to the certificate, such as root certificate update and the like. In the present embodiment, the voting management module 20 can be deployed in the CA management module 21 and the certificate management module 22, so as to manage the voting of the operations that require the consensus of the CA, so as to determine whether the CA needs to reach a consensus on the transaction. In the embodiments of the present application, the transaction that requires the consensus of the CA is usually related to the trust degree of the user to the entire system, such as CA registration, CA deregistration and root certificate update, which all involve the security level of the entire system. Therefore, only one CA is used to determine whether to perform the first operation, which reduces the security level of the entire system and thus reduces the trust degree of the user to the entire system. For the convenience of description, the operation corresponding to the operation that requires the consensus of the CA is referred to as the first operation.

[0109] As a possible implementation, as shown in FIG. 2b, each node in the consortium chain is deployed with a CA management module 21, a certificate management module 22 and a voting management module 23. The CA management module 21 and the certificate management module 22 can perform data transmission with the voting management module 23 and the like.

[0110] It can be understood that the consortium chain provided by the embodiments of the present application can run the DPKI system.

[0111] The CA consensus method provided by the embodiments of the present application can be applied in the DPKI system, and the DPKI system is deployed in the consortium chain provided by the embodiments of the present application. When the DPKI system is in the working state after initialization, the CA consensus method provided by the embodiments of the present application can be executed. Therefore, before the CA consensus method is described, the initialization of the DPKI system needs to be described in detail.

[0112] As shown in FIG. 2c, the method for initializing the DPKI provided by the embodiments of the present application includes the following steps S201 to S203.

[0113] S201, the CA obtains the configuration information of the DPKI system and the underlying configuration information of the blockchain running the DPKI system.

[0114] In the process of initializing the DPKI system, first, each initial CA needs to create configuration information of the DPKI system, wherein the configuration information includes keys required by nodes, such as keys for p2p communication between nodes, keys for consensus between nodes, and the like. The configuration information of the DPKI system also includes information of the CA, such as an identity of the CA, a state of the CA, a blockchain transaction key (a public key of the node and a private key of the node), a permission of the CA, and a CA certificate, and the like. The state of the CA includes registered, unregistered, and the like. The state of the initial CA is registered. The permission of the CA includes a permission of the CA to initiate some operations, a permission of the CA to vote on some operations, and the like. For example, the CA has the permission to update a root certificate, register a new CA, and unregister other CAs, and the CA has the voting permission and the voting weight on whether to update the root certificate, register the new CA, and unregister the other CAs.

[0115] In some embodiments, the user can access the CA to configure the configuration information of the DPKI system and the underlying configuration information of the blockchain running the DPKI system into the CA.

[0116] S202, the CA sends the underlying configuration information of the blockchain and the configuration information of the node to the node, so that the node writes the underlying configuration information of the blockchain into the genesis block.

[0117] The underlying configuration information of the blockchain includes blockchain underlying configuration and DPKI application layer configuration. The blockchain underlying configuration can include a node trust list, a consensus authority list, an authority CA list, a DPKI key code or a hash value. Optionally, the blockchain underlying configuration can also include an account balance list. The account balance list includes a public key of each account and a resource balance of each account.

[0118] The node trust list includes public keys of nodes allowed to access the blockchain. The public key of the node is included in the information of each CA. When the public key of the node in the information of the CA is updated, the CA can automatically synchronize the public key of the node to the node trust list. When a node in the blockchain receives a connection request of a certain node, if the public key of the node is in the node trust list, the node can choose to trust the node and agree to establish a connection.

[0119] The consensus authority list is a list of public keys used to verify the identity of the node. It can be divided into two usage scenarios according to "block generation" and "block verification". In some embodiments, the blockchain can use a certain mechanism (rotation or verifiable random function (VRF)) to determine the order of the nodes in the consensus authority list to generate blocks in turn. The node creating the block can sign the block with the public key. The node can use the signature in the received block to verify whether the node generating the block has the right to generate a new block at the current time point through the consensus authority list.

[0120] In some embodiments, the consensus authority list contains voting weights. The nodes in the list vote for each newly generated block, and the blockchain system receives the block and adds it to the blockchain when the threshold is reached. The nodes that verify the block can sign the p2p message for the block with the public key. The nodes can verify the vote by the signature of the received voting message and count the votes, and the block is included when the threshold is reached.

[0121] The DPKI key code or hash value can be a smart contract code or hash value. The logic of the DPKI system is implemented by a smart contract (for example, the CA consensus method provided in the embodiments of the present application can be implemented by a smart contract), and the smart contract code or its hash value can be written into a block. The initial version of the smart contract can be written into the genesis block.

[0122] The authority CA list is used to indicate a list of CAs that can vote to decide the blockchain governance operation. The governance operation can be an operation of updating the underlying parameters of the blockchain. The authority CA list includes information of the CAs and the underlying parameters of the blockchain that can be voted to decide.

[0123] The DPKI application layer configuration can include a CA information list and a certificate information list. The CA information list includes information of the CAs, such as the identity of the CA, the status, the blockchain transaction key, the authority of the CA, etc. The certificate information list includes certificates issued by each CA and metadata of the certificates, wherein the metadata of the certificates includes the CA that issues the certificate, and if the certificate is issued to a certain CA, the subject CA is recorded.

[0124] The main use of the DPKI system is to upload the certificates issued by each CA to the chain, and to make the certificate issuance record queryable and more transparent by using the unchangeable feature of the blockchain. The initial value of the certificate information list (such as the root certificate of each initial CA) needs to be given during initialization.

[0125] The configuration information of the node includes the unique code (Identity document, ID) of the blockchain, the name of the blockchain, and the address of the starting node. The starting node refers to the node that needs to be connected for communication when the node starts.

[0126] S203, after the CA confirms that the configuration information is correct, the respective nodes are started, an alliance chain is formed, the initial CA is registered successfully, and the DPKI system starts to run.

[0127] The shared configuration is synchronized to all CAs. After confirming that there is no error, each CA starts its own blockchain node, and the nodes start p2p connection according to the configuration, and an alliance blockchain is established. The DPKI system starts to work immediately, and the initial member CAs and their CA certificates have been pre-registered.

[0128] Next, the CA consensus method provided by the embodiments of the present application is described in detail.

[0129] FIG. 3a is a flow diagram of a CA consensus method provided by an embodiment of the present application. The CA consensus method provided by the embodiments of the present application is applied to a DPKI system or a node in the DPKI system. As shown in FIG. 3a, the CA consensus method provided by the embodiments of the present application includes the following steps S301 and S302.

[0130] S301, obtaining a final voting result of the voting event based on voting results of a plurality of first CAs.

[0131] The first CA refers to a registered CA in the DPKI system. Each first CA can vote on the voting event, thereby obtaining a voting result of the first CA. The voting event is used to indicate an event of voting on performing a first operation. The first operation can be a CA registration, a CA deregistration, or an update of a root certificate, etc.

[0132] The final voting result is obtained according to the voting results of the plurality of first CAs. The final voting result is used to indicate whether the voting event is passed.

[0133] For example, the number of first CAs in favor of the voting event is counted. In a case where the number of first CAs in favor of the voting event is greater than or equal to a first threshold value, the final voting result of the voting event is that the voting event is passed, and the first operation is performed. In a case where the number of first CAs in favor of the voting event is less than the first threshold value, the final voting result of the voting event is that the voting event is not passed, and the first operation is not performed. The first threshold value is pre-configured. For example, the first threshold value can be a positive integer greater than 0. For another example, the first threshold value can also be set according to specific requirements. In actual application, the first threshold value can be configured according to the requirements of actual application, which is not limited in the embodiments of the present application.

[0134] For example, the voting event indicates the registration of CA1. The CAs that vote on the voting event include CA2 to CA5. The voting results of CA2, CA3 and CA4 are in favor, and the voting result of CA5 is not in favor. The number of CAs in favor of the voting event is 3, and the first threshold value is 2. Therefore, the final voting result is passed.

[0135] In another example, the voting weights of different first CAs are different, and the passing ratio of the approval voting event and the passing ratio of the disapproval voting event are calculated according to the voting results of different first CAs and the voting weights of different first CAs, so as to determine the final voting result. In the case where the ratio of approval in the final voting result is greater than the second threshold, the voting event passes, and the first operation is performed. In the case where the ratio of approval in the final voting result is less than or equal to the second threshold, the voting event does not pass, and the first operation is not performed. In an example, the second threshold can be less than or equal to 1, and the second threshold is greater than 0. In another example, the second threshold can also be set according to specific needs. In actual application, the second threshold can be configured according to the needs of actual application, which is not limited in the embodiments of the present application.

[0136] For example, the voting event indicates the registration of CA1. The CAs that vote on the voting event include CA2 to CA5. The voting results of CA2, CA3 and CA4 are approval, and the voting result of CA5 is disapproval. The number of CAs that approve the voting event is 3, the first threshold is 2, and 3 is greater than 2, so the final voting result is passed.

[0137] In some embodiments, the first CA can initiate a second request, and the second request is sent to the target node after being signed by the first CA. The second request includes the identity of the voting event and the voting result. The target node can determine the voting event corresponding to the voting result of the first CA according to the identity of the voting event in the second request. The target node authenticates and authorizes the second request based on the signature of the second request, so as to determine whether the first CA has voting authority. If the first CA has voting authority, the voting result in the voting transaction is recorded. If the first CA does not have voting authority, the voting result in the second request is not processed. In this way, all CAs or part of CAs can vote on the first operation, so as to improve the decentralization degree of the DPKI system. Here, the target node is any node in the alliance chain running the DPKI system, such as the first node or the second node.

[0138] In some embodiments, the first CA initiates the second request by initiating a voting transaction. After the target node receives the voting transaction, the voting transaction is consensus with other nodes. Each node parses the voting transaction to obtain the second request. According to the CA signature of the second request, it is determined whether the target CA has voting authority. In the case where it is determined that the target CA has voting authority, whether the first operation is performed is determined after the voting results of all target CAs are counted based on the voting results. In the case where the final voting result of the voting event does not pass, all voting results are consensus in all nodes, so that each node can determine the final voting result and synchronously determine whether to perform the first operation.

[0139] In the embodiments of the present application, the voting event is established based on the first operation.

[0140] In some embodiments, as shown in FIG. 3b, in S301, the following S3011-S3013 can be included.

[0141] S3011, obtaining a first request, the first request being used to indicate a request to perform a first operation.

[0142] The first request is signed by an initiator of the first request, and the first request includes specific content of the first operation requested to be performed, an identity of the initiator involved in the first operation, and the like. For example, CA2 initiates the first request, wherein the first operation of the first request is to register CA1. Then the first request is signed by CA2.

[0143] The voting event is obtained in the case that the first request is authenticated and authorized. For example, after obtaining the first request, the signature of the first request is authenticated and authorized. The CA information list is included in the underlying configuration information of the DPKI system. The signature is authenticated and authorized according to the authority of the CA in the CA information list. For example, it is necessary to determine whether the CA involved in the first operation has the execution authority of the first operation according to the signature of the first request and the authority of the CA in the CA information list. Specifically, the first request carries the public key of the CA, after obtaining the first request, the signature is verified by the public key of the second CA carried by the first request, and whether the second CA has the execution authority of the first operation is determined from the CA information list by the public key of the second CA. In the case that the second CA has the execution authority of the first operation, the authentication and authorization of the first request are passed. For example, CA2 initiates the first request. Wherein the first operation indicated by the first request is to register CA1, and the first request further includes the signature of the first request and the public key of CA2. The signature of CA2 is decrypted by the public key of CA2. Then, according to the authority of CA2 in the CA information list, it is determined whether CA2 has the authority to register CA1. In the case that CA2 has the authority to register CA1, the authentication and authorization of the first request are passed.

[0144] Exemplarily, in the embodiment of the present application, the initiator of the first request can be a second CA. The second CA can initiate the first request in the form of a transaction. Specifically, the second CA initiates a first transaction. The first transaction carries a field of the first request. All nodes in the DPKI need to reach a consensus on the first transaction. Exemplarily, a user accesses the first node through the second CA, and thus sends the first transaction to the first node. The first node reaches a consensus with a second node in the DPKI system on the first transaction. Then, the first node and the second node both analyze the first transaction, and thus obtain the first request. The first node and the second node both authenticate and authorize the first request based on the signature of the second CA, and thus determine whether the second CA has the permission to request to perform the first operation. For example, the CA2 initiates the first transaction, and the first transaction includes the first request. The first operation of the first request is to register the CA1. The first request is signed by the CA2. After the first node and the second node reach a consensus on the first transaction, the first node and the second node analyze the first transaction, and thus obtain the first request. The signature of the first request is authenticated and authorized, and thus it is determined whether the CA2 has the permission to request to register the CA1.

[0145] It should be noted that the alliance chain running the DPKI system includes the first node and at least one second node.

[0146] S3012, a voting event corresponding to the first operation is created.

[0147] Each node in the DPKI system creates a voting event according to the first operation. In some embodiments, the voting event has an association relationship with the first operation. The second request includes the identity of the voting event, so that the target node can determine the voting event corresponding to the voting result according to the identity of the voting event, and thus determine the first operation corresponding to the voting result.

[0148] In some embodiments, in order to facilitate the query of the content of the first operation corresponding to the voting event, it is also necessary to create a corresponding relationship between the voting event and the first operation. Exemplarily, the voting event includes the identity of the voting event, and a one-to-one association relationship between the identity of the voting event and the first operation is established. In this way, the target node can determine the voting event corresponding to the voting result according to the identity of the voting event, and thus determine the first operation corresponding to the voting result.

[0149] S3013, the voting event is transmitted to a plurality of first CAs.

[0150] After the voting event is created, the voting event is transmitted to a plurality of first CAs, so that the first CAs vote on the voting event, and thus obtain the voting results of the plurality of first CAs on the voting event.

[0151] S302, in the case that the final voting result indicates that the voting event is passed, performing the first operation; wherein the first operation comprises registering a CA, unregistering a CA or root certificate updating.

[0152] In the case that the final voting result indicates that the voting event is passed, the first operation is performed. In the case that the final voting result indicates that the voting event is passed, the first operation is not performed.

[0153] Exemplarily, as shown in FIG. 4, a user initiates a target transaction to node 1 through CA1. Node 1, node 2 and node 3 perform consensus on the target transaction. After node 1, node 2 and node 3 perform consensus on the target transaction, the target transaction is parsed, and thus a first request is obtained. The first request is authenticated and authorized through the signature of the first request, so that in the case that the first request authentication and authorization are passed, a voting event corresponding to the first operation is created, and the voting event is sent to the respective corresponding CA. Among them, node 1 sends the voting event to CA1, node 2 sends the voting event to CA2, and node 3 sends the voting event to CA3. CA1, CA2 and CA3 vote on the voting event, thereby generating a voting result. Among them, CA1 sends voting transaction 1 to node 1, CA2 sends voting transaction 2 to node 2, and CA3 sends voting transaction 3 to node 3. Node 1, node 2 and node 3 perform consensus on the voting transaction received by each node. Among them, the second request 1 is included in the voting transaction 1, the second request 1 includes the voting result 1. The second request 2 is included in the voting transaction 2, the second request 2 includes the voting result 2. The second request 3 is included in the voting transaction 3, the second request 3 includes the voting result 3. Node 1, node 2 and node 3 can determine the final voting result according to the voting result 1, the voting result 2 and the voting result 3. For example, the voting result 1 is passed, the voting result 2 is passed, and the voting result 3 is not passed, so the passing rate of the voting event is 2 / 3. Therefore, the final voting result is passed, and the first operation can be performed. The above content is only an exemplary description of the CA consensus method provided by the embodiments of the application, especially the number of nodes, the number of CAs and the communication connection relationship between the nodes and the CAs in FIG. 4. In actual situations, the CA can be in communication connection with multiple nodes, or some nodes are not connected with the CA, or the CA of some nodes has not been registered, but these nodes have joined the DPKI system.

[0154] In some embodiments, in order to improve the processing efficiency of the request, such as improving the processing efficiency of the first request and the second request in the above embodiments, before the nodes reach consensus on the transaction corresponding to the request, the nodes can locally simulate the execution of the authentication and authorization of the request. If the authentication and authorization is passed, the nodes reach consensus on the transaction. After the nodes reach consensus on the transaction, the application layer again authenticates and authorizes the request. If the local simulation of the authentication and authorization of the transaction fails, the request stops execution. In this way, the processing efficiency of the request can be improved.

[0155] Next, the CA consensus method provided by the embodiments of the present application is described in detail with specific examples.

[0156] FIG. 5 is a flowchart of a CA consensus method provided by an embodiment of the present application when the CA is registered. CA registration refers to the CA needing to join the DPKI system. As shown in FIG. 5, the CA consensus method provided by the embodiments of the present application includes the following steps S501-S510.

[0157] S501, in the case where the fourth CA needs to join the DPKI system, the fourth CA generates configuration information required by the DPKI.

[0158] The configuration information required by the DPKI includes the blockchain transaction key of the fourth CA, and the information of the fourth CA, such as the identity of the fourth CA, the authority of the fourth CA, etc.

[0159] In some embodiments, the user of the fourth CA can configure the information of the fourth CA, so that the fourth CA can generate the configuration information required by the DPKI.

[0160] S502, the fourth CA initiates a CA registration transaction to the first node.

[0161] When the fourth CA needs to be registered in the DPKI system, the fourth CA can initiate a CA registration transaction to the first node. The CA registration transaction includes a CA registration request. The CA registration request is used to indicate that the fourth CA wants to be registered in the DPKI system. The CA registration request includes the operation content: registering the fourth CA.

[0162] Here, the fourth CA and the first node do not have an established communication connection. In this case, the fourth CA needs to initiate a CA registration transaction to the DPKI system through other media.

[0163] In one case, the fourth CA has a node managed by the fourth CA, such as the first node can be a node managed by the fourth CA. After the fourth CA generates the configuration information of the DPKI system, the fourth CA can negotiate with a fifth CA in the DPKI system to establish a p2p communication connection between the first node and a second node managed by the fifth CA. In this way, after the fourth CA negotiates with one or more fifth CA in the DPKI system to establish a p2p communication connection between the nodes, the first node can join the DPKI system. In this way, the fourth CA can initiate a CA registration transaction to the first node. For example, the DPKI system includes CA1, CA2 and CA3, and CA4 wants to register to the DPKI system. Among them, CA4 manages node 4, CA1 manages node 1, CA2 manages node 2, and CA3 manages node 3. CA4 negotiates with CA1, CA2 and CA3 to establish a p2p connection between the nodes, so that node 1, node 2 and node 3 are connected to node 4 through p2p connection.

[0164] In another case, the fourth CA does not have a managed node. The fourth CA sends information of the fourth CA to the fifth CA. The fifth CA generates a CA registration request according to the information of the fourth CA, and sends the CA registration request to the second node. Among them, the second node can be a node managed by the fifth CA. For example, the DPKI system includes CA1, CA2 and CA3, and CA4 wants to register to the DPKI system. Among them, CA1 manages node 1, CA2 manages node 2, and CA3 manages node 3. CA4 sends information of CA4 to CA1, and CA1 generates a CA registration transaction according to the information of CA4. Among them, the CA registration transaction includes the information of CA4. CA1 sends the CA registration transaction to node 1.

[0165] Here, the CA registration request in the CA registration transaction includes the information of the fourth CA, such as the identity of the fourth CA, the authority of the fourth CA, and the content of the operation: registering the fourth CA, and the CA registration request is signed by the fourth CA, so that the identity of the fourth CA can be determined, the fourth CA can be authenticated, and whether the fourth CA has the registration authority can be determined.

[0166] S503, the first node and the second node reach consensus on the CA registration transaction.

[0167] S504, the second node authenticates and authorizes the CA registration request.

[0168] After the first node receives the CA registration transaction, the first node can reach consensus with the second node on the CA registration transaction. After the first node and the second node reach consensus on the registration, the first node and the second node can both parse the CA registration transaction to obtain the CA registration request. The first node and the second node can authenticate and authorize the registration request. Specifically, the first node can authenticate and authorize the CA registration request by the signature of the CA registration request, to determine whether the fourth CA has the right to register. Only when the CA registration request authentication and authorization pass, the next step can be performed. For details, refer to the detailed description of S301, which will not be repeated here.

[0169] S505, the second node creates a voting event for registering the fourth CA.

[0170] The voting event includes an identity of the voting event. The identity of the voting event has a one-to-one correspondence with the operation of registering the fourth CA. For details of the implementation of S504, refer to the detailed description of S302, which will not be repeated here.

[0171] S506, the second node sends the voting event to the sixth CA.

[0172] In some embodiments, the second node determines whether the sixth CA has the voting right according to the CA information list. In the case that the sixth CA has the voting right, the voting event is sent to the sixth CA.

[0173] S507, the sixth CA votes on the voting event according to the identity of the voting event.

[0174] Specifically, the sixth CA queries the operation corresponding to the voting event from the second node according to the identity of the voting event, to determine that the operation corresponding to the voting event is to register the fourth CA. The sixth CA determines whether to agree to register the fourth CA according to the pre-configured information.

[0175] The sixth CA generates a voting transaction according to the voting result. The voting transaction includes the voting result and the identity of the voting event, and the voting transaction is signed by the sixth CA. If the sixth CA agrees to register the fourth CA, the voting result is agree, and if the sixth CA does not agree to register the fourth CA, the voting result is disagree.

[0176] S508, the sixth CA sends the second request to the second node.

[0177] S509, the second node determines whether to register the fourth CA according to the second request.

[0178] Specifically, the sixth CA can initiate a voting transaction to the second node. After the second node receives the voting transaction, the voting transaction is consensus with other nodes in the consortium chain. Each node in the DPKI system parses the voting transaction, thereby obtaining a second request. According to the signature of the second request, the second request is authenticated and authorized, thereby determining whether the sixth CA has voting rights. In the case where the second request authentication and authorization pass, the second node records the voting result. If the second request authentication and authorization does not pass, the second node does not process the second request. The second node determines the final voting result according to the second request of the plurality of CAs, thereby determining whether to register the fourth CA.

[0179] S510, in the case where the second node registers the fourth CA, the second node records the state of the fourth CA as registered.

[0180] The state of the fourth CA is registered, the fourth CA joins the DPKI system, and thus the second node can write the information of the fourth CA into the CA information list and the authoritative CA list.

[0181] Here, in order to clearly describe the scheme, only the second node is taken as an example to illustrate, in the above process, the actions performed by the second node also need to be performed by other nodes in the DPKI system according to the same principle, including the first node, so that all nodes in the DPKI system can consensus on the CA registration transaction and the voting transaction of the sixth CA.

[0182] According to the embodiment of the application, when the CA needs to be registered, the CA registration operation is voted by multiple CAs, without excessive dependence on the central CA, and the CA registration can be determined by multiple CAs, which improves the decentralization degree of the DPKI system, and further improves the security of the DPKI system.

[0183] FIG. 6 is a flow diagram of a CA consensus method when a CA is deregistered according to an embodiment of the application. As shown in FIG. 6, the CA consensus method when a CA is deregistered according to an embodiment of the application includes the following steps S601-S608.

[0184] S601, the fourth CA sends a CA deregistration transaction about the fifth CA to the first node.

[0185] When the fourth CA decides to revoke the fifth CA, the fourth CA obtains the information of the fifth CA, such as the identity of the fifth CA, from the CA information list in the first node. According to the information of the fifth CA, the CA revocation transaction is generated. The CA revocation transaction includes the identity of the fifth CA and the revocation reason. For example, when the CA has an operation that threatens the security of the DPKI system, the CA needs to be revoked, and the revocation reason is that the CA has an improper operation that threatens the security of the DPKI system. The CA revocation transaction is used to indicate the revocation of the fifth CA, and the operation included in the CA revocation transaction is to revoke the fifth CA.

[0186] In the embodiments of the present application, the CA revocation transaction is signed by the fourth CA.

[0187] S602, the first node and the second node reach consensus on the CA revocation transaction.

[0188] After the first node receives the CA revocation transaction, the first node and the second node can reach consensus on the CA revocation transaction. Specifically, the first node synchronizes the CA revocation transaction to the second node. In this way, the first node and the second node reach consensus on the CA revocation transaction.

[0189] S603, the second node authenticates and authorizes the CA revocation transaction.

[0190] After the second node receives the CA revocation transaction, the second node parses the CA revocation transaction to obtain the CA revocation request in the CA revocation transaction. According to the signature of the CA revocation request, the CA revocation request is authenticated and authorized.

[0191] S604, the second node creates a voting event for revoking the fifth CA.

[0192] The voting event includes the identity of the voting event. The identity of the voting event has a one-to-one correspondence with the operation of revoking the fifth CA. In the case that the CA revocation request is successfully authenticated and authorized, the voting event of the operation of revoking the fifth CA is created. The specific implementation of S506 can be referred to the detailed description of S302, which will not be repeated here.

[0193] Here, the fourth CA and the fifth CA are not the same CA. If the fourth CA and the fifth CA are the same CA, the node managed by the fourth CA updates the state of the fourth CA to be revoked, and the revocation of the fourth CA is consensus with other nodes. In addition, the fourth CA and the nodes managed by the fourth CA are removed from the CA information list, the authoritative CA list, the node trust list, the consensus authority list and the like.

[0194] S605, the second node sends the voting event to the sixth CA.

[0195] In some embodiments, the second node determines whether the sixth CA has voting right. In the case that the sixth CA has voting right, the voting event is sent to the sixth CA.

[0196] S606, the sixth CA votes for the voting event according to the identity of the voting event.

[0197] Specifically, the sixth CA queries the second node for the operation corresponding to the voting event according to the identity of the voting event, so as to determine that the operation corresponding to the voting event is deregistering the fifth CA. The sixth CA determines whether to agree with deregistering the fifth CA according to the pre-configured information.

[0198] The sixth CA generates a voting transaction according to the voting result. The voting transaction includes the voting result and the identity of the voting event, and the voting transaction is signed by the sixth CA. If the sixth CA agrees with deregistering the fifth CA, the voting result is agree, and if the sixth CA does not agree with registering the fourth CA, the voting result is disagree.

[0199] S607, the sixth CA sends a second request to the second node.

[0200] S608, the second node determines whether to deregister the fifth CA according to the second request.

[0201] Specifically, the sixth CA can initiate the voting transaction to the second node. The second node and other nodes in the DPKI system consensus the voting transaction. Each node in the DPKI system parses the voting transaction, so as to obtain the second request. According to the signature of the second request, the second request is authenticated and authorized, so as to determine whether the sixth CA has voting right. In the case that the authentication and authorization of the second request are passed, the second node performs the CA deregistration operation. In the case that the authentication and authorization of the voting transaction are not passed, the second node does not process the second request. The second node determines the final voting result according to the second request of the plurality of CAs, so as to determine whether to perform the deregistration of the fifth CA. For details, please refer to the detailed description of S303, which will not be repeated here.

[0202] S609, in the case that the second node deregisters the fifth CA, the second node registers the state of the fifth CA as deregistered.

[0203] The state of the fifth CA is the deregistered state, and the fifth CA and the nodes managed by the fifth CA are removed from the CA information list, the CA authority list, the node trust list, the consensus authority list and the like.

[0204] Here, for the sake of clear description of the scheme, only the second node is taken as an example to describe the actions performed by the second node in the above process, and other nodes in the alliance chain also need to perform the same principle, including the first node, so that all nodes in the DPKI system can reach consensus on the CA revocation transaction and the voting transaction of the sixth CA.

[0205] According to the embodiment of the application, when the CA needs to be revoked, the CA revocation request is voted by multiple CAs, so that the multiple CAs reach consensus on the revocation request. Without excessive dependence on the central CA, the CA revocation can be determined by multiple CAs, which improves the degree of decentralization of the DPKI system, and further improves the security of the DPKI system.

[0206] Based on the same idea as the method embodiment of the application, the CA consensus device is also provided in the embodiment of the application. The CA consensus device includes a plurality of modules, each module is used to perform each step in the CA consensus method provided by the embodiment of the application, and the division of the modules is not limited here. Those skilled in the art can clearly understand that in actual application, each step in the CA consensus method provided by the embodiment of the application can be completed by different modules according to needs, that is, the internal structure of the device is divided into different modules to complete all or part of the functions described above. Each module in the embodiment can be integrated in a processing unit, or each unit can exist physically, or two or more modules can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software function unit. In addition, the specific name of each module is only for easy distinction, and does not limit the protection scope of the application. The specific working process of the module in the device can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here.

[0207] For example, the CA consensus device is used to execute the CA consensus method provided by the embodiment of the application. FIG. 7 is a structural schematic diagram of the consensus device provided by the embodiment of the application. As shown in FIG. 7, the consensus device provided by the embodiment of the application includes:

[0208] The processing module 701 is configured to obtain a final voting result of the voting event based on the voting results of the multiple first CAs.

[0209] The execution module 702 is configured to execute a first operation in a case where the final voting result indicates that the voting event passes.

[0210] The first operation includes registering a CA, revoking a CA, or updating a root certificate.

[0211] According to the scheme, when some operations have an impact on the security of the DPKI system, such as registration of a CA, deregistration of a CA, or root certificate update, the final voting result of the voting event can be obtained through the voting results of multiple CAs in the DPKI system. When the final voting result is passed, the operation is performed. In this way, the central CA does not need to be excessively dependent, and the decentralization degree of the DPKI system is improved through the joint decision of multiple CAs, thereby improving the overall security of the DPKI system.

[0212] In a possible implementation, the voting event is obtained when the first request authentication and authorization are passed, and the voting result is obtained when the second request authentication and authorization are passed.

[0213] The first request is used to indicate a request to create a voting event, and the second request is used to indicate writing of the voting result into a block in a block chain.

[0214] In this way, the requests in the DPKI system are performed when the authentication and authorization are passed, thereby improving the security of the system.

[0215] In a possible implementation, the first request is signed by a second CA that initiates the first request, the second request is signed by the first CA, and the first request and the second request both carry a public key of the CA. The apparatus comprises:

[0216] An authentication and authorization module is configured to authenticate and authorize the first request according to the signature of the second CA, the public key of the CA, and a preconfigured CA information list;

[0217] The authentication and authorization module is further configured to authenticate and authorize the second request according to the signature of the first CA, the public key of the CA, and the preconfigured CA information list.

[0218] The CA information list includes the public key of the CA and the authority of the CA, and the authority of the CA is used to indicate whether the CA has the authority to perform the first operation.

[0219] In this way, the requests in the DPKI system are performed when the authentication and authorization are passed, thereby improving the security of the system.

[0220] In a possible implementation, when the number of votes in favor of the voting result is greater than a first threshold, the final voting result is that the voting event is passed, and the first threshold is pre-set.

[0221] Alternatively, the processing module is configured to obtain the final voting result according to the voting result of each first CA in the multiple first CAs and the voting weight of each first CA.

[0222] In a case where the proportion of the approval in the final voting result is greater than the second threshold, the final voting result is that the voting event is passed, and the voting weight of the first CA and the second threshold are preconfigured.

[0223] In this way, whether to perform some operations can be determined by the center CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0224] In a possible implementation, the apparatus is applied after the initialization of the DPKI system is completed, and the initialization of the DPKI system includes:

[0225] The underlying configuration information of the blockchain is written into the genesis block;

[0226] The configuration information of the node is written into the node;

[0227] The underlying configuration information and the configuration information of the node are obtained based on configuration information of the DPKI system, and the configuration information of the DPKI system is created by a third CA, which is a CA initially registered to the DPKI system.

[0228] In this way, after the initialization of the DPKI system, the CA consensus can be performed, whether to perform some operations can be determined by the center CA, the degree of decentralization of the system is improved, and the overall security of the system is improved.

[0229] In a possible implementation, the underlying configuration information of the blockchain includes a node trust list, a consensus authority list, an authority CA list, a DPKI key code or a hash value; and the DPKI application layer configuration includes a CA information list and a certificate information list.

[0230] The node trust list includes public keys of nodes allowed to access the blockchain.

[0231] The consensus authority list includes public keys used to verify the identity of the node.

[0232] The authority CA list is used to indicate CAs that can vote to determine the governance operation of the blockchain.

[0233] The CA information list includes information of the CA, and the information of the CA includes an identity of the CA, a state, a blockchain transaction key, and a permission of the CA.

[0234] The certificate information list includes certificates issued by each CA and metadata of the certificates.

[0235] The configuration information of the node includes a unique coding ID of the blockchain, a name of the blockchain, and an address of a starting node.

[0236] In this way, after the DPKI system is initialized, the CA consensus can be performed, so as to avoid determining whether to perform some operations through a central CA, improve the decentralization degree of the system, and thus improve the overall security of the system.

[0237] FIG. 8 is a structural schematic diagram of a computing device provided by an embodiment of the present application.

[0238] As shown in FIG. 8, the computing device 800 includes a processor 801, a memory 802, and a communication interface 803.

[0239] The processor 801 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0240] The memory 802 can include a mass storage for data or instructions, thereby providing a storage space that stores the operating system and executable program code of the computing device, which can include but is not limited to: a Windows system (an operating system), a Linux system (an operating system), a HongMeng system (an operating system), etc., without limitation.

[0241] By way of example and not limitation, the memory 802 can include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 802 can include removable or non-removable (or fixed) media. Where appropriate, the memory 802 can be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, the memory 802 is a non-volatile solid-state memory.

[0242] The memory can include read-only memory (ROM), random-access memory (RAM), magnetic disk storage mediums devices, optical storage mediums devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Accordingly, generally, the memory can include one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software that, when executed (by one or more processors), is operable to perform, in conjunction with the other components of the computing device, the operations described with respect to the methods in the present application.

[0243] For example, the computer program can be stored in the memory 802 and implemented by the processor 801. Alternatively, the computer program can be stored in a computer program product separate from the memory 802 and the processor 801, and the computer program product can be a storage medium or a computer program product that transmits computer programs over a network. When the computer program is implemented by the separate computer program product, the computer program can be downloaded from the network and stored in the memory 802, or transmitted to the memory 802 from the computer program product, and then executed by the processor 801. The computer program can be a program of instructions, statements, or lines, which can be executed by one or more processors to implement the steps of the methods described above.

[0244] The communication interface 803 is configured to transceive data, for example, transmitting data processed by the processor 801 to other computing devices, or receiving data transmitted by other computing devices, etc.

[0245] Of course, for simplicity, only some of the components of the computing device 800 related to the present application are shown in FIG. 8, and components such as buses, input / output interfaces, etc. are omitted. In addition, the computing device 800 can include any other appropriate components according to specific application circumstances. In addition, the computing device can be a desktop computer, a notebook, a palm computer, and a cloud server, etc. Those skilled in the art can understand that FIG. 8 is only an example of the computing device 800, and does not constitute a limitation on the computing device, and can include more or fewer components than shown, or combine certain components, or different components, for example, the computing device can also include input devices, output devices, network access devices, buses, etc. For example, the input device can be a microphone array, and can also include, for example, a keyboard, a mouse, etc. For example, the output device can output various information to the outside, and can include, for example, a display, a speaker, a printer, a communication network and a remote output device connected thereto, etc.

[0246] In addition to the above method, apparatus, and computing device, embodiments of the present disclosure can also provide a computer program product including computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods of various embodiments of the present disclosure described in the above “METHOD” section of the specification. Wherein the computer program product can be written in any combination of one or more programming languages including an object-oriented programming language such as Java, C++, etc., and conventional procedural programming languages such as “C” language or similar programming languages. Wherein the computer program code can be in the form of source code, object code, executable code, or some intermediate form. The computer program code can be executed entirely on the user computing device, partially on the user device, as an independent software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0247] In addition, embodiments of the present disclosure can also provide a computer readable storage medium having stored thereon computer program instructions, which when executed by a processor, cause the processor to perform the steps of the display control method according to various embodiments of the present disclosure described in the above “METHOD” section of the specification. The computer readable storage medium can employ any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any combination of the above. More specific examples (a non-exhaustive list) of the readable storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. It should be noted that the computer readable medium contained therein can be appropriately added or reduced according to requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, computer readable media do not include electrical carrier signals and telecommunication signals.

[0248] The method steps in the embodiments of the present application can be implemented by hardware, or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in a random access memory (RAM), a flash memory, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable PROM (EPROM), an electrically EPROM (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to a processor, so that the processor can read information from, and write information to, the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0249] In the above embodiments, all or some of the embodiments can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or some of the embodiments can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed by a computer, all or some of the processes or functions described in the embodiments of the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable apparatus. The computer instructions can be stored in or transmitted by a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center through a wired (such as a coaxial cable, an optical fiber, a digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server, data center, etc. that includes one or more available media sets. The available medium can be a magnetic medium (such as a floppy disk, a hard disk, a magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk (SSD)), etc.

[0250] In the above embodiments, the description of each embodiment has its own focus, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0251] It should be understood that the size of the serial number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the application.

[0252] The above describes the basic principles of the application in combination with specific embodiments, but it should be pointed out that the advantages, advantages, effects and the like mentioned in the application are only examples and not limitations, and these advantages, advantages, effects and the like cannot be considered as the various embodiments of the present disclosure must have. In addition, the specific details of the above disclosure are only for the purpose of example and for the purpose of understanding, and are not limited to the above specific details, and the above details do not limit the present disclosure to be implemented with the above specific details.

[0253] The block diagrams of the devices, apparatuses, equipment, systems involved in the present disclosure are only illustrative examples and are not intended to require or imply the connection, arrangement, configuration shown in the block diagram. As those skilled in the art will recognize, these devices, apparatuses, equipment, systems can be connected, arranged, configured in any manner. Words such as "include", "contain", "have" and the like are open-ended words, which mean "include but not limited to", and can be used interchangeably. The words "or" and "and" used herein mean the word "and / or", and can be used interchangeably unless the context clearly indicates otherwise. The word "such as" used herein means the phrase "such as but not limited to", and can be used interchangeably.

[0254] It should also be noted that in the devices, equipment and methods of the present disclosure, each component or each step can be decomposed and / or recombined. These decompositions and / or recombination should be considered as equivalent solutions of the present disclosure.

[0255] The above description has been given for the purpose of illustration and description. Furthermore, this description is not intended to limit the embodiments of the present disclosure to the forms disclosed herein. Although a number of example aspects and embodiments have been discussed above, those skilled in the art will recognize certain modifications, alterations, changes, additions and sub-combinations thereof.

[0256] It can be understood that the various numerical numbers involved in the embodiments of the present application are only for the purpose of differentiation for the convenience of description, and are not used to limit the scope of the embodiments of the present application.

Claims

1. A method for CA consensus, characterized in that, The method comprises: obtaining a final voting result of a voting event based on voting results of a plurality of first CAs; performing a first operation in a case where the final voting result indicates that the voting event is passed; wherein the first operation comprises registering a CA, unregistering a CA, or updating a root certificate.

2. The method of claim 1, wherein, The voting event is obtained in a case where first request authentication and authorization are passed, and the voting result is obtained in a case where second request authentication and authorization are passed; wherein the first request is used to indicate a request for creating the voting event, and the second request is used to indicate writing a voting result into a block in a blockchain.

3. The method of claim 2, wherein, The first request is signed by a second CA that initiates the first request, and the second request is signed by the first CA, and the first request and the second request both carry a public key of the CA, and the method comprises: authenticating and authorizing the first request according to the signature of the second CA, the public key of the CA, and a pre-configured CA information list; authenticating and authorizing the second request according to the signature of the first CA, the public key of the CA, and the pre-configured CA information list; wherein the CA information list comprises a public key of a CA and a permission of the CA, and the permission of the CA is used to indicate whether the CA has a permission to perform the first operation.

4. The method of any one of claims 1-3, wherein: in a case where the number of votes in favor is greater than a first threshold, the final voting result is that the voting event is passed, and the first threshold is pre-set; or, the method of obtaining a final voting result of a voting event based on voting results of a plurality of first CAs comprises: obtaining the final voting result according to a voting result of each of the plurality of first CAs and a voting weight of the each of the first CAs; wherein in a case where a proportion of votes in favor in the final voting result is greater than a second threshold, the final voting result is that the voting event is passed, and the voting weight of the first CA and the second threshold are pre-configured.

5. The method according to any one of claims 1 to 4, characterized in that, The method is applied after the DPKI system is initialized, and the DPKI system initialization comprises: writing underlying configuration information of a blockchain into a genesis block; writing configuration information of a node into the node; the underlying configuration information and the configuration information of the node are obtained based on configuration information of the DPKI system, the configuration information of the DPKI system is created by a third CA, and the third CA is a CA that is initially registered to the DPKI system.

6. The method of claim 5, wherein: the underlying configuration information of the blockchain comprises a node trust list, a consensus authority list, an authority CA list, a DPKI key code, or a hash value; and the DPKI application layer configuration comprises a CA information list and a certificate information list; the node trust list comprises public keys of nodes allowed to access the blockchain; the consensus authority list comprises public keys used to verify node identities; the authority CA list is used to indicate CAs that can vote to decide blockchain governance operations. The CA information list includes information of the CA, and the information of the CA includes an identity of the CA, a state, a blockchain transaction key, and a permission of the CA; The certificate information list includes certificates issued by each CA and metadata of the certificates; The configuration information of the node includes a unique code ID of the blockchain, a name of the blockchain, and an address of a starting node. 7.A CA consensus device, characterized in that, comprises: The processing module is configured to obtain a final voting result of the voting event based on voting results of the plurality of first CAs; The execution module is configured to perform a first operation in a case where the final voting result indicates that the voting event passes. The first operation includes registering a CA, unregistering a CA, or updating a root certificate.

8. The apparatus of claim 7, wherein, The voting event is obtained in a case where first request authentication and authorization pass, and the voting result is obtained in a case where second request authentication and authorization pass. The first request is signed by a second CA that initiates the first request, and the second request is signed by the first CA. The first request and the second request both carry a public key of the CA. The apparatus comprises:

9. The apparatus of claim 8, wherein, The authentication and authorization module is configured to authenticate and authorize the first request based on the signature of the second CA, the public key of the CA, and a preconfigured CA information list. The authentication and authorization module is further configured to authenticate and authorize the second request based on the signature of the first CA, the public key of the CA, and the preconfigured CA information list. The CA information list includes the public key of the CA and the permission of the CA, and the permission of the CA is used to indicate whether the CA has the permission to perform the first operation.

10. The apparatus of any one of claims 7-9, wherein In a case where the number of approvals in the voting result is greater than a first threshold, the final voting result indicates that the voting event passes, and the first threshold is preconfigured. Or, the processing module is configured to obtain the final voting result based on a voting result of each first CA in the plurality of first CAs and a voting weight of the each first CA. In a case where a proportion of approvals in the final voting result is greater than a second threshold, the final voting result indicates that the voting event passes, and the voting weight of the first CA and the second threshold are preconfigured. The apparatus is applied after the initialization of a DPKI system is completed, and the initialization of the DPKI system includes:

11. The device according to any of claims 7-10, characterized in that writing underlying configuration information of the blockchain into a genesis block; writing configuration information of a node into the node; The underlying configuration information and the configuration information of the node are obtained based on configuration information of the DPKI system, the configuration information of the DPKI system is created by a third CA, and the third CA is a CA that is initially registered to the DPKI system.

12. The apparatus of claim 11, wherein ​ The underlying configuration information of the blockchain includes a node trust list, a consensus authority list, an authority CA list, a key code or hash value of a DPKI; the DPKI application layer configuration includes a CA information list and a certificate information list; The node trust list includes public keys of nodes allowed to access the blockchain; The consensus authority list includes public keys used to verify node identities; The authority CA list is used to indicate CAs capable of voting to decide blockchain governance operations; The CA information list includes information of CAs, which includes an identity, a status, a blockchain transaction key, and a permission of the CA; The certificate information list includes certificates issued by each CA and metadata of the certificates; The configuration information of the node includes a unique coding ID of the blockchain, a name of the blockchain, and an address of a starting node.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-6.

14. A node, characterized by A device includes a memory and a processor, the memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-6.

15. A computer program product comprising instructions, characterized in that, The instructions, when executed on a computer, cause the computer to perform the method of any one of claims 1-6.

Images