CN110768781B - Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation - Google Patents

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

Info

Publication number
CN110768781B
CN110768781B CN201910798814.7A CN201910798814A CN110768781B CN 110768781 B CN110768781 B CN 110768781B CN 201910798814 A CN201910798814 A CN 201910798814A CN 110768781 B CN110768781 B CN 110768781B
Authority
CN
China
Prior art keywords
key
public key
private key
public
management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201910798814.7A
Other languages
Chinese (zh)
Other versions
CN110768781A (en
Inventor
富尧
钟一民
汪仲祥
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ruban Quantum Technology Co Ltd
Nanjing Ruban Quantum Technology Co Ltd
Original Assignee
Ruban Quantum Technology Co Ltd
Nanjing Ruban Quantum Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ruban Quantum Technology Co Ltd, Nanjing Ruban Quantum Technology Co Ltd filed Critical Ruban Quantum Technology Co Ltd
Priority to CN201910798814.7A priority Critical patent/CN110768781B/en
Publication of CN110768781A publication Critical patent/CN110768781A/en
Application granted granted Critical
Publication of CN110768781B publication Critical patent/CN110768781B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0852—Quantum cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0863—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving passwords or one-time passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0866—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving user or device identifiers, e.g. serial number, physical or biometrical information, DNA, hand-signature or measurable physical characteristics
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

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 transactions to the Endorsers, and the transaction information comprises public key generation numbers 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 number 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 management 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 chain members comprise a User and a plurality of Endorsers, Orderers and Committers 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, implemented between federation chain members in communication with each other, where the federation chain members include a User and a plurality of endorsers, orderers and commimitters 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 serverpub＝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 polynomial
Figure GDA0003202325600000071
Then si ═ f (xi) (1. ltoreq. i.ltoreq.n). (xi, si) as the shadow secret of the participant Pi.
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 formula
Figure GDA0003202325600000081
T 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 PpubManaging public key Ppubi si P and the management private key si, as shown in fig. 2. PpubAnd also securely sent to members of other servers who will get PpubStored 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 | messaging)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
Figure GDA0003202325600000091
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 Ppub＝sP＝(∑λi*si)*P＝∑λi*(si*P)＝∑λi*Ppubi can obtain Ppub＝∑λi*Ppubi to find PpubAnd is combined with PpubIs 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:
the User puts forward transactions to the Endorsers, and the transaction information comprises public key generation numbers 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.
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:
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.
In this embodiment, 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 number parameters and the own private key.
In this embodiment, after the Endorser receives the transaction and calculates a private key component according to the public key generation number and the management private key, the method 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.
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:
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.
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, that is, tx ═ propofol, clientSig, where propofol includes IDU, chain code chaincodeID (i.e., a number using a smart contract function), txPayload (i.e., a parameter of a function), and timestamp, where txPayload has a value of RUnew RU, that is, 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, timestamp }, (r × PKU, (r + h) × SKU) } to the Endorser.
Step 2: the Endorser performs the transaction.
After receiving the transaction, the enrerer takes out each part of { { IDU, chaincodieid, txPayload ═ RUnew ^ RU, timestamp }, (r × PKU, (r + h) × SKU) }. The Endorser finds a public key unit in the key fob according to the IDU and takes out a public key random number RU from the public key unit, and can calculate a public key PKU according to a formula PKU-H (IDU-RU), and then verify the obtained signature by using the PKU.
To verify the signature, only verification (P, P) is requiredpubR 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,Ppub(r + h) PKU, (r + h) SKU)), (P, sP, (r + h) PKU, s (r + h) PKU)), that is, it is only necessary to prove (P, sP, (r + h) PK)U, 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.
And the Endorser calculates RUnew according to the RU ^ RU received and the RU obtained from the key fob to obtain RUnew, calculates PKUnew according to PKUnew ^ H (IDU | | RUnew), obtains a management private key si from the key fob, obtains SKUi according to SKUi ═ si PKU, and obtains SKUnewew according to SKUneww ═ si PKUnew. The hash operation is performed on the propofol to obtain the tid, and the tran-propofol comprises { IDEi, tid, chaincoded ID, txPayload, readset, writeset }. If Endorser approves the transaction tx, assigning the result of the hash operation on tid | | | RU to readset, and assigning the value of writeset to RUnew | | RU; if Endorser does not approve the transaction tx, then the values of readset and writeset are invalid.
Endoser encrypts skunnewi. According to the formula gU＝e(PKU,Ppub) G can be calculatedU. Taking a random number r, EU ═ rP, EV ═ skunnewi ∞ H2 is calculated (g)U)r) Further, an encrypted ciphertext EC may 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.
And the User judges that the number of the received approved transactions is not less than t, and the secret sharing requirement is met. And then analyzing rtxdata after signature verification, namely { EU-H (tid | | RU | | IDEi) } | | EV to obtain two parts of { EU-H (tid | | RU | | | IDEi) } and EV. Taking out IDEi in the key fob, taking out tid from the obtained tran-propofol, reading RU in the local key fob to obtain tid RU I IDEi, acting on tid RU I IDEi with a hash function to obtain H (tid RU I IDEi), adding H (tid RU I IDEi) to { EU-H (tid RU I IDEi) } to obtain recovered ciphertext < EU, EV >. The ciphertext is then decrypted. And calculating the decrypted original text SKUnewwi according to a formula SKUnewwi-EV ^ H2(e (SKU, EU)).
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 fobpubAnd 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 Orderer receives UC sent by each Client, each part in the UC is obtained, and the method for recovering the offset is used for obtaining < UU, UV >. The private key SKO of the user is taken out, and the decrypted endorsement etx is calculated according to the formula etx ≧ UV ≦ H2(e (SKO, UU)). After a certain number of etx are accumulated, Orderer sorts etx. After the maximum size of the block is reached or the timeout time is reached, Orderer combines the sequence number seqno, the hash value prevhash of the last block of the federation chain, and Σ etx, and may 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 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 the < OU, OV > is obtained by the method for recovering the offset. And (3) taking out the private key SKC of the user, and calculating according to a formula etx (OV ^ H2(e (SKC, OU)) to obtain a decrypted etx set. Then each part in { seqno, prevhash, ∑ etx } is fetched. Each etx is fetched separately and viewed for rtx, i.e., { tran-proporal, rtxdata, epSig }. 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. Taking RUs from the key fob based on IDU, taking tid from tran-proval, calculating the value of HASH (tid | | | RU) and comparing with readset, if equal, indicating rtx is approved.
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.
The writeset is taken out, RUnew can be obtained according to that the writeset ^ RUnew ^ RU and RU is known, and RUnew is replaced by RUnew in the key fob. According to this step, all RUs that need to be updated are replaced.
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
Figure GDA0003202325600000161
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 ═ PpubAnd 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 PpubManaging public key Ppubi si P and the management private key si, as shown in fig. 2. PpubAnd also securely sent to members of other servers who will get PpubStored 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 | | | 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 × PpubSince 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 calculated
Figure GDA0003202325600000171
Then, SKU ═ s ═ PKU ═ Σ λ i ═ SKUi can be obtained from SKU ═ s ═ PKU ═ Σ λ i ═ SKUi. Similarly, the client may be according to formula Ppub＝sP＝(∑λi*si)*P＝∑λi*(si*P)＝∑λi*Ppubi can obtain Ppub＝∑λi*Ppubi to find PpubAnd is combined with PpubIs 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 fobpubAnd 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'; and performing hash operation on part of the public key YU to obtain HYU, taking HYU as a key pointer random number and obtaining a key position PYU in the key fob, finding out the part of the public key YU 'at the position, and performing offset on 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* qCalculating U ═ rP according to the formulaThe formula V ═ SKU + rH2 (propofol, IDU, XU, U) + XU × H3 (propofol, IDU, XU) was calculated to give V, 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.
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.
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)nThe value of i is calculated according to the formula i H5(σ, skunnewi). Then, EU ═ iP, EV ═ σ ≠ H4(e (PKU, YU) is calculatedi) EW ═ skunnewi ≧ H6(σ). H4, H5, and H6 are hash functions, so that the ciphertext EC encrypted by skunnewi 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.
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 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.
And the User judges that the number of the received approved transactions is not less than t, and the secret sharing requirement is met. Then, the rtxdata after signature verification, namely { EU-H (tid | | XU | YU | | IDEi) } | | EV | | EW is analyzed to obtain three parts of { EU-H (tid | | XU | | YU IDEi) }, EV and EW. Taking out IDEi in the key fob, taking out tid from the obtained tran-proposal, reading XU | | YU in the local key fob to obtain tid | | XU | | YU | | IDEi, acting on tid | | | XU | | YU IDEi with a hash function to obtain H (tid | | | | XU | | | YU IDEi), thereby obtaining EU and obtaining the recovered ciphertext < EU, EV, EW >. The ciphertext is then decrypted. σ ' is calculated according to a formula of σ '. EV ≦ H4(e (xU × SKU, EU)), and then σ ' is calculated according to a formula of skuewi '. EW ≦ H6(σ '). Let i 'H5 (σ', skunnewi '), verify whether equation EU' P holds. If the equality is not true, the verification fails; if the equation is true, skunnewi 'is the original text obtained by decryption, i.e., skunnewi' is skunnewi, and then the following steps are performed.
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 fobpubAnd 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 | | | 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 Orderer receives UC sent by each Client, each part in the UC is obtained, and the offset recovery method is used for obtaining < UU, UV and UW >. The private key SKO of the user is taken out, and the decrypted endorsement etx is calculated according to the formula etx ≧ UV ≦ H2(e (SKO, UU)). After a certain number of etx are accumulated, Orderer sorts etx. After the maximum size of the block is reached or the timeout time is reached, Orderer combines the sequence number seqno, the hash value prevhash of the last block of the federation chain, and Σ etx, and may 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 the < OU, OV, OW > is obtained by the method for recovering the offset. And (3) taking out the private key SKC of the user, and calculating according to a formula etx (OV ^ H2(e (SKC, OU)) to obtain a decrypted etx set. Then each part in { seqno, prevhash, ∑ etx } is fetched. Each etx is fetched separately and viewed for rtx, i.e., { tran-proporal, rtxdata, epSig }. 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. XU and YU are taken from the key fob according to IDU, tid is taken from tran-provosan, the value of HASH (tid | | XU | | YU) is calculated and compared with readset, and if equal, rtx is approved.
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.
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 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 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
Figure GDA0003202325600000231
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 chain members comprise a User and a plurality of Endorsers, Orderers and Committers 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 (7)

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;
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 transactions to the Endorsers, and the transaction information comprises public key generation numbers 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;
after receiving the transaction notification, the User calculates a private key by adopting a relevant formula according to the public key generation number, the private key components and the private key parameters relevant to the private key components to finish the private key issuance;
the public key generation number is a public key random number or a part of public keys generated based on the unlicensed cryptography, and comprises the following steps:
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:
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;
the mode 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 number parameters and the own private key.
2. The method for issuing the quantum-computation-resistant public and private keys as claimed in claim 1, wherein the Endorser receives the transaction, and after obtaining the private key component by computing according to the public key generation number and the management private key, the method further comprises:
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.
3. The method of claim 2, wherein the User verifies each transaction response after receiving a plurality of transaction responses, and the obtaining the private key component from the transaction response verified as valid further comprises:
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.
4. The method of claim 3, 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;
and encrypting the endorsement according to the Orderer public key and the system management public key to obtain the encrypted endorsement.
5. The method of claim 4, wherein the order of the Orderer receiving the endorsement and sending the endorsement to the Committer comprises:
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.
6. The method of claim 5, wherein the Committer receives the endorsement and further comprises:
and correspondingly decrypting the encrypted endorsement set according to the private key of the own party to obtain the decrypted endorsement set.
7. 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 chain 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 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 computation resistant public and private key issuing method as claimed in any one of claims 1-6 when executing the computer programs.
CN201910798814.7A 2019-08-28 2019-08-28 Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation Active CN110768781B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910798814.7A CN110768781B (en) 2019-08-28 2019-08-28 Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910798814.7A CN110768781B (en) 2019-08-28 2019-08-28 Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation

Publications (2)

Publication Number Publication Date
CN110768781A CN110768781A (en) 2020-02-07
CN110768781B true CN110768781B (en) 2021-10-22

Family

ID=69329506

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910798814.7A Active CN110768781B (en) 2019-08-28 2019-08-28 Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation

Country Status (1)

Country Link
CN (1) CN110768781B (en)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111385350B (en) * 2020-02-13 2022-12-30 南京如般量子科技有限公司 Quantum computation resistant blockchain transaction method and system based on one-time-varying secret sharing and routing device
CN111342967B (en) * 2020-03-06 2021-03-19 北京中宇万通科技股份有限公司 Method and device for solving block chain user certificate loss or damage
CN112104453B (en) * 2020-08-06 2022-08-09 如般量子科技有限公司 Anti-quantum computation digital signature system and signature method based on digital certificate
CN114362926B (en) * 2020-09-30 2024-04-09 如般量子科技有限公司 Quantum secret communication network key management communication system and method based on key pool
CN114978518A (en) * 2021-02-20 2022-08-30 南京如般量子科技有限公司 Quantum-computation-resistant digital signature method and system based on quantum communication service station
CN115955308B (en) * 2023-03-13 2023-06-27 国开启科量子技术(北京)有限公司 Digital asset processing method, device, equipment and medium based on quantum-resistant key

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107623569A (en) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 Block chain key escrow and restoration methods, device based on Secret sharing techniques
CN109064324A (en) * 2018-06-15 2018-12-21 重庆金融资产交易所有限责任公司 Method of commerce, electronic device and readable storage medium storing program for executing based on alliance's chain
CN109409884A (en) * 2018-10-25 2019-03-01 北京安如山文化科技有限公司 A kind of block chain secret protection scheme and system based on SM9 algorithm
CN109660345A (en) * 2019-01-17 2019-04-19 如般量子科技有限公司 Anti- quantum calculation block chain method of commerce and system based on unsymmetrical key pool server
CN109687963A (en) * 2019-01-15 2019-04-26 如般量子科技有限公司 Anti- quantum calculation alliance chain method of commerce and system based on public key pond
CN109685511A (en) * 2018-05-30 2019-04-26 上海分壳信息技术股份有限公司 Data transaction of servitude method based on block chain
CN110086626A (en) * 2019-04-22 2019-08-02 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce and system based on unsymmetrical key pond pair

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107623569A (en) * 2017-09-30 2018-01-23 矩阵元技术（深圳）有限公司 Block chain key escrow and restoration methods, device based on Secret sharing techniques
CN109685511A (en) * 2018-05-30 2019-04-26 上海分壳信息技术股份有限公司 Data transaction of servitude method based on block chain
CN109064324A (en) * 2018-06-15 2018-12-21 重庆金融资产交易所有限责任公司 Method of commerce, electronic device and readable storage medium storing program for executing based on alliance's chain
CN109409884A (en) * 2018-10-25 2019-03-01 北京安如山文化科技有限公司 A kind of block chain secret protection scheme and system based on SM9 algorithm
CN109687963A (en) * 2019-01-15 2019-04-26 如般量子科技有限公司 Anti- quantum calculation alliance chain method of commerce and system based on public key pond
CN109660345A (en) * 2019-01-17 2019-04-19 如般量子科技有限公司 Anti- quantum calculation block chain method of commerce and system based on unsymmetrical key pool server
CN110086626A (en) * 2019-04-22 2019-08-02 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce and system based on unsymmetrical key pond pair

Also Published As

Publication number Publication date
CN110768781A (en) 2020-02-07

Similar Documents

Publication Publication Date Title
CN110768781B (en) Public and private key issuing and issuing method and system based on alliance chain and resisting quantum computation
CN109687963B (en) Anti-quantum computing alliance chain transaction method and system based on public key pool
CN111639361B (en) Block chain key management method, multi-person common signature method and electronic device
CN110661613B (en) Anti-quantum-computation implicit certificate issuing method and system based on alliance chain
CN110690957B (en) Anti-quantum computing private key backup, loss report and recovery method and system
CN110519046B (en) Quantum communication service station key negotiation method and system based on one-time asymmetric key pair and QKD
CN109919611B (en) Quantum computation resistant blockchain transaction method and system based on symmetric key pool server
CN110830244B (en) Anti-quantum computing Internet of vehicles method and system based on identity secret sharing and alliance chain
CN110737915B (en) Anti-quantum-computation anonymous identity recognition method and system based on implicit certificate
CN110380845B (en) Quantum secret communication alliance chain transaction method, system and equipment based on group symmetric key pool
CN110930251B (en) Anti-quantum computing cloud storage method and system based on alliance chain and implicit certificate
CN109918888B (en) Anti-quantum certificate issuing method and issuing system based on public key pool
CN109921905B (en) Anti-quantum computation key negotiation method and system based on private key pool
CN111211910A (en) Anti-quantum computation CA (certificate Authority) and certificate issuing system based on secret shared public key pool and issuing and verifying method thereof
CN111327419B (en) Method and system for resisting quantum computation block chain based on secret sharing
CN110493005B (en) Anti-quantum computing public key pool updating method and system based on alliance chain
US20220086006A1 (en) Computer-implemented system and method for asset mixing
CN110868295A (en) Anti-quantum computing alliance chain system based on secret sharing and communication method
CN110636050B (en) Anonymous identity recognition method and system based on alliance chain and resisting quantum computation
CN110971403A (en) Anti-quantum computation blockchain system based on secret shared public key pool and transaction method
CN110737907B (en) Anti-quantum computing cloud storage method and system based on alliance chain
CN110740034B (en) Method and system for generating QKD network authentication key based on alliance chain
CN110557247A (en) Identity-based quantum computation resistant blockchain method and system
CN110635897B (en) Key updating or downloading method and system based on alliance chain and resisting quantum computing
CN110519045B (en) Anti-quantum computing alliance chain transaction method and system based on group asymmetric key pool

Legal Events

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