Certificate issuing method and system, and blockchain node

Abstract

A certificate issuing method based on a blockchain system. A CA contract and a signature contract are deployed in the blockchain system. The method comprises: a blockchain system receiving a first transaction which invokes a CA contract, wherein the first transaction comprises a user certificate issuing request; providing a signature contract with a digest of user certificate content corresponding to the user certificate issuing request, so as to instruct at least t+1 service parties among n service parties to generate a signature; the at least t+1 service parties generating a first signature for the user certificate content; sending to the blockchain system a second transaction which invokes the signature contract, wherein the second transaction comprises a contract account of the CA contract and the first signature; and the blockchain system returning the first signature to the CA contract on the basis of the second transaction, and issuing a user certificate on the basis of the first signature.

Description

Certificate issuance method, system and blockchain node

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on December 29, 2023, with application number 2023118699522 and application name “Certificate Issuance Method, System and Blockchain Node”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of this specification belong to the field of blockchain technology, and in particular, relate to a certificate issuance method, system, and blockchain node. Background Art

[0003] Blockchain is a novel application model for computer technologies, including distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms. In a blockchain system, data blocks are linked sequentially in chronological order to form a chain-like data structure, cryptographically guaranteeing an unalterable and unforgeable distributed ledger. Due to its decentralized, tamper-proof, and autonomous nature, blockchain is gaining increasing attention and application.

[0004] In cryptography, public-key cryptography, also known as asymmetric cryptography, uses a public-private key pair (denoted as PK-SK, where PK stands for public key and SK stands for secret key). This contrasts with cryptography that uses only a private key. Public-key cryptography includes encryption algorithms and digital signature algorithms. Public-private key pairs are the cornerstone of modern cryptographic security. Many applications are based on PK-SK, such as the application-layer encrypted transmission protocol based on HTTPS (Hypertext Transfer Protocol Secure) and blockchain.

[0005] A private key typically represents the identity of the party that possesses it. It can only be held by the owner and cannot be made public, whereas the corresponding public key can be made public. Signing with a private key can indicate the owner's approval of certain information in the digital world. The signed information in a protocol message can also represent the owner's actions. Generally, a single owner possesses a private key. This owner can use their private key to sign a message and send it to another party. Upon receiving the signature, the recipient can verify it using the corresponding public key. If verification is successful, the recipient can confirm that the owner signed the message and that the signed message has not been tampered with.

[0006] Users can obtain a public-private key pair and a CA certificate (digital certificate) from a Certificate Authority (CA). A CA certificate contains the certificate owner's information, public key, validity period, and the CA's signature. A verifier can use the CA's public key to verify the authenticity and integrity of the CA certificate. If verification succeeds, the CA certificate proves the identity of the owner and the matching public key.

[0007] Summary of the Invention

[0008] The purpose of the present invention is to provide a certificate issuance method based on a blockchain system, so that CA certificates can be issued through contracts in the blockchain system, ensuring the correctness of the CA certificates and providing a CA certificate system for the blockchain system.

[0009] A first aspect of this specification provides a certificate issuance method based on a blockchain system, wherein a CA contract and a signature contract are deployed in the blockchain system, the CA contract includes a call to the signature contract, and the contract state of the signature contract stores a signature public key and information of parameters n and t in association with an account of the CA contract, the signature public key being generated by n service parties through a distributed key agreement, and the method comprising:

[0010] The blockchain system receives a first transaction that calls the CA contract, the first transaction including a user certificate issuance request; provides a summary of the user certificate content corresponding to the user certificate issuance request to the signature contract; and instructs at least t+1 of the n service providers to generate a signature corresponding to the signature public key according to the signature contract;

[0011] The at least t+1 service providers generate a first signature for the user certificate content based on the private key shard corresponding to the signature public key; send a second transaction to the blockchain system that calls the signature contract, where the second transaction includes the contract account of the CA contract and the first signature;

[0012] The blockchain system returns the first signature to the CA contract according to the second transaction, and issues a user certificate based on the first signature by executing the CA contract.

[0013] The second aspect of this specification provides a certificate issuance method based on a blockchain system, which is executed by a node in the blockchain system. The blockchain system has a CA contract and a signature contract deployed, the CA contract includes a call to the signature contract, and the contract state of the signature contract stores a signature public key and parameters n and t in association with the account of the CA contract. The signature public key is generated by n service parties through a distributed key agreement. The method includes:

[0014] receiving a first transaction invoking the CA contract, wherein the first transaction includes a user certificate issuance request;

[0015] Providing a summary of the user certificate content corresponding to the user certificate issuance request to the signature contract;

[0016] According to the signature contract, instruct at least t+1 service providers among the n service providers to generate a first signature for the content of the user certificate based on the private key shard corresponding to the signature public key;

[0017] receiving a second transaction that calls the signature contract from the at least t+1 service providers, where the second transaction includes the contract account of the CA contract and the first signature;

[0018] The first signature is returned to the CA contract according to the second transaction, and a user certificate is issued based on the first signature by executing the CA contract.

[0019] The third invention of this specification provides a certificate issuance system, including a blockchain system and multiple service-party devices. A CA contract and a signature contract are deployed in the blockchain system. The CA contract includes a call to the signature contract. The contract state of the signature contract stores a signature public key and parameters n and t in association with the account of the CA contract. The signature public key is generated by n service parties through a distributed key agreement.

[0020] The blockchain system is configured to: receive a first transaction that calls the CA contract, the first transaction including a user certificate issuance request; provide a summary of the user certificate content corresponding to the user certificate issuance request to the signature contract; and, based on the signature contract, instruct a service party device of at least t+1 of the n service parties to generate a signature corresponding to the signature public key;

[0021] The at least t+1 service-side devices are configured to: generate a first signature for the user certificate content based on the private key shard corresponding to the signature public key; and send a second transaction to the blockchain system that calls the signature contract, where the second transaction includes the contract account of the CA contract and the first signature.

[0022] The blockchain system is further configured to: return the first signature to the CA contract according to the second transaction, and issue a user certificate based on the first signature by executing the CA contract.

[0023] A fourth aspect of this specification provides a node of a blockchain system, wherein a CA contract and a signature contract are deployed in the blockchain system, wherein the CA contract includes a call to the signature contract, wherein the contract state of the signature contract stores a signature public key and information of parameters n and t in association with an account of the CA contract, wherein the signature public key is generated by n service parties through a distributed key agreement, and wherein the node includes:

[0024] A receiving unit, configured to receive a first transaction that calls the CA contract, wherein the first transaction includes a user certificate issuance request;

[0025] a providing unit, configured to provide a summary of the user certificate content corresponding to the user certificate issuance request to the signature contract;

[0026] a signing unit, configured to instruct at least t+1 service providers among the n service providers to generate a first signature on the content of the user certificate based on a private key fragment corresponding to the signature public key according to the signature contract;

[0027] The receiving unit is further configured to receive, from the at least t+1 service providers, a second transaction for invoking the signature contract, wherein the second transaction includes the contract account of the CA contract and the first signature;

[0028] An issuing unit is configured to return the first signature to the CA contract according to the second transaction, and issue a user certificate based on the first signature by executing the CA contract.

[0029] A fifth aspect of this specification provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0030] A sixth aspect of this specification provides a blockchain node, comprising a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0031] In the solution provided in the embodiments of this specification, the CA contract in the blockchain system calls a signature contract based on distributed (threshold) signature technology to generate the certificate signature of the CA certificate. The entire process does not contain a complete private key, and can tolerate a certain degree of leakage and loss of private key fragments, thereby effectively avoiding the security risks brought by improper private key management; through a decentralized management model based on the CA contract, the certificate operation threshold is raised, the risk of misoperation is reduced, and the mis-issuance of certificates is effectively avoided; the certificate lifecycle management process is made transparent through the blockchain system, effectively avoiding the abuse of certificates, and at the same time, the certificate effectiveness time is determined based on the current block through the CA contract, providing consistency in the blockchain system. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0033] FIG1 is a system architecture diagram of an embodiment of this specification;

[0034] FIG2 is a flowchart of the key generation phase in the threshold signature implementation method according to an embodiment of this specification;

[0035] FIG3 is a flow chart of the pre-processing stage in the distributed threshold signature in one embodiment of this specification;

[0036] FIG4 is a flow chart of the signature phase in the distributed threshold signature in an embodiment of this specification;

[0037] FIG5 is a flowchart of the pre-processing stage in the distributed threshold signature in another embodiment of this specification;

[0038] FIG6 is a flowchart of the signing phase in a distributed threshold signature in another embodiment of this specification;

[0039] FIG7 is a flow chart of a method for deploying a CA contract in accordance with an embodiment of this specification;

[0040] FIG8 is a flow chart of a certificate issuance method according to an embodiment of the present specification;

[0041] FIG9 is an architectural diagram of a node in a blockchain system according to an embodiment of this specification. DETAILED DESCRIPTION

[0042] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments derived by those skilled in the art based on the embodiments in this specification without creative effort shall fall within the scope of protection of this specification.

[0043] In related technologies, CA institutions are centralized and therefore inherently subject to risks. These risks include: the CA institution itself may act maliciously and issue false certificates; the CA institution may operate improperly and mistakenly issue certificates with the same number; the CA institution may mismanage private keys and leak private keys, etc.

[0044] At the same time, CA organizations manage the lifecycle of CA certificates based on natural time, which conflicts with the consistency of blockchain systems. For example, when a new node joins a blockchain system, it needs to pull completed blocks from other nodes and re-execute the transactions in these blocks. If the lifecycle of the key of an account in the blockchain system corresponds to natural time, when re-executing transactions in past blocks, if the account's key has expired, the newly joined node will fail to verify the past transactions, resulting in a state inconsistency between the newly joined node and other nodes.

[0045] Therefore, a CA certificate system for blockchain systems is needed that can bind CA certificates to on-chain time to provide certainty and validity of CA certificates in blockchain systems.

[0046] To this end, in the embodiment of this specification, the CA contract in the blockchain system calls a signature contract based on distributed (threshold) signature technology to generate the certificate signature of the CA certificate. The entire process does not contain a complete private key and can tolerate a certain degree of private key fragmentation leakage and loss, thereby effectively avoiding the security risks brought by improper private key management; through a decentralized management model based on the CA contract, the certificate operation threshold is raised, the risk of misoperation is reduced, and the mis-issuance of certificates is effectively avoided; the certificate lifecycle management process is made transparent through the blockchain system, effectively avoiding the abuse of certificates. At the same time, the CA contract determines the certificate validity time (such as the block timestamp) based on the current block. In this way, even if the transaction of the past block is re-executed, the account key of the transaction is always consistent and valid when executing the block, thereby providing consistency in the blockchain system.

[0047] Figure 1 shows a system architecture diagram of an embodiment of this specification, which includes a blockchain system 100 and an off-chain service system 200.

[0048] As shown in Figure 1, a blockchain system 100 includes N nodes, with nodes 1 through 8 schematically illustrated. The lines connecting the nodes schematically represent connections between them, used to transmit data between them. These nodes can store the full ledger, i.e., the state of all blocks and all accounts. Each node in the blockchain system can generate the same state by executing the same transactions, and each node in the blockchain system can store the same state database.

[0049] A transaction in the blockchain field refers to a task unit executed and recorded in the blockchain system. A transaction typically includes a sender (From), a receiver (To), and a data field (Data). In the case of a transfer transaction, the From field indicates the address of the account initiating the transaction (i.e., initiating a transfer task to another account), the To field indicates the address of the account receiving the transaction (i.e., receiving the transfer), and the Data field includes the transfer amount.

[0050] Blockchain systems include smart contracts. Smart contracts are contracts whose execution can be triggered by transactions within the blockchain system. Smart contracts can be defined in code. Invoking a smart contract within a blockchain system involves initiating a transaction directed to the smart contract address, enabling each node in the blockchain system to execute the smart contract code in a distributed manner.

[0051] In a contract deployment scenario, for example, Bob sends a transaction containing information about creating a smart contract (i.e., deploying a contract) to the blockchain system 100 shown in FIG1 . The transaction's data field includes the code (e.g., bytecode or machine code) for the contract to be created, and the transaction's to field is empty, indicating that the transaction is for contract deployment. After the nodes reach consensus through a consensus mechanism, they determine the contract address "0x6f8ae93..." Each node adds a contract account corresponding to the smart contract's contract address to the state database, allocates state storage corresponding to the contract account, stores the contract code, and saves the hash value of the contract code in the state storage of the contract, thus successfully creating the contract.

[0052] In a contract invocation scenario, for example, Bob sends a transaction to invoke a smart contract to the blockchain system 100 shown in Figure 1. The transaction's "from" field is the address of the account of the transaction initiator (i.e., Bob), the "to" field is the aforementioned "0x6f8ae93...", the address of the invoked smart contract, and the transaction's "data" field includes the method and parameters for invoking the smart contract. After the blockchain system reaches consensus on this transaction, each node in the blockchain system can execute the transaction, thereby executing the contract and updating the state database based on the execution of the contract.

[0053] As shown in Figure 1, a CA contract and a signature contract are deployed in the blockchain system. The CA contract pre-applies for a distributed key in the signature contract. The CA contract can generate a distributed signature for the certificate content by calling the signature contract with the help of the service provider in the off-chain service system, thereby providing a CA certificate.

[0054] To facilitate understanding of the embodiments of this specification, some concepts in cryptography are first introduced below.

[0055] The DKG (Distributed Key Generation) protocol is a distributed protocol that generates a set of keys through collaboration among multiple parties. The VSS (Verifiable Secret Sharing) protocol is an important theoretical foundation for the DKG protocol.

[0056] VSS allows for sharing secret data between multiple parties. Without leaking the secret data itself, the data can be split into multiple shards, each of which is kept by a different party. Later, when restoring the secret data, all shards must be collected to successfully restore the complete secret data.

[0057] The VSS protocol, first proposed by Shamir in 1979, is a polynomial-based secret sharing protocol. The VSS protocol is derived from Shamir's Secret Sharing (SSS), so we'll first introduce Shamir's Secret Sharing.

[0058] Shamir secret sharing includes two stages: secret sharing (or secret distribution) and secret reconstruction. First, a dealer needs to construct a polynomial: f(x) = a0 + a1x + a2x 2 +…+a n x n Polynomial(*)

[0059] Among them, a0 is the secret data to be shared.

[0060] This n-degree polynomial consists of a set of coefficients (a0, a1, a2, ..., a n ) is uniquely determined, and this set of coefficients includes n+1 values. In this way, if it is known that the curve corresponding to the n-degree polynomial passes through n+1 different points on the plane, the coordinates of n+1 different points are obtained (x1, y1), (x2, y2), ..., (x n ,y n ),(x n+1 ,y n+1 ), we can get a set of (n+1) linear equations of n+1 equations, and from this set of equations we can determine the n+1 coefficients a0, a1, a2, ..., a n The value of the polynomial (*) is determined, and finally the value of the secret data a0 is obtained. The coordinates of the n+1 different points (x1, y1), (x2, y2), ..., (x n ,y n ), (xn+1 ,y n+1 ) means n+1 secret shards.

[0061] The process of finding a curve passing through a number of existing points is called polynomial interpolation. There are many ways to implement polynomial interpolation. The following is a common Lagrange interpolation method. Given an nth degree polynomial*, it is known that the corresponding curve of the polynomial passes through n+1 points (x 1， y1),(x 2， y2),...,(x n, y n ), (x n+1， y n+1 ), then the polynomial of the n-degree curve can be obtained by Lagrange interpolation as follows:

[0062] Polynomial (**) and polynomial (*) are actually equivalent. If x = 0 in polynomial (*), then f(0) = a0, which means the value of the secret data a0 can be obtained. Therefore, if x = 0 in polynomial (**), the value of the secret data a0 can also be obtained, that is, f(0) = a0.

[0063] For n+1 points (x1, y1), ..., (x n ,y n ), (x n+1 ,y n+1 ), the above polynomial (**) can also be expressed as:

[0064] in, Similarly, for constant terms or secret values, we have

[0065] In summary, we can select any n+1 points on the polynomial and share these n+1 points among n+1 participants, for example, each participant receives the coordinates of one point. Collecting the coordinates of any fewer than n+1 points will not reveal the original secret data a0. Only after obtaining all n+1 points can the value of secret data a0 be restored by reconstructing the polynomial coefficients. Furthermore, even if we collect the coordinates of fewer than n+1 points, for example, n points, the value of secret data a0 will not be revealed probabilistically, as there are an infinite number of n-degree curves passing through these n points. The degree n here is also called the degree of the polynomial.

[0066] On this basis, threshold Shamir secret sharing can be implemented. For example, t-of-n secret sharing is to share a secret between n participants, and stipulate that the threshold of the minimum secret shards required for recovery is greater than t, that is, greater than or equal to t+1. For example, in a transaction involving four parties, the agreed threshold is 3, that is, n=4, t=2, then the secret can only be restored when greater than or equal to t+1=3 participants provide their own secret shards, otherwise the secret cannot be restored. Specifically, a polynomial of degree t=2 can be constructed: f(x)=a0+a1x+a2x 2 Polynomial(***)

[0067] The curve corresponding to the 2-degree polynomial can be obtained to pass through 4 different points on the plane, that is, the coordinates of 4 different points are obtained (x1, y1), (x2, y2), (x3, y3), (x4, y4), and the coordinates of these 4 points are distributed to one participant respectively during the secret sharing phase. The 4 participants are set as Party1, Party2, Party3, and Party4. In this way, it is assumed that Party1 has a slice (x1, y1), Party2 has a slice (x2, y2), Party3 has a slice (x2, y3), and Party4 has a slice (x4, y4). Since the polynomial (**) can be determined by any 3 points on the corresponding curve, Party i In (i∈{1, 2, 3, 4}), if any three participants provide their own secret slices, the polynomial (***) can be restored during the secret reconstruction phase, thereby obtaining the secret value a0. If fewer than three participants provide their own secret slices, the polynomial (***) cannot be restored, and the secret value a0 cannot be obtained. The above t is also called the threshold.

[0068] The aforementioned Shamir Secret Sharing and Threshold Shamir Secret Sharing require a role to generate polynomials and distribute secret shards. This role can be called a dealer. This dealer is an entity that knows the secret and must be a trusted third party by all participating parties. Furthermore, an entity is required to aggregate at least t+1 shards and derive the secret. This entity can be the dealer, a participating party, or another entity.

[0069] In engineering practice, polynomials are often defined in finite fields (based on elliptic curves or discrete logarithms) or prime number fields (based on RSA), rather than real number fields or natural number fields.

[0070] The classic Shamir secret sharing scheme assumes that all participants are honest. However, dishonest behavior, or malicious behavior, is possible. For example, a dealer could deceive one or more participants by sending incorrect secret shards to them.

[0071] In secret sharing, to verify malicious behavior, such as verifying whether the dealer is deceiving them (as described above, verifying whether the dealer sends an incorrect secret fragment), Verifiable Secret Sharing (VSS) is proposed. Feldman VSS is a practical VSS scheme based on Shamir's secret sharing, including:

[0072] The dealer has a secret and distributes n fragments of this secret to n participants, of which t+1 participants can reconstruct the secret. A similar threshold Shamir secret sharing scheme can be used to construct a t-degree polynomial: f(x) = a0 + a1x + a2x 2 +…+a t x t Polynomial (****)

[0073] Dealer is for each party i Choose any non-zero x i , calculate s i =f(x i ), and the sub-secret s i Encrypted and sent to the participating party i At the same time, the Dealer calculates Where j = 0, 1, 2, ..., t, and A is public j , that is, {A0,A1,A2,…,A t}. A j Also known as public authentication parameters. Here A j The method of generating the public key is the same as the method of generating the public key based on the private key on the elliptic curve. Therefore, A j It can also be called public key sharding or public key sharing.

[0074] For the case where the selected polynomial corresponds to an elliptic curve, the public A j It is safe because according to the properties of elliptic curves, it is impossible to j Reverse to get a j .

[0075] Public verification parameters {A0, A1, A2, ..., A t} is also called a commitment. Since the commitment is bound to the coefficients of the polynomial, it can be used to verify whether a value of the polynomial is correct. In the implementation based on discrete logarithms, g is a generator of the cyclic group over a finite field. g can be between Dealer and Party.i The above sub-secrets are also called secret shards.

[0076] The participants receive the sub-secret s i After that, public verification parameters can be used to verify s i The validity of s can be verified by verifying whether the following equation holds: i Validity:

[0077] The right side of the polynomial (*****) can be derived as follows:

[0078] The right side of the polynomial (*****) can also be written as:

[0079] It can be seen that for Party i , a non-zero x selected by the Dealer i , x i For example, if it is i, then Party i It is possible to use i and public verification parameters {A0, A1, A2, ..., A t}Calculate the right side of the polynomial (*****) and use the generator g and the sub-secret s i To calculate the left side of the polynomial (*****), we can determine whether the left and right sides of the polynomial (*****) are equal. Is it {A0,A1,A2,…,A t} corresponds to a point on the curve. This verification belongs to the verification of the secret distribution phase. For simplicity, we can usually take x i =i.

[0080] In engineering, it is generally implemented based on discrete logarithms. Modulo operations are used for the above equations, such as mod p, where p is a large prime number and p is also the value of Dealer and Party. i Pre-configured. mod p is also omitted in the following similar places.

[0081] During the secret reconstruction phase, for example, if at least t+1 participants each send their own secret shards to the dealer, the dealer can verify each secret shard using the public verification parameter corresponding to the polynomial. Failure to verify can be used to prove that the party sending the secret shard is malicious; secret shards that pass verification can be used as the basis for reconstructing the secret.

[0082] In the secret reconstruction phase, after collecting the secret shards of at least t+1 participants, the polynomial f(x) can be reconstructed through the Lagrange interpolation method to obtain the value of f(0), that is, the secret value.

[0083] In addition, through the public verification parameters {A0, A1, A2, ..., A t The legitimacy of the secret a0 can also be verified, that is, it can be verified whether (0, a0) is a point on the curve, because the following relationship exists:

[0084] In other words, the verification of the legitimacy of the secret a0 can be simplified to being achieved through the public verification parameter A0.

[0085] In the above derivation, define 0 0 =1, and 0 k =0, k≠0.

[0086] The above solution requires a dealer, a centralized entity with access to the secret. As mentioned above, it needs to be a trusted third party, or in other words, all parties must trust the dealer. In a distributed scenario, both distributed secret distribution and distributed secret reconstruction are required. This requires eliminating the centralized dealer, thus achieving trustlessness. To address this problem, Rabin et al. proposed an improved protocol called Joint-Feldman in 1999. The basic idea of ​​this protocol is to execute the Feldman VSS protocol n times in parallel, with each participant generating a random polynomial locally and then sharing the randomly selected secret value among all participants. Since what is shared is a commitment to the secret, rather than the secret itself, the secret cannot be recovered unless there is collusion and cheating by multiple participants exceeding a threshold t. This distributed VSS protocol that eliminates the trusted third party is also called DVSS (Distributed VSS).

[0087] Specifically, taking four participants as an example, assuming the threshold t = 2, then the degree of the polynomial is also 2. The decentralized threshold secret sharing, also known as the Joint-Feldman implementation, includes the following:

[0088] Each P i (Party i Abbreviated as P i , i∈{1, 2, 3, 4}) sets the secret s to be shared i0 , and randomly choose other parameters to generate a t-degree polynomial:

[0089] Participant P1 generates a 2nd degree polynomial:

[0090] f1(z)=a 10 +a 11 z+a 12 z 2, where a 10 It is the secret s1 set by P1;

[0091] Participant P2 generates a 2nd-degree polynomial:

[0092] f2(z)=a 20 +a 21 z+a 22 z 2 , where a 20 It is the secret s2 set by P2;

[0093] Participant P3 generates a 2nd degree polynomial:

[0094] f3(z)=a 30 +a 31 z+a 32 z 2 , where a 30 It is the secret s3 set by P3;

[0095] Participant P4 generates a 2nd-degree polynomial:

[0096] f4(z)=a 40 +a 41 z+a 42 z 2 , where a 40 It is the secret s4 set by P4.

[0097] Then, each participant P i Generate n values ​​on the curve corresponding to its own t-degree polynomial and distribute them. Here we still assume n = 4, t = 2, n = 1, 2, 3, 4, then:

[0098] Participant P1 generates s 11 =f1(1),s 12 =f1(2),s 13 =f1(3),s 14 =f1(4), keep s 11 , and encrypt and send s 12 To P2, encrypt and send s 13 To P3, encrypt and send 14 to P4;

[0099] Participant P2 generates s 21 =f2(1),s 22 =f2(2),s 23 =f2(3),s 24 =f2(4), keep s 22 , and encrypt and send s 21 To P1, encrypt and send s 23 To P3, encrypt and send24 to P4;

[0100] Participant P3 generates s 31 =f3(1),s 32 =f3(2),s 33 =f3(3),s 34 =f3(4), keep s 33 , and encrypt and send s 31 To P1, encrypt and send s 32 To P2, encrypt and send s 34 to P4;

[0101] Participant P4 generates s 41 =f4(1),s 42 =f4(2),s 43 =f4(3),s 44 =f4(4), keep s 44 , and encrypt and send s 41 To P1, encrypt and send s 42 To P2, encrypt and send s 43 To P3.

[0102] Moreover, each participant P i It also generates the public verification parameters corresponding to its own t-degree polynomial Where k = 0, 1, ..., t, and is announced to each participant, specifically:

[0103] Participant P1 generates include Broadcast 10 ,A 11 ,A 12} to P2, P3 and P4;

[0104] Participant P2 generates include Broadcast 20 ,A 21 ,A 22} to P1, P3 and P4;

[0105] Participant P3 generation include Broadcast 30 ,A 31 ,A 32} to P1, P2 and P4;

[0106] Participant P4 generation include Broadcast 40 ,A 41 ,A42} to P1, P2 and P3.

[0107] In this way, P1 receives s 21 After that, you can use {A 20 ,A 21 ,A 22} to verify; P1 receives s 31 After that, you can use {A 30 ,A 31 ,A 32} to verify; P1 receives s 41 After that, you can use {A 40 ,A 41 ,A 42} for verification; the verification method is similar to the above and will not be repeated here.

[0108] Similarly, P2 receives s 12 After that, you can use {A 10 ,A 11 ,A 12} to verify; P2 receives s 32 After that, you can use {A 30 ,A 31 ,A 32} to verify; P2 receives s 42 After that, you can use {A 40 ,A 41 ,A 42} to verify;

[0109] Similarly, P3 receives s 13 After that, you can use {A 10 ,A 11 ,A 12} to verify; P3 receives s 23 After that, you can use {A 20 ,A 21 ,A 22} to verify; P3 receives s 43 After that, you can use {A 40 ,A 41 ,A 42} to verify;

[0110] Similarly, P4 receives s 14 After that, you can use {A 10 ,A 11 ,A 12} to verify; P4 receives s 24 After that, you can use {A 20 ,A 21 ,A 22} to verify; P4 receives s 34After that, you can use {A 30 ,A 31 ,A 32} for verification.

[0111] Assume that the set of participants that pass the verification after verification is Qual, and Qual = {P1, P2, P3, P4}, then:

[0112] P1 has local secret shards generated by different parties 11 、s 21 、s 31 、s 41 , and public authentication parameters {A 10 ,A 11 ,A 12}, {A 20 ,A 21 ,A 22}, {A 30 ,A 31 ,A 32}, {A 40 ,A 41 ,A 42};

[0113] P2 has local secret shards generated by different parties 12 、s 22 、s 32 、s 42 , and public authentication parameters {A 10 ,A 11 ,A 12}, {A 20 ,A 21 ,A 22}, {A 30 ,A 31 ,A 32}, {A 40 ,A 41 ,A 42};

[0114] P3 locally has secret shards generated by different parties 13 、s 23 、s 33 、s 43 , and public authentication parameters {A 10 , A 11 ,A 12}, {A 20 ,A 21 ,A 22}, {A 30 ,A 31 ,A 32}, {A 40,A 41 ,A 42};

[0115] P4 locally has secret shards generated by different parties 14 、s 24 、s 34 、s 44 , and public authentication parameters {A 10 ,A 11 ,A 12}, {A 20 ,A 21 ,A 22}, {A 30 ,A 31 ,A 32}, {A 40 ,A 41 ,A 42}.

[0116] then:

[0117] Participant P1 can calculate the secret shard s1 as: s1 = s 11 +s 21 +s 31 +s 41 ;

[0118] Participant P2 can calculate the secret shard s2 as: s2 = s 12 +s 22 +s 32 +s 42 ;

[0119] Participant P3 can calculate the secret shard s3 as: s3 = s 13 +s 23 +s 33 +s 43 ;

[0120] Participant P4 can calculate the secret shard s4 as: s4 = s 14 +s 24 +s 34 +s 44 ;

[0121] Each participant P i The secret shards calculated by themselves can be i Broadcast to other participants. Then each participant P i After collecting at least threshold t+1 secret fragments from {s1, s2, s3, s4}, the secret s0 can be reconstructed. Here, for t=2, each participant P i After collecting at least a threshold of t+1=2+1=3 secret shards, the secret s0 can also be reconstructed.

[0122] This is because the sum of the curves of each participant can be summed up to get the total curve: f(z)=f1(z)+f2(z)+f3(z)+f4(z) f(z=(a 10 +a 11 z+a 12 z 2 )+(a 20 +a 21 z+a 22 z 2 )+(a 30 +a 31 z+a 32 z 2 ) +(a 40 +a 41 z+a 42 z 2 ) f(z)=(a 10 +a 20 +a 30 +a 40 )+(a 11 +a 21 +a 31 +a 41 )z+(a 12 +a 22 +a 32 +a 42 )z 2 Polynomial (I)

[0123] Thus: s1=s 11 +s 21 +s 31 +s 41 =f1(1)+f2(1)+f3(1)+f4(1); s2=s 12 +s 22 +s 32 +s 42 =f1(2)+f2(2)+f3(2)+f4(2); s3=s 13 +s 23 +s 33 +s 43 =f1(3)+f2(3)+f3(3)+f4(3); s4=s 14 +s 24 +s 34 +s 44 =f1(4)+f2(4)+f3(4)+f4(4);

[0124] For the total curve f(z), there is the relationship: s1=f1(1)+f2(1)+f3(1)+f4(1)=f(1); s2=f1(2)+f2(2)+f3(2)+f4(2)=f(2); s3=f1(3)+f2(3)+f3(3)+f4(3)=f(3); s4=f1(4)+f2(4)+f3(4)+f4(4)=f(4);

[0125] The secret is s0=a 10 +a 20 +a 30 +a 40 .

[0126] In this way, any participant P i After collecting at least three of the secret fragments s1, s2, s3, and s4, we can obtain at least three points on the curve corresponding to polynomial (I), that is, at least three of the four coordinates (x1=1, y1=s1), (x2=2, y2=s2), (x3=3, y3=s3), and (x4=4, y4=s4), thereby recovering the total curve f(z). Furthermore, we can calculate f(0)=a 10 +a 20 +a 30 +a 40 =s0, so the secret s0 can be obtained.

[0127] Furthermore, by verifying the parameter {A 10 ,A 11 ,A 12}, {A 20 ,A 21 ,A 22}, {A 30 ,A 31 ,A 32}, {A 40 ,A 41 ,A 42} can also be used to i The legitimacy of (0,s i ) is a point on the total curve. Specifically, the legitimacy is determined by verifying whether the following equation holds:

[0128] This is because the following relationship exists:

[0129] It is usually also assumed that the right side of the polynomial (II) is the public key shard, denoted as pub i , i = 1, 2, ..., n, to verify the corresponding private key shard.

[0130] As mentioned above, we can generally take x i =i for each i=1, 2, ..., n. In this way, i can be used as the number of each participant.

[0131] For the verification of secret s0, that is, x i =0, the above formula can be further deduced as follows:

[0132] Definition 0 0 =1, and 0 k =0, k≠0, so the above formula can be further deduced:

[0133] It can be seen that based on the polynomial (III), the legitimacy of s0 can be verified.

[0134] Moreover, based on the derivation of the above polynomial (III), the verification of the legitimacy of s0 can be further simplified as follows:

[0135] It is also common to assume that the right side of the equal sign of polynomial (Ⅳ) is the total public key, denoted as pub.

[0136] The Joint-Feldman protocol described above enables distributed secret sharing, fulfilling the core concept of DKG. The series of secret sharing implementations, from Shamir to Threshold Shamir, the Feldman VSS protocol, and finally the Joint-Feldman DVSS protocol, is a series. In addition to the series of schemes starting with Shamir's secret sharing, there are also schemes based on Additive Secret Sharing, SPDZ (a key protocol in multi-party secure computation, first proposed in 2012), or the Chinese Remainder Theorem, which can ultimately achieve DKG. These are omitted here and will not be further elaborated.

[0137] Through the implementation of the above DKG protocol, the problem of single point failure resulting in overall unavailability caused by the generation of keys by a single entity can be overcome, as well as the problem of needing to trust a single point of key generation. i Broadcast the generated secret shards ij ,i,j∈(1,2,...,n), n is the number of participants, and each participant P i The secret shards calculated by themselves can be i Broadcast to other participants, so that each participant P iAfter collecting at least a threshold of t+1 secret shards from {s1, s2, s3, s4}, the secret s0 can be reconstructed. This means that at least t+1 participants will obtain the final reconstructed secret s0, which will expose the secret s0 and make the overall curve unusable. If a new secret s0 is to be generated next time, the DKG protocol process must be repeated.

[0138] The DKG protocol's properties regarding thresholds and secret commitments, combined with the matching threshold signature algorithm, can be used to construct a distributed threshold signature protocol. As a distributed system, blockchains make extensive use of signature algorithms. In this way, nodes in a blockchain generate secret shards in a distributed manner using DKG. After at least t+1 blockchain nodes use these secret shards as private key shards to sign the signature information and broadcast it, any blockchain node that has collected at least t+1 signature shards can recover the total signature and, using the aforementioned method, the total public key. This recovered total signature can then be verified using this total public key, thus implementing threshold signatures. Furthermore, this approach offers the advantage that each blockchain node's secret shard does not need to be broadcast to other nodes, thus preventing the exposure of its own secret shard and, consequently, its private key. Therefore, a secret shard generated by a single DKG can be reused multiple times, eliminating the need to perform a complete DKG protocol for each threshold signature.

[0139] The basic Elliptic Curve Signature Algorithm (ECDSA) can include the following process:

[0140] The signing party Alice chooses an elliptic curve E q (a, b) and base point g, and share this information with the verifier Bob, where q is the modulus;

[0141] Alice in a finite field Select a private key And generate the public key X=g based on the private key x (or x·g);

[0142] Alice in a finite field Select a random number And calculate R = g k-1 =(a1, b1), where a1 and b1 are the horizontal and vertical coordinates of point K on the elliptic curve respectively. Let r = a1;

[0143] Alice hashes the message to be signed to obtain the digest value m = H(message), and then calculates: s = k·(m+r·x) mod q; Formula (a)

[0144] Alice generates a signature σ = (r, s), and sends the message, the signature σ, and the public key X to the signer Bob.

[0145] Bob calculates the coordinates of point K′ using the base point g, the signature σ, and the public key X:

[0146] Bob compares whether a′1 is equal to r. If they are equal, the signature is valid; otherwise, the signature is invalid.

[0147] The above basic ECDSA signature algorithm can be extended to a threshold signature algorithm. For example, after the above DKG process, n signers P1, P2, …, P n each have their own secret shards and a total public key, where the threshold value is t and t < n. After at least t + 1 signers among the n participants each use their own secret shards as private key shards respectively to sign the same message to be signed and broadcast, any verifier who collects at least t + 1 signature shards can recover the total signature and can verify the total signature using the total public key, thereby implementing threshold signature.

[0148] The certificate issuance scheme in the embodiments of this specification includes three major parts: an initialization stage, a certificate application stage, and a certificate issuance stage. Among them, the initialization stage includes the following three small stages: (1) a key application stage, (2) a preprocessing stage, (3) a stage where the Root CA or Intermediate CA issues a certificate, and (4) a CA contract deployment stage. Below, the initialization stage in the embodiments of this specification is first described by referring to FIGS. 2 - 7, and the certificate application stage and the certificate issuance stage in the embodiments of this specification are described by referring to FIG. 8. The embodiments of this specification are described by taking the ECDSA signature algorithm as an example. It can be understood that the solutions in the embodiments of this specification can similarly use other signature algorithms.

[0149] FIG. 2 is a flowchart of the key application stage in the threshold signature implementation method of the embodiments of this specification. Among them, as described above, a signature contract is pre - deployed in the blockchain system, and the off - chain service system may include devices of service providers greater than or equal to n. One service provider among the n service providers is shown as an example in FIG. 2. It can be understood that the other service providers among the n service providers operate in the same way as the off - chain service provider in FIG. 2.

[0150] As shown in FIG. 2, first, in step S201, the administrator device sends a transaction Tx1 for invoking the signature contract to the blockchain system, requesting to generate a key.

[0151] The administrator device is the blockchain system administrator's device. The administrator has certain permissions, such as the ability to deploy a CA contract. The administrator requests a key and can subsequently transfer the requested key to the CA contract for use. The sender of transaction Tx1 is the administrator account (e.g., Account1).

[0152] Transaction Tx1 includes parameters for distributed signature, which may include: the accounts of the specified n service parties, the signature threshold t and other parameters.

[0153] In some embodiments, the parameters may also include a service threshold k in the preprocessing stage, where n>k>t. That is, in the preprocessing stage, when the number of service parties is greater than or equal to the threshold k, the preprocessing stage can be pushed forward, and in the signing stage, when the number of service parties is greater than the threshold t, the signing can be completed.

[0154] In some embodiments, the parameters may also include several backup service providers, which participate in the distributed key generation phase and obtain private key shards, but usually do not participate in the preprocessing phase and the signing phase, and only participate in the preprocessing phase and the signing phase when the private key shards of other service providers are lost.

[0155] In some embodiments, the parameters may also include a minimum number min and a maximum number max for the preprocessing stage. The minimum data and maximum number are used to limit the number of times the preprocessing process is performed, thereby generating multiple sets of intermediate data through multiple preprocessing processes for use in the CA certificate issuance stage. That is, if one set of intermediate data fails, the intermediate data of another preprocessing process can also be used, thereby achieving high availability of the subsequent signing process.

[0156] Among them, taking the parameter group (2,5,7,9) as an example, 2 is the signature threshold t, that is, any t+1=3 private key shards can complete the distributed signature; 5 is the service threshold k, that is, at least 5 service parties are guaranteed to participate in the preprocessing stage, so that 2 service parties are allowed to fail in the signing stage during the signing process; "7" means that at least 7 service parties are guaranteed to participate in the key generation stage, so that 2 service parties are allowed to fail in the preprocessing stage; 9-7=2 is the number of backup service parties.

[0157] In step S203, the blockchain system executes transaction Tx1 and stores the request-related data in the blockchain.

[0158] After executing transaction Tx1, each node in the blockchain system associates and stores account Accoun1 and its corresponding parameters in the contract state of the signature contract based on transaction Tx1. The parameters include, for example, the accounts of the n service providers specified above, k, t, max, min, and other parameters.

[0159] Specifically, a data table (e.g., Table 1) corresponding to the distributed threshold signature can be maintained in the contract state of the signature contract. Based on transaction Tx1, the blockchain node can add a row corresponding to account Account1 to Table1 and add account Account1, the accounts of the specified n service parties, and parameters such as k, t, max, and min to a field in the row. "Account 1" in the row indicates that account Account1 has the authority to obtain the signature.

[0160] At the same time, the blockchain node also generates a receipt for transaction Tx1 based on the transaction Tx1. This receipt includes a first start event k1 set to a preset topic (e.g., "initialization phase"). The preset topic may include keywords such as "initialization phase," but this is not limited here. This first start event k1 may include the account Account1, parameters n, k, t, max, min, etc., and is used to instruct each of the n service providers to enter the key generation phase corresponding to account Account1.

[0161] In step S205 , the blockchain system pushes the first start event k1 to each of the n service parties.

[0162] Each of the n service providers in the blockchain system can pre-subscribe to events with the aforementioned pre-set topic from a blockchain node in the blockchain system. For example, if service provider P1 pre-subscribes to events with the aforementioned topic from node 1 in the blockchain system, node 1 will generate the first start event k1 and, based on service provider P1's subscription, send the first start event k1 to service provider P1.

[0163] It is understood that the embodiments of this specification are not limited to the blockchain system pushing event k1 to n service providers. In one embodiment, each service provider can obtain event k1 from the receipt of transaction Tx1 by pulling each transaction receipt from the blockchain system.

[0164] In step S207, the off-chain service provider generates a homomorphic public-private key pair.

[0165] Assume that the n service providers are P1, P2, ..., P n Each service provider P i In response to the received event k1, a Paillier public-private key pair (pk i ,ski ). where sk i is the private key, pk i For the corresponding public key. Homomorphic encryption technology can process plaintext data in a "homomorphic" manner, that is, through the homomorphic public key pk i Map the plaintext data to a new, confidential state so that only those with the homomorphic private key sk i The recipient can obtain the plaintext data. Paillier homomorphic addition is a public key encryption system widely used in cryptography, proposed by Pascal Paillier in 1999. Its main feature is that it has additive homomorphic properties, which means that given two ciphertexts, the ciphertext of the sum of their corresponding plaintexts can be calculated without decryption. Specifically, suppose there are two plaintexts m1 and m2, and their Paillier encrypted ciphertexts are c1 and c2 respectively. Paillier's additive homomorphic property can realize the calculation of a new ciphertext c obtained by multiplying c1 and c2, which is exactly the ciphertext of the sum of m1 and m2. The additive homomorphic property is an important feature of the Paillier encryption algorithm, which can be simply expressed as: E(m1)·E(m2)=E(m1+m2), where the point product·is the subsequent homomorphic addition This homomorphic property allows certain forms of computation to be performed on encrypted data without revealing the original data.

[0166] In step S209, each service sends a transaction Tx2 to the blockchain system to call the signature contract to upload the homomorphic public key pk i .

[0167] It can be understood that transaction Tx2 is used to indicate that each of the n service parties sends a request to the blockchain system to upload the homomorphic public key pk i It refers to a transaction sent by a service to the blockchain system, rather than a transaction sent by a service to the blockchain system.

[0168] The transaction Tx2 is sent by the blockchain account of the service provider, and the transaction Tx2 includes the account Account1 and pk i .

[0169] In step S211, the blockchain system executes transaction Tx2 and sends the homomorphic public key pk i Push to other service providers.

[0170] After receiving and reaching consensus on transaction Tx2, each node in the blockchain system executes Tx2. Based on Tx2, it determines whether the sending account of Tx2 is one of the n service-party accounts corresponding to Account1. If the determination result is yes, a receipt corresponding to Tx2 is generated. This receipt stores the homomorphic public key corresponding to the service-party account that sent Tx2 as an event, which is used to push the service-party's homomorphic public key to other service-parties. If the determination result is no, execution of the transaction ends.

[0171] At the same time, the blockchain system also maintains the number of received transactions Tx2 in association with account Account1 in the contract status of contract C1. In the blockchain system, each time a transaction Tx2 is executed, the number of received transactions Tx2 is increased by 1 in the contract status of contract C1.

[0172] In step S213, each time the blockchain system completes the execution of a transaction Tx2, it determines whether the transaction Tx2 has been received from the n service parties based on the data in Table 1 in the contract status of contract C1. If the judgment result is "yes", step S215 is executed to generate a second start event k2 to push the second start event k2 to the n service parties, instructing each service party to enter the second round of interaction in the key generation phase.

[0173] The second start event k2 may include the homomorphic public keys pk of the n service parties. i , so that each service provider can obtain the homomorphic public key pk of other n-1 service providers i .

[0174] In step S217, n service providers each generate a random secret value x i , Public Key Sharding Random t-degree polynomial f i (z) and f i (j).

[0175] Assume that each service provider P i The secret value x generated by each i The sum is x, that is And the sum of the polynomials generated by each service provider is f(z), that is,

[0176] Specifically, f i (z) = a i0 +a i1 z+a i2 z 2 +…+a it z t, where a i0 It's P i The secret value set, here set to x i The threshold here is t, so the degree of the polynomial is also t. i takes values ​​from 1 to n.

[0177] Assume the threshold is 2 and the total number of service providers is 7, that is, t = 2, n = 7. There are 7 service providers P1, P2, P3, P4, P5, P6, and P7. They use their own generated secret values ​​x1, x2, x3, x4, x5, x6, and x7 to construct polynomials, where:

[0178] P1 generates a 2nd degree (t=2) polynomial: f1(z)=a 10 +a 11 z+a 12 z 2 , where a 10 It is the secret x1 set by P1;

[0179] P2 generates a 2nd degree (t=2) polynomial: f2(z)=a 20 +a 21 z+a 22 z 2 , where a 20 It is the secret x2 set by P2;

[0180] P3 generates a 2nd degree (t=2) polynomial: f3(z)=a 30 +a 31 z+a 32 z 2 , where a 30 It is the secret x3 set by P3;

[0181] P4 generates a 2nd degree (t=2) polynomial: f4(z)=a 40 +a 41 z+a 42 z 2 , where a 40 It is the secret x4 set by P4;

[0182] P5 generates a 2nd degree (t=2) polynomial: f5(z)=a 50 +a 51 z+a 52 z 2 , where a 50 It is the secret x5 set by P5;

[0183] P6 generates a 2nd degree (t=2) polynomial: f6(z)=a 60 +a 61 z+a 62 z 2 , where a60 It is the secret x6 set by P6;

[0184] P7 generates a 2nd degree (t=2) polynomial: f7(z)=a 70 +a 71 z+a 72 z 2 , where a 70 It is the secret x7 set by P7;

[0185] Furthermore, each service provider P i n secret shards f can be generated i (j), j takes values ​​from 1 to n. For example, the service provider P i Generate the coordinates of n points on the curve corresponding to the polynomial itself as n secret shards.

[0186] Specific examples include:

[0187] P1 generates 11 =f1(1),s 12 =f1(2),s 13 =f1(3),s 14 =f1(4),s 15 =f1(5),s 16 =f1(6),s 17 =f1(7);

[0188] P2 generates 21 =f2(1),s 22 =f2(2),s 23 =f2(3),s 24 =f2(4),s 25 =f2(5),s 26 =f2(6),s 27 =f2(7);

[0189] P3Generators 31 =f3(1),s 32 =f3(2),s 33 =f3(3),s 34 =f3(4),s 35 =f3(5),s 36 =f3(6),s 37 =f3(7);

[0190] P4Generators 41 =f4(1),s 42 =f4(2),s 43 =f4(3),s 44 =f4(4),s 45 =f4(5),s46 =f4(6),s 47 =f4(7);

[0191] P5 Generations 51 =f5(1),s 52 =f5(2),s 53 =f5(3),s 54 =f5(4),s 55 =f5(5),s 56 =f5(6),s 57 =f5(7);

[0192] P6 Generations 61 =f6(1),s 62 =f6(2),s 63 =f6(3),s 64 =f6(4),s 65 =f6(5),s 66 =f6(6),s 67 =f6(7);

[0193] P7 Generations 71 =f7(1),s 72 =f7(2),s 73 =f7(3),s 74 =f7(4),s 75 =f7(5),s 76 =f7(6),s 77 =f7(7).

[0194] In step S219, each service provider sends a transaction Tx3 to call the signature contract, uploads the public key fragment and f to the blockchain system, and i (j), where j≠i.

[0195] Among them, transaction Tx3 may include the public key shards of account Account1 and the service provider and f i (j).

[0196] Specifically, P1 retains s 11 , upload s to the blockchain system through transaction Tx3 12 、s 13 、s 14 、s 15 、s 17 、s 17 and X1, where P1 can use P2’s homomorphic public key pair s 12 After encryption, it is uploaded to the blockchain system for provision to P2, using P3’s homomorphic public key pair s 13After encryption, it is uploaded to the blockchain system for provision to P3, using P4’s homomorphic public key pair s 14 After encryption, it is uploaded to the blockchain system for provision to P4, using P5's homomorphic public key pair s 15 After encryption, it is uploaded to the blockchain system for provision to P5, using P6’s homomorphic public key pair s 16 After encryption, it is uploaded to the blockchain system for provision to P6, and P7’s homomorphic public key pair s 17 After encryption, it is uploaded to the blockchain system for provision to P7.

[0197] P2 keeps s for itself 22 , upload s to the blockchain system 21 、s 23 、s 24 、s 25 、s 26 、s 27 and X2.

[0198] P3 keeps s 33 , upload s to the blockchain system 31 、s 32 、s 34 、s 35 、s 36 、s 37 and X3.

[0199] P4 keeps s 44 , upload s to the blockchain system 41 、s 42 、s 43 、s 45 、s 46 、s 47 and X4.

[0200] P5 keeps s 55 , upload s to the blockchain system 51 、s 52 、s 53 、s 54 、s 56 、s 57 and X5.

[0201] P6 keeps s 66 , upload s to the blockchain system 61 、s 62 、s 63 、s 64 、s 65 、s 67 and X6.

[0202] P7 keeps s 77, upload s to the blockchain system 71 、s 72 、s 73 、s 74 、s 75 、s 76 and X7.

[0203] In step S221, the blockchain system executes transaction Tx3, sharding the public key of the service provider and f i (j) Push to other service providers.

[0204] When executing transaction Tx3 in the blockchain system, it is first determined whether the sender of transaction Tx3 is one of the n service accounts corresponding to the account Account1. If the result is yes, a receipt for transaction Tx3 is generated. The receipt includes an event in which Account1, the public key shard of the service provider, and f are stored in association with the sender of transaction Tx3. i (j).

[0205] At the same time, the blockchain system maintains the number of transactions Tx3 received in the blockchain in the contract state of contract C1 each time the transaction Tx3 is executed.

[0206] In step S223, after each execution of a transaction Tx3, the blockchain system determines whether the transaction Tx3 has been received from n service parties based on the number of transactions Tx3 received in the blockchain maintained in the contract status of contract C1.

[0207] If the judgment result is yes, step S225 is executed to send a third start event k3 to each of the n service providers to indicate the third round of interaction in the key generation phase. The event k3 may include Account1, the public key fragments of each of the n service providers, and f i (j), where j≠i.

[0208] In step S227, the n service parties generate signature public keys and private key fragments ω respectively. i .

[0209] After receiving event k3, each service provider P i Based on the public key set corresponding to each service provider {X i} i∈[1,n] The total public key X (i.e., the signature public key) is calculated, for example, using the following formula:

[0210] At the same time, each service provider P j f can be obtained from event k3 i (j), so that

[0211] P1 has secret shards generated locally by different service parties 11 、s 21 、s 31 、s 41 、s 51 、s 61 、s 71 ;

[0212] P2 has a different secret shard generated locally by the server. 12 、s 22 、s 32 、s 42 、s 52 、s 62 、s 72 ;

[0213] P3 has secret shards generated locally by different service parties 13 、s 23 、s 33 、s 43 、s 53 、s 63 、s 73 ;

[0214] P4 has secret shards generated locally by different service parties 14 、s 24 、s 34 、s 44 、s 54 、s 64 、s 74 ;

[0215] P5 has secret shards generated locally by different service parties 15 、s 25 、s 35 、s 45 、s 55 、s 65 、s 75 ;

[0216] P6 has secret shards generated locally by different service parties 16 、s 26 、s 36 、s 46 、s 56 、s 66 、s 76 ;

[0217] P7 has secret shards generated locally by different service parties 17 、s 27 、s 37 、s 47 、s 57 、s67 、s 77 .

[0218] Then, each service provider P i A secret shard that can be retained by itself ii and from other service providers P j The secret shard obtained ji After aggregation, the sum of the secret shards is obtained as its own private key shard. The aggregation method is, for example, summation. For example, the service provider P i The sum of the secret shards For example:

[0219] The service provider P1 can calculate the private key shard ω1 as: ω1=s 11 +s 21 +s 31 +s 41 +s 51 +s 61 +s 71 ;

[0220] The server P2 can calculate the private key shard ω2 as: ω2 = s 12 +s 22 +s 32 +s 42 +s 52 +s 62 +s 72 ;

[0221] The server P3 can calculate the private key shard ω3 as: ω3 = s 13 +s 23 +s 33 +s 43 +s 53 +s 63 +s 73 ;

[0222] The server P4 can calculate the private key shard ω4 as: ω4 = s 14 +s 24 +s 34 +s 44 +s 54 +s 64 +s 74 ;

[0223] The server P5 can calculate the private key shard ω5 as: ω5 = s 15 +s 25 +s 35 +s 45 +s 55 +s 65 +s 75 ;

[0224] The server P6 can calculate the private key shard ω6 as: ω6 = s 16 +s 26 +s 36 +s 46 +s 56 +s 66 +s 76 ;

[0225] The server P7 can calculate the private key fragment ω7 as: ω7 = s 17 +s 27 +s 37 +s 47 +s 57 +s 67 +s 77 .

[0226] It can be understood that from step S207 to step S227, n service parties exchange information based on the blockchain system, and the embodiments of this specification are not limited to this. For example, n service parties can also exchange information with other service parties through off-chain broadcasting. In one embodiment, n service parties can also exchange public verification parameters A corresponding to their respective t-degree polynomials. ik =a ik G, where k = 0, 1, ..., t, and is published to each service provider. Specifically:

[0227] Service provider P1 generates A 1k =a 1k G, k=0,1,...,t=2, including A 10 =a 10 G=s 10 G, A 11 =a 11 G, A 12 =a 12 G, broadcast {A 10 ,A 11 ,A 12} to P2, P3, P4, P5, P6, P7;

[0228] Service provider P2 generates A 2k =a 2k G, k=0,1,…,t=2,including A 20 =a 20 G=s 20 G, A 21 =a 21 G, A 22 =a 22 G, broadcast {A 20 ,A 21 ,A 22} to P1, P3, P4, P5, P6, P7;

[0229] Service provider P3 generates A 3k =a 3k G, k=0,1,...,t=2,including A 30 =a 30 G=s 30 G, A 31 =a 31 G, A 32 =a 32 G, broadcast {A 30 ,A 31 ,A 32} to P1, P2, P4, P5, P6, P7;

[0230] The server P4 generates A 4k =a 4k G, k=0,1,...,t=2,including A 40 =a 40 G=s 40 G, A 41 =a 411 G, A 412 =a 412 G, broadcast {A 40 ,A 41 ,A 42} to P1, P2, P3, P5, P6, P7;

[0231] Service provider P5 generates A 5k =a 5k G, k=0, 1, ..., t=2, including A 50 =a 50 G=s 50 G, A 51 =a 51 G, A 52 =a 52 G, broadcast {A 50 ,A 51 ,A 52} to P1, P2, P3, P4, P6, P7.

[0232] Service provider P6 generates A 6k =a 6k G, k=0,1,...,t=2,including A 60 =a 60 G=s 60 G, A 61 =a 61 G, A 62 =a 62 G, broadcast {A 60 ,A61 ,A 62} to P1, P2, P3, P4, P5, P7.

[0233] Service provider P7 generates A 7k =a 7k G, k=0,1,…,t=2,including A 70 =a 70 G=s 70 G, A 71 =a 71 G, A 72 =a 72 G, broadcast {A 70 ,A 71 ,A 72} to P1, P2, P3, P4, P5, P6.

[0234] Each service provider P i You can also use P j The public authentication parameters j0 ,A j1 ,…,A jt Verify P j Secret shards sent ji , for example, verified by the following formula: s ji G=A j0 +iA j1 +…+i t A jt

[0235] Specifically:

[0236] Service provider P1 uses s 21 G=A 20 +A 21 +A 22 Verifications 21 , through s 31 G=A 30 +A 31 +A 32 Verifications 31 , through s 41 G=A 40 +A 21 +A 42 Verifications 41 , through s 51 G=A 50 +A 51 +A 52 Verifications 51 , through s 61 G=A 60 +A 61 +A 62 Verifications 61, through s 71 G=A 70 +A 71 +A 72 Verifications 71 ;

[0237] The service provider P2 uses s 12 G=A 10 +2A 11 +2 2 A 12 Verifications 12 , through s 32 G=A 30 +2A 31 +2 2 A 32 Verifications 32 , through s 42 G=A 40 +2A 21 +2 2 A 42 Verifications 42 , through s 52 G=A 50 +2A 51 +2 2 A 52 Verifications 52 , through s 62 G=A 60 +2A 61 +2 2 A 62 Verifications 62 , through s 72 G=A 70 +2A 71 +2 2 A 72 Verifications 72 ;

[0238] The service provider P3 uses s 13 G=A 10 +3A 11 +3 2 A 12 Verifications 13 , through s 23 G=A 30 +3A 31 +3 2 A 32 Verifications 23 , through s 43 G=A 40 +3A 21 +3 2 A 42 Verifications 43 , through s53 G=A 50 +3A 51 +3 2 A 52 Verifications 53 , through s 63 G=A 60 +3A 61 +3 2 A 62 Verifications 63 , through s 73 G=A 70 +3A 71 +3 2 A 72 Verifications 73 ;

[0239] The service provider P4 passes s 14 G=A 10 +4A 11 +4 2 A 12 Verifications 14 , through s 24 G=A 20 +4A 21 +4 2 A 22 Verifications 24 , through s 34 G=A 40 +4A 21 +4 2 A 42 Verifications 34 , through s 54 G=A 50 +4A 51 +4 2 A 52 Verifications 54 , through s 64 G=A 60 +4A 61 +4 2 A 62 Verifications 64 , through s 74 G=A 70 +4A 71 +4 2 A 72 Verifications 74 ;

[0240] Service provider P5 through s 15 G=A 10 +5A 11 +5 2 A 12 Verifications 15 , through s25 G=A 20 +5A 21 +5 2 A 22 Verifications 25 , through s 35 G=A 30 +5A 31 +5 2 A 32 Verifications 35 , through s 45 G=A 40 +5A 41 +5 2 A 42 Verifications 45 , through s 65 G=A 60 +5A 61 +5 2 A 62 Verifications 65 , through s 75 G=A 70 +5A 71 +5 2 A 72 Verifications 75 ;

[0241] Service provider P6 through s 16 G=A 10 +6A 11 +6 2 A 12 Verifications 16 , through s 26 G=A 20 +6A 21 +6 2 A 22 Verifications 26 , through s 36 G=A 30 +56+6 2 A 32 Verifications 36 , through s 46 G=A 40 +6A 41 +6 2 A 42 Verifications 46 , through s 56 G=A 50 +6A 51 +6 2 A 52 Verifications 56 , through s 76 G=A 60 +6A 71+6 2 A 72 Verifications 76 ;

[0242] Service provider P7 through s 17 G=A 10 +7A 11 +7 2 A 12 Verifications 17 , through s 27 G=A 20 +7A 21 +7 2 A 22 Verifications 27 , through s 37 G=A 30 +7A 31 +7 2 A 32 Verifications 37 , through s 47 G=A 40 +7A 41 +7 2 A 42 Verifications 47 , through s 57 G=A 50 +7A 51 +7 2 A 52 Verifications 57 , through s 67 G=A 60 +7A 61 +7 2 A 62 Verifications 67 .

[0243] If either party fails the verification, they can terminate the agreement.

[0244] In step S229, each service sends a transaction Tx4 to the blockchain system to call the signature contract to upload the signature public key.

[0245] Transaction Tx4 may include account Account1 and the signature public key generated by the service provider.

[0246] In step S231, transaction Tx4 is executed in the blockchain system. In the blockchain system, in the row of account Account1 in Table1 in the contract status of the signature contract, the signature public key calculated by the service party is stored in association with each service party account.

[0247] In step S233, each time the blockchain system executes transaction Tx4, it determines whether it has received n signature public keys corresponding to n service party accounts. If the judgment result is yes, it determines whether these n signature public keys are consistent. If they are consistent, it executes step S235.

[0248] In step S235 , when it is determined that the n signature public keys are consistent, the signature public key is stored in the signature public key field in the row of account Account1 in Table 1 , and the key generation phase is determined to be completed.

[0249] After the key generation phase as described above, in the contract state of the signature contract, the signature public key is stored in association with the account Account1, and the n service parties corresponding to the account Account1 respectively store their private key fragments ω i .

[0250] It is understood that steps S203-S235 in FIG. 2 (i.e., the steps included in the dashed box in FIG. 2 ) illustrate an example process in which the blockchain system generates a distributed key by interacting with n service providers according to the DKG protocol. The embodiments of this specification are not limited to generating distributed keys through steps S203-S235 in FIG. For example, the n service providers may also exchange data (such as homomorphic public keys, public key shards, etc.) through off-chain interactions, and this is not limited thereto.

[0251] FIG3 is a flowchart of the pre-processing stage in the distributed threshold signature in one embodiment of this specification.

[0252] In step S301, in response to the completion of the key generation phase corresponding to account Account1, the blockchain system pushes a pre-processing event to n off-chain service providers respectively. The pre-processing event includes account Account1 to instruct the n service providers to enter the pre-processing phase corresponding to account Account1.

[0253] In step S303, each of the t+1 service providers updates the private key fragment and generates a first random number k i , the second random number γ i , the first random number k i The homomorphic ciphertext and the second random number γ i The random public key.

[0254] In one embodiment, the blockchain system may select several groups of service providers from among n service providers for preprocessing, or the n service providers may determine several groups of service providers through negotiation. Each group of service providers includes at least t+1 service providers. The following description uses a group of service providers including t+1 service providers as an example.

[0255] For each group of servers, each server in the group performs the following operations:

[0256] Each of the t+1 service providers can calculate the Lagrange coefficient And use the Lagrange coefficient to update its own private key shard to obtain the updated private key shard x′ i ←l i (0)·ω i For example, if i is 1, 2, or 3, then:

[0257] Service provider P1 calculates the Lagrange coefficient And update its own private key shard to obtain x′1←l1(0)·ω1;

[0258] Service provider P2 calculates the Lagrange coefficient And update its own private key shard to obtain x′2←l2(0)·ω2;

[0259] Service provider P3 calculates the Lagrange coefficient And update its own private key shard to obtain x′3←l3(0)·ω3.

[0260] According to the above Lagrange interpolation method, we can get

[0261] At the same time, each of the t+1 service providers generates a first random number k i and the second random number γ i , and generate the first random number k i Homomorphic ciphertext K i =enc i (k i ), and the second random number γ i The random public key definition Each of the t+1 service providers can broadcast or upload K to the blockchain system. i and Γ i Provide it to other service providers among t+1 service providers. The following example describes the method of uploading the blockchain.

[0262] In step S305, each service sends a transaction Tx5 to the blockchain system to call contract C1 to upload the random number k i Homomorphic ciphertext and random number γ i The random public key.

[0263] In step S307, the blockchain system executes transaction Tx5 and generates a random number k including each service party. i Homomorphic ciphertext and random number γ i The event of the random number public key is stored in the blockchain system in the form of a receipt, for example, for pushing to other service providers among the t+1 service providers.

[0264] In step S309, each service provider P among the t+1 service providers i Select the first mask and the second mask for each other service party, generate the first intermediate ciphertext for the other service party based on its own second random number, the homomorphic ciphertext of the other service party, and the homomorphic ciphertext corresponding to the first mask, and generate the second intermediate ciphertext for the other service party based on its own private key shard, the homomorphic ciphertext of the other service party, and the homomorphic ciphertext corresponding to the second mask.

[0265] Each service provider P among t+1 service providers i Generate multiple first masks for other servers in the group Generate t first intermediate ciphertexts D corresponding to t other service parties based on the following formula i,j :For example, using Paillier encryption and calculation where enc j Indicates that the ciphertext and the service provider P j The homomorphic public key of the server P i The t first intermediate ciphertexts D can be broadcasted or uploaded to the blockchain system. i,j Provided to other t service providers.

[0266] Each service provider P among t+1 service providers i A plurality of second masks are also generated for other servers in the group Generate t second intermediate ciphertexts corresponding to t other service parties based on the following formula For example, using Paillier encryption and calculation where enc j Indicates that the ciphertext and the service provider P j The homomorphic public key of the server P i The t second intermediate ciphertexts can be broadcasted or uploaded to the blockchain system. Provided to other t service providers.

[0267] In step S311, each service party sends a transaction Tx6 to call the contract to the blockchain system, and uploads the first intermediate ciphertext and the second intermediate ciphertext corresponding to each other service party.

[0268] In step S313, transaction Tx6 is executed in the blockchain system, and an event is generated. The event includes account Account1, and the first intermediate ciphertext and the second intermediate ciphertext corresponding to each other service provider account.

[0269] In step S315, each service account uses its own homomorphic private key to decrypt the first intermediate ciphertext and the second intermediate ciphertext corresponding to itself to obtain the first intermediate plaintext and the second intermediate plaintext.

[0270] Service provider P i Received from other service providers P j Provided first intermediate ciphertext D j,i =enc i (γ j ·k i -β j,i ) After that, use your own homomorphic private key to decrypt each first intermediate ciphertext to obtain multiple first intermediate plaintexts α i,j =γ j ·k i -β j，i Service provider P i Received from other service providers P j Provided second intermediate ciphertext Afterwards, use your own homomorphic private key to decrypt each second intermediate ciphertext to obtain multiple second intermediate plaintexts

[0271] For example, take service provider P1 as an example:

[0272] P1 randomly selects the first mask number β between the service parties for P2 1,2 , using Paillier encryption, calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 1,2 Provided to P2; similarly, P1 randomly selects a first mask number β between the service parties for P3 1,3 , calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 1,3 Provided to P3, P1 can similarly generate the first intermediate ciphertext for other service parties, which will not be repeated here.

[0273] P2 randomly selects the first mask number β between the service parties for P1 2,1 , using Paillier encryption and computing the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 2,1 Provided to P1; similarly, P2 randomly selects a first mask number β between the service parties for P3 2,3, calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 2,3 Provided to P3.

[0274] P3 randomly selects the first mask number β between the service parties for P1 3,1 , using Paillier encryption and computing the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 3,1 Provided to P1; similarly, P3 randomly selects a first mask number β between the service parties for P2 3,2 , calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 3.2 Provided to P2.

[0275] In this way, P1 can receive D 2,1 、D 3,1 , thus, P1 can decrypt and obtain the first intermediate plaintext γ2·k1-β 2,1 =α 1,2 ,γ3·k1-β 3，1 =α 1,3 etc.

[0276] After completing step S315, the preprocessing process ends. The blockchain system can also determine whether to repeat the preprocessing process shown in Figure 3 based on the above parameters min and max. After executing each of the above transactions Tx6, the blockchain system determines whether the number of preprocessing processes maintained in the contract status has reached the maximum. If not, the preprocessing process shown in Figure 3 is executed again. If the maximum has been reached, the preprocessing phase is determined to be complete.

[0277] FIG4 is a flow chart of the signature phase in the distributed threshold signature in one embodiment of this specification.

[0278] As shown in FIG4 , in step S401 , the administrator device sends a transaction Tx7 to the blockchain system to call the signature contract, requesting the generation of a signature for the certificate content of the CA contract. The sending account of the transaction Tx7 is account Account1.

[0279] The certificate can be the RootCA or Intermediate CA of the CA contract. In the case that the CA contract will adopt the self-signed RootCA mode, the administrator device will generate the certificate content of the RootCA, extract the summary of the certificate content (such as the hash value), and put the summary into the transaction Tx7 for requesting the signature of the certificate content. The certificate content may include description information of the CA contract, public key information, validity period information, etc. The public key information includes the public key currently corresponding to Account1 stored in the signature contract. In the case that the CA contract will adopt the intermediate CA mode, the administrator device will generate a certificate signing request (CSR), extract the summary of the CSR, and put the summary into the transaction Tx7 for requesting the signature of the CSR. The CSR may include description information of the CA contract, public key information, etc.

[0280] In step S403, the blockchain system executes transaction Tx7 and generates a first signature event.

[0281] When executing transaction Tx7, the blockchain system reads Table 1 from the contract state of contract C1 to determine whether there is a row corresponding to account Account 1 in Table 1. If a row corresponding to account Account 1 is found, the permission verification passes. Otherwise, if no row corresponding to Account 1 is stored in the row, the transaction is determined to be unauthorized to obtain a signature.

[0282] After the permission verification is passed, each node in the blockchain system executes transaction Tx7, generates a first signature event, and stores this first signature event in the blockchain as a receipt for transaction Tx7, which is then pushed to each service provider. This first signature event includes the account Account1, the target message (i.e., the certificate content of the CA contract), and a specific topic (e.g., "sign1").

[0283] In step S405, the blockchain system pushes the first signature event to each service provider in response to the event subscription of each service provider.

[0284] The n service providers can negotiate to enter the signing phase by forming several groups of service providers, each group comprising t+1 of the n service providers. These groups can subscribe to events with a topic such as "sign1" from one or more nodes in the blockchain system. Upon determining that the receipt for transaction Tx7 includes an event with the topic "sign1," these one or more nodes push the receipt to the subscribed service providers. The following description uses a group of service providers as an example.

[0285] In step S407, each of the t+1 service providers generates an intermediate value fragment based on its own first random number, second random number, first intermediate plaintext and first mask number corresponding to the other t service providers, and generates an intermediate value fragment based on its own first random number, private key fragment x′ i , the second intermediate plaintext and second mask corresponding to the other t service parties respectively, generate the private key fragment x″ i .

[0286] Each service provider P i The median value fragment δ can be calculated by the following formula i :

[0287] For example, taking t=2 as an example, assuming that the blockchain system selects a group of service providers including P1-P3, for service providers P1-P3:

[0288] P1 randomly selects the first mask number β between the service parties for P2 1,2 , using Paillier encryption, calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 1,2 Provided to P2; similarly, P1 randomly selects a first mask number β between the service parties for P3 1,3 , calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 1,3 Provided to P3.

[0289] P2 randomly selects the first mask number β between the service parties for P1 2,1 , using Paillier encryption and computing the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 2,1 Provided to P1; similarly, P2 randomly selects a first mask number β between the service parties for P3 2,3 , calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 2,3 Provided to P3.

[0290] P3 randomly selects the first mask number β between the service parties for P1 3,1 , using Paillier encryption and computing the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D 3，1 Provided to P1; similarly, P3 randomly selects a first mask number β between the service parties for P2 3,2 , calculate the first intermediate ciphertext And by broadcasting or uploading to the blockchain system, D3.2 Provided to P2.

[0291] In this way, P1 can receive D 2,1 、D 3，1 , thus, P1 can decrypt to get γ2·k1-β 2,1 =α 1,2 ,γ3·k1-β 3,1 =α 1,3 , and then, P1 can calculate the intermediate value fragment

[0292] Similarly, P2 can receive D 1,2 、D 3，2 , thus, P2 can decrypt to get γ1·k2-β 1,2 =α 2,1 ,γ3·k2-β 3,2 =α 2,3 , and then, P2 can calculate the intermediate value fragment

[0293] P3 can receive D 1，3 、D 2，3 , thus, P3 can decrypt to get γ1·k3-β 1，3 =α 3，1 ,γ2·k3-β 2，3 =α 3，2 , and then, P3 can calculate the intermediate value fragment

[0294] Each service provider P i The private key shard can be updated again using the following formula:

[0295] In step S409, each of the t+1 service providers sends a transaction Tx8 to the blockchain system to call contract C1 to upload the intermediate value shard and its corresponding t+1 service provider accounts.

[0296] In step S411, the blockchain system executes transaction Tx8 and pushes the sending service provider's account, the intermediate value shard, and its corresponding t+1 service provider accounts to other service providers.

[0297] Specifically, by executing transaction Tx8 in the blockchain system, an event is generated including the account of the sending service party, the intermediate value shard and its corresponding t+1 service party accounts, and as described above, in response to the subscription of each service party to the event, the event is pushed to each service party.

[0298] In step S413, each service provider generates an intermediate value based on the collected intermediate value fragments, generates r in the signature, and generates the intermediate value based on the first random number k. i , the message digest m, r and private key shard to be signed, generate the signature shard.

[0299] Specifically, for the t+1 service providers selected by the blockchain system, the service provider P i After receiving δ from other t service providers i Afterwards, the t+1 δ can be calculated as shown in the following formula: i Take the sum and get the intermediate value δ:

[0300] It can be easily verified that:

[0301] For example, taking t=2 as an example, δ=δ1+δ2+δ3 =γ1·k1+(γ2·k1-β 2，1 +β 1,2 +γ3·k1-β 3,1 +β 1，3 )+γ2·k2+(γ1·k2-β 1,2 + β 2,1 +γ3·k2-β 3,2 +β 2，3 )+γ3·k3+(γ1·k3-β 1，3 +β 3,1 +γ2·k3-β 2，3 +β 3，2 ) = γ1·k1+γ2·k1+γ3·k1+γ2·k2+γ1·k2+γ3·k2+γ3·k3+γ1·k3+γ2·k3 = (k1+k2+k3)(γ1+γ2+γ3)=kγ

[0302] The server can then perform the following calculation to generate r in the signature:

[0303] Among them, (a1, a2) are the coordinates of point R, so we can get r = a1.

[0304] Afterwards, the service provider P i The first random number k based on itself i , the target message digest m, r and its own private key fragment x″ i , generate signature fragment σ i =k i m+x″ i r.

[0305] In step S415, each service provider P in the t+1 service provider iSend the contract call transaction Tx9 to the blockchain system to upload its signature shard σ i , the transaction includes the corresponding account Account1.

[0306] In step S417, the blockchain system executes transaction Tx9, generates an event including the signature shard and its corresponding service provider account, stores the event in the blockchain system, and pushes the event to other service providers in response to their subscription to the event.

[0307] In step S419, each service provider determines whether the signature fragments of t+1 service providers are collected.

[0308] Each service provider may periodically determine whether the signature fragments of t+1 service providers have been collected, or determine whether the signature fragments of at least t+1 service providers have been collected after a preset time from the start of the signing phase.

[0309] If the judgment result is yes, step S421 is executed to generate s in the signature based on the t+1 (or at least t+1) signature fragments.

[0310] Specifically,

[0311] in,

[0312] In step S423, after generating s, any service provider among the t+1 service providers sends a transaction Tx10 to call the contract to the blockchain system and uploads r and s in the signature.

[0313] In step S425, the blockchain system uses the signature public key corresponding to account Account1 to verify the signature. If the verification passes, step S427 is executed to push the signature to the administrator device.

[0314] Since s here is essentially the same as formula (a) in the aforementioned ECDSA signature algorithm, it is obvious that the total public key X can be used for verification.

[0315] It should be noted that the above example mainly uses the case where there are exactly t+1 service providers. In fact, there may be more than t+1 service providers. In the case where there are more than t+1 service providers, for example, there are t+2 service providers, since x′1+x′2+…+x′ t+1 +x′ t+2 It is still equal to x, so the sum of the private key shards of the t+2 service parties is still equal to k·H(m)+k·x·r.

[0316] In the case where the preprocessing phase includes multiple preprocessing processes, the number of groups of preprocessed data is maintained in the row of account Account1 in table Table1 in the contract status. Each group of preprocessed data corresponds to a preprocessing process. That is, after each preprocessing process is completed, the number of groups of preprocessed data is increased by 1. After the signing phase using a group of preprocessed data as shown in Figure 4, step S403 also includes decrementing the number of groups of preprocessed data by 1 and determining whether the number of groups of preprocessed data is less than the above-mentioned parameter min. If it is less than the above-mentioned parameter min, the blockchain system sends a preprocessing event to the n off-chain service providers, causing the process shown in Figure 3 to be repeated until the number of groups of preprocessed data reaches the parameter max.

[0317] It will be appreciated that steps S403-S421 in FIG. 4 (i.e., the steps included in the dashed box in FIG. 4 ) illustrate an example process in which at least t+1 service parties exchange information based on the blockchain system to generate a signature for the target message. The embodiments of this specification are not limited to generating signatures through the interactive process shown in steps S403-S421 in FIG. 4 ; for example, the blockchain system may interact with at least t+1 service parties in different ways, depending on different distributed signature protocols.

[0318] If the administrator device obtains the signature of the root CA of the CA contract, it can assemble the root CA based on the signature and the root CA certificate content. If the administrator device obtains the signature of the CSR of the CA contract, it can assemble the complete CSR based on the signature and the CSR content, and submit the complete CSR to the superior CA for issuance of an intermediate CA. The intermediate CA may include the description information of the CA contract, public key information, the signature of the CA contract on the description information and public key information, validity period information, serial number, and the signature of the superior CA on all of the above information.

[0319] FIG5 is a flow chart of the pre-processing stage in another embodiment of the present specification.

[0320] As shown in FIG5 , in step S501 , the blockchain system pushes a first pre-processing event p1 to n off-chain service providers respectively.

[0321] This step can refer to the description of step S301 above and will not be repeated here.

[0322] In step S503, each service provider P i Update the private key shard and generate the first random number k i and the second random number γ i , the first random number k i The homomorphic ciphertext and the second random number γ i The random public key.

[0323] Each service provider P i The above Lagrange coefficient can be used to update the private key fragment x′ i ←l i (0)·ω i .

[0324] For example, for service provider P1, The private key shards of the service provider P1 are all updated to x′1←3·ω1.

[0325] For the service provider P2, The private key shards of the service provider P2 are all updated to x′2←-3·ω2.

[0326] For the service provider P3, The private key shards of the service provider P3 are all updated to x′3←1·ω3.

[0327] For the service provider P4, The private key shards of the service provider P4 are all updated to x′4←-1·ω4.

[0328] Other service providers P i The private key shard can be updated similarly and will not be described here.

[0329] Each service provider generates a random number k i and random number γ i , random number k i Homomorphic ciphertext and random number γ i The process of obtaining the random number public key can refer to the description of step S303 above and will not be repeated here.

[0330] In step S505, each service sends a transaction Tx5′ to the blockchain system to call contract C1 to upload the random number k i Homomorphic ciphertext and random number γ i The random public key.

[0331] In step S507, the blockchain system executes transaction Tx5′ and generates a random number k including the service party. i Homomorphic ciphertext and random number γ i In response to other service providers subscribing to the event, the event is pushed to other service providers.

[0332] When executing transaction Tx5′, the blockchain system also maintains the number of received transactions Tx5 in the contract state of contract C1. That is, each time a transaction Tx5′ is executed, the number is increased by 1.

[0333] In step S509, the blockchain system also determines whether it has received the homomorphic ciphertext and random number public key of at least k service parties based on the pre-stored parameter k corresponding to the account Account1.

[0334] In one embodiment, after executing and completing a transaction Tx5′ each time, the blockchain system determines whether transactions Tx5′ from k service parties have been received based on a pre-stored parameter k corresponding to the account Account1.

[0335] In another embodiment, a timeout period corresponding to the preprocessing process can be set in contract C1. After each execution of a transaction Tx5′, the blockchain system determines whether the preprocessing process has exceeded the timeout period based on the timestamp recorded in the blockchain system. If the timeout period has exceeded, it determines whether transactions Tx5′ from at least k service parties have been received. If the determination result is yes, the next round of interaction in the preprocessing process is entered; otherwise, the preprocessing process is determined to be invalid.

[0336] When the blockchain system determines that it has received transactions Tx5′ from at least k service parties, it executes step S511 to push the second pre-processing event p2 to the at least k service parties respectively.

[0337] The second preprocessing event p2 may include the account Account1 and a field indicating the second round of the preprocessing phase, so as to instruct the at least k service parties to continue the second round of interaction in the preprocessing process corresponding to the account Account1.

[0338] In the blockchain system, contract C1 controls the progress of the preprocessing process based on the threshold k, so that there is no need to collect data from all n service providers. Instead, some of the n service providers are allowed to go offline during the preprocessing stage. At the same time, at least some of the k service providers are allowed to go offline after entering the signing stage, thereby ensuring the overall availability of the service.

[0339] In step S513, each service provider P among at least k service providers i Select the first mask for other servers and the second mask number A second random number based on itself γ i , the homomorphic ciphertext K of other service providers j , the homomorphic ciphertext enc corresponding to the first mask j (-β i,j ), generate the first intermediate ciphertext for other service parties Shard x′ based on its own private key i , the homomorphic ciphertext K of other service providersj , the homomorphic ciphertext corresponding to the second mask Generate a second intermediate ciphertext for other service parties

[0340] In step S515, each of the at least k service providers P i Send a contract-invoking transaction Tx6' to the blockchain system, uploading the first intermediate ciphertext generated by the service provider and the second intermediate ciphertext corresponding to each other service provider. Transaction Tx6' includes account Account1, the service provider account sending transaction Tx6, and the first and second intermediate ciphertexts corresponding to each other service provider.

[0341] In step S517, the blockchain system executes transaction Tx6′, generates an event corresponding to the transaction, stores the first intermediate ciphertexts and second intermediate ciphertexts calculated by the service party for other service parties in the event, and pushes the event to each service party in response to the subscription of each service party.

[0342] In step S519, each of the at least k service providers P i Decrypt using your own homomorphic private key Decrypt each first intermediate ciphertext D corresponding to yourself using your own homomorphic private key j,i =enc i (γ j ·k i -β j,i ) and the second intermediate ciphertext Get the first intermediate plaintext α i,j =γ j ·k i -β j,i and the second intermediate plaintext

[0343] After completing step S517, the blockchain system can determine whether to loop the preprocessing process shown in Figure 5 again based on the parameter max, similar to the process shown in Figure 3. Therefore, by looping the process shown in Figure 5 max times, multiple sets of preprocessing data can be prepared in advance on each service party, thereby ensuring the high availability of the signature function.

[0344] FIG6 is a flowchart of the signature phase in the distributed threshold signature in another embodiment of this specification.

[0345] As shown in FIG6 , in step S601 , the administrator device sends a transaction Tx7′ to the blockchain system to call a signature contract, requesting the generation of a signature for the target message (e.g., the CA contract certificate content).

[0346] This step can refer to the description of step S401 above and will not be repeated here.

[0347] In step S603, the blockchain system executes transaction Tx7′ and generates a first signature event, which includes the account Account1 with signing authority.

[0348] In step S605, the blockchain system pushes the first signature event to each service provider based on the subscription of each service provider.

[0349] In step S607, each service party that receives the first signature event s1 generates u intermediate value fragments based on its own first random number, second random number, u groups of first intermediate plaintexts and first mask corresponding to u groups of service parties, and generates u intermediate value fragments based on its own first random number, private key fragment x′ i , u groups of second intermediate plaintexts and second masks corresponding to u groups of service providers, generate u private key fragments x″ i .

[0350] Assume that n service providers can form at most q service provider groups, where each service provider group includes at least t+1 service providers. The following description takes a group of service providers including t+1 service providers as an example. For service provider P i For example, among the q groups of service providers, there are d groups of service providers including service provider P i .

[0351] For example, for n=7, t=2, 7 service parties can form a maximum of Group service providers, including, for example, the following 10 groups of service providers:

[0352] (1) P1, P2, P3;

[0353] (2) P1, P2, P4;

[0354] (3) P1, P2, P5;

[0355] (4) P1, P3, P4;

[0356] (5) P1, P3, P5;

[0357] (6) P1, P4, P5;

[0358] (7) P2, P3, P4;

[0359] (8) P2, P3, P5;

[0360] (9) P2, P4, P5;

[0361] (10) P3, P4, P5;

[0362] …

[0363] Among the 35 service providers mentioned above, The group of service providers includes service provider P i .

[0364] Each service provider that receives the first signature event s1 can randomly select u groups from the above d groups of service providers including itself (each service provider group includes t+1 service providers), and generate intermediate value fragments and private key fragments for the u groups respectively.

[0365] Specifically, for one of the u groups of service providers, each service provider is based on its own first random number k i , the second random number γ i , the first intermediate plaintext α corresponding to the other t service providers i,j and the first mask number β i,j , generate intermediate value fragments The first random number k based on itself i , private key shard x′ i , the second intermediate plaintext corresponding to the other t service providers and the second mask number Generate an updated private key shard

[0366] In step S609, each service provider P i Send transaction Tx8′ to the blockchain system to call contract C1, upload the calculated u intermediate value shards and their corresponding t+1 service provider accounts.

[0367] In step S611, the blockchain system executes the transaction Tx8′ and generates an event corresponding to the transaction Tx8′, including the service provider P i The account, u intermediate value shards and their corresponding t+1 service provider accounts, push the event to each service provider based on their subscription to the event.

[0368] Multiple service parties that receive the first signature event s1 may execute steps S607-S611 multiple times. When each service party executes step S607 for the second time, it may determine several service party groups selected for this processing based on the service party groups corresponding to the intermediate value fragments generated by other service parties. This allows each service party to avoid exhaustively performing calculations on the d groups it belongs to, and to have a greater probability of gathering data for a service party group when subsequently generating the intermediate value or signature component s.

[0369] In step S613, each service provider generates p intermediate value slices based on the collected p groups of intermediate value slices. Obtain the random number public keys of t+1 service parties corresponding to each of the p intermediate values, generate r in the p signatures, and generate p signature fragments based on the first random number, the summary of the data to be signed, the p r's, and the p private key fragments corresponding to the p r's.

[0370] Specifically, assuming that the service provider P1 collects the three intermediate value fragments corresponding to the above-mentioned group (1) of service providers, namely, δ1 corresponding to group (1) calculated by service provider P1, δ2 corresponding to group (1) calculated by service provider P2, and δ3 corresponding to group (1) calculated by service provider P3, service provider P1 can generate the intermediate value corresponding to group (1) For the above-mentioned group (2) of service providers, service provider P1 collects δ1 corresponding to group (2) calculated by service provider P1, δ2 corresponding to group (2) calculated by service provider P2, and δ3 corresponding to group (2) calculated by service provider P3, and generates the intermediate value δ corresponding to group (2). And so on.

[0371] Service provider P i After generating p intermediate values, obtain the random number public keys Γ of t+1 service providers corresponding to each of the p intermediate values ​​δ i , generate r of the p signatures.

[0372] Referring to the description of step S413 above, for each intermediate value δ, the blockchain system can obtain the random number public key Γ of the t+1 service providers corresponding to the intermediate value i , based on the formula Calculate r corresponding to this intermediate value.

[0373] For example, as described above, after generating the intermediate value corresponding to group (1), service provider P1 can obtain the random number public keys Γ1, Γ2, and Γ3 of service providers P1, P2, and P3 respectively and calculate R according to the above formula to obtain r corresponding to group (1).

[0374] Afterwards, the service provider P i Based on the first random number k i , the target message digest m, p r and p private key fragments x″ corresponding to the p r i , generate p signature fragments.

[0375] Specifically, the service provider P i You can get x″ generated for the service provider of group (1) for example i , then based on the formula σ i =k i H(m)+x″ i r, calculate the signature fragment σ corresponding to the first group of service providers i .

[0376] In step 615, each service party sends a transaction Tx9′ to the blockchain system to call contract C1 to upload p signature shards and the t+1 service party accounts corresponding to each signature shard. This transaction Tx9′ includes account Account1.

[0377] Taking service provider P1 as an example, service provider P1 sends transaction Tx9′ to the blockchain system, uploading several signature shards corresponding to several groups of service providers, and each service provider account in a group of service providers corresponding to each signature shard.

[0378] In step S617, the blockchain system executes transaction Tx9′ and generates an event corresponding to transaction Tx9′. The event includes the service party account that sent transaction Tx9′, p signature shards, and t+1 service party accounts corresponding to each signature shard. In response to each service party's subscription to the event, the event is pushed to each service party that subscribes to the event.

[0379] In step S619, each service provider determines whether the signature fragments corresponding to any group of t+1 service providers are collected.

[0380] Each service provider may determine whether the signature fragments of any group of service providers have been collected after a preset period of time has passed after any signature fragment is generated, or may determine whether the signature fragments of any group of service providers have been collected every preset period of time after any signature fragment is generated. For example, assuming that service providers P1, P2, and P3 have all sent transaction Tx9′ to the blockchain system, service provider P1 has generated signature fragment σ1 corresponding to group (1) and has received signature fragments σ2 and σ3 of service providers P2 and P3 corresponding to group (1) from the blockchain system, thereby determining that the signature fragments corresponding to group (1) of service providers have been collected.

[0381] In step S621, after determining that the signature fragments of any group of t+1 service providers have been collected, any service provider generates s in the signature based on the t+1 signature fragments corresponding to the group of service providers.

[0382] In step S623, any service party sends a transaction Tx10′ to the blockchain system to call the contract C1 to upload r and s in the signature. The transaction 10′ may include the account Account1.

[0383] In step S625, the blockchain system uses the signature public key corresponding to account Account1 to verify the signature and determine whether the verification is successful.

[0384] In step S627, if the signature verification passes, the blockchain system returns the signature to the administrator device.

[0385] Steps S621-S627 can refer to the above description of steps S421-S427 and will not be repeated here.

[0386] Similar to the process shown in Figure 4, in the blockchain system, after each signature of account Account1, a set of pre-processed data corresponding to account Account1 can be deleted in the contract state, and based on the number of remaining sets of pre-processed data, it is determined whether to loop the pre-processing process again.

[0387] It will be appreciated that steps S603-S621 in FIG. 6 (i.e., the steps included in the dashed box in FIG. 6 ) illustrate an example process in which the blockchain system generates a signature for a target message by interacting with multiple service providers. The embodiments of this specification are not limited to generating signatures through the interactive process shown in steps S603-S621 in FIG. 6 ; for example, the blockchain system may interact with multiple service providers in different ways, depending on different distributed signature protocols.

[0388] FIG7 is a flow chart of a method for deploying a CA contract in an embodiment of this specification.

[0389] As shown in FIG7 , in step S701 , the administrator device sends a transaction Tx11 for deploying the CA contract to the blockchain system.

[0390] In addition to the contract code of the CA contract, the transaction Tx11 may also include the following:

[0391] The root CA or intermediate CA of the CA contract, used to prove the validity of the CA contract;

[0392] A list of several CA administrator accounts;

[0393] The contract address of the signature contract, used to submit signature requests to the signature contract.

[0394] In step S703, the blockchain system executes transaction Tx11 and deploys the CA contract.

[0395] Specifically, each node in the blockchain system generates the contract address of the CA contract based on transaction Tx11, and stores the contract code of the CA contract, the root CA or intermediate CA of the CA contract, the account list of several CA administrators, and the contract address of the signature contract in association with the contract address of the CA contract in the state database.

[0396] In step S705, the administrator device sends a transaction Tx12 to the blockchain system to call the signature contract and transfer the distributed key corresponding to the account Account1 to the CA contract.

[0397] Transaction Tx12 is issued by the administrator account Account1, calling the Transfer function of the signature contract, for example. The input parameters of the Transfer function include Account1 and the contract address of the CA contract, so as to transfer the distributed key corresponding to Account1 to the CA contract. Specifically, when the blockchain node executes transaction Tx12, it first determines whether the table Table1 in the contract state of the signature contract includes a row corresponding to the sender of transaction Tx12. If not, it means that the sender does not have the authority to transfer the key. If it is included, the Account1 in the row corresponding to the sender (i.e., Account1) in the table Table1 in the contract state of the signature contract is updated to the contract address of the CA contract (e.g., Account3). After this transfer, the initialization node in the embodiment of this specification is completed, and the CA contract can start providing certificate services.

[0398] In another embodiment, the administrator device may call the signing contract in the transaction for deploying the CA contract, and include the CSR to be signed, to directly apply to the signing contract for the distributed key corresponding to the CA contract, and instruct the signing contract to sign the CSR based on the distributed key and return the signature to the CA contract. After receiving the signature, the CA contract, in the self-signed RootCA mode, assembles the root certificate of the CA contract based on the signature and stores the root certificate in the contract state of the CA contract. In the intermediate certificate mode, the CA contract assembles the complete CSR based on the signature, and the CA administrator submits the complete CSR to the upper-level CA for signature, thereby obtaining the intermediate CA, and stores the intermediate CA in the contract state of the CA contract.

[0399] Specifically, the administrator device may send a transaction Tx11′ for deploying the CA contract to the blockchain system. The transaction Tx11′ includes the CA contract certificate content of the CA contract, the call to the signature contract, and the information of parameters n and t. The transaction Tx11′ may also include the accounts of several CA administrators. The administrator device verifies whether the sending account of the transaction Tx11′ is the administrator account. If the verification is passed, the administrator device provides the summary of the CA contract certificate content, the information of the parameters n and t, and the contract account of the CA contract to the signature contract. The administrator device associates the CA contract account with the summary of the CA contract certificate content and the information of the parameters n and t in the contract state of the signature contract, instructing n service parties to enter the key generation phase.

[0400] Each of the n service-side devices generates its own first private key shard and signature public key based on the distributed key generation protocol, and sends a transaction Tx12′ invoking the signature contract to the blockchain system;

[0401] The blockchain system stores the signature public key in association with the CA contract account in the contract state of the signature contract according to the transaction Tx12′; instructs at least t+1 service parties among the n service parties to sign the contents of the CA contract certificate;

[0402] The devices of the at least t+1 service providers perform distributed threshold signatures, so that the device of any of the at least t+1 service providers generates a signature for the contents of the CA contract certificate, and returns the signature to the blockchain system by sending a transaction Tx13′ that calls a signature contract to the blockchain system. The signature is generated based on a digest of the contents of the CA contract certificate and a shard of the private key of each of the at least t+1 service providers, and the contract account of the CA contract is included in the transaction Tx13′.

[0403] The blockchain system returns the signature to the CA contract based on the contract account of the CA contract in transaction Tx13′; stores the certificate of the CA contract in the contract state of the CA contract, and the certificate of the CA contract includes the CA contract certificate content and the signature.

[0404] After completing the above initialization phase, the CA contract can provide certificate services, such as issuing CA certificates, revoking CA certificates, etc.

[0405] FIG8 is a flow chart of a certificate issuance method in an embodiment of this specification.

[0406] As shown in FIG8 , first in step S801 , the user device sends a transaction Tx13 that calls the CA contract to the blockchain system to send a certificate issuance request.

[0407] The user first generates their public-private key pair and then generates a CSR based on their public key. This CSR includes the required certificate content and the user's public key. The certificate content may include, for example, the user's identity information, user device information, and certificate expiration date. Transaction Tx13 calls the CA contract and passes the generated CSR to the CA contract to request the issuance of the user's certificate.

[0408] In step S803, the blockchain system executes transaction Tx13 and stores the certificate issuance request.

[0409] The blockchain system can store the CSR in the contract state of the CA contract based on transaction Tx13.

[0410] Specifically, the CSR may be stored in a pending approval queue in the contract status of the CA contract.

[0411] In step S805, the blockchain system sends the CSR to be approved to several CA administrator devices for approval.

[0412] The blockchain system can send the pending CSRs in the pending approval queue to the devices of each CA administrator based on a list of CA administrator accounts stored in the CA contract. In one embodiment, each CA administrator device can request to read the pending CSRs in the pending approval queue by sending a transaction to the blockchain system to invoke the CA contract. Based on this transaction, if the blockchain system determines that the sending account of the transaction is a CA administrator account, it can read the pending CSRs in the contract status of the CA contract and return the pending CSRs in the queue to the CA administrator device.

[0413] In step S807 , the CA administrator device obtains the approval result of the CSR.

[0414] Each CA administrator can review and approve the CSR received by the CA administrator device and input the review and approval result into the CA administrator device.

[0415] In step S809, each CA administrator device sends a transaction Tx14 that calls the CA contract to the blockchain system to upload the approval result of the CSR.

[0416] Multiple CA administrator devices each send multiple transactions Tx14 to the blockchain system. It should be understood that these transactions Tx14 include transactions sent by each CA administrator device at that stage. Each Tx14 transaction is sent from the CA administrator's account and includes the CA administrator's approval result for the CSR.

[0417] In step S811, the blockchain system executes each transaction Tx14 and, based on the approval results in each transaction Tx14 and the pre-set rules, determines whether the CSR has been approved. If approved, an unsigned certificate is generated and its digest is provided to the signing contract to generate a signature event.

[0418] The preset rule is, for example, that each blockchain node in the blockchain system considers the CSR approved only when all CA administrators have approved it.

[0419] In the case of approval, each blockchain node obtains the serial number of the current certificate based on the serial number field in the contract status of the CA contract, and after obtaining the serial number of the current certificate, adds 1 to the serial number field in the contract status to ensure the uniqueness of the serial number of each certificate.

[0420] Afterwards, each blockchain node can generate an unsigned certificate corresponding to the CSR. The unsigned certificate may include, for example, the contents of the CSR (such as user information, user device information, user public key, etc.), the certificate validity period, and the certificate serial number. The certificate validity period is the time corresponding to the current block (such as the timestamp of the current block). If the CSR also includes the certificate expiration date, the unsigned certificate may also include the certificate expiration date.

[0421] It is understandable that steps S805-S809 in Figure 8 are not necessary steps. For example, the user device may first send the certificate issuance request to the CA administrator device. After the CA administrator device approves the certificate issuance request, the CA administrator device sends a transaction to the blockchain system to call the CA contract to upload the certificate issuance request to the CA contract. In this case, in step S811, an unsigned certificate can be generated directly based on the transaction sent by the CA administrator. In another embodiment, an approval logic different from steps S805-S809 can be set in the contract code of the CA contract. For example, after pushing the certificate issuance request to be approved to the CA administrator device, if it is determined that the user meets the preset conditions, the certificate can be issued to the user first, without waiting for the CA administrator device to return the approval result before issuing the certificate.

[0422] Afterwards, each blockchain node can calculate the digest (e.g., hash value) of the unsigned certificate and, based on the call to the signature contract in the CA contract, provide the digest of the unsigned certificate to the signature contract to request the generation of a signature for the unsigned certificate. Each blockchain node can then execute the signature contract and, based on the execution of the signature contract, first determine whether the CA contract has the authority to request a signature. That is, the blockchain node determines whether there is a row corresponding to the contract account of the CA contract in Table 1 in the contract state of the signature contract. If so, it determines that the CA contract has the authority. The blockchain node can then generate a signature event, which, for example, includes the digest of the unsigned certificate and the contract account of the CA contract to indicate that the signature request was made by the CA contract.

[0423] In step S813, in response to the subscription of multiple service providers among the n off-chain service providers to the signature event, the blockchain system pushes the generated signature event to each service provider that subscribes to the event.

[0424] In step S815 , at least t+1 service parties among the n service parties enter the signing phase in response to the signing event and generate signatures of the unsigned certificates.

[0425] The at least t+1 service parties may interact with each other through the process shown in FIG4 or FIG6 to generate a signature (r, s) for the unsigned certificate, which will not be described in detail here.

[0426] In step S817, after generating the signature, any one of the at least t+1 service providers sends a transaction Tx15 calling the signature contract to the blockchain system to upload the certificate signature. The transaction Tx15 includes the contract account of the CA contract.

[0427] In step S819, the blockchain system executes transaction Tx15, and after verifying the certificate signature, returns the certificate signature to the CA contract.

[0428] When executing transaction Tx15, each blockchain node obtains the signature public key corresponding to the CA contract from the contract status of the signature contract, and uses the signature public key to verify the certificate signature. If the verification passes, the certificate signature is returned to the CA contract by calling the CA contract.

[0429] In step S821, the blockchain system issues a certificate based on the certificate signature.

[0430] Specifically, each blockchain node can execute the CA contract based on the signature contract's call to the CA contract, assemble the signed and unsigned certificates into a certificate, and store the certificate in the CA contract's contract state. The certificate owner or verifier can obtain the certificate from the blockchain system.

[0431] In one embodiment, a revocation list is further stored in the contract status of the CA contract, and the revocation list includes serial numbers of revoked certificates.

[0432] When the CA administrators decide to revoke, for example, certificate CA1, each CA administrator can send a transaction Tx16 to the blockchain system, invoking the CA contract to request the revocation of certificate CA1. This transaction includes the serial number of certificate CA1. After executing each transaction Tx16, the blockchain system stores each CA administrator's revocation request in the contract state and determines whether to revoke certificate CA1 based on pre-set rules. For example, after all CA administrators send revocation requests for certificate CA1 to the blockchain system, the blockchain system determines that certificate CA1 has been revoked and adds the serial number of certificate CA1 to the revocation list to indicate that certificate CA1 has been revoked.

[0433] FIG9 is an architectural diagram of a node of a blockchain system in an embodiment of this specification. A CA contract and a signature contract are deployed in the blockchain system. The CA contract includes a call to the signature contract. The contract state of the signature contract stores a signature public key and information of parameters n and t in association with the account of the CA contract. The signature public key is generated by n service parties through a distributed key agreement. The node includes:

[0434] A receiving unit 91 is configured to receive a first transaction for invoking the CA contract, wherein the first transaction includes a user certificate issuance request;

[0435] A providing unit 92, configured to provide a summary of the user certificate content corresponding to the user certificate issuance request to the signature contract;

[0436] a signing unit 93 configured to, according to the signing contract, instruct at least t+1 service providers among the n service providers to generate a first signature for the content of the user certificate based on a private key fragment corresponding to the signature public key;

[0437] The receiving unit 91 is further configured to receive, from any one of the at least t+1 service providers, a second transaction for invoking the signature contract, wherein the second transaction includes the contract account of the CA contract and the first signature;

[0438] The issuing unit 94 is configured to return the first signature to the CA contract according to the second transaction, and issue a user certificate based on the first signature by executing the CA contract.

[0439] The embodiments of this specification also provide a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computer, the computer is caused to execute a method as shown in any one of FIG. 2 to FIG. 8 .

[0440] An embodiment of this specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the method shown in any of Figures 2 to 8 is implemented.

[0441] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using a hardware module. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system onto a PLD through their own programming, eliminating the need for a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0442] The controller can be implemented in any suitable manner. For example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0443] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude that with the future development of computer technology, the computer that implements the functions of the above embodiments may be, for example, a personal computer, a laptop computer, an in-vehicle human-computer interaction device, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0444] Although one or more embodiments of this specification provide method operation steps as described in the embodiments or flow charts, more or fewer operation steps may be included based on conventional or non-creative means. The order of steps listed in the embodiments is only one way of executing the order of many steps and does not represent the only execution order. When the device or terminal product in practice is executed, it can be executed in sequence or in parallel according to the method shown in the embodiments or the drawings (for example, a parallel processor or a multi-threaded processing environment, or even a distributed data processing environment). The term "comprise", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, product or equipment including a series of elements includes not only those elements, but also includes other elements that are not clearly listed, or also includes elements inherent to such process, method, product or equipment. In the absence of more restrictions, it is not excluded that there are other identical or equivalent elements in the process, method, product or equipment including the elements. For example, if the words first, second, etc. are used to represent the name, they do not represent any particular order.

[0445] For the convenience of description, the above devices are described in terms of functions divided into various modules. Of course, when implementing one or more of the present specifications, the functions of each module can be implemented in the same or multiple software and / or hardware, or the module that implements the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0446] The present invention is described with reference to the flowcharts and / or block diagrams of the methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more blocks in the block diagram.

[0447] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0448] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0449] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0450] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0451] Computer-readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0452] Those skilled in the art will appreciate that one or more embodiments of this specification may be provided as a method, system, or computer program product. Thus, one or more embodiments of this specification may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, one or more embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0453] One or more embodiments of this specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform specific tasks or implement specific abstract data types. One or more embodiments of this specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communications network. In distributed computing environments, program modules may be located in local and remote computer storage media, including storage devices.

[0454] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between the various embodiments can be referenced across them. Each embodiment focuses on the differences from the other embodiments. In particular, since the system embodiments are generally similar to the method embodiments, their description is relatively simple. For relevant parts, reference can be made to the description of the method embodiments. Throughout this specification, reference to the terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" means that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of this specification. In this specification, the schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, those skilled in the art may combine and integrate the different embodiments or examples, and features of different embodiments or examples, described in this specification, without conflict.

[0455] The foregoing is merely an example of one or more embodiments of this specification and is not intended to limit the one or more embodiments of this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of this specification shall be included within the scope of the claims.

Claims

1. A method for issuing a certificate based on a blockchain system, where a CA contract and a signature contract are deployed in the blockchain system, the CA contract includes a call to the signature contract, and in the contract state of the signature contract, a signature public key, and information of parameters n and t are stored in association with the account of the CA contract. The signature public key is generated by devices of n service providers through a distributed key protocol. The method includes: The blockchain system receives a first transaction that calls the CA contract, and the first transaction includes a user certificate issuance request; Providing a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract; According to the signature contract, instructing at least t + 1 of the n service providers to generate a signature corresponding to the signature public key; Devices of the at least t + 1 service providers perform distributed threshold signature, so that a device of any one of the at least t + 1 service providers generates a first signature for the user certificate content, and sends a second transaction that calls the signature contract to the blockchain system. The second transaction includes the contract account of the CA contract and the first signature; The blockchain system returns the first signature to the CA contract according to the second transaction, and issues a user certificate based on the first signature by executing the CA contract.

2. According to the method described in claim 1, the CA contract includes certificate approval logic, and the providing of the digest of the user certificate content corresponding to the user certificate issuance request to the signature contract includes: The blockchain system approves the user certificate according to the certificate approval logic, and provides a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract after the approval passes.

3. The method according to claim 2, where several CA administrator accounts are stored in the contract state of the CA contract. The blockchain system approving the user certificate according to the certificate approval logic includes: The blockchain system, by executing the first transaction, sends the user certificate issuance request to several CA administrator devices respectively, and the several CA administrator devices correspond to the several CA administrator accounts respectively; The method further includes: the several CA administrator devices send a third transaction that calls the CA contract to the blockchain system, and the third transaction includes an approval result of the user certificate issuance request; The providing a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract includes: In the case where the blockchain system determines that the approval of the user certificate issuance request passes according to the several third transactions, according to the call to the signature contract in the CA contract, providing a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract.

4. The method according to claim 1, further includes: The blockchain system receives a fourth transaction that calls the signature contract, and the fourth transaction is used to request to generate a distributed key corresponding to a first account. The first account is an external account, and the first transaction includes information of parameters n and t; Associate and store the information of the first account, the parameter n, and t into the contract state of the signature contract according to the first transaction, indicating that n service providers enter the key generation phase; The devices of the n service providers generate their respective first private key shards and signature public keys based on the distributed key generation protocol, and send a fifth transaction to call the signature contract to the blockchain system; The blockchain system stores the signature public key in the contract state of the signature contract in association with the first account according to the fifth transaction.

5. The method according to claim 4, wherein the method further comprises: The blockchain system receives a sixth transaction to call the signature contract, the sixth transaction is sent by the first account and is used to request to generate a signature for the content of the CA contract certificate, and the blockchain system instructs at least t + 1 of the n service providers to perform the signature according to the sixth transaction; The devices of the at least t + 1 service providers perform distributed threshold signature, so that any device among the devices of the at least t + 1 service providers generates a second signature for the content of the CA contract certificate, and returns the second signature to the blockchain system. The second signature is generated based on the digest of the content of the CA contract certificate and the first private key shards of each of the at least t + 1 service providers, and the blockchain system pushes the second signature to the device of the first administrator corresponding to the first account.

6. The method according to claim 5, after the blockchain system stores the signature public key in the contract state of the signature contract in association with the first account according to the fifth transaction, further comprising: The blockchain system instructs at least t + 1 of the n service providers to perform a preprocessing process; Each device of at least t + 1 of the n service providers generates a first random number and a second random number, calculates intermediate data based on the first random number and the second random number, and updates the first private key shard to obtain a second private key shard; The second signature is generated based on the digest of the content of the CA contract certificate, the intermediate data of each of the at least t + 1 service providers, the second private key shard, and the first random number.

7. The method according to claim 6, wherein the devices of the at least t + 1 service providers performing distributed threshold signature comprises: Each device of the at least t + 1 service providers generates a first signature component corresponding to the first account based on the intermediate data of the service provider; Generate a signature shard for the service provider based on the intermediate data of the service provider, the second private key shard, the first random number, the digest of the content of the CA contract certificate, and the first signature component; the devices of the at least t + 1 service providers respectively send their signature shards to the devices of the other service providers of the at least t + 1 service providers by sending a transaction to call the signature contract to the blockchain system; When the device of any one of the at least t + 1 service providers has collected the signature shards of each of the at least t + 1 service providers, a second signature component corresponding to the first account is generated based on the at least t + 1 signature shards.

8. The method according to claim 6, wherein the fifth transaction further includes a value of k, where n > k > t, each of the at least t + 1 service providers among the n service providers calculates intermediate data based on the first random number and the second random number, including: Devices of several service providers among the n service providers generate a homomorphic ciphertext of the first random number and a random number public key of the second random number, and send a seventh transaction for invoking the signature contract to the blockchain system. The seventh transaction includes the homomorphic ciphertext of the first random number and the random number public key of the second random number. Based on the seventh transaction, the blockchain system pushes the first account, the homomorphic ciphertexts of the first random numbers of each service provider, and the random number public keys of the second random numbers to other service providers. When the blockchain system determines that the number of received seventh transactions is greater than or equal to k, it instructs at least k service providers that sent the seventh transaction to continue the preprocessing process. Each device of the at least k service providers selects a first mask for each other service provider, and based on its own second random number, the homomorphic ciphertext of the first random number of other service providers, and the homomorphic ciphertexts corresponding to each first mask, generates a first intermediate ciphertext for each other service provider, sends a transaction for invoking the signature contract to the blockchain system, and sends the first intermediate ciphertext to the corresponding other service provider through the blockchain system; decrypts at least k - 1 first intermediate ciphertexts of at least k - 1 other service providers received to obtain at least k - 1 first intermediate plaintexts.

9. The method according to claim 6, wherein updating the first private key shard to obtain a second private key shard includes: Devices of at least t + 1 service providers among the n service providers respectively update the first private key shard based on Lagrange coefficients to obtain the second private key shard.

10. The method according to claim 6 further includes that the blockchain system receives an eighth transaction for deploying the CA contract. The eighth transaction is sent by the first account and includes the CA contract certificate, the accounts of the several CA administrators, and the account of the signature contract; verifies whether the first account is the account of the first administrator, and if the verification is passed, deploys the CA contract, and stores the CA contract certificate, the accounts of the several CA administrators, and the account of the signature contract in the contract state of the CA contract. The CA contract certificate includes the CA contract certificate content and the second signature.

11. The method according to claim 10 further includes: the blockchain system receives a ninth transaction for invoking the signature contract, the ninth transaction is sent by the first account and is used to transfer the key corresponding to the first account to the contract account of the CA contract; according to the ninth transaction, the contract state of the signature contract is updated to store the signature public key and the contract account of the CA contract in an associated manner.

12. The method according to claim 1 further comprises: The blockchain system determines, according to the first transaction, whether the signature public key corresponding to the account of the CA contract is stored in the contract state of the signature contract. In the case where the signature public key corresponding to the account of the CA contract is not stored in the contract state, the execution of the first transaction is ended.

13. The method according to claim 1, wherein the user certificate content includes a certificate effective time, and the certificate effective time is the time corresponding to the current block.

14. The method according to claim 1, wherein the user certificate content includes a certificate serial number determined by the CA contract.

15. The method according to claim 14, wherein a revocation list is stored in the contract state of the CA contract, and the method further includes: The blockchain system respectively receives a tenth transaction from the several CA administrator devices, and the tenth transaction includes a first serial number of a first certificate to be revoked. In the case where it is determined according to the several tenth transactions that the first certificate is to be revoked, the first serial number is added to the revocation list.

16. The method according to claim 1 further includes: The blockchain system receives an eleventh transaction for deploying the CA contract, and the eleventh transaction includes the CA contract certificate content of the CA contract, an invocation of the signature contract, and information on parameters n and t. Verify whether the sending account of the eleventh transaction is the first administrator account. In the case where the verification is passed, provide the digest of the CA contract certificate content, the information on the parameters n and t, and the contract account of the CA contract to the signature contract, and store the CA contract account, the digest of the CA contract certificate content, and the information on the parameters n and t in an associated manner in the contract state of the signature contract, and instruct n service parties to enter the key generation phase. Each device among the devices of the n service parties generates its own first private key shard and signature public key based on the distributed key generation protocol, and sends a twelfth transaction for invoking the signature contract to the blockchain system. The blockchain system stores the signature public key in an associated manner with the CA contract account in the contract state of the signature contract according to the twelfth transaction. Instruct at least t + 1 service parties among the n service parties to sign the CA contract certificate content. The devices of the at least t + 1 service providers perform distributed threshold signature, such that the device of any one of the at least t + 1 service providers generates a third signature for the content of the CA contract certificate, and returns the third signature to the blockchain system, where the third signature is generated based on the digest of the content of the CA contract certificate and the first private key shards of each of the at least t + 1 service providers; The blockchain system returns the third signature to the CA contract; Store the certificate of the CA contract in the contract state of the CA contract, where the certificate of the CA contract includes the content of the CA contract certificate and the third signature.

17. The method according to claim 1, wherein the blockchain system returns the first signature to the CA contract according to the second transaction includes: The blockchain system verifies the first signature using the signature public key according to the second transaction, and returns the first signature to the CA contract when the verification passes.

18. A method for issuing a certificate based on a blockchain system, executed by a node in the blockchain system, where a CA contract and a signature contract are deployed in the blockchain system, the CA contract includes a call to the signature contract, and information of a signature public key, and parameters n and t are stored in the contract state of the signature contract in association with the account of the CA contract, the signature public key is generated by n service providers through a distributed key protocol, and the method includes: Receiving a first transaction that calls the CA contract, where the first transaction includes a user certificate issuance request; Providing a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract; According to the signature contract, instructing at least t + 1 of the n service providers to generate a first signature for the user certificate content based on the private key shards corresponding to the signature public key; Receiving a second transaction that calls the signature contract from the device of any one of the at least t + 1 service providers, where the second transaction includes the contract account of the CA contract and the first signature; Returning the first signature to the CA contract according to the second transaction, and issuing a user certificate based on the first signature by executing the CA contract.

19. A certificate issuance system, including a blockchain system and multiple service provider devices, where a CA contract and a signature contract are deployed in the blockchain system, the CA contract includes a call to the signature contract, and information of a signature public key, and parameters n and t are stored in the contract state of the signature contract in association with the account of the CA contract, the signature public key is generated by n service providers through a distributed key protocol, The blockchain system is configured to: receive a first transaction that calls the CA contract, where the first transaction includes a user certificate issuance request; provide a digest of the user certificate content corresponding to the user certificate issuance request to the signature contract; according to the signature contract, instruct the service provider devices of at least t + 1 of the n service providers to generate signatures corresponding to the signature public key; The at least t + 1 service provider devices are configured to: perform distributed threshold signature such that a device of any one of the at least t + 1 service providers generates a first signature on the content of the user certificate, and send a second transaction invoking the signature contract to the blockchain system, where the second transaction includes the contract account of the CA contract and the first signature; The blockchain system is further configured to: return the first signature to the CA contract according to the second transaction, and issue a user certificate based on the first signature by executing the CA contract.

20. A node of a blockchain system, where a CA contract and a signature contract are deployed in the blockchain system, the CA contract includes an invocation of the signature contract, and in the contract state of the signature contract, a signature public key, and information of parameters n and t are stored in association with the account of the CA contract. The signature public key is generated by n service providers through a distributed key protocol. The node includes: a receiving unit, configured to receive a first transaction invoking the CA contract, where the first transaction includes a user certificate issuance request; a providing unit, configured to provide a digest of the content of the user certificate corresponding to the user certificate issuance request to the signature contract; a signing unit, configured to, according to the signature contract, instruct at least t + 1 of the n service providers to generate a first signature on the content of the user certificate based on private key shards corresponding to the signature public key; The receiving unit is further configured to receive, from a device of any one of the at least t + 1 service providers, a second transaction invoking the signature contract, where the second transaction includes the contract account of the CA contract and the first signature; an issuing unit, configured to return the first signature to the CA contract according to the second transaction, and issue a user certificate based on the first signature by executing the CA contract.

Images