A Privacy-Preserving Authenticated Key Exchange Method

Abstract

A method for authentication key exchange based on privacy protection belongs to the technical field of authentication key exchange. The technical problem to be solved is to provide an improvement to the method for authentication key exchange based on privacy protection. The technical solution adopted to solve this technical problem is as follows: It includes the following key exchange steps. First, user registration is carried out in a trusted channel: Define that the user inputs real identity information and a user password, generates a random number and performs calculations. After the calculations are completed, the user sends the processed information to the server, and the server responds to the request. Then, the smart card is set up, and information authentication is carried out in a normal channel: Require the user to first insert the smart card into the card reader and input the processed information. The card reader checks whether the reset threshold exceeds the threshold. If it exceeds the threshold, the authentication process is aborted. If it does not exceed the threshold, the card reader reads the parameters from the smart card and performs calculations. This invention is applied to authentication key exchange.

Description

Technical Field

[0001] A method for authenticated key exchange based on privacy protection according to the present invention belongs to the technical field of authenticated key exchange. Background Art

[0002] In recent years, with the development of network and communication technologies, information security has become increasingly important. Among various secure communication solutions, the authentication key exchange protocol is one of the basic components. Currently, people often use user passwords and smart cards as authentication factors. For example, using a smart card as a physical token for a card reader to read and entering a pre-set password for secure payment and access control, etc. This mode usually requires users to set their own user passwords during the registration phase and obtain a smart card issued by the server that records authentication information for use.

[0003] However, at the same time, there are also security risks in the registration and use of user passwords and smart cards, which may lead to the leakage of user privacy. To prevent the server or malicious network attackers from obtaining the user identity during the authentication process, various existing solutions have different degrees of defects. For example, they cannot resist offline dictionary attacks, key loss imitation attacks, and cannot provide forward security. In addition, in the Internet of Things scenario, due to the limited computing power of many devices, lightweight computing will also be a factor that the application protocol must consider. Therefore, it is necessary to improve the existing protocol methods for authenticated key exchange for privacy protection. Summary of the Invention

[0004] In order to overcome the deficiencies in the prior art, the technical problem to be solved by the present invention is to provide an improvement of a method for authenticated key exchange based on privacy protection.

[0005] To solve the above technical problem, the technical solution adopted by the present invention is: A method for authenticated key exchange based on privacy protection, including the following key exchange steps:

[0006] Step 1: User registration in a trusted channel:

[0007] Step 1.1: User requests registration: Define that user U inputs real identity information ID U and user password PW U , generates two random numbers and calculates respectively:

[0008] AID U = Hash(ID U ∥PW U ∥a U );

[0009] BID U = Hash(ID U ∥PWU ∥b U );

[0010] After the calculation is completed, user U sends the information {ID U , AID U , BID U} to server S;

[0011] Step 1.2: Server responds to the request: After receiving the registration request, server S checks whether the identity information ID U already exists in the registration table. If it does, server S asks user U to re-enter an identity information ID U . If the identity information ID U is unique, server S generates two random numbers and calculates respectively:

[0012]

[0013]

[0014] After the calculation is completed, server S stores in the registration table, where ID SC is the identifier of the smart card and CTR S is the authentication attempt counter maintained by the server;

[0015] Specifically, server S stores in smart card SC, and then server S sends smart card SC to user U;

[0016] Step 1.3: Complete the smart card setup: After receiving smart card SC, user U makes the following calculations:

[0017]

[0018] After the calculation is completed, user U stores in smart card SC to complete the registration phase;

[0019] Step Two: Conduct information authentication in the normal channel:

[0020] Step 2.1: Request authentication: User U first inserts the smart card into the card reader and enters ID U and PW U . Then, card reader SCR checks whether the reset threshold exceeds the threshold, that is, determines whether CTR SC ≥RT holds. If it exceeds the threshold, the authentication process is aborted. If it does not exceed the threshold, card reader SCR reads

[0021] And calculate respectively:

[0022] AID U = Hash(ID U ∥PW U ∥a U );

[0023]

[0024] Then, the card reader SCR generates a random number as a temporary secret, generates a timestamp TS SCR , and calculates respectively:

[0025] A = Hash(PW U ∥b U ∥α);

[0026]

[0027] Finally, the card reader SCR sends the information M1 = {DID U , M SCR , H SCR , TS SCR} to the server S;

[0028] Step 2.2: Respond to the user: When receiving the information M1, the server S first generates a timestamp TS S , and then checks the timeliness of the request, that is, judges whether |TS S - TS SCR | < ΔT holds. If this inequality does not hold, the authentication request is rejected. If the inequality holds, the following calculations are performed:

[0029] (ID U ∥b S ) = Dec sk (DID U );

[0030] Then the server S looks up according to ID U in the registry The server S checks whether the reset threshold is exceeded, that is, judges whether CTR S ≥ RT holds. If the threshold is exceeded, the authentication request is rejected. If the threshold is not exceeded, the following calculations are performed:

[0031]

[0032] The server S uses its own parameters to perform the following calculations:

[0033]

[0034] The server S checks H′ SCR =H SCR to see if it holds. If it does not hold, the authentication request is rejected, and the value of CTR S is incremented by 1. If it holds, the server S generates a random number as a temporary secret, and then performs the following calculations:

[0035]

[0036] B = Hash(a S ∥b S ∥β);

[0037]

[0038] To update the identity, the server S generates a random number Then the server S performs the following calculations:

[0039]

[0040] Finally, the server S sends the information to the card reader SCR;

[0041] Step 2.3: The user receives the session key: When receiving the message M2, the card reader SCR performs the following calculations:

[0042]

[0043] The card reader SCR uses its own parameters to perform the following calculations:

[0044]

[0045] The card reader SCR checks if H S ′ = H S holds. If it does not hold, the acceptance of the session key is rejected, and the value of CTR SC is incremented by 1. If it holds, the card reader SCR resets CTR SC to 0, and then the card reader SCR accepts the session key

[0046] Step 2.4: The user updates the identity: The card reader SCR uses to replace the DID in SC U , and then the card reader SCR performs the following calculations:

[0047]

[0048] The card reader SCR sends the message to the server S;

[0049] Step 2.5: The server receives the session key: When receiving the message M3, the server S makes the following calculations using its own parameters:

[0050]

[0051] The server S detects Whether it holds. If it does not hold, the server rejects the received session key and increments the value of CTR S by 1. If it holds, the server S resets CTR S to 0, and then the server S accepts the session key

[0052] The beneficial effects of the present invention compared with the prior art are as follows: The present invention provides a new authentication key exchange protocol based on privacy protection, using common smart cards and user passwords as authentication elements, and only requiring lightweight operations such as hashing, symmetric key encryption and decryption, and exclusive OR to complete security authentication. Moreover, it can resist various currently known attacks, such as offline dictionary attacks, key loss imitation attacks, temporary key loss attacks, and smart card loss attacks. At the same time, the present invention uses user passwords and smart cards to provide a two-factor authentication scheme, which is more secure and reliable than other single-factor schemes, enhancing the privacy protection function. Malicious attackers cannot obtain the user's identity information through eavesdropping. The present invention has two-way authentication, forward security, and anonymity, and does not require scalar multiplication calculations in the authentication phase, enabling the protocol of this method to be deployed on resource-constrained terminals in the Internet of Things. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0054] Figure 1 is a flowchart of the key exchange authentication phase of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0055] As Figure 1 shown, the present invention specifically proposes an authentication key exchange protocol based on smart cards and user passwords for privacy protection. Using this protocol, the server and the user will finally negotiate and generate a secure session key.

[0056] First, define the meanings of the parameters used in the key exchange method of the present invention:

[0057] F p is a finite field containing p elements;

[0058] E(F p ) is the set of all rational points on the elliptic curve E over F p ;

[0059] G is a base point of the set E(F p );

[0060] n is the order of the base point G, where n is a prime number;

[0061] is the set [1, 2, …, n - 1];

[0062] PW U is the user password;

[0063] sk is the private key of the server;

[0064] PK is the public key of the server;

[0065] Hash(·) is a secure hash equation;

[0066] Enc k (·) is a symmetric key encryption equation using k as the key;

[0067] Dec k (·) is a symmetric key decryption equation using k as the key;

[0068] × is the scalar multiplication on the elliptic curve;

[0069] ⊕ is the bitwise exclusive OR operation;

[0070] ∥ is the concatenation operation;

[0071] U is the User;

[0072] S is the Server;

[0073] SC is the Smart Card;

[0074] CTR is the counter for authentication attempts;

[0075] RT is the reset threshold;

[0076] TS is the timestamp;

[0077] ΔT is the maximum transmission delay.

[0078] The present invention specifically includes the algorithm for authentication step one, i.e., request authentication, and authentication step two, i.e., response authentication:

[0079] Step one: User registration is performed in a trusted channel:

[0080] Step 1.1: User requests registration: Define that user U inputs the real identity information ID U and the user password PW U , and generates two random numbers and calculates respectively:

[0081] AID U= Hash(ID U ∥PW U ∥a U );

[0082] BID U = Hash(ID U ∥PW U ∥b U );

[0083] After the calculation is completed, user U sends the information {ID U , AID U , BID U} to server S;

[0084] Step 1.2: Server responds to the request: After receiving the registration request, server S checks whether the identity information ID U already exists in the registration table. If it does, server S asks user U to re-enter an identity information ID U . If the identity information ID U is unique, server S generates two random numbers and calculates respectively:

[0085]

[0086] After the calculation is completed, server S stores in the registration table, where ID SC is the identifier of the smart card and CTR S is the authentication attempt counter maintained by the server;

[0087] Specifically, server S stores in smart card SC, and then server S sends smart card SC to user U;

[0088] Step 1.3: Complete the smart card setup: After receiving smart card SC, user U makes the following calculations:

[0089]

[0090] After the calculation is completed, user U stores in smart card SC, completing the registration phase;

[0091] Step Two: Conduct information authentication in the ordinary channel:

[0092] Step 2.1: Request authentication: User U first inserts the smart card into the card reader and enters ID U and PW U , and then card reader SCR checks whether the reset threshold exceeds the threshold, that is, determines whether CTR SCWhether ≥RT holds. If the threshold is exceeded, the authentication process is aborted. If the threshold is not exceeded, the card reader SCR reads from the smart card SC and calculates respectively:

[0093] AID U = Hash(ID U ∥PW U ∥a U );

[0094]

[0095] Then, the card reader SCR generates a random number as a temporary secret, generates a timestamp TS SCR , and calculates respectively:

[0096] A = Hash(PW U ∥b U ∥α);

[0097]

[0098] Finally, the card reader SCR sends the information M1 = {DID U , M SCR , H SCR , TS SCR} to the server S;

[0099] Step 2.2: Respond to the user: When receiving the information M1, the server S first generates a timestamp TS S , and then checks the timeliness of the request, that is, judges whether |TS S - TS SCR | < ΔT holds. If this inequality does not hold, the authentication request is rejected. If the inequality holds, the following calculations are performed:

[0100] (ID U ∥b S ) = Dec sk (DID U );

[0101] Then the server S looks up according to ID U in the registry The server S checks whether the reset threshold is exceeded, that is, judges whether CTR S ≥RT holds. If the threshold is exceeded, the authentication request is rejected. If the threshold is not exceeded, the following calculations are performed:

[0102]

[0103] The server S uses its own parameters to perform the following calculations:

[0104]

[0105] The server S checks H'. SCR = H SCR to see if it holds. If not, the authentication request is rejected, and the value of CTR S is incremented by 1. If it holds, the server S generates a random number as a temporary secret, and then performs the following calculations:

[0106]

[0107] B = Hash(a S ∥ b S ∥ β);

[0108]

[0109] To update the identity, the server S generates a random number and then the server S performs the following calculations:

[0110]

[0111] Finally, the server S sends the information to the card reader SCR;

[0112] Step 2.3: The user receives the session key: When receiving the information M2, the card reader SCR performs the following calculations:

[0113]

[0114] The card reader SCR uses its own parameters to perform the following calculations:

[0115]

[0116] The card reader SCR checks if H S ' = H S holds. If not, the acceptance of the session key is rejected, and the value of CTR SC is incremented by 1. If it holds, the card reader SCR resets CTR SC to 0, and then the card reader SCR accepts the session key

[0117] Step 2.4: The user updates the identity: The card reader SCR uses to replace the DID in SC U , and then the card reader SCR performs the following calculations:

[0118]

[0119] The card reader SCR sends a message to the server S;

[0120] Step 2.5: The server receives the session key: When receiving the message M3, the server S makes the following calculations using its own parameters:

[0121]

[0122] The server S checks whether it holds. If it does not hold, the server rejects the acceptance of the session key and increments the value of CTR S by 1. If it holds, the server S resets CTR S to 0, and then the server S accepts the session key

[0123] For the hash function used in the above step protocol, the hash message authentication code HMAC can be used, or the SM3 cryptographic hash algorithm of the national cryptography system can be used to replace it.

[0124] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A privacy - protected authentication key exchange method, characterized in that: It includes the following key exchange steps: Step 1: User registration is carried out in a trusted channel: Step 1.1: User requests registration: Define that user U inputs real identity information ID U and user password PW U , generate two random numbers a U , and calculate respectively: AID U = Hash(ID U ∥PW U ∥a U ); BID U = Hash(ID U ∥ PW U ∥ b U ); After the calculation is completed, user U sends the information {ID U , AID U , BID U} to server S; Step 1.2: Server responds to the request: After receiving the registration request, the server S checks whether the identity information ID U already exists in the registration table. If it does, the server S will ask the user U to re-enter an identity information ID U . If the identity information ID U is unique, the server S generates two random numbers a S , and calculates respectively: After the calculation is completed, the server S will store it in the registry, where ID SC is the identifier of the smart card, and CTR S is the authentication attempt counter maintained by the server; The server S specifically stores in the smart card SC, and then the server S sends the smart card SC to the user U; Step 1.3: Complete the smart card setup: After receiving the smart card SC, user U makes the following calculations: After the calculation is completed, user U will store it in the smart card SC to complete the registration phase; Step 2: Information authentication is carried out in a normal channel: Step 2.1: Request authentication: User U first inserts the smart card into the card reader and enters the ID U and PW U , and then the card reader SCR checks whether the reset threshold exceeds the threshold, that is, determines whether CTR SC ≥RT holds. If the threshold is exceeded, the authentication process is aborted. If the threshold is not exceeded, the card reader SCR reads from the smart card SC and calculates respectively: AID U = Hash(ID U ∥PW U ∥a U ); Then, the card reader SCR generates a random number as a temporary secret and generates a timestamp TS SCR , and calculates respectively: A = Hash(PW U ∥b U ∥α); Finally, the card reader SCR sends the information M1 = {DID U , M SCR , H SCR , TS SCR} to the server S; Step 2.2: Respond to the user: When receiving the message M1, the server S first generates a timestamp TS S , and then checks the timeliness of the request, that is, determines whether |TS S -TS SCR |<ΔT holds. If this inequality does not hold, the authentication request is rejected. If the inequality holds, the following calculations are performed: (ID U ∥b S ) = Dec sk (DID U ); Then the server S looks up according to the ID U in the registry The server S checks whether the reset threshold is exceeded, that is, it judges whether CTR S ≥RT holds. If the threshold is exceeded, the authentication request is rejected. If the threshold is not exceeded, the following calculations are performed: Server S makes the following calculations using its own parameters: The server S checks H S ′ CR = H SCR to see if it holds. If it does not hold, the authentication request is rejected and the value of CTR S is incremented by 1. If it holds, the server S generates a random number as a temporary secret and then performs the following calculations: B = Hash(a S ∥ b S ∥ β); To update the identity, server S generates a random number Then server S performs the following calculations: Finally, the server S sends the information to the card reader SCR; Step 2.3: The user receives the session key: When receiving the message M2, the card reader SCR makes the following calculations: The card reader SCR makes the following calculations using its own parameters: Card Reader SCR Detection H S ′ = H S Is it established? If not, reject the session key and increment the value of CTR SC by 1. If it is established, the card reader SCR resets CTR SC to 0, and then the card reader SCR accepts the session key Step 2.4: User updates identity: The card reader SCR uses to replace the DID in the SC U , and then the card reader SCR performs the following calculations: The card reader SCR sends the message to the server S; Step 2.5: The server receives the session key: When receiving the message M3, the server S makes the following calculations using its own parameters: Server S detects whether it holds. If not, it rejects the session key and increments the value of CTR S by 1. If it holds, Server S resets CTR S to 0, and then Server S accepts the session key

Images