Nothing Special   »   [go: up one dir, main page]

CN111181718A - Anti-quantum computing IKE system based on alliance chain and negotiation communication method - Google Patents

Anti-quantum computing IKE system based on alliance chain and negotiation communication method Download PDF

Info

Publication number
CN111181718A
CN111181718A CN201911388616.XA CN201911388616A CN111181718A CN 111181718 A CN111181718 A CN 111181718A CN 201911388616 A CN201911388616 A CN 201911388616A CN 111181718 A CN111181718 A CN 111181718A
Authority
CN
China
Prior art keywords
client
key
identity
endorser
transaction
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.)
Pending
Application number
CN201911388616.XA
Other languages
Chinese (zh)
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 CN201911388616.XA priority Critical patent/CN111181718A/en
Publication of CN111181718A publication Critical patent/CN111181718A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0852Quantum cryptography
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key 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)
    • H04L9/0825Key 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) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • Electromagnetism (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

The invention discloses an anti-quantum computation IKE system based on a alliance chain and a negotiation communication method, wherein the alliance chain consists of a block chain server and a client, the server and the client are provided with independent key fobs, a private key and a public key pool are stored in the key fobs, the identity information of all alliance chain servers and the client is stored in the server public key pool, and the identity information of the client and the identity information of all the servers are stored in the client public key pool.

Description

Anti-quantum computing IKE system based on alliance chain and negotiation communication method
Technical Field
The invention relates to the field of alliance chains, in particular to an anti-quantum computing IKE system based on alliance chains and a negotiation communication method.
Background
The Internet key exchange protocol, i.e., IKE protocol, consists of Internet Security Association and Key Management Protocol (ISAKMP) and two key exchange protocols. The IKE protocol is used to exchange and manage encryption keys used in the VPN. It solves the problem of securely establishing or updating shared keys in an unsecured network environment. IKE is a very general protocol that can negotiate security parameters for not only IPsec, but also any protocol requiring privacy, such as SNMPv3, RIPv2, OSPFv2, etc. But so far it still has security drawbacks.
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. the current IKE negotiation key process is possibly cracked under the calculation of a quantum computer, which can cause the problem that the negotiation key is leaked.
2. The current DH negotiation method based on the asymmetric key pool needs to share the public keys of both parties of the negotiation to the other party in advance, the sharing process is troublesome, and manual operation is needed.
3. At present, the key negotiation process of the IKE is replaced by a quantum key issuing process, expensive quantum key issuing equipment is needed, the quantum key issuing process needs unified scheduling of a key management server, and the process is easy to be attacked by denial of service to cause paralysis.
Disclosure of Invention
The purpose of the invention is as follows: the invention aims to provide an anti-quantum computing IKE system based on a coalition chain and a negotiation communication method, which cannot be attacked and cracked by a quantum computer.
The technical scheme is as follows: in order to achieve the above purpose, the anti-quantum computing IKE system based on the federation chain of the present invention includes a block chain server and a block chain client, where the server and the client are equipped with independent key fobs, a private key and a public key pool are stored in the key fobs, all identity information of the server and the client of the federation chain is stored in the server public key pool, own identity information and all identity information of the server are stored in the client public key pool, and a system management public key is also stored in the key fobs. The private key is obtained through calculation of the public key and the private key of the private key generation server, the key fobs issue uniformly, each client side holds an independent key fobs, and the private key in each key fobs is never disclosed.
The negotiation communication method of the quantum computing IKE resisting system based on the alliance chain comprises the following steps:
step 1: performing IKE SA negotiation between a client A and a client B;
the client A sends the SA load with the related negotiation strategy algorithm, the encrypted information Cookie A and the second identity of the client A to the client B;
after receiving the information of the client A, the client B selects a related negotiation strategy algorithm agreed by the own party to form an SA load, and sends the second identity of the client B, the SA load of the own party, the encrypted information Cookie B and the encrypted information Cookie A to the client A together to complete a negotiation task in the first stage;
step 2: a client A and a client B acquire a session key;
(1) the client A signs a proposal consisting of second identity information PIDA, CookieA, chain code chaincoded ID, function parameters and a timestamp by using a private key SKA of a self-party to obtain a signature clientSig, and sends a transaction tx containing the clientSig to the Endorser;
(2) the Endorser receives the transaction tx, searches and confirms the identity information IDA of the client A in the key fob, obtains a public key PKA through IDA calculation so as to verify the signature clientSig, and judges whether the client A has the authority of generating a session key; after the judgment is passed, the Endorser selects a random number Ki as a secret shared component of the session key, the random number xi is a parameter to form (xi, Ki), the (xi, Ki) is encrypted and offset calculation is carried out to obtain an offset ciphertext, and the offset ciphertext and other information are assigned to readset and writeset;
the Endorser calculates to obtain a second identity of the own party, simultaneously signs the tran-propofol containing the second identity, readset and writeset by adopting a private key SKE of the own party to obtain epSig, combines the epSig with the tran-propofol to be used as a transaction response rtx, and sends the transaction response rtx to A;
(3) a, after receiving a transaction response rtx, taking out each part of rtx, searching and confirming an Endorser identity information IDE in a key fob, verifying a signature epSig according to the IDE, and if the verification is successful, receiving the rtx; when the received rtx meets the secret sharing requirement, the ciphertext after the offset is restored is stored locally;
meanwhile, all the received rtx are combined into an endorsement etx, then a public key PKO of Orderer is used for encrypting etx to obtain a ciphertext AC, and the AC is sent to Orderer;
(4) after Orderer receives AC, the private key SKO is taken out, endorsement etx is obtained through calculation and decryption, after a certain number of etx are accumulated, Orderer sorts etx, all etx combinations are combined together with Orderer serial numbers and hash values of the last alliance chain block to obtain a etx set; the etx sets are respectively encrypted by the public key PKC of the Committer to obtain a ciphertext OC which is sent to all Committers;
(5) after each Committer receives the OC, each part of the OC is taken out, each etx set is obtained through calculation and decryption of a private key SKC, the rtx in the taken-out etx is verified, after the rtx value passing the verification meets the requirement of secret sharing, the verification result is signed through the private key SKC, and the obtained signature and the verification result jointly form ntx and are sent to the client A and the client B;
(6) the client A receives ntx, decrypts the ciphertext which is stored in the local recovery offset in the step (3) after the verification is confirmed to pass, obtains a plurality of groups (xi, Ki), and recovers the session key K through calculation of the secret shared component Ki and the parameter xi;
(7) the client B receives ntx, and after the verification is confirmed, the client B sends a transaction request to the Endorser in the mode in (1); the Endorser receives the transaction request, verifies the transaction request, reads the local world state after the verification is passed, obtains a secret shared component ciphertext locally corresponding to the client B, signs the secret shared component ciphertext, forms a transaction response and sends the transaction response to the client B;
(8) after receiving the transaction response, the client B verifies the signature, and recovers a session key K by calculating a secret shared component Ki and a parameter xi according to a plurality of groups (xi, Ki) after verifying that the transaction response passes through the plurality of groups;
and step 3: the client A and the client B carry out identity authentication;
the client B encrypts the identity information IDB of the client B through the session key K and sends the encrypted identity information IDB to the client A, and the client A decrypts and authenticates the identity information of the client B through the session key K after receiving the information;
after the verification is passed, the client A encrypts the identity information IDA of the client A through the session key K and sends the encrypted identity information IDA to the client B, and the client B receives the information and then decrypts and authenticates the identity information of the client A through the session key K;
and after the verification is passed, the client A and the client B communicate through a session key K.
Further, in step 1, the cookie a is a result obtained by calculating the IP of the client a, the IP of the client B, the random number, the current date and the current time by using an MD5 algorithm; CookieB is the result of calculating the IP of the client B, the IP of the client A, the random number, the current date and the current time by using an MD5 algorithm.
Further, in step 1, the second identity of the client a is a result of performing hash operation on the ID of the client a and the cookie a; the second identity of the client B is the result of performing hash operation on the ID of the client B and the Cookie B.
Further, in step 2 (1), the transaction tx is composed of a propofol and a clientSig, where the propofol includes the second ID of the client a, a cookie a, a chain code chaincocleid, a function parameter txPayload and a timestamp, the function parameter txPayload is calculated by the second ID of the client B and the cookie B, and the client a calculates the ID cryptography-based signature of the propofol as the clientSig through a private key SKA.
Preferably, in order to improve the quantum computation resistance, in (3) of step 2, the method of performing encryption offset calculation on (xi, Ki) is as follows;
and encrypting xi and Ki through a public key of the client, after encryption, acting a hash function on the ID of the client and the Endorser and the transaction ID to obtain an offset, and performing offset operation on the ciphertext by using the offset to obtain the offset ciphertext.
In step 2, (2) when the Endorser searches for the identity information of the client a in the key fob, the Endorser traverses an ID list in the key fob, performs hash operation on the ID and the cookie a, compares the obtained result with the second identity of the client a, and the IDs with the same result are the identity information IDA of the client a;
in order to recover the identity information of the server and the client, when the Endorser identity information IDE is searched in the key fob in step 2 (3), the client a traverses the ID list in the key fob, performs hash operation on the ID and the transaction ID, compares the obtained result with the second identity of the Endorser, and the ID with the same result is the Endorser identity information IDE.
Has the advantages that:
1. the patent uses a key fob to store the ID and private key, the key fob being a separate hardware-isolated device, the likelihood of stealing the key by malware or malicious operations is greatly reduced. And the quantum computer can not obtain the public key of the user, so the corresponding private key can not be obtained. The security of the private key is greatly improved.
2. In the method, the ID based on the ID cryptography is changed into a hidden form, and the signature parameters are correspondingly improved, so that the signature parameters cannot be calculated by an enemy, and the digital signature has high quantum security.
3. 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 characteristic of quantum computation 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.
4. The invention uses a alliance chain to issue a pair of secret symmetric keys for two IKE communication parties as session keys of the two parties. The session key K is generated by carrying out distributed storage through secret sharing, and the enemy can obtain t secrets less than the secret sharing threshold value through various means and can not obtain the final session key, so that the security of session key network distribution is improved.
5. The invention does not need to inform the own public key to the other party before carrying out the key exchange, thereby avoiding the problem that the public keys of the two parties need to be manually shared in the prior asymmetric key pool technology.
6. The key negotiation process of the IKE can resist quantum computation without expensive quantum key issuing equipment, and the quantum key issuing process is uniformly scheduled by a alliance chain rather than a centralized key management server, so that paralysis caused by denial of service attack is not easy to occur in the process.
Drawings
FIG. 1 is a block diagram of a system according to an embodiment of the present invention;
FIG. 2 is an internal block diagram of a server key fob according to the present invention;
FIG. 3 is an internal block diagram of a client key fob according to the present invention;
FIG. 4 is a flow chart of IKE according to the present invention.
Detailed Description
The architecture of the system of the present invention is shown in fig. 1, where a federation chain consists of a blockchain server and a blockchain client, each member equipped with a key fob, where the blockchain client is both parties that need to communicate using IKE.
In the invention, the session keys K of both communication parties are stored in a distributed way through secret sharing and generated, n Endorsers in the session keys K form a distributed key generation service based on ID cryptography, and the generation principle is as follows:
finite field GF from prime order q (q) of n different non-zero elements x1, x2, …, xn are randomly chosen and assigned to the participants Pi (i ═ 1,2, …, n). Taking the session key K as shared secret information, selecting t-1 elements a1, a2, … and a (t-1) from GF (q), and constructing a polynomial
Figure BDA0002344292250000051
Then, there is Ki ═ f (xi) (1. ltoreq. i.ltoreq.n). (xi, Ki) as the shadow secret of participant Pi.
K can be obtained by acquiring any t shadow secrets from n Endorsers, and the specific steps are as follows. According to the formula
Figure BDA0002344292250000052
T lagrangian parameters λ i can be found, and therefore K can be found according to the formula K (f (0) ═ Σ λ i Ki.
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 Committer function and store block chain data, and the Endorser also stores intelligent contracts which run in the key fob.
The following labels for User Client, endosser, Orderer, Committer are as follows:
1) the IDs are IDU, IDE, IDO and IDC respectively.
2) The public keys are PKU, PKE, PKO and PKC respectively.
3) The private keys are SKU, SKE, SKO and SKC respectively.
As shown in fig. 2 and fig. 3, in this embodiment, the key fobs of the federation chain server and the client include respective private keys and public key pools, the public key pool of the server has the identity IDs corresponding to all federation chain servers and the client, and the public key pool of the client has the ID of the client and the IDs corresponding to all federation chain servers. For all key fobs, the corresponding public key can be found from the ID: PK ═ H (ID). All key fobs are issued by a fixed organization, the key fobs of all users keep respective private keys and are never disclosed, and a key system adopts the theory generation based on ID cryptography. 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 Ppub ═ sP of the private key generation server exists. All key fobs also have a system management public key Ppub stored therein.
In this embodiment, the blockchain servers such as the enrerer, the Orderer, and the commit have the server key fob shown in fig. 2, and the User Client has the Client key fob shown in fig. 3.
All public key and private key calculation methods in the invention are PK ═ H (ID), SK ═ s PK. s is the private key of the private key generation server. And setting the two communication parties as A and B respectively, wherein the A and the B start to communicate, establish a secure connection in an IKE mode and send a message. As shown in fig. 4, the entire process is divided into three stages, and the entire process will be described in detail next.
The first stage is as follows: IKE SA negotiation between A and B:
where SA is the meaning of security association. And the A calculates the own IP, the IP of the B, the random number taken by the own, the current date and the current time by using an MD5 algorithm, takes the obtained result as Cookie A and generates a second identity PIDA ═ HASH (IDA | | Cookie A). 3 and 3 sending 3 the 3 PIDA 3, 3 the 3 SA 3 load 3 SA 3- 3 A 3 including 3 the 3 related 3 negotiation 3 strategy 3 algorithm 3 and 3 CookieA 3 to 3 the 3 B 3. 3
And B, after receiving the negotiation request information of A, calculating the own IP, the IP of A, the random number taken by the own, the current date and the current time by using an MD5 algorithm, and taking the obtained result as Cookie B. 3 and 3 B 3 generates 3 a 3 second 3 identity 3 identification 3 PIDB 3 ( 3 IDB 3 | 3 | 3 | 3 CookieB 3) 3, 3 processes 3 the 3 received 3 SA 3- 3 A 3, 3 selects 3 a 3 related 3 negotiation 3 strategy 3 algorithm 3 agreed 3 by 3 the 3 own 3 party 3, 3 forms 3 an 3 SA 3 load 3 SA 3- 3 B 3 of 3 the 3 own 3 party 3 and 3 sends 3 the 3 SA 3 load 3 SA 3- 3 B 3, 3 the 3 PIDB 3, 3 the 3 CookieB 3 and 3 the 3 CookieA 3 to 3 the 3 A 3. 3 Both parties have completed the negotiation task of the first phase.
And a second stage: obtaining a session key:
the original technique of IKE is that two parties AB negotiate to obtain a session key, which is now changed to obtain the session key by two parties through a alliance chain flow, thereby replacing the former negotiation process. First, a requests the alliance chain server and obtains the session key.
Step 1: a, proposing a transaction:
a proposes a transaction tx, tx is composed of propofol and clientSig, that is, tx ═ propofol, clientSig, where propofol includes PIDA, cookie a, chain code chaincodied (i.e., using the numbering of the smart contract function), txPayload (i.e., the parameter of the function), and timestamp, where txPayload has a value of PIDB | | cookie b, that is, propofol ═ PIDB |, timestamp }.
A, calculating a signature of propofol based on ID cryptography by using a private key SKA to obtain a signature SIGN (the secret, SKA), and the process is as follows: a acts on the propofol with a hash function to get Hm, uses Hm as a key pointer random number, finds a public key unit in the key fob and takes the IDM from the unit. The MAC value MAC (propofol, IDM) of IDM and propofol, the product r × PKA of r and the public key PKA is obtained by taking the random number parameter r, the product r × PKA is obtained, the signature parameter H ═ H1(MAC (propofol, IDM), r × PKA) is obtained by acting the function H1 on MAC (propofol, IDM) and r × PKA), and the signature clientsign ═ SIGN (SIGN, SKA) of propofol ═ r PKA, (r × (r + H) SKA).
Since the IDA of the patent is not disclosed, the enemy cannot obtain the PKA; therefore, the adversary cannot get the random number r through r PKA and PKA. 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 SKA through (r + h) × SKA. In summary, the disclosed digital signatures are resistant to attack by an adversary's quantum computer on identity-based public key cryptography.
The User Client sends the transaction tx made by A to the Endorser. Wherein, the transaction tx is { { PIDA, cookie a, chaincodied, txPayload ═ PIDB | | cookie b, timestamp }, (r | PKA, (r + h) × SKA) }.
Step 2: the Endorser performs the transaction:
after receiving the transaction tx, the enrser takes out each part of { { PIDA, Cookie A, chaencodieID, txPayload ═ PIDB | | Cookie B, timestamp }, (r | -PKA, (r + h) }. And traversing the ID list in the key fob by the Endorser, calculating HASH (ID | | | CookieA), comparing the result with the PIDA, and if the result is equal, indicating that the found ID is IDA. The Endorser can calculate the public key PKA from the found IDA and the formula PKA ═ H (IDA), and can then verify the resulting signature with the PKA. Similarly, the enrerer can find the IDB in the key fob according to the PIDB and the cookie b, and then find the public key PKB according to the IDB.
To verify the Signature, only (P, Ppub, r PKA + h PKA, (r + h) SKA)) needs to be verified as a valid Diffie-Hellman tuple according to the digital Signature verification theory of An Identity-Based Signature from Gap Diffie-Hellman groups.
After the signature is verified successfully, the Endorser judges whether the A has the authority of generating the session key and judges whether the difference between the timestamp and the local time is in 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 propofol by the Endorser to obtain tid, namely the transaction ID, and calculating a second identity identifier PIDE of the Endorser according to a formula PIDE ═ HASH (IDE | | | tid), wherein,
the Endorser takes a random number Ki as a secret sharing component of a session key, takes a random number xi as a parameter, wherein each Endorser has different xi value ranges, and xi obtained by any two Endorsers is ensured to be unequal.
the public key PKA is used to encrypt Ki | | xi, a random number r1 can be obtained by calculation gA. according to a formula gA ═ e (PKA, Ppub), r 1P is calculated EUi | | | xi,) ⊕ H2((gA) r1), and further an encrypted ciphertext EKi ═ EUi, EVi > can be obtained, and then Ki | | | | xi is encrypted by using the public key PKB, and an encrypted ciphertext EKi2 ═ EUi2, EVi2> is obtained.
After the result is calculated, the Endorser acts on IDE | tid | IDA by using a hash function to obtain PKEA ═ H (IDE | tid | | IDA); the hash function is applied to IDE | | | tid | | | IDB to obtain PKEB ═ H (IDE | | | | tid | | | IDB). Shifting EKi and EKi2 to obtain EKi '═ < EUi-PKEA, EVi >, EKi 2' ═ < EUi2-PKEB, EVi2 >.
After Endorser approves the transaction tx, the PIDB is assigned to readset, the PIDA | | PIDB | | timemap | | tid | | | PIDE | | EKi '| | EKi 2' is assigned to writeset, and the values of readset and writeset are invalid if Endorser does not approve the transaction tx.
The readset acquisition mode is as follows: according to the PIDB, reading each ID in the public key pool by the method described above for comparison, and if the comparison is successful, the readset is equal to the PIDB, otherwise the readset is equal to an invalid value.
The tran-propofol comprises { PIDE, tid, chaencodeID, txPayload, readset, writeset }, is used as a text, is signed by a private key SKE by using a signature method in the step 1 to obtain epSig, and the Endorser obtains a transaction response rtx ═ tran-propadal, epSig }, and sends rtx to A.
And 4, step 4: a sends the encrypted endorsement to Orderer.
After A receives the transaction response, taking out rtx, namely each part in { tran-pro passive, epSig }, traversing the ID list in the key fob, calculating HASH (ID | | tid), comparing the result with PIDE, and if the result is equal, indicating that the found ID is IDE. And calculating according to the IDE to obtain the PKE.
Firstly, the signature epSig is verified by the PKE according to the method in the step 2, if the verification is successful, the values of readset and writeset are taken out, if readset is equal to PIDB and writeset is not invalid, the transaction is approved by Endorser. If the verification fails, the rtx is discarded.
And A, judging that the number of the received approved transactions is not less than t, and meeting the requirement of secret sharing. A is acted on IDE | tid | IDA by a hash function to obtain H (IDE | tid | IDA), namely PKEA. And performing offset recovery on the EKi' to obtain EKi ═ < EUi-PKEA + PKEA, EVi ═ EUi, EVi >. A performs the above-described processing for a plurality of received approved transactions and retains the resulting sets of EKi locally.
A composes the endorsement with the approved rtx of the transaction, i.e. endorsement etx ═ Σ rtx. The public key PKO is calculated using the order ID value IDO and the formula PKO ═ H (IDO). And (3) encrypting the endorsement etx by using PKO according to the method in the step 3 to obtain a ciphertext AC ═ AU-H (IDA | | | tid | | | IDO), AV >, and sending the ciphertext AC to Orderer. If etx is too large, symmetric encryption etx is performed by using a random number key, and the random number key is asymmetrically encrypted to obtain AC; for subsequent decryption, the random number key may be obtained by asymmetric decryption of the AC, and then symmetric decryption etx 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 AC sent by each client, the order obtains each part in the AC, and obtains < AU, AV >. by the method for recovering the offset, takes out its private key SKO, calculates and obtains decrypted endorsement etx according to formula etx ⊕ AV ⊕ H2(e (SKO, AU)), and after accumulating 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 block of the alliance chain, and Σ etx, so as to obtain etx set { seqno, prevhash, Σ etx }.
Orderer then calculates the public key PKC using Committer's ID value IDC and the formula PKC ═ H (IDC). And (3) encrypting the etx set by using PKC according to the method in the step 3 to obtain a ciphertext OC ═ < OU-H (IDO | | | tid | | IDC), 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 commatter 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 commatter is taken out, the decrypted etx set is calculated according to the formula etx set which is OV ⊕ H2(e (SKC, OU)), each part in { seqno, prevhash, & sigma etx } is taken out, each etx is taken out, the rtx in the rtx, namely { tran-pro pass, epSig }, the signature epSig 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 to be discarded, the values of readset and writeset are taken out, and if the readset is equal to the PIDB and the writeset is not an invalid value, the transaction 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, Committer writes the block into the block chain and updates the local world state according to the valid transactions in the block chain. That is, the values of writeset contained in all rtxs in each etx, i.e., PIDA | | PIDB | | time estimate | tid | PIDE | | EKi '| EKi 2' are taken, and all PIDE | | EKi '| EKi 2' are combined into the set PIDA | | | PIDB | | time estimate | | tid Σ { PIDE | EKi '| EKi 2' } and stored locally.
And 7: committer sends a transaction notification.
Committer sends a transaction notification to A. If tx is valid, using success as a result value; combining result, tid, commentersig serves to obtain ntx ═ PIDC, tid, result, commentersig }. PIDC ═ HASH (IDC | | | tid). 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). If tx is invalid, failure is taken as the value of result.
Committer sends a combination ntx to the User Client, including clients A and B.
When ntx is received by the User Client, each part in { PIDC, tid, result, commenterSig } is obtained. The client finds IDCs in the key fob from PIDCs and tids. The signature committerSig is verified as in step 2. After the signature is verified successfully:
(1) client A
And taking out result to check the value of the result, and if the value of the result is success, performing the following calculation: the EKi that was kept local in step 4 is decrypted. For ciphertext EKi<EUi,EVi>decrypting, calculating to obtain decrypted original text Ki | | | xi according to a formula (Ki | | xi) ═ EVi ⊕ H2(e (SKA, EUi)), decrypting a plurality of EKis to obtain a plurality of groups Ki | | | | xi, namely a plurality of groups (xi, Ki), as the secret shared by the (t, n) secret, and calculating the Lagrangian parameter according to the secret sharing theory
Figure BDA0002344292250000101
K ═ Σ λ i × Ki can then be obtained, so that this gives rise toBecomes the session key. If the value of result is failure, it indicates that the generation of the session key failed.
(2) Client B
And (4) taking out the result to check the value of the result, and entering the third stage if the value of the result is success. If the result value is failure, it indicates that the generation of the session key has failed, and B does not perform the processing.
And a third stage: b, obtaining a session key:
the federation chain Client User Client informs B that a session key has been generated, B requests and obtains the session key.
Step 1: and B, proposing a transaction.
B proposes a transaction tx, tx is composed of propofol and clientasig, that is, tx ═ propofol, clientasig, where propofol includes PIDB, cookie B, chain code chaincoded id (i.e., using the number of the intelligent contract function), function parameter txPayload, and timestamp, and the value of function parameter txPayload is PIDA, that is, propofol ═ PIDB, cookie B, chaincoded id, txPayload ═ PIDA, timestamp.
Calculating the signature of the propofol based on the ID cryptography to obtain the signature SIGN (the propofol, SKB) as follows: b acts on the propofol with a hash function to get Hm, uses Hm as a key pointer random number, finds a public key unit in the key fob and takes the IDM out of the unit. The MAC values MAC (propofol, IDM) of IDM and propofol, the product r × PKB of r and the public key PKB of B is obtained by taking the random number parameter r, and the signature parameter H ═ H1(MAC (propofol, IDM), r × PKB) is obtained by applying the function H1 to MAC (propofol, IDM) and r × PKB. The signature clientSig ═ SIGN (propofol, SKB) ═ r (r × PKB, (r + h) × SKB) of propofol can be obtained.
Because the IDB of the patent is not disclosed, the enemy cannot obtain the PKB; therefore, the enemy cannot obtain the random number r through r PKB and PKB. 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 SKB through (r + h) × SKB. In summary, the disclosed digital signatures are resistant to attack by an adversary's quantum computer on identity-based public key cryptography.
B sends tx { { PIDB, cookie B, chaincodeID, txPayload ═ PIDA, timetag }, (r × PKB, (r + h) × SKB) } to the enrerer.
Step 2: the Endorser performs the transaction.
After receiving the transaction tx, the enrser takes out each part of { { PIDB, CookieB, chaincocode ID, txPAyload ═ PIDA, timetag }, (r × (r + h) × SKB) }, then the enrser traverses the ID list in the key fob, calculates HASH (ID | | | CookieB), compares the result with the PIDB, and if the result is equal, the found ID is IDB. The Endorser can calculate the public key PKB from the IDB and the formula PKB ═ H (IDB), and then verify the resulting signature with the PKB.
To verify the signature, only one valid Diffie-Hellman tuple needs to be verified (P, Ppub, r PKB + h PKB, (r + h) SKB)).
After the signature is verified successfully, the Endorser judges whether the B has the right to acquire the session key, reads the local world state, judges whether the session key exists between the B and the A, and judges whether the difference between the timestamp in the proxy of the B 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 performing HASH operation on the propofol by the Endorser to obtain the tidB, calculating the PIDE according to a formula PIDE ═ HASH (IDE | | | tidB) to obtain the PIDE, and calculating to obtain the tran-propofol.
Wherein the tran-propofol comprises { PIDE, tidB, chaincoded ID, txPayload, readset, writeset }. If the Endorser approves the transaction tx, the Endorser reads the local world state according to the PIDA | | PIDB, reads the latest record according to the timestamp, namely obtains the latest tid | | Σ { PIDE | | | EKi2 '}, assigns the latest tid | | | Σ EKi 2' } to readset, and assigns NULL to writeset; if Endorser does not approve the transaction tx, then the values of readset and writeset are invalid.
And (3) taking the tran-proposal as a text, signing the text by using a private key SKE by using a signature method in the step 1 to obtain epSig, obtaining a transaction response rtx (tran-propasal, epSig) by the Endorser, and sending rtx to the B.
And 4, step 4: b receives the result
And B, after receiving the transaction response, taking out rtx, namely each part in the { tran-pro passive, epSig }. B finds the IDE in the key fob according to PIDE and tidB. PKE was obtained from IDE.
And (3) firstly, verifying the signature epSig by using the PKE according to the method in the step 2, if the verification is successful, keeping the rtx, and if the verification fails, discarding the rtx.
after a plurality of rtxs which are successfully verified are verified, readsets in the rtxs are respectively taken out and compared whether the tid values of the rtxs are equal, if the rtxs are equal, the tid | Σ { PIDE | | EKi2 '} is decrypted, the retrieved EKi 2' is taken out, offset is recovered, namely, a hash function is acted on IDE | | | | | tidb to obtain H (IDE | | | IDB), namely, the EKi2 'is subjected to offset recovery to obtain EKi2 | < EUi2-PKEB + PKEB, the EVi2> < EUi2, the EVi2>, then the < EUi2, the EVi2>, and the decrypted original text Ki | | i2 | H2(e (SKB, EUi2)) is calculated according to a formula (Ki | xi) | i, the decrypted original text Ki | | | is decrypted to obtain a plurality of EKi's 685 EKi 2.
Groups (xi, Ki) are formed as secrets shared by the (t, n) secrets. According to the formula K ═ Sigma λ i ═ Ki, and
Figure BDA0002344292250000121
the session key K can be derived. At this point, acquiring the session key is completed.
A fourth stage: and A and B carry out identity authentication:
b encrypts own identity information IDB by using the session key K to obtain { IDB | | HASHB } K, and sends { IDB } K, CookieB and CookieA to A. 3 the 3 hash 3 is 3 MAC 3 ( 3 cookie 3 b 3 | 3 | 3 | 3 cookie 3 a 3 | 3 | 3 | 3 SA 3- 3 a 3 | 3 | 3 | 3 idb 3, 3 k 3) 3, 3 and 3 MAC 3 ( 3 m 3, 3 k 3) 3 is 3 a 3 message 3 authentication 3 code 3 using 3 m 3 as 3 a 3 message 3 and 3 k 3 as 3 a 3 key 3. 3 The third phase in the original technology is that a initiates identity authentication to B first, here we change that B initiates identity authentication to a first, because the second phase B obtains the session key later.
After receiving the message of B, A decrypts the encrypted information by using K to obtain the identity information of B and verifies HASHB, then encrypts the own identity information IDA by using K to obtain { IDA } K, and sends { IDA | | | HAHAHAHAHA } K, CookieA and CookieB together to B. 3 where 3 has 3 ha 3 ═ 3 MAC 3 ( 3 cookie 3 a 3 | 3 | 3 cookie 3 b 3 | 3 | 3 | 3 SA 3- 3 a 3 | 3 | 3 | 3 ida 3, 3 k 3) 3. 3 And B decrypts the encrypted information by using K after receiving the message of A to obtain the identity information of A and verifies HAHAHAHAHASH. This completes the IKE negotiation process. A and B can use the session key K to carry out secure and identity-guaranteed communication.

Claims (10)

1. An anti-quantum computing IKE system based on a federation chain, the federation chain consisting of a blockchain server and a blockchain client, the system comprising: the server side and the client side are provided with independent key fobs, private keys and public key pools are stored in the key fobs, the identity IDs of all the alliance chain server sides and the identity IDs of all the client sides are stored in the server side key fobs public key pools, and the identity IDs of the client side key fobs and the identity IDs of all the server sides are stored in the client side key fobs public key pools.
2. A federation chain-based anti-quantum computing IKE system according to claim 1, wherein: a system management public key is also stored within the key fob.
3. A federation chain-based anti-quantum computing IKE system according to claim 1, wherein: the private key is calculated by the public key and the private key of the private key generation server.
4. A federation chain-based anti-quantum computing IKE system according to claim 1, wherein: the key fobs issue uniformly, each client holds an independent key fobs, and private keys in the key fobs are never disclosed.
5. The negotiation communication method of a federation chain-based quantum computation-resistant IKE system according to claim 1, comprising the steps of:
step 1: performing IKE SA negotiation between a client A and a client B;
the client A sends the SA load with the related negotiation strategy algorithm, the encrypted information Cookie A and the second identity of the client A to the client B;
after receiving the information of the client A, the client B selects a related negotiation strategy algorithm agreed by the own party to form an SA load, and sends the second identity of the client B, the SA load of the own party, the encrypted information Cookie B and the encrypted information Cookie A to the client A together to complete a negotiation task in the first stage;
step 2: a client A and a client B acquire a session key;
(1) the client A signs a proposal consisting of second identity information PIDA, CookieA, chain code chaincoded ID, function parameters and a timestamp by using a private key SKA of a self-party to obtain a signature clientSig, and sends a transaction tx containing the clientSig to the Endorser;
(2) the Endorser receives the transaction tx, searches and confirms the identity information IDA of the client A in the key fob, obtains a public key PKA through IDA calculation so as to verify the signature clientSig, and then judges whether the client A has the authority of generating a session key; after the judgment is passed, the Endorser selects a random number Ki as a secret shared component of the session key, the random number xi is a parameter to form (xi, Ki), the (xi, Ki) is encrypted and offset calculation is carried out to obtain an offset ciphertext, and the offset ciphertext and other information are assigned to readset and writeset;
the Endorser calculates to obtain a second identity of the own party, simultaneously signs the tran-propofol containing the second identity, readset and writeset by adopting a private key SKE of the own party to obtain epSig, combines the epSig with the tran-propofol to be used as a transaction response rtx, and sends rtx to A;
(3) a, after receiving a transaction response rtx, taking out each part of rtx, searching and confirming an Endorser identity information IDE in a key fob, verifying a signature epSig according to the IDE, and if the verification is successful, receiving the rtx; when the received rtx meets the secret sharing requirement, the ciphertext after the offset is restored is stored locally;
meanwhile, all the received rtx are combined into an endorsement etx, then a public key PKO of Orderer is used for encrypting etx to obtain a ciphertext AC, and the AC is sent to Orderer;
(4) after Orderer receives AC, the private key SKO is taken out, endorsement etx is obtained through calculation and decryption, after a certain number of etx are accumulated, Orderer sorts etx, all etx combinations are combined together with Orderer serial numbers and hash values of the last alliance chain block to obtain a etx set; the etx sets are respectively encrypted by public keys PKC of all Committers to obtain a ciphertext OC which is sent to all Committers;
(5) after each Committer receives the OC, each part of the OC is taken out, each etx set is obtained through calculation and decryption of a private key SKC, the rtx in the taken-out etx is verified, after the rtx value passing the verification meets the requirement of secret sharing, the verification result is signed through the private key SKC, and the obtained signature and the verification result jointly form ntx and are sent to the client A and the client B;
(6) the client A receives ntx, decrypts the ciphertext which is stored in the local recovery offset in the step (3) after the verification is confirmed to pass, obtains a plurality of groups (xi, Ki), and recovers the session key K through calculation of the secret shared component Ki and the parameter xi;
(7) the client B receives ntx, and after the verification is confirmed, the client B sends a transaction request to the Endorser in the mode in (1); the Endorser receives the transaction request, verifies the transaction request, reads the local world state after the verification is passed, obtains a secret shared component ciphertext locally corresponding to the client B, signs the secret shared component ciphertext, forms a transaction response and sends the transaction response to the client B;
(8) after receiving the transaction response, the client B verifies the signature, and recovers a session key K by calculating a secret shared component Ki and a parameter xi according to a plurality of groups (xi, Ki) after verifying that the transaction response passes through the plurality of groups;
and step 3: the client A and the client B carry out identity authentication;
the client B encrypts the identity information IDB of the client B through the session key K and sends the encrypted identity information IDB to the client A, and the client A decrypts and authenticates the identity information of the client B through the session key K after receiving the information;
after the verification is passed, the client A encrypts the identity information IDA of the client A through the session key K and sends the encrypted identity information IDA to the client B, and the client B receives the information and then decrypts and authenticates the identity information of the client A through the session key K;
and after the verification is passed, the client A and the client B communicate through a session key K.
6. The negotiation communication method of a federation chain-based anti-quantum computing IKE system according to claim 5, wherein: in the step 1, Cookie A is a result obtained by calculating the IP of the client A, the IP of the client B, the random number, the current date and the current time by adopting an MD5 algorithm; CookieB is the result of calculating the IP of the client B, the IP of the client A, the random number, the current date and the current time by using an MD5 algorithm.
7. The negotiation communication method of a federation chain-based anti-quantum computing IKE system according to claim 5, wherein: in the step 1, the second identity of the client A is a result of performing hash operation on the ID of the client A and the CookieA; the second identity of the client B is the result of performing hash operation on the ID of the client B and the Cookie B.
8. The negotiation communication method of a federation chain-based anti-quantum computing IKE system according to claim 5, wherein: in step 2 (1), the transaction tx is composed of a propofol and a clientSig, the function parameter txPayload is calculated by the second identity of the client B and the cookie B, and the client a calculates the ID cryptography-based signature of the propofol as the clientSig through the private key SKA.
9. The negotiation communication method of a federation chain-based anti-quantum computing IKE system according to claim 5, wherein: in step 2 (3), the encryption offset calculation method for (xi, Ki) is as follows;
and encrypting xi and Ki through a public key of the client, after encryption, acting a hash function on the ID of the client and the Endorser and the transaction ID to obtain an offset, and performing offset operation on the ciphertext by using the offset to obtain the offset ciphertext.
10. The negotiation communication method of a federation chain-based anti-quantum computing IKE system according to claim 5, wherein: in step 2, (2) when the Endorser searches for the identity information of the client a in the key fob, the Endorser traverses an ID list in the key fob, performs hash operation on the ID and the cookie a, compares the obtained result with the second identity of the client a, and the IDs with the same result are the identity information IDA of the client a;
when searching for the Endorser identity information IDE in the key fob in the step 2 (3), the client A traverses an ID list in the key fob, performs hash operation on the ID and the transaction ID, compares the obtained result with the second Endorer identity, and the ID with the same result is the Endorer identity information IDE.
CN201911388616.XA 2019-12-30 2019-12-30 Anti-quantum computing IKE system based on alliance chain and negotiation communication method Pending CN111181718A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911388616.XA CN111181718A (en) 2019-12-30 2019-12-30 Anti-quantum computing IKE system based on alliance chain and negotiation communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911388616.XA CN111181718A (en) 2019-12-30 2019-12-30 Anti-quantum computing IKE system based on alliance chain and negotiation communication method

Publications (1)

Publication Number Publication Date
CN111181718A true CN111181718A (en) 2020-05-19

Family

ID=70650439

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911388616.XA Pending CN111181718A (en) 2019-12-30 2019-12-30 Anti-quantum computing IKE system based on alliance chain and negotiation communication method

Country Status (1)

Country Link
CN (1) CN111181718A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112434281A (en) * 2020-11-17 2021-03-02 重庆邮电大学 Multi-factor identity authentication method oriented to alliance chain
CN113612610A (en) * 2021-09-15 2021-11-05 深圳市国信量子科技有限公司 Session key negotiation method
CN114553420A (en) * 2022-04-21 2022-05-27 济南量子技术研究院 Digital envelope packaging method based on quantum key and data secret communication network
CN115955308A (en) * 2023-03-13 2023-04-11 国开启科量子技术(北京)有限公司 Digital asset processing method, device, equipment and medium based on anti-quantum key

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019072281A2 (en) * 2018-11-27 2019-04-18 Alibaba Group Holding Limited Asymmetric key management in consortium blockchain networks
CN110086626A (en) * 2019-04-22 2019-08-02 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce and system based on unsymmetrical key pond pair
CN110380845A (en) * 2019-06-25 2019-10-25 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce based on group's pool of symmetric keys, system, equipment
WO2019217598A1 (en) * 2018-05-10 2019-11-14 Alibaba Group Holding Limited Blockchain data processing methods, apparatuses, devices, and systems
CN110493005A (en) * 2019-08-09 2019-11-22 如般量子科技有限公司 Anti- quantum calculation public key pond update method and system based on alliance's chain

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2019217598A1 (en) * 2018-05-10 2019-11-14 Alibaba Group Holding Limited Blockchain data processing methods, apparatuses, devices, and systems
WO2019072281A2 (en) * 2018-11-27 2019-04-18 Alibaba Group Holding Limited Asymmetric key management in consortium blockchain networks
CN110086626A (en) * 2019-04-22 2019-08-02 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce and system based on unsymmetrical key pond pair
CN110380845A (en) * 2019-06-25 2019-10-25 如般量子科技有限公司 Quantum secret communication alliance chain method of commerce based on group's pool of symmetric keys, system, equipment
CN110493005A (en) * 2019-08-09 2019-11-22 如般量子科技有限公司 Anti- quantum calculation public key pond update method and system based on alliance's chain

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112434281A (en) * 2020-11-17 2021-03-02 重庆邮电大学 Multi-factor identity authentication method oriented to alliance chain
CN112434281B (en) * 2020-11-17 2024-04-30 芽米科技(广州)有限公司 Multi-factor identity authentication method oriented to alliance chain
CN113612610A (en) * 2021-09-15 2021-11-05 深圳市国信量子科技有限公司 Session key negotiation method
CN113612610B (en) * 2021-09-15 2024-02-02 深圳市国信量子科技有限公司 Session key negotiation method
CN114553420A (en) * 2022-04-21 2022-05-27 济南量子技术研究院 Digital envelope packaging method based on quantum key and data secret communication network
CN115955308A (en) * 2023-03-13 2023-04-11 国开启科量子技术(北京)有限公司 Digital asset processing method, device, equipment and medium based on anti-quantum key
CN115955308B (en) * 2023-03-13 2023-06-27 国开启科量子技术(北京)有限公司 Digital asset processing method, device, equipment and medium based on quantum-resistant key

Similar Documents

Publication Publication Date Title
CN111181718A (en) Anti-quantum computing IKE system based on alliance chain and negotiation communication method
CN113556237B (en) Threshold signature method, system, device and storage medium based on aggregation of multiple signatures
CN111416715B (en) Quantum secret communication identity authentication system and method based on secret sharing
CN111416706B (en) Quantum secret communication system based on secret sharing and communication method thereof
CN113037499B (en) Block chain encryption communication method and system
CN114125833A (en) Multi-factor authentication key agreement method for intelligent equipment communication
CN113572603A (en) Heterogeneous user authentication and key agreement method
CN111416712B (en) Quantum secret communication identity authentication system and method based on multiple mobile devices
CN113132104A (en) Active and safe ECDSA (electronic signature SA) digital signature two-party generation method
CN111314083A (en) Quantum secret communication system and method based on secret sharing and asymmetric cryptography
CN110737915A (en) Anti-quantum-computation anonymous identity recognition method and system based on alliance chain and implicit certificate
CN116388995A (en) Lightweight smart grid authentication method based on PUF
CN110737907B (en) Anti-quantum computing cloud storage method and system based on alliance chain
CN113098681A (en) Port order enhanced and updatable blinded key management method in cloud storage
CN110851859B (en) Authentication method of distributed authority node block chain system with (n, t) threshold
CN110708337A (en) Big data security framework system based on identity authentication
CN113179153B (en) User authentication and key agreement method based on certificateless
CN113014376B (en) Method for safety authentication between user and server
CN110880969B (en) Method and system for generating QKD network authentication key based on alliance chain and implicit certificate
CN111245611B (en) Anti-quantum computation identity authentication method and system based on secret sharing and wearable equipment
CN114070549B (en) Key generation method, device, equipment and storage medium
CN110740034B (en) Method and system for generating QKD network authentication key based on alliance chain
CN116599659B (en) Certificate-free identity authentication and key negotiation method and system
KR100456624B1 (en) Authentication and key agreement scheme for mobile network
CN116886306A (en) Verifiable digital signature method based on elliptic curve

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
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20200519