CN118300801A

CN118300801A - Certificate management method, system and related device based on block chain

Info

Publication number: CN118300801A
Application number: CN202211681502.6A
Authority: CN
Inventors: 代文昊; 孟嘉霖; 薛腾飞; 杜明晓
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2022-12-27
Filing date: 2022-12-27
Publication date: 2024-07-05

Abstract

The application provides a certificate management method, a system and a related device based on a blockchain, wherein the method can comprise the following steps: receiving first request information from a service node through a block link, wherein the block chain is used for endorsing management of a digital certificate, the block chain comprises a child node for providing block chain service, the service node is a node newly joining the block chain service, and the first request information is used for requesting to join the digital certificate required by the block chain service; and generating a digital certificate for the service node according to the mode of the threshold group signature. The application can endorse the management of the digital certificate through the blockchain, is convenient for tracing the digital certificate, and can ensure the reliability of the digital certificate.

Description

Certificate management method, system and related device based on block chain

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a blockchain-based certificate management method, system, and related devices.

Background

A public key infrastructure (public key infrastructure, PKI) serves as an internet security infrastructure that provides security services for authentication in a number of ways. The PKI includes a certificate authority (CERTIFICATE AUTHORITY, CA), which is the issuing authority of certificates, and is the core of the PKI. Certificate issuance, certificate renewal, certificate revocation, etc. are performed by the CA and are responsible for regularly issuing expired certificates into a certificate revocation list (CERTIFICATE REVOCATION LIST, CRL). The CA issues a digital certificate for each node using the public key, which is not falsified and tampered with.

The blockchain service (blockchain AS A SERVICE, baaS) manages multiple blockchains as a blockchain unified access service, and when a new service node or user needs to join the blockchain service BaaS, the blockchain service BaaS as a root CA issues digital certificates to the service node, and the blockchain service BaaS manages digital certificates of the service nodes or users joining the blockchain service BaaS.

Because the blockchain service BaaS is opaque to the management of the digital certificate, no record is made of the operation of the digital certificate, so that the digital certificate is not traceable, and the reliability of the digital certificate cannot be ensured.

Disclosure of Invention

The embodiment of the application provides a certificate management method, a system and a related device based on a blockchain, which can endorse the management of a digital certificate through the blockchain, is convenient for tracing the digital certificate and can ensure the reliability of the digital certificate.

In a first aspect, an embodiment of the present application provides a blockchain-based certificate management method, including: receiving first request information from a service node through a block link, wherein the block chain is used for endorsing management of a digital certificate, the block chain comprises a child node for providing block chain service, the service node is a node newly joining the block chain service, and the first request information is used for requesting to join the digital certificate required by the block chain service;

and generating the digital certificate for the service node according to the mode of the threshold group signature.

It can be seen that the blockchain certificate management is performed at the blockchain service layer, the digital certificates of the service nodes accessed to the blockchain service are uniformly managed by the blockchain, the management of the digital certificates is endorsed by the blockchain, and the digital certificates are recorded on the blockchain, so that the compliance uniformity of the digital certificate management can be ensured.

In a possible implementation manner of the first aspect, before the receiving, by the block link, the first request information from the service node, the method further includes: and storing a private key of the certificate authority CA certificate through the blockchain.

It can be seen that the blockchain is a private key for decentralizing storage of CA certificates, so that the storage security of the private key can be improved.

In a possible implementation manner of the first aspect, the storing, by the blockchain, a private key of a certificate authority CA certificate includes:

Dividing the private key of the CA certificate into a plurality of sub-private keys in a secret sharing mode;

And storing each sub private key in the plurality of sub private keys into different sub nodes in the blockchain respectively.

It can be seen that the private key of the CA certificate can be stored on each subnode in a secret sharing manner, the subprivate keys held by more than or equal to t participants can reconstruct the private key, and the subprivate keys held by less than t participants cannot reconstruct the private key and cannot obtain any information of the private key, so that the trusted storage of the private key is ensured.

In a possible implementation manner of the first aspect, the generating the digital certificate for the service node according to the threshold group signature includes:

acquiring a sub signature of the sub node, wherein the sub signature is determined according to the sub private key;

Generating a threshold group signature according to the sub-signature of the sub-node;

And generating the digital certificate for the service node according to the threshold group signature.

It can be seen that the threshold group signature system requires that the signer cannot calculate any legal sub-private key of the signature private key from part of the signature, and cannot calculate the signature private key from less than t sub-private keys, so as to prevent the signature synthesizer from stealing the member sub-private keys and collusion of other members to implement deceptive signature.

In a possible implementation manner of the first aspect, the method further includes:

Receiving second request information from the first child node, wherein the second request information is used for requesting to join the blockchain;

And determining the child private key of the first child node based on the child private key of the child node on the blockchain according to the second request information.

It can be seen that the private key stored in the blockchain can be dynamically and extendably shared, and the normal and reliable operation of the blockchain can be ensured when the child node dynamically joins the block.

In a possible implementation manner of the first aspect, the determining, according to the second request information, the child private key of the first child node based on the child private key of the child node on the blockchain includes:

determining a target child node in the blockchain according to the second request information;

The shared sub-private key of the target sub-node is obtained, and the shared sub-private key is determined by the target sub-node according to the sub-private key;

and determining the sub-private key of the first sub-node according to the shared sub-private key of the target sub-node.

It can be seen that the private key stored in the blockchain can be dynamically expanded according to the increase of the child nodes on the blockchain, so that any child node in the blockchain is ensured not to store the private key of the CA certificate in the intermediate state, and the trusted storage of the private key is ensured.

and under the condition that any child node in the blockchain is about to exit the blockchain, updating the child private keys of other child nodes in the blockchain.

It can be seen that when the child nodes in the blockchain dynamically exit, the child private keys of other child nodes in the blockchain can be updated by adjusting the threshold value, so that any child node can be guaranteed not to store the child private key in the intermediate state, and the trusted storage of the child private key is guaranteed.

In a possible implementation manner of the first aspect, the management of the digital certificate includes one or more of the following: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

It can be seen that the related operations (such as issuing, cancelling, transferring, cancellation, freezing, etc.) of the certificate management in the blockchain are recorded and are transparent in the whole disclosure, the child nodes on the blockchain can check the detailed information, and the record is not tamperable and not repudiatable, so that the reliability and traceability of the certificate management are ensured.

In a second aspect, embodiments of the present application provide a blockchain-based certificate management system that may include a management node, a service node, and a child node in a blockchain, wherein;

The service node is configured to send first request information to a child node that provides a blockchain service in the blockchain, where the blockchain is configured to endorse management of a digital certificate, the service node is a node that newly joins the blockchain service, and the first request information is configured to request to join the digital certificate required by the blockchain service;

the management node is used for receiving first request information from the service node through the block link,

The management node is further configured to generate the digital certificate for the service node according to a threshold group signature manner.

In a possible implementation manner of the second aspect, the management node is further configured to store, by the blockchain, a private key of a CA certificate.

In a possible implementation manner of the second aspect, the management node is specifically configured to divide a private key of the CA certificate into a plurality of sub-private keys by means of secret sharing;

The management node is specifically configured to store each of the plurality of sub-private keys to a different sub-node in the blockchain.

In a possible implementation manner of the second aspect, the child node is configured to determine a child signature according to the stored child private key;

The management node is specifically configured to generate a threshold group signature according to the sub-signature of the sub-node;

the management node is further specifically configured to generate the digital certificate for the service node according to the threshold group signature.

In a possible implementation manner of the second aspect, the system further includes a first sub-node,

The first child node is configured to send second request information to the management node, where the second request information is used to request to join the blockchain;

the management node is specifically configured to determine a child private key of the first child node based on the child private keys of the child nodes in the blockchain.

In a possible implementation manner of the second aspect, the management node is specifically configured to determine a target child node from child nodes in the blockchain according to the second request information;

The target child node is used for calculating a shared child private key according to the child private key stored in the target child node;

The target child node is further configured to send the shared child private key to the first child node;

the first sub-node is configured to generate a sub-private key of the first sub-node according to the shared sub-private key.

In a possible implementation manner of the second aspect, the management node is further configured to: and under the condition that any one of different child nodes in the blockchain is about to exit the blockchain, updating the child private keys of other child nodes in the blockchain.

In one possible implementation manner of the second aspect, the management of the digital certificate includes one or more of the following: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

In a third aspect, embodiments of the present application provide a computing device comprising a communication module and a processing module, the computing device being configured to implement the method described in any of the first aspects.

In a possible implementation manner of the third aspect, the communication module is configured to receive, through a blockchain, first request information from a service node, where the blockchain is used to endorse management of a digital certificate, the blockchain includes a child node that provides a blockchain service, the service node is a node that newly joins the blockchain service, and the first request information is used to request to join the digital certificate required by the blockchain service;

The processing module is used for generating the digital certificate for the service node according to the mode of the threshold group signature.

In a possible implementation manner of the third aspect, the communication module is further configured to:

And storing a private key of the certificate authority CA certificate through the blockchain.

In a possible implementation manner of the third aspect, the communication module is specifically configured to:

In a possible implementation manner of the third aspect, the processing unit is specifically configured to:

In a possible implementation manner of the third aspect, the communication module is further configured to receive second request information from the first child node, where the second request information is used to request to join the blockchain;

The processing module is further configured to determine a child private key of the first child node based on a child private key of a child node on the blockchain according to the second request information.

In a possible implementation manner of the third aspect, the processing module is specifically configured to:

In a possible implementation manner of the third aspect, the processing module is further configured to:

In one possible implementation manner of the third aspect, the management of the digital certificate includes one or more of: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

In a fourth aspect, embodiments of the present application provide a computing device comprising a processor and a memory; the processor is configured to execute instructions stored in the memory to cause the computing device to implement the method described in any one of the preceding first aspects.

Optionally, the computing device further comprises a communication interface for receiving and/or transmitting data, and/or for providing input and/or output to the processor.

The above embodiment is described taking a processor (or general-purpose processor) for executing a method by calling a computer specification as an example. In particular implementations, the processor may also be a special purpose processor in which the computer instructions are already preloaded in the processor. In the alternative, the processor may include both a special purpose processor and a general purpose processor.

In the alternative, the processor and memory may be integrated in one device, i.e., the processor and memory may be integrated.

In a fifth aspect, embodiments of the present application further provide a computing device cluster comprising at least one computing device, each computing device including a processor and a memory;

the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method of any one of the first aspects.

In a sixth aspect, embodiments of the present application provide a computer readable storage medium having instructions stored therein which, when executed on at least one processor, implement a method as described in any of the preceding aspects.

In a seventh aspect, the present application provides a computer program product comprising computer instructions which, when run on at least one processor, implement a method as described in any of the preceding first aspects.

Alternatively, the computer program product may be a software installation package or a mirror package, which may be downloaded and executed on a computing device in case the aforementioned method is required.

The advantages of the technical solutions provided in the second to seventh aspects of the present application may refer to the advantages of the technical solutions in the first aspect, and are not described herein.

Drawings

The drawings to which the present application is applied are described below.

FIG. 1 is a schematic diagram of certificate management provided by an embodiment of the present application;

FIG. 2A is a schematic diagram of a block chain based certificate management system according to an embodiment of the present application;

FIG. 2B is a schematic diagram of another architecture of a blockchain-based digital certificate management system in accordance with embodiments of the present application;

FIG. 3 is a flow chart of one possible blockchain-based certificate management method provided by an embodiment of the present application;

Fig. 4 is a schematic view of a scenario for applying a digital certificate according to an embodiment of the present application;

FIG. 5 is a flowchart illustrating a possible blockchain-based certificate management method according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a computing device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of a computing device according to an embodiment of the present application.

Detailed Description

Embodiments of the present application will be described in detail below with reference to the accompanying drawings.

For ease of understanding, the following description of some of the concepts related to the embodiments of the application are given by way of example for reference. The following is shown:

1. blockchain (BC) technology can be understood as a tamper-resistant, off-centered ledger. Blockchain technology is a distributed infrastructure and computing paradigm that utilizes a block chain data structure to validate and store data, distributed nodes to generate and update data through consensus algorithms, cryptography to preserve security of data transmission and access, and intelligent contracts composed of automated script code to program and manipulate data.

The blockchain mainly includes:

Transaction (transaction): an operation, such as adding a record, that causes a change in the state of the ledger;

block (block): recording transaction and state results occurring within a period of time, wherein the transaction and state results are a consensus of the current account book state;

Chain (chain): the system is formed by serially connecting blocks according to the occurrence sequence, and is used for logging the whole state change.

If the blockchain is used as a state machine, each transaction is an attempt to change state, and each consensus generates a block, i.e., the participant confirms the result of the state change for all the transaction contents in the block.

2. The public key infrastructure (public key infrastructure, PKI), which is an internet security infrastructure, is a set of infrastructure consisting of hardware, software, participants, management policies and procedures, with the purpose of creating, managing, distributing, using, storing and revoked digital certificates. The essence is to standardize asymmetric key management and the mapping relationship between identity and public key.

The PKI comprises a certificate authority (CERTIFICATE AUTHORITY, CA) which performs operations such as certificate issuing, certificate updating and certificate revocation, and periodically issues an expired certificate to a certificate revocation list (CERTIFICATE REVOCATION LIST, CRL). The CA signs a certificate for a certificate applicant through a private key of the CA, and provides a trusted digital identity, so that the authentication identity of a user in the communication process is ensured, and the confidentiality and the integrity of transmission information are protected. Wherein. Certificates issued by CAs are not counterfeitable and tamperable.

3. The digital certificate is a digital certificate for marking the identity information of each party in the internet communication, and can identify the identity of the other party through the digital certificate.

The basic architecture of digital certificates is the public key PKI, i.e. encryption and decryption is performed using a pair of keys. The secret key comprises a private key and a public key, wherein the private key is mainly used for signing and decrypting; the public key is used for signature verification and encryption.

Digital certificates come in many formats, mainly X.509v3 (1997), X509v4 (1997), X.509v1 (1988), etc.

4. Block chain service (blockchain AS A SERVICE)

BaaS is a service platform for deep combination of blockchain and cloud computing, which aims to help users to quickly deploy blockchains and visually manage and operate services on the chains through one key.

The BaaS platform can make the process of blockchain application development and deployment simple and efficient by converting computing resources, communication resources, storage resources, blockchain billing capabilities, blockchain application development capabilities, blockchain companion facility capabilities, and the like into programmable interfaces.

5. The secret sharing is realized by splitting the secret in a proper mode, each split share is managed by different participants, a single participant cannot recover secret information, and only a plurality of participants cooperate together to recover the secret. For example, dividing the secret s into n parts, each part being referred to as a sub-secret and held by one holder, a sub-secret held by greater than or equal to t participants may reconstruct the secret s, while a sub-secret held by less than t participants cannot reconstruct the secret and cannot obtain any information of the secret s.

6. The threshold group signature is the product of combining the constitution of the digital signature with the threshold secret sharing scheme. An organization or group oriented digital signature system can solve the problem of how to digitally sign by a group or individual. The basic idea is that the (t, n) threshold scheme is used to divide the signed key into n keys which are respectively and secretly distributed to n sharing members in the authorized set, when a certain file needs to be signed in group, the t sharing members respectively use their subkeys to calculate the partial signature of the file, and the signature synthesizer calculates the threshold group signature of the file according to the t partial signatures.

However, the threshold group signature system requires that the signature composer cannot calculate any legal subkeys of the signature key from the partial signature, and cannot calculate the signature key from less than t subkeys, so as to prevent the signature composer from stealing member subkeys and other members to collude to implement fraudulent signatures.

Referring to fig. 1, fig. 1 is a schematic diagram of certificate management according to an embodiment of the present application. In the PKI architecture, digital certificates are issued by a certificate authority CA for blockchains (e.g., a first blockchain, a second blockchain, and a third blockchain). Further, as can be seen from fig. 1, in order to implement certificate management at the blockchain service level, the blockchain service BaaS is used as a root CA in the entire PKI architecture, the blockchain service BaaS keeps the CA private key itself, the blockchain service BaaS issues certificates for CA1, CA2 and CA3, and the CA1, CA2 and CA3 issue digital certificates for blockchain 1, blockchain 2 and blockchain 3, respectively. When a new blockchain node (not shown in FIG. 1) needs to access the blockchain service, the blockchain service acts as a root CA to issue the certificate of the blockchain CA to the newly accessed blockchain. Thus, the blockchain service acts as a root CA for managing certificates of nodes or users in the blockchain.

However, the blockchain service as a root CA to manage certificates has the following problems in practical applications: the root CA private key stored by the blockchain service is stored in a centralized mode, once an attacker takes the private key of the root CA, the blockchain CA can be randomly issued, and certificates issued by the root CA and the root CA are not trusted any more; the certificate management is opaque, has no record on the certificate operation of the blockchain CA, and is not traceable and auditable; without a unified certificate management hierarchy, there are tens of millions of blockchains or blockchain upper layer applications in a blockchain service that are confusing with the CA certificate management hierarchy of the upper layer applications.

In order to solve the above problems, the embodiments of the present application provide a method, a system, and related devices for managing certificates based on blockchain. And receiving first request information from a service node through a block link, wherein the block chain is used for endorsing management of the digital certificate, the block chain comprises a child node for providing the block chain service, the service node is a node newly joining the block chain service, and the first request information is used for requesting the digital certificate required by joining the block chain service. And then, generating a digital certificate for the service node according to the mode of the threshold group signature. Because the blockchain is used for endorsing the management of the digital certificate, the information of the digital certificate and the whole management process can be recorded and uplink, so that the transparency, traceability and audit of the public of the certificate management can be ensured.

The system architecture of an embodiment of the present application is exemplarily described below. It should be noted that, the system architecture described in the present application is for more clearly describing the technical solution of the present application, and does not constitute a limitation to the technical solution provided by the present application, and those skilled in the art can know that, as the system architecture evolves and new service scenarios appear, the technical solution provided by the present application is applicable to similar technical problems.

Referring to fig. 2A, fig. 2A is a schematic architecture diagram of a blockchain-based certificate management system according to an embodiment of the present application. Certificate management system 200 includes a service node 201, a management node 202, and a plurality of child nodes in blockchain 203. Wherein,

The service node 201 joins the blockchain service as a new blockchain. The service node may be a mobile phone, an intelligent terminal, a vehicle-mounted terminal, an unmanned plane, a wearable device, a multimedia device, a streaming media device, etc. In one possible implementation, the service node 201 is configured to send first request information to a child node in the blockchain 203 that provides blockchain services. The blockchain 203 is used for endorsing management of digital certificates, and the first request information is used for requesting the digital certificates required for joining the blockchain service.

Management node 202 is a device with computing and communication capabilities that is a device that assumes the functionality of interacting with blockchain 203 and maintaining blockchain 203. The management node may be a server or the like in particular, by way of example. In one possible implementation, the management node 202 may receive the first request information from the service node 201 through the blockchain 203 and generate a digital certificate for the service node 201 according to a threshold group signature manner.

Blockchain 203 is a management chain constructed for management node 202 for managing digital certificates. The blockchain 203 includes a plurality of children nodes thereon, and the blockchain service is added to the blockchain 203 as children nodes.

In one possible implementation, the management node 202 stores the private key of the certificate authority CA certificate through the blockchain 203, and further, the management node 202 fragments the private key of the CA certificate into all nodes in the blockchain 203 for storage in a secret sharing manner. That is, the management node 202 divides the private key of the CA certificate into a plurality of subprivate keys, and stores each of the plurality of subprivate keys into a different subnode in the blockchain, respectively. Thus, the private key of the CA certificate is stored in a decentralization way, and the trusted storage of the private key of the CA certificate is ensured.

In one possible implementation, a child node in blockchain 203 may determine a child signature from its own stored child private key. The management node 202 may generate a threshold group signature from the child signatures of the child nodes, and finally generate a digital certificate for the service node from the threshold group signature.

In another possible implementation, the certificate management system 200 may further include a first child node 204, where the first child node 204 is configured to send second request information to the management node, where the second request information is configured to request to join the blockchain.

Thus, the management node 202 may determine the child private key of the first child node based on the child private keys of the child nodes in the blockchain. Further, the management node 202 may specifically determine a target child node from the child nodes in the blockchain 203 according to the second request information. The target child node (not shown in fig. 2A) may calculate a shared child private key from the child private key stored in itself and send the shared child private key to the first child node. The number of target child nodes may be 1 or more. When the first child node receives the shared child private key from the target child node, the first child node may generate its own child private key according to the shared child private key.

In one possible design, the management of digital certificates includes one or more of the following: issuing a digital certificate, revoking a digital certificate, freezing a digital certificate, etc. Illustratively, when a service node joins a blockchain service, a digital certificate is issued for the service node; when the service node exits the blockchain service, the digital certificate issued for the service node is revoked or frozen. Operations such as issuing, canceling or freezing the digital certificate can be recorded on the blockchain, so that the transparency, traceability and auditability of the certificate management can be ensured.

Referring to fig. 2B, fig. 2B is a schematic architecture diagram of another blockchain-based digital certificate management system according to an embodiment of the present application. In one possible implementation, the digital certificate management system 300 shown in FIG. 2B is a PKI architecture-based system, with nodes in the PKI architecture including a root CA, a multi-level leaf CA, and an underlying service node. The root CA is responsible for issuing a digital certificate to itself and the next-layer CA, the next-layer CA issues a digital certificate to the next-layer CA, and the last-layer CA issues a digital certificate to the service node.

As can be seen from FIG. 2B, the blockchain service is a child node in blockchain 203, and multiple child nodes in blockchain 203 may together constitute a root CA. Each child node in the blockchain 203 may issue a digital certificate for a next layer of leaf CAs (e.g., a first CA, a second CA, and a third CA), the first CA issues a digital certificate for a service node corresponding to the first blockchain, the second CA issues a digital certificate for a service node corresponding to the second blockchain, and the third CA issues a digital certificate for a service node corresponding to the third blockchain.

When a new service node needs to access the blockchain service, a digital certificate can be issued for the new service node through each child node in the blockchain 203. Further, each node in blockchain 203 may issue a digital certificate for the next layer of leaf CAs, and the last layer of leaf CAs issues a digital certificate for the new service node.

It should be noted that, the management node, the service node, and the child nodes in the blockchain shown in fig. 2A or fig. 2B may be implemented by software, or may be implemented by hardware. Illustratively, an implementation of the management node is described next. Similarly, the implementation of the service node and the child nodes in the blockchain may refer to the implementation of the management node.

Modules as an example of a software functional unit, a management node may include code that runs on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the management node may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising one data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.

Also, multiple hosts/virtual machines/containers for running the code may be distributed in the same virtual private cloud (virtual private cloud, VPC) or may be distributed in multiple VPCs. In general, one VPC is disposed in one region, and a communication gateway is disposed in each VPC for implementing inter-connection between VPCs in the same region and between VPCs in different regions.

Modules as an example of hardware functional units, a management node may include at least one computing device, such as a server or the like. Or the management node may be a device implemented using an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or the like. The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA) GATE ARRAY, a general-purpose array logic (GENERIC ARRAY logic, GAL), or any combination thereof.

Multiple computing devices included in a management node may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the management node may be distributed in the same AZ or may be distributed in different AZ. Likewise, multiple computing devices included in a management node may be distributed in the same VPC or may be distributed among multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.

The following describes the process flow of the embodiment of the present application in detail with reference to the accompanying drawings. Referring to fig. 3, fig. 3 is a flowchart of a possible blockchain-based certificate management method according to an embodiment of the present application. Alternatively, the certificate management method may be applied to the foregoing embodiments, such as the embodiments shown in fig. 2A or fig. 2B.

The above-described blockchain-based certificate management method includes one or more steps of step S301 to step S303. It should be understood that the present application is described by the order of S301 to S303 for convenience of description, and is not intended to be limited to being necessarily performed by the above order. The embodiment of the application is not limited to the execution sequence, execution time, execution times and the like of the one or more steps. The steps S301 to S303 are specifically as follows:

in step S301, the service node sends first request information to the blockchain.

In other words, the management node that performs the functions of interacting with and maintaining the blockchain may receive, through the blockchain, first request information from the service node, where the blockchain is used to endorse the management of the digital certificate, the blockchain includes a child node that provides the blockchain service, and the service node is a node that newly joins the blockchain service, and the first request information is used to request the digital certificate required to join the blockchain service.

As one possible design, the certificate application request structure: request=req (cercinfo).

Wherein CertInfo denotes related information of the certificate, and Req denotes a structural encapsulation of the first request information.

For example, referring to fig. 4, fig. 4 is a schematic view of a scenario for applying for a digital certificate according to an embodiment of the present application. As can be seen in fig. 4, when the service node 201 joins the blockchain service BaaS in a blockchain network, a first request message for applying for a digital certificate is sent to the blockchain 203. Thus, a management node (not illustrated in fig. 4) may receive first request information from a service node through a blockchain.

In one possible implementation, the management node may store the private key of the certificate authority CA certificate through the blockchain before the management node receives the first request information from the service node through the blockchain. Thus, the management node, through the blockchain, may be responsible for managing the entire lifecycle of the digital certificate, including issuing the certificate, defining the certificate validity period and revoked certificates, and so forth.

As one possible design, at the time of blockchain initialization, the management node may distribute the private key of the CA certificate into multiple sub-private keys through secret sharing. That is, (t, n) secret sharing is performed on the private key of the CA certificate. Where t is a threshold and n is the number of children in the blockchain.

Illustratively, at the time of blockchain initialization, the management node may randomly select n different non-zero elements x ₁,x₂,…,x_n from the finite field GF (p). Each secret holder, i.e., each child node U _r＝{U₁,U₂,…,U_n in the blockchain (r=1, 2, …, n), holds a corresponding x _r, respectively, where x _r is the unique identity of U _r.

Assuming that the private key required for secret sharing is s e Z _q (where q is denoted as a large prime number), the (t-1) elements a _i (i=1, 2, …, t-1) are arbitrarily selected within the finite field GF (p) to form a (t-1) order polynomial, the expression of which is as follows:

where p is denoted as a large prime number and p > s, q divides p-1 entirely.

Thus, private key s=f (0) =a ₀, the management node can generate its child private key for all child nodes U _r e U in the blockchain. Sub private keyThe management node may then send the child private key s _r to the corresponding child node U _r.

Further, the management node also needs to calculateAnd will beAnd sending the data to a corresponding child node in the blockchain. Wherein,For verifying the correctness of the private key.

In step S302, the management node generates a digital certificate for the service node according to the threshold group signature mode.

In particular, the threshold group signature is a special form of multiple signatures, i.e., t persons of n signers can issue messages on behalf of n signers. Therefore, after the management node acquires the threshold number of sub-signatures, the management node can generate a final signature according to the threshold group signature mode, and the digital certificate can be generated for the service node by the information of the certificate and the final signature. As can be seen from fig. 4, the management node may generate a digital certificate according to a threshold group signature based on a private key stored in the blockchain.

In one possible implementation, the management node may obtain a child signature of a child node in the blockchain, the child node being determined from a child private key. It can be understood that the private key of the CA certificate is divided into n parts of sub-private keys, and each part of sub-private key is correspondingly stored in a sub-node of the blockchain, so that the sub-node in the blockchain can calculate to obtain its own sub-signature according to its own stored sub-private key. The management node may generate a threshold group signature-a final signature based on the sub-signatures of the sub-nodes, and further, the management node may generate the threshold group signature based on a threshold number of sub-signatures. Finally, the management node may generate a digital certificate for the service node according to the threshold group signature.

Illustratively, digital certificates are generated for the service nodes, and the child nodes in the blockchain perform a threshold group signature operation to generate the child signatures. Further, the child nodes participating in the threshold group signature in the blockchain may calculate the partial signature sign _i of the certificate Request from the Request and its own child private key s _i based on a distributed signature algorithm. After receiving at least t sub-signatures, the management node calculates a final signature σ= TSign (sign ₁,sign₂,…,sign_t) according to a sub-signature recovery algorithm. Thus, the digital certificate Cert _ca may be generated for the service node from the relevant information of the certificate in the Request and the final signature σ.

In step S303, the management node issues a digital certificate to the service node.

Specifically, after the management node generates a digital certificate for the service node according to the private key stored in the blockchain, the digital certificate is stored in the blockchain. Thus, the process of generating the digital certificate, as well as information related to the digital certificate, is maintained in the blockchain. Further, the management node may send a digital certificate to the next layer of leaf CA, which issues the digital certificate for the service node. Wherein, the next-layer leaf CA is CA with corresponding relation with service node.

In one possible implementation, the digital certificate contains information including one or more of the following: certificate ID, identification information of the certificate itself; a CA ID of the issuing certificate, identification information of the CA of the issuing certificate; a certificate holder ID, identification information of the certificate holder; a public key of a certificate holder, public key information of the certificate holder, and a digital signature of the message can be verified by using the public key when the message receiver receives the certificate; the period of validity of the certificate, the certificate is valid after exceeding the period of validity; signature of the certificate, the CA issuing the certificate digitally signs the certificate with the private key of the CA.

Some alternatives to the embodiments of the application are further described below. It should be appreciated that the related concepts, operations or logical relationships of the tracks not explained in the following schemes may be described with reference to the corresponding descriptions in the embodiment shown in fig. 3.

In one possible implementation, the management of the digital certificate includes one or more of the following: issuance of digital certificates, revocation of digital certificates, freezing of digital certificates, thawing of digital certificates, rollback of digital certificates, or renewal of digital certificates. It should be noted that, revocation of a digital certificate may refer to an operation of terminating a certificate lifetime of the digital certificate. The freezing of the digital certificate may refer to a temporary freezing of the digital certificate, rather than a permanent revocation. Thawing the digital certificate may refer to revocation of the freeze operation. Rollback of a digital certificate may refer to the revocation of a digital certificate, a misrevocation, a misfreezing, a non-modified certificate operation. An update to a digital certificate may refer to an update to the certificate content of the digital certificate, such as an extension or shortening of the period, etc. The management of the digital certificate can be endorsed by a child node in the blockchain, and the child node can record the digital certificate into the blockchain.

Illustratively, when a digital certificate is frozen, revoked, etc., for a blockchain CA (i.e., the next-tier leaf CA, say the first CA shown in fig. 2B), the blockchain service will initiate a request to the blockchain that manages the certificate, endorsing the transaction by the endorsement node in the blockchain.

In another possible implementation, the management node may perform dynamic secret sharing for the blockchain when a child node in the blockchain dynamically joins or exits, i.e., when there is a new child node to join the blockchain or when any child node in the blockchain is to exit the blockchain, updating the child private keys of other child nodes in the blockchain. That is, the child private key stored in the child node in the blockchain may change with the dynamic joining or exiting of other child nodes, and thus, the child private key of the CA certificate needs to be recalculated.

In yet another possible embodiment, the application is a method for generating a digital certificate for a service node according to a threshold group signature. Thus, when a new child joins the blockchain or when a child exits the blockchain, the number of children in the blockchain will change, so the threshold value in the threshold group signature will be dynamically adjusted based on the number of children and the network state in the blockchain. Therefore, any child node in the blockchain can be guaranteed not to store the private key of the CA certificate in the intermediate state, and the trusted storage of the private key is guaranteed.

In the following, a new child node is taken as an example to join a blockchain, and fig. 5 is a schematic flow chart of a possible blockchain-based certificate management method according to an embodiment of the present application. Alternatively, the certificate management method may be applied to the foregoing embodiments, such as the embodiments shown in fig. 2A or fig. 2B.

The above-described blockchain-based certificate management method includes one or more steps of step S501 to step S503. It should be understood that the present application is described by the order of S501 to S503 for convenience of description, and is not intended to be limited to being necessarily performed by the above order. The embodiment of the application is not limited to the execution sequence, execution time, execution times and the like of the one or more steps. The steps S501 to S503 are specifically as follows:

In step S501, the first child node sends second request information to the management node.

In other words, the management node receives second request information from the first child node, wherein the second request information is for requesting to join in the blockchain.

In step S502, the management node determines a target child node in the blockchain according to the second request information.

Specifically, the first child node may designate a child node in the blockchain to authenticate itself, and thus the second request information carries the target child node in the blockchain designated by the first child node. The management node may determine the target child node in the blockchain based on the second request information to obtain the shared child private key of the target child node. The shared sub-private key is determined by the target sub-node according to the sub-private key.

In step S503, the management node determines the child private key of the first child node according to the shared child private key.

Illustratively, let the set of child nodes participating in the operation be U { U ₁U ₂,…U _t }, each of the target child nodes participating in the operation U _j (j=1, 2, …, t) so that partial sharing of the private key of the CA certificate by the first child node U _i of the newly joined blockchain can be calculated as follows:

Where s _j is the shared child private key of the target child node U _j (j=1, 2,..t) with respect to the private key of the CA certificate, x _i is denoted as the unique ID number of child node i, i.e. the identity of the child node in the blockchain.

L _j(x_i) represents intermediate variables for what each target child node calculates when it takes the value to calculate with the help of t target child nodes.

D _rj is a scrambling factor shared by the nodes U _r,U_j (r, j=1, 2, …, t) (d _rj is a random number over the finite field GF (p)), sign (x) is a sign function, and when x is a positive value, the value of sign (x) is 1; when x is a negative value, the value of sign (x) is-1.

As one possible design, the management node U _i may receive the shared child private key from t target child nodes, so that the management node U _i may calculate polynomial sharing of the private key for the CA certificate.

As another possible design, the first child node U _i may receive the shared child private key from t target child nodes, so that the first child node U _i may calculate its own polynomial share of the private key for the CA certificate.

If the management node determines the sub-private key of the first sub-node according to the shared sub-private key of the target sub-node, the management node needs to send the sub-private key to the first sub-node.

As another possible design, the first child node in the newly joined blockchain may verify the correctness of its child private key by the following equation.

In the case of verification passing, it is stated that the request of the first child node is complete and may be added to the blockchain.

The foregoing details of the method according to the embodiments of the present application and the apparatus according to the embodiments of the present application are provided below.

It should be understood that, in order to implement the functions in the above method embodiments, the multiple devices provided in the embodiments of the present application, for example, a computing device, include a hardware structure, a software unit, or a combination of a hardware structure and a software structure that perform respective functions. Those of skill in the art will readily appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. The skilled person may implement the foregoing method embodiments in different usage scenarios using different device implementations, which should not be considered to be outside the scope of the embodiments of the present application.

The embodiment of the application can divide the functional units of the device. For example, each functional unit may be divided corresponding to each function, or two or more functions may be integrated in one functional unit. The integrated modules may be implemented in hardware or in software functional units. It should be noted that, in the embodiment of the present application, the division of the units is schematic, which is merely a logic function division, and other division manners may be implemented in actual practice.

Referring to fig. 6, fig. 6 is a schematic structural diagram of a computing device 60 according to an embodiment of the application. The computing device 60 may include a communication module 601 and a processing module 602. The computing device 60 is configured to implement the aforementioned blockchain-based credential management method, such as the blockchain-based credential management method in the embodiment shown in fig. 3 or 5.

The communication module 601 is configured to receive, through a blockchain, first request information from a service node, where the blockchain is used to endorse management of a digital certificate, the blockchain includes a child node that provides a blockchain service, the service node is a node that newly joins the blockchain service, and the first request information is used to request to join the digital certificate required by the blockchain service;

the processing module 602 is configured to generate the digital certificate for the service node according to a threshold group signature manner.

Wherein, the communication module 601 and the processing module 602 may be implemented by software, or may be implemented by hardware. Illustratively, the implementation of the communication module 601 is described next using the communication module 601 as an example. Similarly, the implementation of the processing module 602 may refer to the implementation of the communication module 601.

Module as an example of a software functional unit, the communication module 601 may comprise code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container, among others. Further, the above-described computing examples may be one or more. For example, the communication module 601 may include code running on multiple hosts/virtual machines/containers. It should be noted that, multiple hosts/virtual machines/containers for running the code may be distributed in the same region (region), or may be distributed in different regions. Further, multiple hosts/virtual machines/containers for running the code may be distributed in the same availability zone (availability zone, AZ) or may be distributed in different AZs, each AZ comprising one data center or multiple geographically close data centers. Wherein typically a region may comprise a plurality of AZs.

Module as an example of a hardware functional unit, the communication module 601 may include at least one computing device, such as a server or the like. Alternatively, the communication module 601 may be a device or the like implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (programmable logic device, PLD). The PLD may be implemented as a complex program logic device (complex programmable logical device, CPLD), a field-programmable gate array (FPGA) GATE ARRAY, a general-purpose array logic (GENERIC ARRAY logic, GAL), or any combination thereof.

The plurality of computing devices included in the communication module 601 may be distributed in the same region or may be distributed in different regions. The plurality of computing devices included in the communication module 601 may be distributed in the same AZ or may be distributed in different AZ. Likewise, multiple computing devices included in the communication module 601 may be distributed in the same VPC or may be distributed among multiple VPCs. Wherein the plurality of computing devices may be any combination of computing devices such as servers, ASIC, PLD, CPLD, FPGA, and GAL.

In a possible implementation manner, the communication module 601 is further configured to: and storing a private key of the certificate authority CA certificate through the blockchain.

In a possible implementation manner, the communication module 601 is specifically configured to: dividing the private key of the CA certificate into a plurality of sub-private keys in a secret sharing mode; and storing each sub private key in the plurality of sub private keys into different sub nodes in the blockchain respectively.

In a possible implementation manner, the processing module 602 is specifically configured to: acquiring a sub signature of the sub node, wherein the sub signature is determined according to the sub private key; generating a threshold group signature according to the sub-signature of the sub-node; and generating the digital certificate for the service node according to the threshold group signature.

In a possible implementation manner, the communication module 601 is further configured to receive second request information from the first child node, where the second request information is used to request to join the blockchain;

the processing module 602 is further configured to determine a child private key of the first child node based on a child private key of a child node on the blockchain according to the second request information.

In a possible implementation manner, the processing module 602 is specifically configured to: determining a target child node in the blockchain according to the second request information; the shared sub-private key of the target sub-node is obtained, and the shared sub-private key is determined by the target sub-node according to the sub-private key; and determining the sub-private key of the first sub-node according to the shared sub-private key of the target sub-node.

In a possible implementation manner, the processing module 602 is further configured to: and under the condition that any child node in the blockchain is about to exit the blockchain, updating the child private keys of other child nodes in the blockchain.

In one possible implementation, the management of the digital certificate includes one or more of the following: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

Referring to fig. 7, fig. 7 is a schematic structural diagram of a computing device 70 according to an embodiment of the present application. The computing device 70 is a device having computing capabilities, where the device may be an entity such as a controller, processor, server (e.g., rack-mounted server), host, etc., or may be a virtual device such as a virtual machine, container, etc.

As shown in fig. 7, the computing device 70 includes: a processor 702 and a memory 701 optionally include a bus 704, a communication interface 703. Communication between the processor 702 and the memory 701 and the like is via a bus 704. It should be understood that the present application is not limited to the number of processors, memories in computing device 70.

The memory 701 is used to provide storage space in which application data, user data, an operating system, computer programs, and the like may be optionally stored. The memory 701 may include volatile memory (RAM), such as random access memory (random access memory). The memory 701 may also include a nonvolatile memory (non-volatile memory), such as a read-only memory (ROM), a flash memory, a mechanical hard disk (HARD DISK DRIVE, HDD) or a Solid State Disk (SSD), etc.

The processor 702 is a module for performing operations and may include any one or more of a controller (e.g., a memory controller), a central processing unit (central processing unit, CPU), a micro graphics processor (graphics processing unit, GPU), a microprocessor (micro processor, MP), a digital signal processor (DIGITAL SIGNAL processor, DSP), a coprocessor (assisting the central processing unit in performing corresponding processing and applications), an Application Specific Integrated Circuit (ASIC), a micro control unit (Microcontroller Unit, MCU), and the like.

The communication interface 703 is used to provide information input or output to the at least one processor. And/or the communication interface 703 may be used to receive externally transmitted data and/or to transmit data to the outside. The communication interface 703 may be a wired link interface including, for example, an ethernet cable, or may be a wireless link (Wi-Fi, bluetooth, general wireless transmission, other wireless communication technologies, etc.) interface. Optionally, the communication interface 703 may further include a transmitter (e.g., radio frequency transmitter, antenna, etc.) or a receiver, etc. coupled to the interface. Communication interface 703 enables communication between computing device 70 and other devices or communication networks using a transceiver module such as, but not limited to, a network interface card, transceiver, or the like.

Bus 704 may be a peripheral component interconnect standard (PERIPHERAL COMPONENT INTERCONNECT, PCI) bus, or an extended industry standard architecture (extended industry standard architecture, EISA) bus, among others. The buses may be divided into address buses, data buses, control buses, etc. For ease of illustration, only one line is shown in fig. 7, but not only one bus or one type of bus. A bus 704 may include a path that communicates information between various components of the computing device 70 (e.g., memory 701, processor 702, communication interface 703).

In an embodiment of the present application, the memory 701 stores executable program codes, and the processor 702 executes the executable instructions to implement the aforementioned blockchain-based certificate management method, for example, the blockchain-based certificate management method in the embodiment of fig. 3 or fig. 5. That is, the memory 701 has instructions stored thereon for performing a blockchain-based certificate management method.

Embodiments of the present application also provide a computer program product comprising instructions. The computer program product may be software or a program product containing instructions capable of running on a computing device or stored in any useful medium. The computer program product, when executed on at least one computing device, causes the at least one computing device to perform the aforementioned blockchain-based credential management method, such as the blockchain-based credential management method in the embodiments of fig. 3 or 5.

The embodiment of the application also provides a computer readable storage medium. The computer readable storage medium includes instructions for implementing the aforementioned blockchain-based credential management method, such as the blockchain-based credential management method in the embodiment of fig. 3 or 5.

The computer readable storage medium may be any available medium that can be stored by a computing device or a data storage device such as a data center containing one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk), etc.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

Reference to "at least one" in embodiments of the application means one or more, and "a plurality" means two or more. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b, or c may represent: a. b, c, (a and b), (a and c), (b and c), or (a and b and c), wherein a, b, c may be single or plural. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: three cases of A alone, A and B together, and B alone, wherein A, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship.

And, unless otherwise indicated, the use of ordinal numbers such as "first," "second," etc., by embodiments of the present application is used for distinguishing between multiple objects and is not used for limiting a sequence, timing, priority, or importance of the multiple objects. For example, the first container storage management device and the second container storage management device are provided for convenience of description, and are not intended to represent differences in device structures, deployment orders, importance levels, etc. of the first container storage management device and the first container storage management device.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program for instructing relevant hardware, where the program may be stored in a computer readable storage medium, and the storage medium may be a read only memory, a magnetic disk or an optical disk, etc.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present invention, and are not limiting; although the invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; these modifications or substitutions do not depart from the essence of the corresponding technical solutions from the protection scope of the technical solutions of the embodiments of the present invention.

Claims

1. A blockchain-based certificate management method, the method comprising:

Receiving first request information from a service node through a block link, wherein the block chain is used for endorsing management of a digital certificate, the block chain comprises a child node for providing block chain service, the service node is a node newly joining the block chain service, and the first request information is used for requesting to join the digital certificate required by the block chain service;

2. The method of claim 1, wherein prior to receiving the first request information from the service node via the block link, further comprising:

3. The method of claim 2, wherein storing, by the blockchain, a private key of a certificate authority, CA, certificate, comprises:

4. A method according to claim 3, wherein said generating said digital certificate for said service node in accordance with a threshold group signature comprises:

5. The method according to claim 3 or 4, characterized in that the method further comprises:

6. The method of claim 5, wherein the determining the child private key of the first child node based on the child private key of the child node on the blockchain according to the second request information comprises:

7. The method according to any one of claims 3 to 6, further comprising:

8. The method according to any one of claims 1 to 7, wherein the management of digital certificates comprises one or more of: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

9. A blockchain-based certificate management system, the system comprising: a management node, a service node and a child node in a blockchain, wherein;

10. The system of claim 9, wherein the management node is further configured to store a private key of a CA certificate through the blockchain.

11. The system of claim 10, wherein the system further comprises a controller configured to control the controller,

The management node is specifically configured to divide a private key of the CA certificate into a plurality of subprivate keys in a secret sharing manner;

12. The system of claim 11, wherein the system further comprises a controller configured to control the controller,

The child node is used for determining a child signature according to the stored child private key;

13. The system of claim 11 or 12, further comprising a first child node,

14. The system of claim 13, wherein the system further comprises a controller configured to control the controller,

The management node is specifically configured to determine a target child node from child nodes in the blockchain according to the second request information;

15. The system according to any of claims 11 to 14, wherein the management node is further configured to: and under the condition that any one of different child nodes in the blockchain is about to exit the blockchain, updating the child private keys of other child nodes in the blockchain.

16. The system according to any one of claims 9 to 15, wherein the management of digital certificates comprises one or more of: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

17. A computing device, the computing device comprising a communication module and a processing module, comprising:

The communication module is used for receiving first request information from a service node through a block link, wherein the block link is used for endorsing management of a digital certificate, the block link comprises a child node for providing a block chain service, the service node is a node newly joining the block chain service, and the first request information is used for requesting to join the digital certificate required by the block chain service;

18. The apparatus of claim 17, wherein the communication module is further configured to:

19. The apparatus according to claim 18, wherein the communication module is specifically configured to:

20. The apparatus according to claim 19, wherein the processing unit is specifically configured to:

21. The device according to claim 19 or 20, wherein,

The communication module is further configured to receive second request information from the first child node, where the second request information is used to request to join the blockchain;

22. The apparatus according to claim 21, wherein the processing module is specifically configured to:

23. The apparatus of claims 19 to 22, wherein the processing module is further configured to:

24. The apparatus of any of claims 17 to 23, wherein the management of digital certificates comprises one or more of: issuance of digital certificates, revocation of digital certificates, and freezing of digital certificates.

25. A computing device, the computing device comprising a processor and a memory;

The processor is configured to execute instructions stored in the memory to cause the computing device to implement the method of any one of claims 1-8.

26. A computer readable storage medium comprising computer program instructions which, when executed by a computing device, cause the computing device to implement the method of any of claims 1-8.

27. A computer program product containing instructions that, when executed by a computing device, cause the computing device to implement the method of any of claims 1-8.