A lightweight two-factor authentication key agreement method

Abstract

The application provides a lightweight two-factor authentication key agreement method, and belongs to the technical field of key agreement; the method solves the problem of insecurity of the existing IBC key management, and comprises the following steps: S1: an initialization stage, comprising CA initialization, user initialization, user certificate generation and user setting, wherein the CA initialization comprises selection of a private key and a public key of the CA, and the user initialization comprises generation of a user private key and a user public key; S2: a key agreement stage, in which user A and user B first send messages to each other, and then user A and user B respectively calculate a session key; S3: session key derivation, in which user A generates a session key, and user B generates a session key; the application is applied to key agreement.

Description

Technical Field

[0001] This invention provides a lightweight two-factor authentication key negotiation method, belonging to the field of key negotiation technology. Background Technology

[0002] Over the years, numerous AKA protocols have been proposed. However, most are based on traditional public-key cryptography (PKC) or identity-based cryptography (IBC). Traditional PKC suffers from certificate management problems, while IBC has key escrow issues. To address the inherent problems of IBC and traditional PKC, the concept of Certificate-Based Cryptography (CBC) was proposed. In CBC, each user generates a public / private key pair and sends the public key to a trusted Certificate Authority (CA) to request a certificate. The certificate is then pushed to its owner and acts as a partial decryption or signing key. This approach provides an implicit certificate property, so each user needs to use their certificate and private key to perform some operations (such as decryption and signing), while other users do not need the CA's certificate to verify the authenticity of their public key. CBC simplifies the certificate revocation problem in traditional PKC and also eliminates the key escrow and key distribution problems.

[0003] Traditional PKC (public key cryptography) schemes involve the exchange of public keys between communicating parties. When the number of users is large, each user must spend a significant amount of time receiving and storing other users' public keys, resulting in high public key management costs. IBC (identity-based cryptography) schemes establish a key management authority trusted by all users. During communication, both parties only need to obtain each other's public keys from the authority using their ID information, saving the cost of key management. However, the key management authority is a centralized structure, meaning malicious attackers can launch attacks against it. Once compromised, the communication security of all users will be severely impacted. Summary of the Invention

[0004] To address the insecurity issues of existing IBC key management, this invention proposes a lightweight two-factor authentication key negotiation method.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is: a lightweight two-factor authentication key negotiation method, comprising the following steps:

[0006] S1: Initialization phase: includes CA initialization, user initialization, user certificate generation and user settings. CA initialization includes selecting the CA's private key and public key, and user initialization includes generating the user's private key and public key.

[0007] S2: Key negotiation phase: User A and User B first send messages to each other, and then User A and User B calculate the session key respectively;

[0008] S3: Session key derivation: User A generates a call key, and user B generates a call key.

[0009] F needs to be given before initialization. q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2, where F q Let G denote a finite field of order q, G denote the group generated by elliptic curves, and P denote the generator of group G. The field that generates the private key;

[0010] The CA initialization includes: random selection As the master key of the CA, its corresponding public key is P. pub =x×P;

[0011] The user initialization includes user key generation, where each user generates their own private key. Corresponding public key PK u =S u ×P;

[0012] The user certificate generation includes: given parameters, master key x, and user public key PK. u And user identity IDu∈{0,1} n CA calculates Q u =H1(ID) u ||PK u Output Certificate (Cert) u =xQ u Then send M1={Cert u Give it to the user;

[0013] User calculation:

[0014] Q u =H1(ID) u ||PK u );

[0015]

[0016] If the above equations are equal, then user settings are performed; otherwise, the user certificate is regenerated. The above equations are used to verify the CA-issued certificate (Certificate). u Is it effective?

[0017] The user settings include: user calculations:

[0018]

[0019] as well as

[0020]

[0021] Step S2 specifically includes:

[0022] User A first generates a random value. And calculate And T A =t A ·P, then A sends the following message M1 to B;

[0023] A→B:M1=(ID A , Pk A T A );

[0024] After receiving M1, user B first generates a random value. And calculate And T B =t B • P; then B sends the following message M2 to A:

[0025] B→A:M2=(ID B , Pk B T B );

[0026] Next, A calculates the session key as follows:

[0027] Q A =H1(ID) B ||Pk B );

[0028]

[0029]

[0030] B calculates the session key using the following method:

[0031] Q B =H1(ID) A ||Pk A );

[0032]

[0033]

[0034] Step S3 specifically includes:

[0035] A and B calculate the session key as follows:

[0036] Calculate the call key sk generated by user A A :

[0037]

[0038] Calculate the call key sk generated by user B. B :

[0039]

[0040] A lightweight two-factor authentication key negotiation method includes the following steps:

[0041] S1: Initialization phase: includes CA initialization, user initialization, user certificate generation, user registration and user settings. CA initialization includes selecting the CA's private key and public key, and user initialization includes generating the user's private key and public key.

[0042] User registration is conducted on the blockchain after the user certificate is generated, and user settings are also performed on the blockchain.

[0043] S2: Key negotiation phase: User A and User B first send messages to each other, and then User A and User B calculate the session key respectively.

[0044] S3: Session key derivation: User A generates a call key, and user B generates a call key.

[0045] Before initialization in step S1, F needs to be given. q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2, where F q Let G denote a finite field of order q, G denote the group generated by elliptic curves, and P denote the generator of group G.

[0046] 1) CA Initialization: First, randomly select As the master key of the CA, the corresponding public key is P. pub = x × P, CA uses its parameter F q , G, P and key are used to issue certificates;

[0047] 2) User key generation: Each user generates their own private key. Corresponding public key PK u =s u ×P;

[0048] 3) CertGen: Given parameters, master key x, user public key PK u and user identity ID u ∈{0,1} n CA calculates Qu =H1(ID) u ||PK u Output Certificate (Cert) u =xQ u Then send M1={Cert u Give it to the user;

[0049] 4) User registration transaction: After CertGen, the CA sends M1 = {CertGen} U ||P||P pub} To the blockchain;

[0050] 5) User setting 1: After step 4), the user calculates Q. u =H1(ID) u ||PK u ), and then send For blockchain;

[0051] The smart contract will use the messages Cert obtained from steps 4) and 5) respectively. u ,P,P pub Q u As input, calculate the following formula:

[0052]

[0053] If the above equations are equal, output True; otherwise, output False. If the output is True, calculate the following formula: L u =Q u ·(PK u +P pub If the output is False, the verification fails, and the process returns to step 4.

[0054] After this, proceed to the next step and store the transaction information in the node's current block;

[0055] User setting 2: When a user requests a smart contract on the blockchain, if it returns True, the following formula is calculated. Otherwise, verification fails, return to step 4).

[0056] Step S2 specifically includes:

[0057] A first generates a random value. And calculate and T A =t A ·P, then A sends the following message M1 to B: A→B: M1=(ID) A , Pk A T A );

[0058] After receiving M1, B first generates a random value. And calculate and T B =t B ·P, then B sends the following message M2 to A, B→A: M2=(ID B , Pk B T B );

[0059] Then, A uses M2 to request the blockchain's smart contract; if it returns True, it returns the corresponding value L. B Then, A calculates the shared secret as follows:

[0060] Q A =H1(ID) B ||Pk B );

[0061]

[0062]

[0063] B requests the blockchain's smart contract using M1; if True, it obtains L. A B calculates the shared secret as follows:

[0064] Q B =H1(ID) A ||Pk A );

[0065]

[0066]

[0067] Step S3 specifically includes:

[0068] A and B calculate the session key as follows.

[0069] Calculate the generated call key sk for user A A :

[0070]

[0071] Calculate the call key sk generated by user B. B :

[0072]

[0073] The advantages of this invention over the prior art are as follows: the lightweight two-factor authentication key negotiation method provided by this invention simplifies the certificate revocation problem in traditional PKC, and also eliminates the key custody problem and key distribution problem; the blockchain-based certificate authentication scheme reduces the amount of computation on the user end by transferring some processes to the blockchain. Attached Figure Description

[0074] The present invention will be further described below with reference to the accompanying drawings:

[0075] Figure 1 This is a flowchart of the key negotiation method proposed in Embodiment 1 of the present invention;

[0076] Figure 2 This is a flowchart of the blockchain-based key negotiation method proposed in Embodiment 2 of the present invention. Detailed Implementation

[0077] Example 1

[0078] like Figure 1 As shown, this invention proposes a two-factor authentication protocol that provides anonymity and lightweight functionality. Using this protocol, both communicating parties can negotiate a secure session key. The symbols used and their meanings are shown in Table 1 below:

[0079] E Elliptic curve G Elliptic curve generation group <![CDATA[F q ]]> Finite fields of order q P Generators of group G H Hash function × Scalar multiplication || Merge operation <![CDATA[S u ]]> User u's private key <![CDATA[PK u ]]> User u's public key <![CDATA[ID u ]]> User u's identity code x Server private key <![CDATA[P pub ]]> Server public key <![CDATA[Cert u ]]> User u's certificate <![CDATA[sk u ]]> User u generated the call key

[0080] Table 1. Meaning of symbols and parameters used in this invention.

[0081] The lightweight two-factor authentication key negotiation method proposed in this invention has the following steps:

[0082] A: Initialization phase

[0083] Given F q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2.

[0084] 1) CA Initialization: First, randomly select As the master key of the CA, its corresponding public key is P. pub = x×P. The CA uses its parameters and keys to issue certificates.

[0085] 2) User key generation: Each user generates their own private key. Corresponding public key PK u =S u ×P.

[0086] 3) CertGen: Given parameters, master key x, user public key PK u And user identity IDu∈{0,1} nCA calculates Q u =H1(ID) u ||PK u Output Certificate (Cert) u =xQ u Then send M1={Cert u Give it to the user.

[0087] 4) After step 3), the user calculates...

[0088] Q u =H1(ID) u ||PK u );

[0089]

[0090] If the above equations are equal, proceed to step 5; otherwise, return to step 3.

[0091] 5) User settings: After step 4), the user performs the calculation:

[0092]

[0093] as well as

[0094]

[0095] B: Key Negotiation Phase

[0096] A first generates a random value. And calculate And T A =t A ·P. Then A sends the following message M1 to B. Where t A express, It means that T A express.

[0097] A→B:M1=(ID A , Pk A T A );

[0098] After receiving M1, B first generates a random value. And calculate And T B =t B ·P. Then B sends the following message M2 to A: where t B express, It means that T B express.

[0099] B→A:M2=(ID B , PkB T B ).

[0100] Next, A calculates the session key as follows:

[0101] Q A =H1(ID) B ||Pk B );

[0102]

[0103]

[0104] B calculates the session key using the following method:

[0105] Q B =H1(ID) A ||Pk A );

[0106]

[0107]

[0108] Q B express, express, express, express, express. and because:

[0109]

[0110]

[0111]

[0112]

[0113] C: Session key derivation:

[0114] A and B calculate the session key as follows:

[0115] Calculate the call key sk generated by user A A :

[0116]

[0117] Calculate the call key sk generated by user B. B :

[0118]

[0119] Example 2

[0120] This invention further improves upon the aforementioned key negotiation method, proposing a lightweight two-factor authentication key negotiation method based on blockchain, such as... Figure 2 As shown, this method constructs a blockchain-based certificate authentication scheme. This scheme reduces the computational load on the user end by transferring some processes to the blockchain. The specific steps are as follows.

[0121] A: Initialization phase

[0122] Given F q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2.

[0123] 1) CA Initialization: First, randomly select As the master key of the CA, the corresponding public key is P. pub = x×P. The CA uses its parameters and secret to issue certificates.

[0124] 2) User key generation: Each user generates their own private key. Corresponding public key PK u =s u ×P.

[0125] 3) CertGen: Given parameters, master key x, user public key PK u and user identity ID u ∈{0,1} n CA calculates Q u =H1(ID) u ||PK u Output Certificate (Cert) u =xQ u Then send M1={Cert} u Give it to the user.

[0126] 4) User registration transaction: After CertGen, the CA sends M1 = {CertGen} U ||P||P pub} To the blockchain.

[0127] 5) User setting 1: After step 4), the user calculates Q. u =H1(ID) u ||PK u ), and then send To blockchain.

[0128] Proof: The smart contract will use the messages Cert obtained from steps 4 and 5 respectively. u ,P,Ppub Q u As input, calculate the following formula:

[0129]

[0130] If the above equations are equal, output True; otherwise, output False. If the output is True, calculate the following formula: L u =Q u ·(PK u +P pub If the output is False, the verification fails and the process returns to step 4.

[0131] After that, proceed to the next step and store the transaction information in the node's current block.

[0132] User setting 2: When a user requests a smart contract on the blockchain, if it returns True, the following formula is calculated. Otherwise, verification fails, and return to step 4.

[0133] B: Key Negotiation Phase

[0134] A first generates a random value. And calculate and T A =t A P. Then A sends the following message M1 to B.

[0135] A→B:M1=(ID A , pk A T A ).

[0136] After receiving M1, B first generates a random value. And calculate and T B =t B ·P. Then B sends the following message M2 to A, B→A: M2=(ID B , Pk B T B ).

[0137] Then, A uses M2 to request the blockchain's smart contract; if it returns True, it returns the corresponding value L. B Then, A calculates the shared secret as follows:

[0138] Q A =H1(ID) B ||Pk B );

[0139]

[0140]

[0141] B requests the blockchain's smart contract using M1; if True, it obtains L. A B calculates the shared secret as follows:

[0142] Q B =H1(ID) A ||Pk A );

[0143]

[0144]

[0145] and Because:

[0146]

[0147]

[0148]

[0149]

[0150] C: Session key derivation:

[0151] A and B calculate the session key as follows.

[0152] Calculate the generated call key sk for user A A :

[0153]

[0154] Calculate the call key sk generated by user B. B :

[0155]

[0156] Embodiment 1 of this invention proposes an elliptic curve-based certificate encryption scheme, CBC. In this scheme, the Certificate Authority (CA) only needs to sign the authenticated user key; it does not need to store the user key. Before communication, the user only needs to authenticate the CA's signature; successful authentication indicates that the other party has been recognized by the CA and is a secure communication partner. Furthermore, this scheme uses elliptic curve encryption, and multiple experiments have demonstrated that elliptic curves have significant advantages in encryption efficiency and security. Embodiment 2, building upon Embodiment 1, introduces blockchain for authentication. Blockchain is a public, immutable, decentralized ledger where any operation is permanently recorded and traceable. Blockchain further enhances the security of the scheme.

[0157] Regarding the meaning of the parameters in the formulas of this invention, apart from the parameters in Parameter Table 1 which have actual meanings, the other encryption / decryption, hashing, and OR calculations are just intermediate results without actual meanings. Their purpose is to verify whether the result obtained after a series of complex calculations is equal to the received result, because many of the calculation parameters required for these intermediate calculation results are private.

[0158] Regarding the specific structure of this invention, it should be noted that the connection relationships between the various component modules used in this invention are definite and achievable. Except as specifically described in the embodiments, their specific connection relationships can bring about corresponding technical effects and solve the technical problems proposed by this invention without relying on the execution of corresponding software programs. The models of the components, modules, and specific components appearing in this invention, the connection methods between them, and the conventional usage methods and expected technical effects brought about by the above technical features, unless specifically described, are all publicly disclosed content in patents, journal articles, technical manuals, technical dictionaries, and textbooks that can be obtained by those skilled in the art before the application date, or belong to conventional technology, common knowledge, and other existing technologies in this field. There is no need to elaborate, which makes the technical solution provided in this case clear, complete, and achievable, and can reproduce or obtain corresponding physical products based on this technical means.

[0159] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A lightweight two-factor authentication key negotiation method, characterized in that: Includes the following steps: S1: Initialization phase: includes CA initialization, user initialization, user certificate generation and user settings. CA initialization includes selecting the CA's private key and public key, and user initialization includes generating the user's private key and public key. In step S1, F needs to be given before initialization. q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2, where F q Let G denote a finite field of order q, G denote the group generated by elliptic curves, and P denote the generator of group G. The field that generates the private key; The CA initialization includes: randomly selecting As the master key of the CA, its corresponding public key is P. pub =x×P; The user initialization includes user key generation, where each user generates their own private key. Corresponding public key PK u =S u ×P; The user certificate generation includes: given parameters, master key x, and user public key PK. u and user identity ID u ∈{0,1} n CA calculates Q u =H1(ID) u ‖PK u Output Certificate (Cert) u =xQ u Then send M1={Cert u Give it to the user; User calculation: Q u =H1(ID u ||PK u ); If the above equations are equal, then proceed with the user settings; otherwise, regenerate the user certificate. The user settings include: user calculations: as well as S2: Key negotiation phase: User A and User B first send messages to each other, and then User A and User B calculate the session key respectively; Step S2 specifically includes: User A first generates a random value. And calculate And T A =t A ·P, then A sends the following message M1 to B; A→B:M1=(ID A ,Pk A ,T A ); After receiving M1, user B first generates a random value. And calculate And T B =t B • P; then B sends the following message M2 to A: B→A:M2=(ID B ,Pk B ,T B ); Next, A calculates the session key as follows: Q A =H1(ID B ||Pk B ); B calculates the session key using the following method: Q B =H1(ID A ‖Pk A ); S3: Session key derivation: User A generates a call key, and user B generates a call key.

2. The lightweight two-factor authentication key negotiation method according to claim 1, characterized in that: Step S3 specifically includes: A and B calculate the session key as follows: Calculate the call key sk generated by user A A : Calculate the call key sk generated by user B. B :

3. A lightweight two-factor authentication key negotiation method, characterized in that: Includes the following steps: S1: Initialization phase: includes CA initialization, user initialization, user certificate generation, user registration and user settings. CA initialization includes selecting the CA's private key and public key, and user initialization includes generating the user's private key and public key. User registration is conducted on the blockchain after the user certificate is generated, and user settings are also performed on the blockchain. Before initialization in step S1, F needs to be given. q , G, P, and two collision-resistant encrypted one-way hash functions H1 and H2, where F q Let G denote a finite field of order q, G denote the group generated by elliptic curves, and P denote the generator of group G. 1) CA Initialization: First, randomly select As the master key of the CA, the corresponding public key is P. pub = x × P, CA uses its parameter F q , G, P and key are used to issue certificates; 2) User key generation: Each user generates their own private key. Corresponding public key PK u =s u ×P; 3) CertGen: Given parameters, master key x, user public key PK u and user identity ID u ∈{0,1} n CA calculates Q u =H1(ID) u ‖PK u Output Certificate (Cert) u =xQ u Then send M1={Cert u Give it to the user; 4) User registration transaction: After CertGen, the CA sends M1 = {CertGen} U ||P||P pub } To the blockchain; 5) User setting 1: After step 4), the user calculates Q. u =H1(ID) u ||PK u ), and then send For blockchain; The smart contract will use the messages Cert obtained from steps 4) and 5) respectively. u ,P,P pub Q u As input, calculate the following formula: If the above equations are equal, output True; otherwise, output False. If the output is True, calculate the following formula: L u =Q u ·(PK u +P pub If the output is False, the verification fails, and the process returns to step 4. After this, proceed to the next step and store the transaction information in the node's current block; User setting 2: When a user requests a smart contract on the blockchain, if it returns True, the following formula is calculated. Otherwise, verification fails, return to step 4); S2: Key negotiation phase: User A and User B first send messages to each other, and then User A and User B calculate the session key respectively; Step S2 specifically includes: A first generates a random value. And calculate and T A =t A ·P, then A sends the following message M1 to B: A→B:M1=(ID A ,Pk A T A ); After receiving M1, B first generates a random value. And calculate and T B =t B ·P, then B sends the following message M2 to A, B→A: M2=(ID B , Pk B T B ); Then, A uses M2 to request the blockchain's smart contract; if it returns True, it returns the corresponding value L. B Then, A calculates the shared secret as follows: Q A =H1(ID B ||Pk B ); B requests the blockchain's smart contract using M1; if True, it obtains L. A B calculates the shared secret as follows: Q B =H1(ID A ||Pk A ); S3: Session key derivation: User A generates a call key, and user B generates a call key.

4. The lightweight two-factor authentication key negotiation method according to claim 3, characterized in that: Step S3 specifically includes: A and B calculate the session key as follows: Calculate the generated call key sk for user A A : Calculate the call key sk generated by user B. B :

Images