CN110768781A

CN110768781A - Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation

Info

Publication number: CN110768781A
Application number: CN201910798814.7A
Authority: CN
Inventors: 富尧; 钟一民; 汪仲祥
Original assignee: Ruban Quantum Technology Co Ltd; Nanjing Ruban Quantum Technology Co Ltd
Current assignee: Ruban Quantum Technology Co Ltd; Nanjing Ruban Quantum Technology Co Ltd
Priority date: 2019-08-28
Filing date: 2019-08-28
Publication date: 2020-02-07
Anticipated expiration: 2039-08-28
Also published as: CN110768781B

Abstract

The application relates to a method and a system for issuing public and private keys based on a alliance chain and resisting quantum computation, which are implemented between alliance chain members and a User in mutual communication, and are characterized in that each party is provided with a key fob, and all the key fobs store respective private keys, public key pools and system management public keys; the member of the alliance chain comprises a plurality of Endorsers, Orderer and Committer which provide corresponding services, wherein the key card of each Endorser also stores a management private key and a management public key; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography; a management public key pool is also stored in the key fob of the User; when the parties communicate, the secret key card is used for carrying out encrypted communication based on ID cryptography, and the safety is further improved.

Description

Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation

Technical Field

The present application relates to the field of federation chains, and in particular, to a method and a system for issuing and issuing public and private keys based on federation chains and resisting quantum computation.

Background

The block chain is a brand new distributed infrastructure and a calculation paradigm, stores data by using an ordered chain data structure, updates the data by using a consensus algorithm, and ensures data security by using a cryptography technology. In blockchain based transactions, ensuring data security for the transaction and privacy for the customer is a necessary condition for the blockchain to be able to develop further. For this reason, cryptography, and in particular public key cryptography, is widely used in blockchains. The alliance chain is a branch of the block chain, so the alliance chain is a distributed and decentralized public database, and the alliance chain is the block chain which is different from other chains in that the alliance chain is directed to members of a specific group and limited third parties, a plurality of preselected nodes are designated as bookkeeping persons inside the alliance chain, and the consensus process of the preselected nodes is controlled by the preselected nodes.

As most people know, quantum computers have great potential in password cracking. The asymmetric (public key) encryption algorithms, such as the RSA encryption algorithm, which are mainstream today, are mostly based on two mathematical challenges, namely factorization of large integers or computation of discrete logarithms over a finite field. Their difficulty in breaking is also dependent on the efficiency with which these problems are solved. On a traditional computer, the two mathematical problems are required to be solved, and the time is taken to be exponential (namely, the cracking time increases in exponential order along with the increase of the length of the public key), which is not acceptable in practical application. The xiuer algorithm tailored for quantum computers can perform integer factorization or discrete logarithm calculation within polynomial time (i.e. the cracking time increases at the speed of k power along with the increase of the length of a public key, wherein k is a constant irrelevant to the length of the public key), thereby providing possibility for the cracking of RSA and discrete logarithm encryption algorithms.

The problems existing in the prior art are as follows:

1. ID cryptography and its digital signatures are easily cracked by quantum computers.

2. The risk that the private key of the private key generation server based on the ID cryptography is stolen is high, and since the private key generation server grasps the entire private key, the digital signatures of other users can be forged.

3. After the user updates the public key, other users need to query and acquire a new public key from a central server such as a CA, and the process is troublesome.

4. The public keys of all users need to be maintained by a central server similar to CA, and the DOS attack risk is higher

Disclosure of Invention

In view of the foregoing, it is desirable to provide a method and system for issuing public and private keys based on federation chain and resisting quantum computing.

A public and private key issuing method based on a alliance chain and resisting quantum computing is implemented between alliance chain members in mutual communication, each party is provided with a key fob, and all the key fobs store respective private keys, public key pools and system management public keys;

the key card of each Endorser also stores a management private key and a management public key; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography;

a management public key pool is also stored in the User key fob, the management public key pool comprises each management public key unit, and each management public key unit stores each Endorser identity, a management public key corresponding to the Endorer identity and a private key parameter;

the public and private key issuing method specifically comprises the following steps:

the User puts forward a transaction to a plurality of Endorsers, and the transaction information comprises a public key generation number generated by a key card of the User;

after the Endorser receives the transaction, calculating to obtain a private key component according to the public key generation number and the management private key, writing the private key component into a transaction response and sending the transaction response to the User;

the User acquires the private key component from the transaction response, and also makes an endorsement by using the effective transaction response and sends the endorsement to the Committer through the Orderer;

after the Committee receives the endorsement, a transaction notification is correspondingly generated and sent to the User, and the world state is updated according to the public key generation number acquired from the endorsement to complete the public key issuance;

and after receiving the transaction notification, the User calculates a private key by adopting a related formula according to the public key generation number, the private key components and the private key parameters related to the private key components to finish the private key issuing.

Preferably, the public key generation number is a public key random number or a partial public key generated based on the unlicensed cryptography.

Preferably, the User proposes a transaction to the enrser, the enrser responds to the transaction and performs corresponding operation, and then sends a transaction notification corresponding to a transaction result to the User, wherein an interactive message carries a signature for verification;

the generation mode of the signature is as follows:

mode A: the public key generation number is a public key random number, and the signature is generated based on an ID cryptography mode; or

Mode B: the public key generation number is a part of public keys generated based on the unlicensed cryptography, and the signature is generated based on the unlicensed cryptography.

Preferably, the method a specifically includes:

taking a value obtained by calculation according to the transaction content and the hash function as a key pointer random number;

acquiring a corresponding public key unit in a public key pool according to the key pointer random number, and acquiring a signature public key random number from the public key unit;

and calculating to obtain signature parameters according to the random number parameters generated in the key fob and the random number of the signature public key, and generating a signature according to the random parameters and the own private key.

Preferably, the receiving, by the enrorer, the transaction, and calculating the private key component according to the public key generation number and the system private key, further includes:

acquiring a corresponding key generation number in the public key pool according to the User identity identification, and calculating to obtain a User public key by using the key generation number and the User identity;

encrypting the private key component according to the User public key and the system management public key to obtain a private key component encrypted ciphertext;

and writing the private key component encrypted ciphertext into the content of a transaction response.

Preferably, after receiving the plurality of transaction responses, the User verifies each transaction response, and the obtaining the private key component from the transaction response verified as valid further includes:

correspondingly decrypting the encrypted ciphertext of the private key component in the transaction response to obtain the private key component;

and verifying the private key component, and reserving the private key component with correct verification.

Preferably, the User endorsements an Orderer with an effective transaction response further comprises:

acquiring a corresponding key generation number in the public key pool according to the Orderer identity identification, and calculating to obtain an Orderer public key by using the key generation number and the Orderer identity;

and encrypting the endorsement according to the Orderer public key and the system management public key to obtain the encrypted endorsement.

Preferably, after receiving the endorsement, the Orderer orders and sends the endorsement to the commatter, including:

correspondingly decrypting the encrypted endorsement according to the private key of the own party to obtain a decrypted endorsement;

sequencing the endorsements to obtain an endorsement set;

acquiring a corresponding key generation number in the public key pool according to the Committer identity, and calculating to obtain a Committer public key by using the key generation number and the Committer identity;

and encrypting the endorsement set according to the Committer public key and the system management public key to obtain the encrypted endorsement set.

Preferably, after receiving the endorsement, the commit further includes:

and correspondingly decrypting the encrypted endorsement set according to the private key of the own party to obtain the decrypted endorsement set.

The invention also provides a federation chain-based quantum computation resistant public and private key issuing system, which comprises federation chain members in mutual communication, wherein the federation members comprise a User and a plurality of Endorsers, Orderer and Committer which provide corresponding services, each party is provided with a key fob, and all the key fobs store respective private keys, public key pools and system management public keys; a management private key, a private key parameter and a management public key are stored in the key fob of each Endorser; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography; in the generation process of the management private key, the private key parameter and the management public key are correspondingly generated; a management public key pool is also stored in the User key card, the management public key pool comprises each management public key unit, and each management public key unit stores each Endorser identity, a management public key corresponding to the Endorser identity and a private key parameter;

the alliance chain and the user comprise memories and processors, computer programs are stored in the memories, and the processors realize the alliance chain-based quantum computing resistant public and private key issuing method when executing the computer programs.

According to the public and private key issuing method and system based on the alliance chain and resistant to quantum computation, the ID in the ID cryptography is changed into a form of adding a public key random number or a part of a public key to the ID, and the signature parameters are correspondingly improved, so that the signature parameters cannot be obtained by computation of an enemy, and the digital signature has high quantum security. And the private key of the private key server is stored in a distributed manner in a secret sharing manner, and the related public and private keys are respectively stored in the key fob, so that the risk of stealing the private key is greatly reduced. Neither private key server has access to the entire private key, which also improves overall security.

Drawings

FIG. 1 is a system diagram of a public-private key issuance method in one embodiment;

FIG. 2 is a diagram of the internal structure of an Endorser key fob in one embodiment;

FIG. 3 is an internal block diagram of a Client key fob in one embodiment;

fig. 4 is an internal block diagram of another blockchain service key fob in one embodiment.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

For a better description and illustration of embodiments of the application, reference may be made to one or more of the drawings, but additional details or examples used in describing the drawings should not be construed as limiting the scope of any of the inventive concepts of the present application, the presently described embodiments, or the preferred versions.

It should be understood that steps may be performed in other sequences unless explicitly stated otherwise. Moreover, at least a portion of the steps may include multiple sub-steps or multiple stages that are not necessarily performed at the same time, but may be performed at different times, and the order of performance of the sub-steps or stages is not necessarily sequential, but may be performed in turn or alternating with other steps or at least a portion of the sub-steps or stages of other steps.

As shown in fig. 1, a federation chain-based quantum computing-resistant public-private key issuing method is provided, which is implemented between federation chain members in communication with each other, where the federation members include a User and a plurality of endorsers, orderers and committers providing corresponding services, each of which is configured with a key fob, and all key fobs store respective private keys, public key pools and system management public keys.

In this embodiment, the federation chain members include a plurality of enrbersers, orderers and commimitters that provide corresponding services, wherein each key fob of the enrerer further stores a management private key and a management public key; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography;

in this embodiment, a management public key pool is further stored in the User's key fob, the management public key pool includes each management public key unit, and each management public key unit stores each enrorer identity, and a management public key and a private key parameter corresponding to the enrorer identity.

In this embodiment, a plurality of components related to the private key, which are calculated based on ID cryptography by the private key of the private key generation server, are respectively placed in different secret key cards of the Endorser. When a user needs to update the public and private keys, a key card of the user generates a new public key generation number, the public key generation number is put into a transaction, and the transaction is sent to a plurality of Endorsers. In the enrerer, the public key generation number will be used as well as the management private key generation private key component. And the User receives the transaction responses sent by the Endorsers, acquires a plurality of private key components from the transaction responses, and calculates to obtain the private key according to the private key components.

In this embodiment, the relevant contents of the ID cryptography that are utilized include: assuming that G is a group, a generator P is taken from G, a random number is selected as a private key s of a private key generation server, and a system management public key P of the private key generation server_pub＝sP。

In this embodiment, the private key of the private key generation server is stored in a distributed manner by secret sharing, and n endorsers in the private key generation server constitute a distributed private key generation service based on ID cryptography. The principle and flow of secret sharing will be briefly described below.

N different non-zero elements x1, x2, …, xn are randomly selected from the finite field gf (q) of prime order q and assigned to the participants Pi (i ═ 1,2, …, n). Taking the private key s of the server as shared secret information, selecting t-1 elements a1, a2, … and a (t-1) from GF (q), and constructing a polynomialThen si ═ f (xi) (1. ltoreq. i.ltoreq.n). (xi, si) as the shadow secret of participant PiAnd (5) encryption.

The s of the server can be recovered by using any t of the n Endorsers, and the specific steps are as follows. According to the formulaT lagrangian parameters λ i can be found, and thus s can be found according to the formula s (f (0) ═ Σ λ i × si.

Federation chain members also include respective blockchain services, each service having 1 or more IDs. The block chain service comprises a Peer service, an Order service and the like. Wherein the Peer service is divided into Committer and Endorser; the Order service consists of a number of orderers. All members of the alliance chain have a commit function and store block chain data, the Endorser also stores an intelligent contract, the intelligent contract runs in the key fob, and a key pool in the key fob is world status.

The following labels for User Client, endosser, Orderer, Committer are given as follows:

1) the IDs are IDU, IDE, IDO and IDC respectively. The corresponding public key pool unit can be found according to the ID

2) The public keys are PKU, PKE, PKO and PKC respectively

3) The private keys are SKU, SKE, SKO and SKC respectively

Specifically, as shown in fig. 2 to 4, the key fobs of the members of the federation chain each include a respective private key and a respective public key random number pool (also referred to as a public key pool), each public key unit is in the public key pool, each public key unit stores an ID and a public key random number R, and a user can find a corresponding public key unit in the public key pool according to the ID to obtain R. The correspondence between the public key random number R and the user public key PK is as follows: PK ═ H (ID | | | R). All key fobs are issued by a certain organization, the public key units in the public key pool in the initial state are completely consistent, and the key fobs are composed of the public key units corresponding to all users. The key cards of the individual users retain their respective private keys and are never public, and the key system employs a theory based on ID cryptography. In this embodiment, the enrerer owns the enrerer key fob shown in fig. 2, the Client owns the Client key fob shown in fig. 3, and the Orderer and commit own the other blockchain service key fobs shown in fig. 4. The Client and the Committer exist in the blockchain Client at the same time, and key fobs of the Client and the Committer can be combined into the same key fob or can be separated. The blockchain server may have both an enrerer and a commit, and the key fobs of both may be merged into the same key fobs or may be separated.

For each enrorer, the public key PKE ═ H (IDE | | | RE) and the private key SKE ═ s ═ PKE. The Endorser key fob also stores a system management public key P_pubManaging public key P_pubi si P and the management private key si, as shown in fig. 2. P_pubAnd also securely sent to members of other servers who will get P_pubStored in the other blockchain service key fob of the host as shown in fig. 4.

The private key of the key fob of the client side of the blockchain is issued by t endorsers, and each Endorser key fob calculates: PKU ═ H (IDU | | | RU), SKUi ═ si ═ PKU, the Endorser key fob securely sends SKUi to the client key fob. The secure transmission mode can be direct copy or encrypted transmission through a key issued by a secure communication mode such as QKD. The client key fob has a management public key pool after initialization, wherein the management public key pool stores xi and issued management public keys of n Endorsers, and each actual storage is (IDEi, P)_pubi, xi) as shown in fig. 3. After the client receives t SKUi, the Lagrange parameter can be calculated

Then, the private key SKU ═ Σ λ i ═ SKUi can be obtained from SKU ═ s ═ PKU ═ Σ λ i ═ si ═ Σ λ i ═ SKUi. Similarly, the client may be according to formula P_pub＝sP＝(∑λi*si)*P＝∑λi*(si*P)＝∑λi*P_pubi can obtain P_pub＝∑λi*P_pubi to find P_pubAnd is combined with P_pubIs stored in the Client key fob of the host, as shown in fig. 3.

In this embodiment, the method for issuing a public and private key specifically includes:

In this embodiment, the public key generation number is a public key random number or a partial public key generated based on the unlicensed cryptography.

In this embodiment, the User proposes a transaction to the enrer, the enrer responds to the transaction and performs a corresponding operation, and then sends a transaction notification corresponding to a transaction result to the User, where an interactive message carries a signature for verification. The generation mode of the signature is as follows:

In this embodiment, the method a specifically includes:

In this embodiment, after the Endorser receives the transaction and calculates a private key component according to the public key generation number and the system private key, the method further includes:

In this embodiment, after receiving the plurality of transaction responses, the User verifies each transaction response, and obtaining the private key component from the transaction response verified as valid further includes:

In this embodiment, the User further includes, by making an endorsement using the valid transaction responses, sending the endorsement to the order: acquiring a corresponding key generation number in the public key pool according to the Orderer identity identification, and calculating to obtain an Orderer public key by using the key generation number and the Orderer identity; and encrypting the endorsement according to the Orderer public key and the system management public key to obtain the encrypted endorsement.

In this embodiment, after receiving the endorsement, Orderer orders and sends it to Committer, including: correspondingly decrypting the encrypted endorsement according to the private key of the own party to obtain a decrypted endorsement; sequencing the endorsements to obtain an endorsement set; acquiring a corresponding key generation number in the public key pool according to the Committer identity, and calculating to obtain a Committer public key by using the key generation number and the Committer identity; and encrypting the endorsement set according to the Committer public key and the system management public key to obtain the encrypted endorsement set.

In this embodiment, after receiving the endorsement, the commit further includes: and correspondingly decrypting the encrypted endorsement set according to the private key of the own party to obtain the decrypted endorsement set.

When the public key generation number is a public key random number, the specific process of the federation chain transaction is further described with respect to details of each step as follows:

step 1: the Client presents the transaction.

The Client generates a public key random number RUnew in the key fob, and generates an asymmetric public key pkueew according to the formula pkueew ═ H (IDU | | RUnew). transaction tx consists of propofol and clientSig, i.e., tx ═ propofol, clientSig, where propofol includes IDU, chain code chaincodeID (i.e., the number using the smart contract function), txPayload (i.e., the parameter of the function), and timestamp, where txPayload has a value of RUnew ⊕ RU, i.e., propofol { IDU, chaincodeID, txPayload ═ RUnew ⊕ RU, timestamp }.

The ID-cryptography-based signature of propofol is computed to obtain the signature SIGN (propofol, SKU), clientSig, as follows. The Client uses the hash function to act on the proxy to obtain Hm, uses Hm as a key pointer random number, finds a public key unit in the key fob and takes out a public key random number Rm from the unit. And obtaining a MAC value MAC (propulsal, Rm) of Rm and propulsal, obtaining a product r PKU of r and the Client public key PKU by taking a random number parameter r, and acting a function H1 on the MAC (propulsal, Rm) and r PKU to obtain a signature parameter H-H1 (MAC (propulsal, Rm) and r PKU). Then the signature clientSig ═ SIGN (propofol, SKU) ═ PKU, (r + h) × SKU) of propofol can be obtained, where SKU is the private key of the Client.

Because the public key random number R of the patent is not public, an enemy cannot obtain a PKU; therefore, the adversary cannot obtain the random number r through r PKU and PKU. Since the signed object is a message authentication code and cannot be known by the enemy, the enemy cannot obtain h through the signed object. Since the enemy cannot get r and h, the enemy cannot get the SKU through (r + h). multidot.SKU. In summary, the disclosed digital signatures are resistant to attack by an adversary's quantum computer on identity-based public key cryptography.

The Client sends tx { { IDU, chaincodeID, txPayload { [ RUnew ⊕ RU, timetag }, (r × PKU, (r + h) × SKU) } to the Endorser.

Step 2: the Endorser performs the transaction.

After receiving the transaction, the Endorser takes out each part of { { IDU, chaincodied, txPayload ═ RUnew ⊕ RU, timestamp }, (r × PKU, (r + H) × SKU) }.

To verify the signature, only verification (P, P) is required_pubR PKU + h PKU, (r + h SKU)) is a valid Diffie-Hellman tuple. And also has (P, P)_pub,r*PKU+h*PKU,(r+h)*SKU))＝(P,P_pubAnd (r + h) PKU, (r + h) SKU)), (P, sP, (r + h) PKU, s (r + h) PKU)), i.e., it is only necessary to prove that (P, sP, (r + h) PKU, s (r + h) PKU)) is a valid Diffie-Hellman tuple.

After the signature is verified successfully, the Endorser judges whether the User has the authority of updating the public key and the private key and judges whether the difference between the timestamp and the local time is within a reasonable range. If all the determinations are passed, the Endorser approves the transaction tx, otherwise the Endorser does not approve the transaction.

And step 3: the Endorser sends a transaction reply.

The Endorser calculates RUnew according to the received RUnew ⊕ RU and RU obtained from the key fob, calculates PKUnew according to PKUnew (IDU | | | RUnew), obtains management private key si from the key fob, obtains SKUi according to SKUi ═ PKU, obtains SKUwi according to SKUwi | | | PKUnew, and hashes the propofol to obtain tid, and assigns a hash result of hashing the tid | | | RU to readset if the Endorser approves the transaction tx, the value of the readset is RUnew ⊕, and if the Endorser does not approve the transaction tx, the result and the invalid value of the RU are RU.

Endoser encrypts skunnewi. According to the formula g_U＝e(PKU,P_pub) G can be calculated_UTaking a random number r, calculating EU ═ rP, EV ═ skunnewi ⊕ H2 ((g)_U)^r) And then further onThe encrypted ciphertext EC can be obtained<EU,EV>. The IDEi is taken out of the key fob and the combination { EU-H (tid | | RU | | IDEi) } | | EV is also referred to as rtxdata. Taking tran-proposal | | | rtxdata as original text, signing the original text by using a private key SKE by using the signature method in the step 1 to obtain epSig, obtaining a transaction response rtx ═ tran-propassal, rtxdata and epSig } by the Endorser, and sending rtx to the Client.

And 4, step 4: the Client sends the encrypted endorsement to Orderer.

After the User receives the transaction response, the rtx, namely each part in the { tran-proporal, rtxdata and epSig }, is taken out.

The signature epSig is first verified as in step 2, and if the verification is successful, the following steps are performed, and if the verification fails, the rtx is discarded. The readset and writeset values are fetched. The Client reads the RU in the local key fob according to the IDU, and if readset is equal to the HASH (tid | RU) calculated in the local key fob and writeset is not an invalid value, it indicates that the transaction is a transaction approved by the Endorser.

The User judges that the number of received approved transactions is not less than t, the requirement of secret sharing is met, then rtxdata after signature verification, namely { EU-H (tid | RU | | | IDEi) } | | EV is analyzed to obtain { EU-H (tid | | RU | | | IDEi) } and EV two parts, the IDEi in the key card is taken out, tid is taken out from the obtained tran-propofol, RU is read in the local key card, so that tid | | | RU | | | | IDEi is obtained, a hash function is used for acting on the tid RU | IDEi to obtain H (tid | RU | | IDEi), the H (tid | RU | | IDEi) } plus H (tid | RU | IDEi) is obtained, and the original SKU < 84 > is decrypted according to obtain an original SKEU < RTU > 85RE < RTE > and an original SKU < RTE < 84 > is obtained after decryption.

And (3) the User checks the decrypted SKUnewwi: according to the formula e (skuewi, P) ═ e (si × pkuew, P) ═ e (pkuew, si × P) ═ e (pkuew, P)_pubi) One can deduce e (skunnewi, P) ═ e (pkunnew, P)_pubi) Taking P out of the key fob_pubAnd i, taking out the PKUnew and the parameter P existing by the own party, and calculating, wherein if the equation is true, the SKUnew is correct, otherwise, the SKUnew is wrong.

The User composes the approved rtx of the transaction into an endorsement, i.e., endorsement etx ═ Σ rtx. Reading a public key random number RO in the key fob by using the ID value IDO of Orderer, and calculating to obtain a public key PKO according to a formula PKO ═ H (IDO | | | RO). And (3) encrypting the endorsement etx by using PKO according to the method in the step 3 to obtain a ciphertext UC ═ UU-H (tid | | RO | | IDU), UV >, and sending the ciphertext UC to Orderer. If etx is too large, symmetric encryption etx is performed by using a random number key, and UC is obtained by performing asymmetric encryption on the random number key; for subsequent decryption, UC may be decrypted asymmetrically to obtain a random number key, and then decrypted etx symmetrically using the random number key. Other encryption related to long messages herein may be in accordance with this method.

And 5: orderer encrypts and sends the ordered etx set to Committer.

After receiving the UC sent by each Client, the order obtains each part in the UC, obtains < UU, UV > by the offset recovery method, extracts its private key SKO, calculates to obtain decrypted endorsement etx according to formula etx ═ UV ⊕ H2(e (SKO, UU)), and after accumulating to a certain number of etx, the order sorts etx, and after reaching the maximum size of the block or reaching the timeout time, the order combines the serial number seqno, the hash value prevhash of the last alliance chain block, and Σ etx, so as to obtain etx sets { seqno, prevhash, Σ etx }.

And then Orderer reads a public key random number RC in the key fob by using the ID value IDC of Committer, and then calculates the public key PKC according to the formula PKC ═ H (IDC | | | RC). And (3) encrypting the etx set by using PKC according to the method in the step 3 to obtain a ciphertext OC ═ OU-H (tid | | RC | | | IDO), OV >, and sending the ciphertext OC to the Committer. In this way the etx set is encrypted separately with the public keys of all Committers and sent separately to all Committers.

Step 6: each Committer validates the transaction and updates the world state.

After each Committer receives the OC, each part in the OC is taken out, and < OU, OV > is obtained by the method for recovering the offset, the private key SKC of the Committer is taken out, a decrypted etx set is calculated according to the formula etx set which is OV ⊕ H2(e (SKC, OU)), each part in { seqno, prevhash, Σ etx } is taken out, each etx is taken out, the rtx in the rtx, namely { tran-propassal, rtxdata, epSig }, the signature epsigig is verified according to the method in step 2, if the verification is successful, the subsequent steps are carried out, if the rtx is failed, the RU is discarded, the RU is taken out from the key card according to the IDU, the tid is taken out from the tran-popassal, the value of the HASH is calculated and compared with readset, and if the rtx is equal, the rtx can be considered.

Committer checks to see if the verified rtx meets the requirements for secret sharing, e.g., if t valid endorsements have been reached. If the etx is approved as a valid transaction, marking it as valid; otherwise Committer will not approve etx as a valid transaction and mark as invalid. Next, commit writes the block to the blockchain and updates the local world state, i.e. the local key pool, according to valid transactions in the blockchain.

Take out the writeset, get RUnew from that it is RUnew ⊕ RU and RU is known, replace RU in the key fob with RUnew.

And 7: committer sends a transaction notification.

Committer sends a transaction notification to the Client. If tx is valid, using success as a result value; if tx is invalid, failure is taken as the value of result. Combining result, tid, commentersig serves to obtain ntx ═ { tid, result, commentersig }. Wherein, committerSig is the signature of Committer on result according to the method in step 1, that is, committerSig is obtained as SIGN (result, SKC).

Committer sends the combination ntx to the Client.

When ntx is received, the Client obtains each part of { tid, result, commimitersig }. The signature committerSig is verified as in step 2. After the signature is successfully verified, the result is taken out to check the value of the result, if the value of the result is success, the public key is successfully updated, all SKUnewew successfully verified in the step 4 is taken out, and according to the formula SKUnewew ═ s ═ PKUnew ═ Σ λ i ═ PKUnew ∑ SKUnewew ∑ λ i ∑ SKUnewew and

SKUnew can be obtained through calculation, and the SKUnew is stored into a key fob to replace the original SKU of the user private key, so that the public key is successfully updated; if the result value is failure, the update of the public and private keys fails.

When the generated number of public keys is a part of public keys generated based on the unlicensed cryptography, as shown in fig. 2 to 4, in this embodiment, the key fob of a member of the federation includes a private key and a public key pool, each public key unit in the public key pool includes an ID, a part of public keys X, and a part of public keys Y, and a user can find the corresponding public key unit in the public key pool according to the ID. The correspondence between the partial public key X and the user public key PK is as follows: PK ═ H (ID | | X). All key fobs are issued by a certain organization, the public key units in the public key pool in the initial state are completely consistent, and the key fobs are composed of the public key units corresponding to all users. The key cards of the individual users retain their respective private keys and are never public, and the key system employs a theory based on certificateless cryptography. In this embodiment, the enrerer owns the enrerer key fob shown in fig. 2, the Client owns the Client key fob shown in fig. 3, and the Orderer and commit own the other blockchain service key fobs shown in fig. 4. The Client and the Committer exist in the blockchain Client at the same time, and key fobs of the Client and the Committer can be combined into the same key fob or can be separated. The blockchain server may have both an enrerer and a commit, and the key fobs of both may be merged into the same key fobs or may be separated.

For each enrorer, the public keys PKE ═ H (IDE | | | XE), XE ═ P, YE ═ XE ═ P_pubAnd the private key SKE is s × PKE, xE, wherein the private key xE is a true random number. The Endorser key fob also stores a system management public key P_pubManaging public key P_pubi si P and the management private key si, as shown in fig. 2. P_pubAnd also securely sent to members of other servers who will get P_pubStored in the other blockchain service key fob of the host as shown in fig. 4.

The blockchain client key fob private key is issued by t endorsers,each enrerser key fob calculates: PKU ═ H (IDU | | | XU), SKUi ═ si ═ PKU, the Endorser key fob securely sends SKUi to the client key fob. The secure transmission mode can be direct copy or encrypted transmission through a key issued by a secure communication mode such as QKD. In the certificate-free cryptography theory, the blockchain client further has a partial private key xU, a partial public key xU, and a partial public key YU, where the relationship xU × P, YU × xU × P_pubSince PKU exists as H (IDU | | XU) and SKU ═ s · PKU, the private key actually used by the user IDU is (XU, SKU), and the public key actually used is (XU, YU, PKU).

The client key fob has a management public key pool after initialization, wherein the management public key pool stores xi and issued management public keys of n Endorsers, and each actual storage is (IDEi, P)_pubi, xi) as shown in fig. 3. After the client receives t SKUi, the Lagrange parameter can be calculatedThen, SKU ═ s ═ PKU ═ Σ λ i ═ SKUi can be obtained from SKU ═ s ═ PKU ═ Σ λ i ═ SKUi. Similarly, the client may be according to formula P_pub＝sP＝(∑λi*si)*P＝∑λi*(si*P)＝∑λi*P_pubi can obtain P_pub＝∑λi*P_pubi to find P_pubAnd is combined with P_pubIs stored in the Client key fob of the host, as shown in fig. 3.

The specific flow of the federation chain transaction is further described in detail with respect to each step as follows:

step 1: the Client presents the transaction.

The Client generates a new partial private key xUnew, a new partial public key xUnew ═ xUnew P, and a new partial public key YUnew ═ xUnew P in the key fob_pubAnd then, calculating the public key PKUnew according to PKUnew ═ H (IDU | | XUnew), wherein H is a hash function. Performing hash operation on part of the public key XU to obtain HXU, taking HXU as a key pointer random number and obtaining a key position PXU in a key fob, finding out part of the public key XU 'at the position, and performing offset on XUnew to obtain XUnew-XU'; performing Hash operation on part of the public key YU to obtain HYU, using HYU as a key pointer random number and obtaining a key bit in the key fobPYU, finding out part of the public key YU 'at the position, and offsetting YUnew to obtain YUnew-YU'. And assigning XUnew-XU '| YUnew-YU' to txPayload. Transaction tx consists of propofol and clientSig, i.e., tx ═ propofol, clientSig, where propofol includes IDU, chain code chaincodeID (i.e., using the numbering of the intelligent contract function), txPayload (i.e., the parameter of the function), and timestamp, i.e., propofol ═ { IDU, chaincodeID, txPayload ═ XUnew-XU '| | | YUnew-yuu', timestamp }.

The certificateless cryptography based signature of propofol is computed to obtain the signature SIGN (SKU), clientSig, as follows. Client acts on the proposal with a hash function to get Hm, uses Hm as a key pointer random number, finds a public key cell in the key fob and fetches the public key PKm from the cell. Taking a random number r epsilon Z^* _qU-rP is calculated, and V is calculated according to the formula V-SKU + rH2(proposal, IDU, XU, U) + XU H3(proposal, IDU, XU), where H2 and H3 are hash functions. The signature clientSig ═ SIGN (propofol, SKU) ═ U-PKm, V can thus be obtained for propofol.

The Client sends tx { { IDU, chaincodeID, txPayload { { XNew-XU '| YUNew-YU', timestamp }, (U-PKm, V) } to the Endorser.

Step 2: the Endorser performs the transaction.

After receiving the transaction, the Endorser takes out each part of { { IDU, chaincodeID, txPayload ═ XUnew-XU '| | YUew-YU', timestamp }, (U-PKm, V) }. Endorser acts on proposal with a hash function to get Hm, uses Hm as a key pointer random number, finds a public key cell in the key fob and fetches the public key PKm from the cell. Addition of PKm to U-PKm gave U. And finding a public key unit in the key fob according to the IDU, taking out a partial public key XU from the public key unit, calculating the partial public key PKU according to a formula PKU (IDU | | XU), and verifying the obtained signature by using the XU and the PKU.

Endorser takes propofol from tx and verifies the equation e (V, P) ═ e (PKU, P)_pub) e (H2 (propofol, IDU, XU, U), U) e (H3 (propofol, IDU, XU), XU) is true. If the equality is not established, the verification fails; if the equation is true, the verification is successful and the next steps are performed.

And step 3: the Endorser sends a transaction reply.

Performing hash operation on the XU by the Endorser to obtain HXU, taking HXU as a key pointer random number and obtaining a key position PXU in the key fob, finding a partial public key XU 'at the position, and performing offset recovery on the received XUnew-XU' to obtain XUnew; finding out a public key unit in the key fob according to the IDU, taking out a partial public key YU from the public key unit, carrying out hash operation on the YU to obtain HYU, taking HYU as a key pointer random number, obtaining a key position PYU in the key fob, finding out the partial public key YU 'at the position, and carrying out offset recovery on the received YUnew-YU' to obtain YUnew. Calculating to obtain PKUnew according to PKUnew ═ H (IDU | | | XUnew), taking out the management private key si from the key fob, obtaining SKUi according to SKUi ═ si ═ PKU, and obtaining SKUnew according to SKUnew ═ si PKUnew. And carrying out Hash operation on tx to obtain tid, wherein the tran-propofol comprises { IDEi, tid, chaincodeID, txPayload, readset and writeset }. If Endorser approves the transaction tx, assigning the result of Hash operation on tid | | | XU | | YU to readset, wherein the value of writeset is (XUnew-XU ') | (YUnew-YU'); if Endorser does not approve the transaction tx, then the values of readset and writeset are invalid.

Endoser encrypts skunnewi. Calculating the formula e (XU, P)_pub) If e (YU, P) is true, the following steps are continued, otherwise the encryption is aborted. Selecting a random number sigma epsilon (0, 1)ⁿThe value of i is calculated according to the formula i H5(σ, skunnewi), then EU iP, EV σ ⊕ H4(e (PKU, YU)ⁱ) In which H4, H5, and H6 are hash functions, the ciphertext EC encrypted by skuewi can be obtained<EU，EV，EW>。

The IDEi is taken out of the key fob and the combination { EU-H (tid | | XU | YU | | | IDEi) } | | EV | | EW is also known as rtxdata. Taking tran-propofol | | | rtxdata as original text, signing the original text by using a private key SKE by using the signature method in the step 1 to obtain epSig, and thus obtaining epSig (tran-propofol | | | rtxdata, SKE).

The Endorser obtains a transaction response rtx ═ { tran-pro passive, rtxdata, epSig }, and sends rtx to the Client.

And 4, step 4: the Client sends an Endorsement (Endorsement) etx to order.

The signature epSig is first verified as in step 2, and if the verification is successful, the following steps are performed, and if the verification fails, the rtx is discarded. The readset and writeset values are fetched. The Client takes out XU in the local key fob according to the IDU, and if readset is equal to the HASH (tid XU YU) calculated in the local key fob and writeset is not an invalid value, the transaction is approved by Endorser.

The method comprises the steps of determining that the number of received approved transactions is not less than t, meeting the requirement of secret sharing, analyzing rtxdata subjected to signature verification, namely { EU-H (tid | XU | | YU | | | IDEi) } | | EV | | EW to obtain { EU-H (tid | | XU | | | YU | | IDEi) }, EV and EW, taking out IDEi in the key fob, taking out tid from obtained tran-proposal, reading XU | YU in the local key fob to obtain tid XU | | | YU | | IDEi, obtaining H (tid XU | YU | IDEi) by acting on tid XU | YU IDEi by a hash function, and obtaining a ciphertext (SKU | | | |), and obtaining the ciphertext by decrypting the skew, (6', if the skew is not equal to obtain the ciphertext, and obtaining the ciphertext by decrypting the skew, (6).

And (3) the User checks the decrypted SKUnewwi: according to the formula e (skuewi, P) ═ e (si × pkuew, P) ═ e (pkuew, si × P) ═ e (pkuew, P)_pubi) One can deduce e (skunnewi, P) ═ e (pkunnew, P)_pubi) Taking P out of the key fob_pubi, taking out the existing PKUnew sum of the own partyAnd calculating a parameter P, wherein if the equation is true, SKUnewwi is correct, and otherwise, the SKUnewwi is wrong.

The User composes the approved rtx of the transaction into an endorsement, i.e., endorsement etx ═ Σ rtx. Reading a public key random number RO in the key fob by using the ID value IDO of Orderer, and calculating to obtain a public key PKO according to a formula PKO ═ H (IDO | | | RO). And (3) encrypting the endorsement etx by using PKO according to the method in the step 3 to obtain a ciphertext UC ═ UU-H (tid | | | XO | | | IDU), UV >, and sending the ciphertext UC to Orderer. If etx is too large, symmetric encryption etx is performed by using a random number key, and UC is obtained by performing asymmetric encryption on the random number key; for subsequent decryption, UC may be decrypted asymmetrically to obtain a random number key, and then decrypted etx symmetrically using the random number key. Other encryption related to long messages herein may be in accordance with this method.

And 5: orderer sends the sorted etx set to Committer.

After receiving the UC sent by each Client, the order obtains each part in the UC, obtains < UU, UV, UW > by the offset recovery method, obtains its private key SKO, calculates to obtain decrypted endorsement etx according to formula etx ═ UV ⊕ H2(e (SKO, UU)), and after accumulating a certain number of etx, the order sorts etx, and after reaching the maximum size of block or reaching timeout time, the order combines the serial number seqno, the hash value prevhash of the last alliance chain block, and Σ etx, so as to obtain etx set { seqno, prevhash, Σ etx }.

And then Orderer reads a public key random number RC in the key fob by using the ID value IDC of Committer, and then calculates the public key PKC according to the formula PKC ═ H (IDC | | | RC). And (3) encrypting the etx set by using the PKC according to the method in the step 3 to obtain a ciphertext OC ═ OU-H (tid | | XC | | YC | | | IDO), OV and OW >, and sending the ciphertext OC to the Committer. In this way the etx set is encrypted separately with the public keys of all Committers and sent separately to all Committers.

Step 6: each Committer validates the transaction and updates the world state.

After each Committer receives the OC, each part in the OC is taken out, and < OU, OV, OW > is obtained by the method for recovering the offset, a private key SKC of the Committer is taken out, a decrypted etx set is calculated according to the formula etx set which is OV ⊕ H2(e (SKC, OU)), each part in { seqno, prevhash, Σ etx } is taken out, each etx is taken out, rtx, namely { tran-pro, rtxdata, epSig }, is checked, the signature epSig is verified according to the method in step 2, if the verification succeeds, the following steps are carried out, if the rtx fails, the rtx is discarded, XU and YU are obtained from the key card according to the IDU, tid is taken out from the tran-pro, the HASH is calculated, the value of HASH (tid XU | | YU) is compared with the retry set, and the result shows that the HASH is equal to the value of the secret key.

Carrying out Hash operation on the XU to obtain HXU, taking HXU as a key pointer random number, obtaining a key position PXU in the key fob, and finding a partial public key XU' at the position; hashing YU yields HYU, using HYU as the key pointer random number and yielding key location PYU in the key fob where the partial public key YU' is found. Taking out the writeset, obtaining XUnew and YUNEw according to the fact that the writeset is equal to (XUnew-XU ') | (YUNEw-YU') and XU 'and YU' are obtained, replacing XU in the key card with XUnew, and replacing YU in the key card with YUNEw. According to this step, all XUs and YUs that need to be updated are replaced.

And 7: committer sends a transaction notification.

Committer sends the combination ntx to the Client.

When ntx is received, the Client obtains each part of { tid, result, commimitersig }. The signature committerSig is verified as in step 2. After the signature is verified successfully, a result is taken out to check the value of the result, if the value of the result is success, the update of the public and private keys is successful, all SKUnews verified successfully in the step 4 are taken out, and according to a formula SKUnew ═ s ═ PKUnew ═ Σ λ i ═ PKUnew ∑ Σ λ i ═ Σ λ i ∑ SKUnews and

SKUnew can be obtained through calculation, and (xU, SKUnew) is stored in a key card to replace an original user private key (xU, SKU), and the public key and the private key are updated successfully; if the result value is failure, the update of the public and private keys fails.

The public-private key issuing method based on the federation chain and resisting quantum computing stores a public key and a private key by using the key fob, including a partial public key and a partial private key, wherein the public key is stored in a public key pool of the key fob. The key fob is a separate hardware-isolated device and the likelihood of key theft by malware or malicious operations is greatly reduced. Since the quantum computer cannot obtain the user public key, the corresponding private key cannot be obtained. In addition, the invention also ensures the security of the transmitted message by anti-quantum computation signature and encryption based on the public and private keys, and the private key is difficult to be deduced even in the presence of a quantum computer. Therefore, the scheme is not easy to crack by a quantum computer.

In the invention, the ID based on the ID cryptography is changed into a form of adding a public key random number or a part of a public key to the ID, and the signature parameter h is correspondingly improved, so that the signature parameter h cannot be calculated by an enemy, and the digital signature has high quantum security resistance. And the private key of the private key server is stored in a distributed manner in a secret sharing manner, and the related public and private keys are respectively stored in the key fob, so that the risk of stealing the private key is greatly reduced. Neither private key server has access to the entire private key, which also improves overall security.

Meanwhile, the offset is used in different occasions in the process, the offsets can be calculated only by the participation of a public key pool in the key fob, and other parties without the key fob cannot crack the data protected by the offset. The data is encrypted by using the offset, so that the transmission process is safer, and the quantum resistance is realized; and the calculation amount of the encryption mode is smaller than that of the common encryption mode, so that the attack of resisting a quantum computer by using the common encryption mode is avoided, and the equipment burden of each party is reduced.

After the public key is updated, the information of the public key update of other communication parties can be inquired through the block chain, and a central server does not exist, namely, the inquiry to the central server and the downloading of the public key update are not needed. The block chain is a communication system without a central network, so that the loss of the communication function of the central server caused by the network problem possibly occurring in the extreme situation of the central server is avoided, and the public key can not be updated and inquired; in addition, because the central server does not exist, an attacker cannot launch denial of service type attack, and the normal operation of the public key updating system is ensured.

In one embodiment, a computer device, namely a public and private key issuing system based on a alliance chain and resisting quantum computing, is provided, and can be a terminal, and the internal structure of the computer device can comprise a processor, a memory, a network interface, a display screen and an input device which are connected through a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to realize the public-private key issuing method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the computer equipment, an external keyboard, a touch pad or a mouse and the like.

In one embodiment, a federation chain-based quantum computation resistant public and private key issuing system is provided, and comprises federation chain members which are communicated with each other, wherein the federation members comprise a User and a plurality of Endorsers, Orderer and Committer which provide corresponding services, each party is provided with a key fob, and all the key fobs store respective private keys, public key pools and system management public keys; the member of the alliance chain comprises a plurality of Endorsers, Orderer and Committer which provide corresponding services, wherein the key card of each Endorser also stores a management private key and a management public key; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography; a management public key pool is also stored in the User key fob, the management public key pool comprises each management public key unit, and each management public key unit stores each Endorser identity, a management public key corresponding to the Endorer identity and a private key parameter;

the User and the member of the alliance chain both comprise a memory and a processor, the memory is stored with a computer program, and the processor realizes the alliance chain-based quantum computation resistant public and private key issuing method when executing the computer program.

The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples are merely illustrative of several embodiments of the present invention, and the description thereof is more specific and detailed, but not to be construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present invention should be subject to the appended claims.

Claims

1. A public and private key issuing method based on a alliance chain and resisting quantum computing is implemented between alliance chain members which communicate with each other, wherein the alliance chain members comprise a User and a plurality of Endorser, Orderer and Committer which provide corresponding services, and the public and private key issuing method is characterized in that each party is provided with a key fob, and all the key fobs store respective private keys, public key pools and system management public keys;

2. The method of claim 1, wherein the public key generation number is a public key random number or a partial public key generated based on unlicensed cryptography.

3. The method of claim 2, wherein the anti-quantum public and private key issuance method,

the User proposes a transaction to the Endorser, the Endorser responds to the transaction and carries out corresponding operation, and then a transaction notification corresponding to a transaction result is sent to the User, wherein the interactive message carries a signature used for verification;

the generation mode of the signature is as follows:

4. The method according to claim 3, wherein the method a specifically includes:

5. The method as claimed in claim 1, wherein the step of receiving the transaction by the Endorser, calculating the private key component according to the generated number of the public key and the system private key, further comprises:

6. The method of claim 5, wherein the User verifies each transaction response after receiving the plurality of transaction responses, and obtaining the private key component from the transaction response verified as valid further comprises:

7. The method of claim 6, wherein the User endorses the order to order with a valid transaction response further comprises:

acquiring a corresponding key generation number in the public key pool according to the Orderer identity identification, and calculating to obtain an Orderer public key by using the key generation number and the Orderer identity identification;

8. The method of claim 7, wherein the order of the Orderer receiving the endorsement and sending the endorsement to the Committer comprises:

sequencing the endorsements to obtain an endorsement set;

9. The method of claim 8, wherein the Committer receives the endorsement and further comprises:

10. The public and private key issuing system based on the alliance chain and resistant to quantum computing comprises alliance chain members which are communicated with each other, wherein the alliance members comprise a User and a plurality of Endorser, Orderer and Committer which provide corresponding services; a management private key, a private key parameter and a management public key are stored in the key fob of each Endorser; the management private key is as follows: a private key of a private key generation server obtains a plurality of components related to the private key based on ID cryptography; in the generation process of the management private key, the private key parameter and the management public key are correspondingly generated; a management public key pool is also stored in the User key card, the management public key pool comprises each management public key unit, and each management public key unit stores each Endorser identity, a management public key corresponding to the Endorser identity and a private key parameter;

the federation chain and the user comprise a memory and a processor, wherein the memory stores a computer program, and the processor realizes the public-private key issuing method based on the federation chain and resisting quantum computing as claimed in any one of claims 1 to 9 when executing the computer program.