CN117643010A

CN117643010A - Certificateless authentication and secure communication

Info

Publication number: CN117643010A
Application number: CN202180100645.0A
Authority: CN
Inventors: 李�泳; 李基�; 田文渊; 陈鑫平
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-11-02
Filing date: 2021-11-02
Publication date: 2024-03-01
Also published as: WO2023077280A1

Abstract

A client device (202, 206, 300, 400, 404, 406, 408, 410) and a method (100) for authenticating the client device with a client private key (308) are disclosed. The method comprises the following steps: generating a client ID and an authentication value; -sending the client ID and the authentication value to a key generation server (204); receiving one or more system parameters; generating a first message; sending the first message to the server; receiving a second message; authentication credentials are also received. The method further comprises the steps of: a valid private key and a valid public key are determined, wherein the valid private key and the valid public key are based on the first and second messages, the authentication credentials, the client private key, and the server public key.

Description

Certificateless authentication and secure communication

Technical Field

The present disclosure relates generally to the field of network security, and more particularly, to a client device and a method for certificateless authentication and secure communication.

Background

In a network security system, a secure communication channel is required between devices (e.g., between two computers) to maintain the authenticity, integrity, and confidentiality of messages transmitted over the secure communication channel. Traditionally, certificate-based authentication and communication techniques are employed. Certificate-based authentication communication technology is a general technology, and has good compatibility because of its wide acceptance. However, certificate-based authentication communication techniques may require maintenance of complex public key infrastructure (public key infrastructure, PKI) systems and performance is low due to the use of certificates. Because of the complexity of certificate systems, PKI systems cannot be deployed in a variety of execution environments, and thus entity authentication is difficult in such environments.

Another conventional technique widely used in network security systems is an identity-based scheme. Here, an Identification (ID) is used as a public key for the entity, which is relatively efficient for the certificate-based authentication in question. The system architecture used in identity-based schemes is also relatively simple. However, in an identity-based scheme, the private key of each entity needs to be generated entirely by the server, e.g. by a mutually trusted key generation center (key generation center, KGC) service. If such a server is affected, the whole system is threatened. In addition, network security systems employing identity-based schemes also present a number of key escrow problems.

Thus, in light of the above discussion, there is a need to overcome the above-described shortcomings associated with conventional methods of establishing a secure communication channel between communication devices.

Disclosure of Invention

The present disclosure is directed to a client device and a method for authenticating a client device having a client private key. The present disclosure is directed to providing a solution to the existing problem of requiring complex public key infrastructure (public key infrastructure, PKI) systems. It is an object of the present disclosure to provide an arrangement that at least partly overcomes the problems encountered in the prior art and to provide an improved method for authenticating a client device having a client private key.

The object of the present disclosure is achieved by the solution provided in the attached independent claims. Advantageous embodiments of the present disclosure are further defined in the dependent claims.

In one aspect, the present disclosure provides a client device comprising: a processor; a communication module; a memory for storing a client private key and instructions that cause the processor to: generating a client ID and an authentication value based on the client private key; transmitting the client ID and the authentication value to a key generation server using the communication module; receiving, by the communication module, one or more system parameters for secure communications from the server; generating a first message according to the client private key and the received system parameters, and sending the first message to the server by using the communication module; receiving, by the communication module, a second message from the server generated based on a server private key and the system parameters, and receiving an authentication credential generated based on the first message, the server private key, a server public key, and the client ID; a valid private/public key pair is calculated based on the first and second messages, the authentication credentials, the client private key, and the server public key.

The client device of the present disclosure provides secure communications without requiring the use of credentials. Thus, the disclosed client device may provide lightweight and secure communications without requiring overly complex computations as compared to traditional certificate-based schemes. Thus, the client device of the present disclosure may be more compatible and may have a friendly integrated environment.

In another implementation, generating the authentication value is further based on state information of the client device.

Here, the authentication value is generated based on the state information of the client device so as to obtain a unique value at a specific timing, which facilitates secure communication.

In another implementation, generating the authentication value includes: a first cryptographic hash function is generated based on the client private key.

The first cryptographic hash function may help to maintain the authenticity and integrity of the authentication value.

In another implementation, transmitting the client ID and authentication value to the server includes: concatenating the client ID and authentication value and encrypting using the client public key.

The concatenation may be used to link the client ID and the authentication value so that the client ID and the authentication value may be sent simultaneously. Furthermore, encrypting the client ID and the authentication value may prevent hackers from accessing the client ID and the authentication value.

In another implementation, the parameters for secure communications include one or more of a mapping function, a hash function, and an encryption algorithm.

The inclusion of the mapping function, the hash function, and the encryption algorithm in the parameters may ensure that compatible mapping functions, hash functions, and encryption algorithms are implemented on the client device and the key generation server to enable secure communications to be established.

In another implementation, generating the first message includes: generating a second cryptographic hash function based on the client private key, and encrypting using a server public key.

The second cryptographic hash function may convert a first message of any size into a fixed-size binary array, which in turn may facilitate transmission, thereby enabling communication, and furthermore, the use of encryption may facilitate preventing hackers from accessing the first message.

In another implementation, encrypting includes: concatenating the second cryptographic hash function with the first randomly generated value and the client ID.

The concatenation of the second cryptographic hash function with the first randomly generated value and the client ID may be used to link the second cryptographic hash function value and the client ID to simultaneously transmit the second cryptographic hash function value and the client ID.

In another implementation, the second message is generated by decrypting the first message using the server private key and verifying the authentication value.

The key generation server is able to decrypt a first message received from the client device, the first message being further verified using the authentication value, through access to the server private key.

In another implementation, the authentication credential is generated by generating a third cryptographic hash function based on the client ID, a server ID, and a second randomly generated value and multiplying the third cryptographic function by the server private key.

The implementation of the third cryptographic hash function may facilitate the conversion of authentication credentials of any size into fixed-size sets of binary numbers, which in turn may facilitate transmission, thereby enabling communication.

In another implementation, the second randomly generated value is based on one or more components of the first message.

The second randomly generated value is based on the encrypted first message and prevents a hacker from establishing communication with the key generation server even though the hacker may access the server private key.

In another implementation, the client device further includes: transmitting a connection message to a second client device based on the valid private/public key pair and the system parameters, and calculating one or more session keys for secure communications with the second client device based on a response from the second client device.

Secure communications are established between the client device and the second client device for exchanging information between the two devices using a valid private/public key pair and system parameters.

In another implementation, sending the connection message further includes: and verifying the public key and identity of the second client device using the public key revocation list provided by the server.

Here, verifying the public key and identity of the second client device using the server-provided public key revocation list may facilitate performing two-way verification to ensure that secure communications are established.

In another aspect, the present disclosure provides a method for authenticating a client device having a client private key. The method comprises the following steps: generating a client ID and an authentication value based on the client private key; transmitting the client ID and the authentication value to a key generation server; receiving one or more system parameters for secure communications from the server; generating a first message based on the client private key and the received system parameters; the first message is sent to the server. The method further comprises the steps of: a second message generated based on a server private key and the system parameters is received from the server, and an authentication credential generated based on the first message, the server private key, a server public key, and the client ID is also received. The method further comprises the steps of: a valid private key and a valid public key are determined, wherein the valid private key and the valid public key are based on the first and second messages, the authentication credentials, the client private key, and the server public key.

The method of the present disclosure provides secure communications without requiring the use of certificates. Thus, the present approach may provide lightweight and secure communications without requiring overly complex computations compared to traditional certificate-based schemes; thus, the method may be more compatible and may have a friendly integrated environment.

In another implementation, the method further comprises sending a connection message to a second client device, wherein the connection message is based on the valid private key and the valid public key and the system parameter; receiving a response from the second client device, wherein the response is based on the system parameters and a valid private key and a valid public key of the second client device; one or more session keys for secure communications with the second client device are calculated based on the response from the second client device.

In yet another aspect, the present disclosure provides a computer-readable medium comprising instructions that, when executed by a processor, cause the processor to perform the method as described above.

It should be noted that all devices, elements, circuits, units and modules described in this application may be implemented in software elements or hardware elements or any type of combination thereof. The steps performed by the various entities described in this application, and the functions to be performed by the various entities described are all intended to mean that the various entities are adapted to perform the various steps and functions. Even though in the description of specific embodiments below the specific functions or steps to be performed by external entities are not reflected in the description of specific detailed elements of the entity performing the specific steps or functions, it should be clear to a person skilled in the art that these methods and functions may be implemented in respective software or hardware elements, or any combination of such elements. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

Other aspects, advantages, features and objects of the present disclosure will become apparent from the accompanying drawings and the detailed description of illustrative implementations explained in conjunction with the following appended claims.

Drawings

The foregoing summary, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the disclosure, there is shown in the drawings exemplary constructions of the disclosure. However, the present disclosure is not limited to the specific methods and instrumentalities disclosed herein. Moreover, those skilled in the art will appreciate that the drawings are not drawn to scale. Identical elements are denoted by the same numerals, where possible.

Embodiments of the present disclosure are described below, by way of example only, with reference to the following drawings.

FIG. 1 is a flow chart of a method provided by an embodiment of the present disclosure for authenticating a client device having a client private key;

FIG. 2A is a schematic diagram of a process flow provided by an embodiment of the present disclosure for registering a client device with a key generation server;

FIG. 2B is a table listing exemplary registration information stored in the key generation server of FIG. 2A provided by an embodiment of the present disclosure;

FIG. 2C is a schematic diagram of a process flow provided by an embodiment of the present disclosure for determining a valid private key and a valid public key after a first client device registers with a key generation server;

FIG. 3 is a block diagram of a client device provided by an embodiment of the present disclosure;

FIG. 4A is a block diagram of an implementation of a key generation server for establishing secure communications between a client device and a second client device provided by various embodiments of the present disclosure;

fig. 4B is a block diagram of an implementation of a key generation server for establishing secure communications between a plurality of client devices provided by various embodiments of the present disclosure.

In the drawings, the underlined numbers are used to denote items where the underlined numbers are located or items adjacent to the underlined numbers. The non-underlined number is associated with the item identified by the line linking the non-underlined number to the item. When a number is not underlined but with an associated arrow, the number without the underline is used to identify the general item to which the arrow refers.

Detailed Description

The following detailed description describes embodiments and implementations of the present disclosure. While some ways of practicing the disclosure have been disclosed, those of skill in the art will recognize that other embodiments for practicing or practicing the disclosure can also be implemented.

In an execution environment without a PKI system, the communicating parties may wish to communicate through authentication, integrity, and confidentiality to exchange messages. Here, since the communicating parties lack required certificates, the communicating parties perform authentication and secure communication using a non-certificate technique. In particular, the present disclosure utilizes helpful identity-based implicit authentication and efficient authentication key exchange protocols to enable authentication and secure communication of a certificateless party.

Fig. 1 is a flow chart of a method provided by an embodiment of the present disclosure for authenticating a client device having a client private key. Referring to fig. 1, a method 100 for authenticating a client device having a client private key is shown. The method 100 introduces an efficient method for authenticating a client device having a client private key. Here, the client device may be a computing device such as, but not limited to, a notebook computer, a palm top computer, a computer, and a cell phone. It will be appreciated that the client private key may be secret to the client device and known to the application and authorization server, but generally not known to the public, as required by the implementation. Method 100 includes steps 102 through 114, which are described in detail in the preceding paragraphs.

At step 102, the method 100 includes generating a client ID and an authentication value based on a client private key. Here, the client ID may be an identification for identifying the corresponding client device. For example, the term "client ID" refers to information that can uniquely identify a client. In some examples, the user ID identifies the user of the device, and the device ID identifies the device itself; and one or both of a user ID and a device ID may be used, the term "client ID" refers to one or both of a user ID and a device ID. Furthermore, the authentication value may also be used to verify the identity of the user of the client device. The term "authentication value" may also be referred to as an authentication code for authenticating a user. The authentication value may be known data of the user alone (typically, a personal identification code (personal identification number/personal identifier number, PIN), derived from biometric features of the user (e.g., voice, fingerprint, heat … …), or derived from actions that can only be performed by the user (e.g., signatures). In the present disclosure, the client ID and authentication value of the client device "i" are denoted by "id_i" and "authenvalue_i", respectively.

According to an embodiment, generating the authentication value includes generating a first cryptographic hash function based on the client private key. Here, a hash function may be used to protect the authenticity of the input data. It should be appreciated that a given hash function may convert any size of input data into a fixed size binary array, which in turn may facilitate transmission, thereby enabling communication. For purposes of this disclosure, a first cryptographic hash function may be used to generate an authentication value, which may involve a process described below.

At the beginning of the registration phase, the client device generates a client private key (e.g., K). Then, a client ID and an authentication value are generated using the client private key K and the first cryptographic hash function. In one embodiment, the first cryptographic hash function may be a cryptographic pseudo-random function (PRF). Here, a cryptographic pseudo-random function (PRF) may be implemented to provide "randomness", which in turn may use equations (1), (2) and (3) to generate the authentication value, as follows:

ID_i＝PRF(K,Nonce _i ) (1)

n_i＝PRF(K，ID _i ) (2)

AuthenValue_i＝PRF(n_i，ID_i||“MAC”) (3)

where id_i is the client ID of client device "i"; nonce_i is a random number used only once for client device "i"; n_i is an intermediate value generated in the process implemented for client device "i"; the PRF is a first cryptographic hash function. It should be understood that a random number that is used only once is also referred to as a "one-time" or "number used only once"; may be a generated pseudo-random number, used only once for a particular use. Using a random number only once can ensure that once an attacker accesses the client private key, any old communication is not used for replay attacks. It should be noted that once id_i is generated, id_i and client private key K may be stored locally on client device "i".

According to one embodiment, generating the authentication value is further based on state information of the client device. Here, the status information may provide data related to an activation status of the client device. For example, the status information may provide an IP address of the client device, a media access control (media access control, MAC) address of the client device, a current time, a number of activated pixels, and a Central Processing Unit (CPU) load when generating the authentication value. Thus, the generated authentication value may be unique, depending on the state information of the client device at a particular moment in time. Thus, a unique authentication value is generated each time, and any previously used authentication value may not need to be reused for purposes of establishing secure communications.

The method 100 further includes transmitting the client ID and the authentication value to a key generation server at step 104. A key generation server, also known as a key generation center (key generating center, KGC), may be implemented in the present method 100 to generate another private and public key pair to be provided to a client device. In the present method 100, the authentication value and the client ID may be stored on a key generation server.

According to an embodiment, transmitting the client ID and the authentication value to the server comprises: concatenating the client ID and authentication value and encrypting using the client public key. Here, the client public key may be a large number used to encrypt data, and such key is generated by a software program, but more commonly it is provided by a trusted, designated authority and to everyone through a publicly accessible repository or directory. Concatenating the client ID and the authentication value may refer to linking the client ID and the authentication value together so that they may be sent simultaneously, which may facilitate transmission. Further, the client ID and authentication value may be encrypted using a client public key such that a hacker cannot access the client ID and authentication value. It should be appreciated that encryption may be the process of converting input data into a secret code that may help to hide the input data information. Any known suitable encryption technique may be used for a given process without any limitation.

Fig. 2A is a schematic diagram of a process flow 200A for registering a client device 202 with a key generation server 204 provided by an embodiment of the present disclosure. Referring to fig. 2A, the client ID and authentication value of the client device 202 are "id_i" and "authenvalue_i", respectively. The key generation server 204 has a server private key and a server public key, denoted "SK" and "PK", respectively. In step S2.1, the client device 202 transmits the client ID and the authentication value (id_i, authval_i) to the key generation server 204. The key generation server 204 locally stores registration information.

Fig. 2B is a table 200B listing exemplary registration information stored in key generation server 204 of fig. 2A provided by an embodiment of the present disclosure. As shown, in table 200B, the client ID and corresponding authentication value are stored.

Returning to fig. 1, at step 106, the method 100 further includes receiving one or more system parameters for secure communications from the key generation server. The one or more system parameters may be information sent to the client device such that the key generation server and the client device are the same page.

According to an embodiment, the one or more system parameters for secure communications include one or more of a mapping function, a hash function, and an encryption algorithm. The mapping function may be used to convert input data into output data based on a defined relationship. As discussed, the hash function may convert any size of input data into a fixed-size binary array. The encryption algorithm may facilitate the conversion of the input data into a secret code. One or more system parameters may be received from the key generation server to ensure that the same mapping function, the same hash function, or the same encryption algorithm implementing compatibility is used on the key generation server and the client device to enable secure communications to be established therebetween.

Returning to fig. 2B, at step S2.2, the key generation server 204 sends one or more system parameters to the client device 202. For example, the key generation server 204 sends an Elliptic Curve (EC) group G, a generator G, a hash function, an encryption algorithm, and a server Public Key (PK) to the client device 202.

Returning to fig. 1, at step 108, the method 100 further includes generating a first message based on the client private key and the received system parameters. The first message may be data generated by linking a random number used only once, a client private key, and received system parameters.

According to an embodiment, generating the first message includes generating a second cryptographic hash function based on the client private key and encrypting using the server public key. Here, the second cryptographic hash function may use the random number, the client private key, and the received system parameter, which are used only once, as input data, and may convert them into a secret code as the first message. The server public key may be known to the public and may be used for encryption purposes such that no entity other than the key generation server is able to decipher the information of the first message.

Fig. 2C is a schematic diagram of a process flow provided by an embodiment of the present disclosure for determining a valid private key and a valid public key after a first client device 206 registers with the key generation server 204. The first client device 206 has a client ID, denoted "ID1". Here, the first message may be generated by the first client device 206 using equation (4) provided below:

m1＝F1(sk1，nonce1，systemparameters) (4)

where "m1" is the first message, "sk1" is the client private key of first client device 206, "nonce1" is a random number used only once by first client device 206, and "system parameters" is one or more system parameters received by first client device 206.

According to an embodiment, encrypting comprises concatenating the second cryptographic hash function with the first randomly generated value and the client ID. Here, the first random generated value may be a random number (which may not be truly random) that may be generated using a random number generator. Here, the random number generator may be a computer algorithm known in the art. The random number generator may simulate the selection of the first random generated value to approximate the true random value. The second cryptographic hash function may be linked with the first randomly generated value and the client ID for encryption.

Here, first, the intermediate value "n1" of the first client device is determined by adopting a pseudo-random function (PRF) algorithm to the client private key "K" and the client ID "id_i" by the following equation (5):

n1＝PRF(K，ID_i) (5)

next, based on the point multiplication of the first random variable a1 and the generator g, a first random generated value is determined using the following formula:

A1＝a1*g (6)

where "A1" is the first randomly generated value and "G" is the generator of the Elliptic Curve (EC) group (G). The generator "G" may also be referred to as a generator of base points (also denoted "G"). Further, "G (+, ·)" represents point addition and point multiplication, respectively.

Finally, the first message may be generated by encrypting the server public key, the client ID, the intermediate value, and the first randomly generated value by equation (7) provided below:

C1＝Enc(PK，ID-i||n1||A1) (7)

where "C1" is the first message and "PK" is the server public key. Here, KGC may encrypt { id_i, n1, A1}, using a Public Key (PK) of KGC.

Returning to fig. 1, at step 110, the method 100 further comprises sending a first message to the server, i.e. the key generation server (key generating server, KGC). Here, the first message is sent from the client device to the key generation server over the secure channel. Returning to fig. 2C, as shown, at step S2.3, the first client device 206 sends a first message to the key generation server 204.

In addition, in step 112, the method 100 further includes receiving a second message from the server generated based on the server private key and the system parameters, and further receiving authentication credentials generated based on the first message, the server private key, the server public key, and the client ID. Here, the server private key may be a secret code known to the key generation server, and the secret code may not be generally known to the public. Once the key generation server receives the first message, the key generation server may generate a second message based on the server private key and system parameters. Authentication credentials may also be generated by verifying the integrity and identity of the first message. Further, the first message and the authentication credential may be sent to the client device. In other words, the key generation server performs a helpful key exchange and implicit authentication, computes the second message and generates authentication credentials.

Referring again to fig. 2C, as shown, the key generation server 204 generates a second message and authentication credentials using equations (8) and (9) provided below:

m2＝F1(sk2，nonce2，system parameters) (8)

S＝F2(SK，m1，pk2，ID1) (9)

where "m2" is the second message, "SK2" is the server private key, "nonce2" is a random number used only once by KGC, "system parameters" is one or more system parameters received by the first client device, "S" is the authentication credential, "SK" is the server private key, "pk2" is the server public key, "ID1" is the client ID.

Further, as shown, at step S2.4, the key generation server 204 sends a second message "m2" and authentication credentials "S" to the first client device 206.

According to an embodiment, the second message is generated by decrypting the first message using the server private key and verifying the authentication value. Once the KGC receives the first message, the first message may be decrypted by a decryption algorithm. The authentication value may be verified to check the identity of the client device. Here, the authentication value may be first determined by the client ID and an intermediate value obtained by decrypting the first message. Next, the determined authentication value may be compared with an authentication value initially stored in the key generation server during the registration process. If the determined authentication value is the same as the stored authentication value, communication over the secure channel is established by accepting the first message, otherwise the communication is aborted and the communication request is denied. That is, returning to equations (5), (6) and (7), once the KGC receives the first message "C1", decryption of the first message may be accomplished according to equation (10) provided below:

decryption C1: id_i i n1 i a1=dec (SK, C1) (10)

Where "SK" is the server private key.

Next, the authentication value may be determined according to equation (11) provided below:

AuthenValue _i *＝PRF(n1，ID_i||“MAC”) (11)

where "authnvalue_i" is the authentication value of the determined client device "i". If "AuthenValue_i" is equal to "AuthenValue_i", then accept the communication request; otherwise, the communication request is denied. It will be appreciated that "AuthenValue_i" herein is the authentication value of the client device "i" stored in KGC at registration.

According to one embodiment, the authentication credential is generated by generating a third cryptographic hash function based on the client ID, the server ID, and the second randomly generated value and multiplying the third cryptographic function by the server private key. Also here, the third cryptographic hash function may convert any size of input data, which is a client ID, a server ID, and a second randomly generated value, into a fixed-size binary array. It should be noted that the server ID may be an identifier for identifying KGC. Similar to the first randomly generated value, the second randomly generated value may be a random number that may be generated using a computer algorithm such as a random number generator.

According to an embodiment, the second randomly generated value is based on one or more components of the first message. For example, the second randomly generated value may be calculated using the first randomly generated value according to equation (12) provided below:

B_i＝b1·g+A1 (12)

Where "b_i" is the second randomly generated value, "B1" is the second random variable, "g" is the generator, and "A1" is the first randomly generated value.

Next, an authentication credential is generated according to equation (13) provided below:

S_i＝F2(SK，b1，B_i，ID_i，ID-KGC)＝b1+Hash(ID_i||ID-KDC，B_i)·SK (13)

where "s_i" is an authentication credential, "F2" is a third cryptographic hash function, and "id_kgc" is a server ID.

Finally, the authentication credential "s_i", the second randomly generated number (in this case "b_1"), and the server ID "id_kgc" may be sent to the client device.

Returning to fig. 1, at step 114, the method 100 further includes determining a valid private key and a valid public key, wherein the valid private key and the valid public key are based on the first and second messages, the authentication credentials, the client private key, and the server public key. The valid private key and the valid public key may be determined according to equation (14) provided below:

sk_ID1/pk_ID1＝F3(sk1，m1，m2,S，PK) (14)

where "sk_id1" is a valid private key, "pk_id1" is a valid public key, "sk1" is a client private key, "m1" is a first message, "m2" is a second message, "S" is an authentication credential, and "PK" is a server public key.

In this example, the public/private key may be calculated by using s_i, b_i, a1, id_i, id_kdc. Specifically, the valid private key and the valid public key may be determined according to formulas (15), (16), and (17) provided below:

(pk1，sk1)＝F3(a1，B_i，S_i，ID_i，ID-KDC) (15)

pk1＝B_i+Hash(ID_i||ID-KDC，B_i)·PK (16)

sk1＝a1+S_i (17)

Where "pk1" is a valid public key, "sk1" is a valid private key, "a1" is a first random variable, "b_i" is a second random generated value, "id_i" is a client ID, and "id_kdc" is a server ID.

According to one embodiment, the method 100 further comprises sending a connection message to the second client device, wherein the connection message is based on the valid private key and the valid public key and the system parameters; receiving a response from the second client device, wherein the response is based on the system parameters and the valid private key and the valid public key of the second client device; one or more session keys for secure communications with the second client device are calculated based on the response from the second client device. The client device may be referred to herein as a first client device, and secure communications may be established between the first client device and a second client device. Here, the connection message may be determined by the first client device according to equation (18) provided below:

sk1/pk1＝KeyGen1()；sends(ID1，S1，pk1) (18)

where "sk1" is the valid private key of the first client device and "pk1" is the valid public key of the first client device.

Here, the first device sends its client ID "ID1", its authentication credential "S1" and its valid public key "pk1". Similarly, the second device sends its client ID "ID2", its authentication credential "S2" and its valid public key "pk2". Next, the first client device and the second client device may verify their respective communication partners, i.e. the second client device and the first client device, respectively. The first client device may authenticate the second client device by calculating the public key of the second client device according to equation (19) provided below:

pk _ID2 ＝F(PK，ID2，S2) (19)

Wherein "pk _ID2 "is the calculated public key of the second client device.

Subsequently, the first client device may calculate the session key "K" according to equation (20) provided below _Auth ||K _Enc ”：

K _Auth ||K _Enc ＝KeyGen2(PK _ID1 ，SK _ID1 ，sk1，pk2) (20)

Similarly, the second client device may authenticate the first client device by calculating the public key of the first client device according to equation (21) provided below:

pk _ID1 ＝F(PK，ID1，S1) (21)

wherein "pk _ID1 "is the calculated public key of the first client device.

The second client device may then calculate the session key "K" according to equation (22) provided below _Auth ||K _Enc ”：

K _Auth ||K _Enc ＝KeyGen2(PK _ID1 ，SK _ID1 ，sk2，pk1) (22)

Furthermore, the procedures involved in establishing a specific secure communication between the first client device and the second client device are described below. The first client device may have a client ID, denoted "id_1", and may have authentication credentials, denoted "S1". The second client device may have a client ID, denoted "id_2", and may have authentication credentials, denoted "S2". First, the first client device may generate a random function "X" by dot multiplication of a random variable with a generator according to formula (23) provided as follows:

X＝x·G (23)

where "x" is a random variable.

The first client device may then send "X", "id_1", and "S1" to the second client device. Similarly, the second client device may generate the random function "Y" by dot-multiplying the random variable "Y" with the generator "G" according to equation (24) provided below:

Y＝y·G (24)

The second client device may then send "Y", "id_2" and "S2" to the first client device. Next, the first client device may verify (ID_2, B ₂ Validation (Y); and upon validation, the first client device may calculate a valid public key "PK" according to equation (25) provided below _ID2 ”：

PK _ID2 ＝F(B ₂ ，PK，ID_2)＝B2+Hash(ID_2||ID _KDC ，B ₂ )·PK (25)

Furthermore, the session key K _Auth ||K _Encn Can be calculated according to the following formulas (26), (27) and (28):

MK＝Hash(PK _ID2 ，SK _ID1 ，x，Y) (26)

W＝B ₁ ||B ₂ ||ID-1||ID-2||X||Y (27)

KAuth||KEnc＝Hash(MK；W||″0″) (28)

finally, the second client device can verify (ID_1, B ₁ Confirmation of X); and upon validation, the first client device may calculate a valid public key "pk" according to equation (29) provided below _ID2 ”：

PK _ID1 ＝F(B1，PK，ID_1)＝B1+Hash(ID1||ID _KDC ，B ₁ )·PK (29)

Further, as described above, the session key K _Auth ||K _Enc n may be calculated according to formulas (30), (31) and (32) provided below:

MK＝Hash(PK _ID1 ，SK _ID2 ，X，y) (30)

W＝B ₁ ||B ₂ ||ID_1||ID_2||X||Y (31)

KAuth||KEnc＝Hash(MK；W||″0″) (32)

according to an embodiment, the connection message further comprises verifying the public key and the identity of the second client device using a server provided public key revocation list. The public key revocation list may be a public key list stored in the server. Here, the public key revocation list may be used to establish a secondary check to assist the client device in establishing a secure communication channel.

The present disclosure also relates to a client device as described above. The various embodiments and variations disclosed above apply mutatis mutandis to the disclosed client device without any limitation.

Fig. 3 is a block diagram of a client device 300 provided by an embodiment of the present disclosure. Client device 300 includes a processor 302, a communication module 304, and a memory 306. As used herein, "processor" refers to structures and/or modules that include programmable and/or non-programmable components for storing, processing, and/or sharing information for translating source text in a first language into a second language. In the alternative, the processor includes means for physical or virtual computing entities capable of enhancing information to perform various computing tasks. Further, a processor refers to a computing element that is operable to respond to and process instructions for performing operations such as translating source text in a first language into a second language. Optionally, the processor includes, but is not limited to, a microprocessor, a microcontroller, a complex instruction set computing (complex instruction set computing, CISC) microprocessor, a reduced instruction set (reduced instruction set, RISC) microprocessor, a very long instruction word (very long instruction word, VLIW) microprocessor, or any other type of processing circuit, such as described above. In additionThe processor is arranged in various architectures for responding to and processing instructions for translating source text in a first language into a second language in the system. Further, it will be appreciated that at least one processor may be implemented as a hardware processor and/or as a plurality of hardware processors operating in a parallel or distributed architecture. Optionally, the processors in the processor are supplemented with additional computational methods, such as neural networks and hierarchical clusters of pseudo-analog variable state machines implementing artificial intelligence algorithms. In one example, a processor may include components such as memory, data communication interfaces, network adapters, etc. to store, process, and/or share information with user devices, translation memory, etc. In the alternative, the processor is implemented as a computer program that provides various services (e.g., database services) to other devices, modules, or means. Furthermore, a "communication module" relates to an arrangement of interconnected, programmable and/or non-programmable components that, in operation, facilitate data communication between one or more computing devices and/or databases. The communication module may enable communication between interactive computing devices (e.g., user devices or translation memory, etc.). In other words, the user device, translation memory, can communicate with other computing devices (e.g., at least one processor) through the communication module. In addition, the communication modules include, but are not limited to, peer-to-peer (P2P) networks, ring communication networks, hybrid peer-to-peer networks, local area networks (local area network, LAN), radio access networks (radio access network, RAN), metropolitan area networks (metropolitan area network, MAN), wide area networks (wide area network, WAN), all or part of a public network, such as what is known as A private network, a cellular network, and any other communication system. Further, the communication module may alternatively employ wired or wireless communication that may be performed by one or more known protocols, including but not limited to Internet protocol (internet protocol, IP), wireless access protocol (wireless access protocol, WAP), frame relay, or asynchronous transfer mode (asynchonous)transfer mode，ATM)、/>Etc. In addition, any other suitable protocol using voice, video, data, or a combination thereof, such as VoIP, may also be employed. Furthermore, as used herein, the term "memory" refers to a device that can store and retrieve information. The term "memory" includes internal and external storage devices, including magnetic and optical disks, magnetic tape, compact disk, and random access memory (random access memory, RAM) and Read Only Memory (ROM).

As shown, memory 306 is used to store client private key 308 and instructions for processor 302. These instructions cause processor 302 to generate a client ID and an authentication value based on client private key 308. Optionally, an authentication value is also generated based on the state information of the client device 300. Optionally, generating the authentication value includes generating a first cryptographic hash function based on the client private key 308. These instructions cause the processor 302 to send the client ID and authentication value to the key generation server using the communication module 304. Optionally, sending the client ID and the authentication value to the server comprises: concatenating the client ID and authentication value and encrypting using the client public key. The instructions cause the processor 302 to receive one or more system parameters for secure communications from a server via the communication module 304. Optionally, the parameters for secure communications include one or more of a mapping function, a hash function, and an encryption algorithm. The instructions cause the processor 302 to generate a first message based on the client private key and the received system parameters. Optionally, generating the first message includes generating a second cryptographic hash function based on the client private key 308 and encrypting using the server public key. Optionally, encrypting comprises concatenating the second cryptographic hash function with the first randomly generated value and the client ID. The instructions also cause the processor 302 to send the first message to the server using the communication module 304. The instructions also cause the processor 302 to receive a second message from the server via the communication module 304 that is generated based on the server private key and the system parameters, and also receive authentication credentials that are generated based on the first message, the server private key, the server public key, and the client ID. Optionally, the second message is generated by decrypting the first message using the server private key and verifying the authentication value. Optionally, the authentication credential is generated by generating a third cryptographic hash function based on the client ID, the server ID, and the second randomly generated value and multiplying the third cryptographic function by the server private key. Optionally, the second randomly generated value is based on one or more components of the first message. These instructions cause the processor 302 to calculate a valid private/public key pair based on the first and second messages, the authentication credentials, the client private key 308, and the server public key.

Fig. 4A is a block diagram of an implementation of key generation server 204 for establishing secure communications between a client device 300 and a second client device 400 provided by various embodiments of the present disclosure. Here, the client device 300 transmits a connection message to the second client device 400 based on the valid private/public key pair and the system parameters. Based on the response from the second client device 400, the client device 300 calculates one or more session keys for secure communications with the second client device 400. Optionally, the connect message further includes verifying the public key and identity of the second client device 400 using the public key revocation list provided by the key generation server 204. A secure channel 402 is established for facilitating secure communications between the client device 200, the second client device 400, and the key generation server 204.

Fig. 4B is a block diagram of an implementation of key generation server 204 for establishing secure communications between a plurality of client devices provided by various embodiments of the present disclosure. The plurality of client devices includes "n" client devices. Here, the first client device 404 has a client ID, denoted as "id_1", the second client device 406 has a client ID, denoted as "id_2", the i-th client device 408 has a client ID, denoted as id_i, and the n-th client device 410 has a client ID, denoted as "id_n". The key generation server 204 has a server private key "SK" and a server public key "PK". Secure channel 402 is established for communication between client devices of the plurality of client devices id_1, id_2, … …, id_i, … …, id_n. Secure channel 402 is also used to communicate between one or more of the plurality of client devices and key generation server 204.

Referring to fig. 3 in combination with fig. 4A and 4B, the present disclosure also provides a computer-readable medium comprising instructions that, when executed by the processor 302, cause the processor 302 to perform the method 100. In particular, a processor (or one or more processors) of the client device 300 is used to perform the method 100. In general, a computer-readable medium may direct a computerized device, other programmable data processing apparatus, or other interactive computing device to function in a particular manner, such that instructions stored in the non-transitory computer-readable storage medium perform a series of steps to implement the functions specified in the flowchart corresponding to the instructions. Examples of implementations of the non-transitory computer readable storage medium include, but are not limited to, electrically Erasable Programmable Read Only Memory (EEPROM), random access memory (random access memory, RAM), read Only Memory (ROM), hard Disk Drive (HDD), flash memory, secure Digital (SD) card, solid State Drive (SSD), and/or CPU cache memory. The computer readable medium for providing non-transitory memory may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

The client devices and methods of the present disclosure provide secure communications without requiring credentials. That is, here, the client device, the key generation server, or the second client device, or the like, can perform secure and authenticated communication based on the public key without requiring a certificate. Client devices and methods provide high security by providing message authentication and maintaining integrity and confidentiality. Furthermore, the client device and method do not present key escrow problems. Furthermore, the client device and method of the present disclosure are able to resist transient key leakage attacks. Furthermore, the client device and method provide extremely lightweight secure communications with limited computational complexity compared to traditional certificate-based schemes. Thus, these methods are more compatible. Furthermore, the client device and method have a friendly integrated environment.

In one example, a single communication may require about 2100 bytes, as compared to the EC-based TLS1.3 protocol known in the art, and a proposed scheme according to an embodiment of the present disclosure may require only about 168 bytes. Furthermore, the EC-based TLS1.3 protocol involves 1 symbol operation+1 validation operation+2 EC dot multiplication+3 PRF operations+1 MAC operations to complete the computation; however, the proposed scheme according to embodiments of the present disclosure may only require 2 EC points by +3 hash operations. Furthermore, the proposed scheme according to embodiments of the present disclosure may meet the necessary security requirements provided by the traditional EC-based TLS1.3 protocol, including confidentiality, authentication, resistance to replay attacks, resistance to MITM attacks, perfect forward security (perfect forward secrecy, PFS), resistance to unknown key sharing (unknown key share, UKS) attacks, and resistance to key leakage masquerading (key compromise impersonation, KCI) attacks. Furthermore, the proposed scheme according to embodiments of the present disclosure may also be resistant to short-lived key leakage (ephermal key leakage, also referred to as ephermal secret leakage, ESL) attacks, which may not be possible in conventional EC-based TLS1.3 protocols.

Modifications may be made to the embodiments of the disclosure described above without departing from the scope of the disclosure as defined in the appended claims. The terms "comprising," "including," "incorporating," "having," "being" and the like used to describe and protect the present disclosure should be interpreted in a non-exclusive manner, i.e., to allow items, parts, or elements not explicitly described to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any embodiment described as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude features from other embodiments. The word "optionally" as used herein means "provided in some embodiments and not provided in other embodiments. It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure that are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as an embodiment of the disclosure.

Claims

1. A client device (202, 206, 300, 400, 404, 406, 408, 410), comprising:

a processor (302);

a communication module (304);

a memory (306) for storing a client private key (308) and instructions that cause the processor to:

generating a client ID and an authentication value based on the client private key,

transmitting the client ID and the authentication value to a key generation server (204) using the communication module;

receiving, by the communication module, one or more system parameters for secure communications from the server;

a first message is generated based on the client private key and the received system parameters,

transmitting the first message to the server using the communication module;

receiving, by the communication module, a second message from the server generated based on a server private key and the system parameters, and receiving an authentication credential generated based on the first message, the server private key, a server public key, and the client ID;

a valid private/public key pair is calculated based on the first and second messages, the authentication credentials, the client private key, and the server public key.

2. The client device (202, 206, 300, 400, 404, 406, 408, 410) of claim 1, wherein generating the authentication value is further based on status information of the client device.

3. The client device (202, 206, 300, 400, 404, 406, 408, 410) of claim 1 or 2, wherein generating the authentication value comprises: a first cryptographic hash function is generated based on the client private key (308).

4. A client device (202, 206, 300, 400, 404, 406, 408, 410) according to any of claims 1-3, wherein transmitting the client ID and authentication value to the server (204) comprises: concatenating the client ID and authentication value and encrypting using the client public key.

5. The client device (202, 206, 300, 400, 404, 406, 408, 410) of any one of claims 1-4, wherein the parameters for secure communications comprise one or more of a mapping function, a hash function, and an encryption algorithm.

6. The client device (202, 206, 300, 400, 404, 406, 408, 410) of any one of claims 1-5, wherein generating the first message comprises: a second cryptographic hash function is generated based on the client private key (308) and encrypted using a server public key.

7. The client device (202, 206, 300, 400, 404, 406, 408, 410) of claim 6, wherein encrypting comprises: concatenating the second cryptographic hash function with the first randomly generated value and the client ID.

8. The client device (202, 206, 300, 400, 404, 406, 408, 410) of any one of claims 1-7, wherein the second message is generated by decrypting the first message using the server private key and verifying the authentication value.

9. The client device (202, 206, 300, 400, 404, 406, 408, 410) of any of claims 1-8, wherein the authentication credential is generated by generating a third cryptographic hash function based on the client ID, a server ID, and a second randomly generated value and multiplying the third cryptographic function by the server private key.

10. The client device (202, 206, 300, 400, 404, 406, 408, 410) of claim 9, wherein the second randomly generated value is based on one or more components of the first message.

11. The client device (300) according to any of claims 1 to 10, further comprising: -transmitting a connection message to a second client device (400) based on the valid private/public key pair and the system parameters, and-calculating one or more session keys for secure communication with the second client device based on a response from the second client device.

12. The client device (300) of claim 11, wherein transmitting the connect message further comprises: -verifying the public key and identity of the second client device (400) using a public key revocation list provided by the server (204).

13. A method (100) for authenticating a client device (202, 206, 300, 400, 404, 406, 408, 410) having a client private key (308), the method comprising:

generating a client ID and an authentication value based on the client private key;

-sending the client ID and the authentication value to a key generation server (204);

receiving one or more system parameters for secure communications from the server;

generating a first message based on the client private key and the received system parameters;

sending the first message to the server;

receiving a second message from the server generated based on a server private key and the system parameters, and also receiving authentication credentials generated based on the first message, the server private key, a server public key, and the client ID;

a valid private key and a valid public key are determined, wherein the valid private key and the valid public key are based on the first and second messages, the authentication credentials, the client private key, and the server public key.

14. The method (100) of claim 13, wherein generating the authentication value is further based on status information of the client device (202, 206, 300, 400, 404, 406, 408, 410).

15. The method (100) of claim 13 or 14, wherein generating the authentication value comprises: a first cryptographic hash function is generated based on the client private key (308).

16. The method (100) of any of claims 13 to 15, wherein transmitting the client ID and authentication value to the server (204) comprises: concatenating the client ID and authentication value and encrypting using the client public key.

17. The method (100) according to any one of claims 13 to 16, wherein the parameters for secure communications comprise one or more of a mapping function, a hash function, and an encryption algorithm.

18. The method (100) of any one of claims 13 to 17, wherein generating the first message includes: a second cryptographic hash function is generated based on the client private key (308) and encrypted using a server public key.

19. The method (100) of claim 18, wherein encrypting includes: concatenating the second cryptographic hash function with the first randomly generated value and the client ID.

20. The method (100) of any of claims 13-19, wherein the second message is generated by decrypting the first message using the server private key and verifying the authentication value.

21. The method (100) of any of claims 13-20, wherein the authentication credential is generated by generating a third cryptographic hash function based on the client ID, a server ID, and a second randomly generated value and multiplying the third cryptographic function by the server private key.

22. The method (100) of claim 21, wherein the second randomly generated value is based on one or more components of the first message.

23. The method (100) according to any one of claims 13 to 22, further comprising:

transmitting a connection message to a second client device (400), wherein the connection message is based on the valid private key and the valid public key and the system parameters;

receiving a response from the second client device, wherein the response is based on the system parameters and a valid private key and a valid public key of the second client device;

one or more session keys for secure communications with the second client device are calculated based on the response from the second client device.

24. The method (100) of claim 23, wherein sending the connect message further comprises: public keys and identities of the second client device are verified using a public key revocation list provided by the server (204).

25. A computer readable medium comprising instructions which, when executed by a processor (202), cause the processor (302) to perform the method according to any one of claims 13 to 24.