Certificateless authentication and secure communication

Abstract

A client device (202, 206, 300, 400, 404, 406, 408, 410) and a method (100) for authenticating the client device having a client private key (308) are disclosed. The method includes 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; and further receiving an authentication credential. The method 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 message and the second message, the authentication credential, the client private key, and a server public key.

Description

Technical Field

[0001] This disclosure generally relates to the field of cybersecurity, and more specifically, to a client device and a method for certificateless authentication and secure communication. Background Technology

[0002] In network security systems, secure communication channels are needed between devices (e.g., between two computers) to maintain the authenticity, integrity, and confidentiality of messages transmitted through these channels. Traditionally, certificate-based authentication and communication technologies are employed. Certificate-based authentication is a universal technology with good compatibility due to its widespread acceptance. However, it may require maintaining a complex public key infrastructure (PKI) system and suffers from performance degradation due to the use of certificates. Furthermore, the complexity of certificate systems limits PKI deployment in various execution environments, making entity authentication difficult.

[0003] Another traditional technology widely used in network security systems is identity-based schemes. Here, an identification (ID) serves as the entity's public key, which is relatively efficient for certificate-based authentication. The system architecture used in identity-based schemes is also relatively simple. However, in identity-based schemes, each entity's private key needs to be entirely generated by a server, such as a mutually trusted key generation center (KGC) server. If such a server is compromised, the entire system is vulnerable. Furthermore, network security systems employing identity-based schemes also face numerous key escrow issues.

[0004] Therefore, based on the above discussion, it is necessary to overcome the aforementioned drawbacks associated with traditional methods for establishing secure communication channels between communication devices. Summary of the Invention

[0005] This disclosure aims to provide a client device and a method for authenticating a client device having a client private key. This disclosure aims to provide a solution to existing problems requiring complex public key infrastructure (PKI) systems. The purpose of this disclosure is to provide a solution that at least partially overcomes the problems encountered in the prior art and to provide an improved method for authenticating a client device having a client private key.

[0006] The object of this disclosure is achieved by the solutions provided in the appended independent claims. Advantageous embodiments of this disclosure are further defined in the dependent claims.

[0007] In one aspect, this disclosure provides a client device, comprising: a processor; a communication module; and a memory for storing a client private key and instructions, the instructions causing the processor to: generate a client ID and an authentication value based on the client private key; send the client ID and the authentication value to a key generation server using the communication module; receive one or more system parameters for secure communication from the server via the communication module; generate a first message based on the client private key and the received system parameters, and send the first message to the server using the communication module; receive a second message generated based on a server private key and the system parameters from the server via the communication module, and receive an authentication credential generated based on the first message, the server private key, the server public key, and the client ID; and calculate a valid private key / public key pair based on the first message and the second message, the authentication credential, the client private key, and the server public key.

[0008] The client device disclosed herein provides secure communication without the need for certificates. Therefore, compared to traditional certificate-based schemes, the client device of this disclosure can provide lightweight and secure communication without overly complex computations. Consequently, the client device of this disclosure is more compatible and can have a user-friendly integration environment.

[0009] In another implementation, the authentication value is also generated based on the state information of the client device.

[0010] Here, the authentication value is generated based on the client device's state information to ensure a unique value at a specific time, which helps with secure communication.

[0011] In another implementation, generating the authentication value includes generating a first cryptographic hash function based on the client's private key.

[0012] The first cryptographic hash function can help maintain the authenticity and integrity of the authentication value.

[0013] In another implementation, sending the client ID and authentication value to the server includes concatenating the client ID and authentication value and encrypting them using the client's public key.

[0014] Cascading can be used to link client IDs and authentication values, allowing both to be sent simultaneously. Furthermore, encrypting the client ID and authentication value can prevent hackers from accessing them.

[0015] In another implementation, the parameters used for secure communication include one or more of a mapping function, a hash function, and an encryption algorithm.

[0016] Including mapping functions, hash functions, and encryption algorithms in the parameters ensures that compatible mapping functions, hash functions, and encryption algorithms are implemented on both the client device and the key generation server to enable secure communication.

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

[0018] The second cryptographic hash function can convert a first message of any size into a fixed-size binary array, which in turn facilitates transmission and enables communication. Furthermore, encryption helps prevent hackers from accessing the first message.

[0019] In another implementation, encryption includes concatenating the second cryptographic hash function with a first randomly generated value and the client ID.

[0020] The second cryptographic hash function, concatenated with the first randomly generated value and the client ID, can be used to link the second cryptographic hash function value and the client ID so that the second cryptographic hash function value and the client ID can be sent simultaneously.

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

[0022] By accessing the server's private key, the key generation server is able to decrypt the first message received from the client device, which is then further verified using an authentication value.

[0023] In another implementation, the authentication credentials are generated by generating a third cryptographic hash function based on the client ID, server ID, and a second randomly generated value, and then multiplying the third cryptographic hash function by the server private key.

[0024] The implementation of a third cryptographic hash function can help convert authentication credentials of any size into a fixed-size binary array, which in turn can facilitate transmission, thereby enabling communication.

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

[0026] The second randomly generated value is based on the encrypted first message, which prevents hackers from establishing communication with the key generation server even if they can access the server's private key.

[0027] In another implementation, the client device further includes: sending a connection message to a second client device, wherein the new connection message is 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 the response from the second client device.

[0028] Secure communication is established between a client device and a second client device by using a valid private / public key pair and system parameters, for exchanging information between the two devices.

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

[0030] Here, using the public key revocation list provided by the server to verify the public key and identity of the second client device can help perform two-way authentication to ensure secure communication is established.

[0031] On the other hand, this disclosure provides a method for authenticating a client device having a client private key. The method includes: 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; receiving one or more system parameters for secure communication from the server; generating a first message based on the client private key and the received system parameters; and sending the first message to the server. The method further includes: receiving a second message generated from the server 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. The method 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 message and the second message, the authentication credentials, the client private key, and the server public key.

[0032] The method disclosed herein provides secure communication without the need for certificates. Therefore, compared to traditional certificate-based schemes, this method can provide lightweight and secure communication without overly complex computations; consequently, it is more compatible and can be integrated into user-friendly environments.

[0033] In another implementation, the authentication value is also generated based on the state information of the client device.

[0034] Here, the authentication value is generated based on the client device's state information to ensure a unique value at a specific time, which helps with secure communication.

[0035] In another implementation, generating the authentication value includes generating a first cryptographic hash function based on the client's private key.

[0036] The first cryptographic hash function can help maintain the authenticity and integrity of the authentication value.

[0037] In another implementation, sending the client ID and authentication value to the server includes concatenating the client ID and authentication value and encrypting them using the client's public key.

[0038] Cascading can be used to link client IDs and authentication values, allowing both to be sent simultaneously. Furthermore, encrypting the client ID and authentication value can prevent hackers from accessing them.

[0039] In another implementation, the parameters used for secure communication include one or more of a mapping function, a hash function, and an encryption algorithm.

[0040] Including mapping functions, hash functions, and encryption algorithms in the parameters ensures that compatible mapping functions, hash functions, and encryption algorithms are implemented on both the client device and the key generation server to enable secure communication.

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

[0042] The second cryptographic hash function can convert a first message of any size into a fixed-size binary array, which in turn facilitates transmission and enables communication. Furthermore, encryption helps prevent hackers from accessing the first message.

[0043] In another implementation, encryption includes concatenating the second cryptographic hash function with a first randomly generated value and the client ID.

[0044] The second cryptographic hash function, concatenated with the first randomly generated value and the client ID, can be used to link the second cryptographic hash function value and the client ID so that the second cryptographic hash function value and the client ID can be sent simultaneously.

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

[0046] By accessing the server's private key, the key generation server is able to decrypt the first message received from the client device, which is then further verified using an authentication value.

[0047] In another implementation, the authentication credentials are generated by generating a third cryptographic hash function based on the client ID, server ID, and a second randomly generated value, and then multiplying the third cryptographic hash function by the server private key.

[0048] The implementation of a third cryptographic hash function can help convert authentication credentials of any size into a fixed-size binary array, which in turn can facilitate transmission, thereby enabling communication.

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

[0050] The second randomly generated value is based on the encrypted first message, which prevents hackers from establishing communication with the key generation server even if they can access the server's private key.

[0051] In another implementation, the method further includes 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 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; and calculating one or more session keys for secure communication with the second client device based on the response from the second client device.

[0052] Secure communication is established between a client device and a second client device by using a valid private / public key pair and system parameters, for exchanging information between the two devices.

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

[0054] Here, using the public key revocation list provided by the server to verify the public key and identity of the second client device can help perform two-way authentication to ensure secure communication is established.

[0055] In another aspect, this disclosure provides a computer-readable medium including instructions that, when executed by a processor, cause the processor to perform the method as described above.

[0056] It should be noted that all devices, elements, circuits, units, and modules described in this application can be implemented in software elements or hardware elements, or any combination thereof. The steps performed by the various entities described in this application, and the functions to be performed by the various entities, are intended for each entity to perform the respective steps and functions. Even in the description of the following specific embodiments, if a particular function or step to be performed by an external entity is not reflected in the description of the specific detailed elements of the entity performing that particular step or function, it will be clear to those skilled in the art that these methods and functions can be implemented in the corresponding software or hardware elements, or in any combination of such elements. It is understood that the features of this disclosure are readily combined in various combinations without departing from the scope of this disclosure as defined by the appended claims.

[0057] Other aspects, advantages, features, and objects of this disclosure will become apparent from the accompanying drawings and the detailed description of illustrative implementations as interpreted in conjunction with the following appended claims. Attached Figure Description

[0058] The foregoing summary of the invention and the following detailed description of illustrative embodiments can be better understood when read in conjunction with the accompanying drawings. Exemplary structures of this disclosure are shown in the drawings to illustrate the present disclosure. However, this disclosure is not limited to the specific methods and means disclosed herein. Furthermore, those skilled in the art will understand that these drawings are not drawn to scale. Where possible, the same elements are represented by the same numbers.

[0059] The embodiments of this disclosure are described below by way of example only, in conjunction with the accompanying drawings.

[0060] Figure 1 This is a flowchart of a method for authenticating a client device with a client private key, provided by an embodiment of this disclosure;

[0061] Figure 2A This is a schematic diagram of a process for registering a client device to a key generation server, provided by an embodiment of this disclosure.

[0062] Figure 2B The embodiments of this disclosure provide a list stored in Figure 2A A table of exemplary registration information in a key generation server;

[0063] Figure 2C This is a schematic diagram of a process for determining a valid private key and a valid public key after a first client device registers with a key generation server, provided by an embodiment of this disclosure.

[0064] Figure 3 This is a block diagram of a client device provided in an embodiment of this disclosure;

[0065] Figure 4A This is a block diagram of an implementation of a key generation server for establishing secure communication between a client device and a second client device, provided by various embodiments of this disclosure.

[0066] Figure 4B This is a block diagram of an implementation of a key generation server for establishing secure communication between multiple client devices, provided by various embodiments of this disclosure.

[0067] In the accompanying diagrams, underlined numbers indicate the item to which the underlined number is located or the item adjacent to the underlined number. Ununderlined numbers are associated with the item identified by the line linking the ununderlined number to that item. When a number is ununderlined but has an associated arrow, the ununderlined number identifies the general item pointed to by the arrow. Detailed Implementation

[0068] The following detailed description illustrates embodiments of this disclosure and their implementation. While some methods for carrying out this disclosure have been disclosed, those skilled in the art will recognize that other embodiments for carrying out or practicing this disclosure can also be implemented.

[0069] In environments lacking a PKI system, communicating parties may wish to communicate and exchange messages with authentication, integrity, and confidentiality in mind. Here, due to the lack of required certificates, the parties employ certificateless techniques for authentication and secure communication. Specifically, this disclosure utilizes helpful identity-based implicit authentication and an efficient authentication key exchange protocol to achieve authentication and secure communication for certificateless parties.

[0070] Figure 1 This is a flowchart illustrating a method for authenticating a client device with a client private key, provided in embodiments of this disclosure. (See also...) Figure 1 This document illustrates a method 100 for authenticating a client device possessing a client private key. Method 100 introduces an efficient method for authenticating a client device possessing a client private key. Here, the client device can be a computing device, such as, but not limited to, a laptop, PDA, computer, and mobile phone. It is understood that the client private key may be secret to the client device and known to the application and authorization server as needed for the implementation, but is generally not publicly known. Method 100 includes steps 102 through 114, which have been described in detail in the preceding paragraphs.

[0071] In step 102, method 100 includes generating a client ID and an authentication value based on the client's private key. Here, the client ID can be an identifier used to identify the corresponding client device. For example, the term "client ID" refers to information that can uniquely identify the client. In some examples, a user ID identifies the user of the device, while a device ID identifies the device itself; and one or both of the user ID and device ID can be used, the term "client ID" referring to one or both of the user ID and device ID. Furthermore, the authentication value can also be used to verify the identity of the user of the client device. The term "authentication value" can also be called an authentication code, used to authenticate the user. The authentication value can be known data unique to the user (typically, a personal identification number (PIN), derived from the user's biometric features (e.g., voice, fingerprint, thermal signature, etc.), or derived from an action that only the user can perform (e.g., signature)). In this disclosure, the client ID and authentication value of client device "i" are represented by "ID_i" and "AuthenValue_i," respectively.

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

[0073] At the start of the registration phase, the client device generates a client private key (e.g., K). Then, the client private key K and a first cryptographic hash function are used to generate a client ID and an authentication value. In one embodiment, the first cryptographic hash function can be a pseudo-random function (PRF). Here, the pseudo-random function (PRF) can be implemented to provide "randomness," which can then be used to generate the authentication value using formulas (1), (2), and (3), as described below:

[0074] ID_i = PRF(K, Nonce i (1)

[0075] n_i = PRF(K, ID) i (2)

[0076] AuthenValue_i=PRF(n_i,ID_i||"MAC") (3)

[0077] Where ID_i is the client ID of client device "i"; Nonce_i is a once-only random number used for client device "i"; ni is an intermediate value generated during the implementation for client device "i"; and PRF is the first cryptographic hash function. It should be understood that a once-only random number is also called a "one-time number" or "number used only once"; it can be a generated pseudo-random number used only once for a specific purpose. A once-only random number ensures that once an attacker gains access to the client's private key, any old communications will not be used for replay attacks. It should be noted that once ID_i is generated, ID_i and the client's private key K can be stored locally on client device "i".

[0078] According to one embodiment, the generation of the authentication value is also based on the client device's state information. Here, the state information can provide data related to the client device's activation state. For example, the state information can provide the client device's IP address, media access control (MAC) address, current time, number of active pixels, and central processing unit (CPU) load at the time the authentication value is generated. Therefore, the generated authentication value can be unique, depending on the client device's state information at a specific moment. Thus, a unique authentication value is generated each time, and any previously used authentication value may not need to be reused for the purpose of establishing secure communication.

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

[0080] According to an embodiment, sending the client ID and authentication value to the server includes: cascading the client ID and authentication value and encrypting them using the client's public key. Here, the client's public key can be a large value used to encrypt data, and this key is generated by a software program, but more commonly, it is provided by a trusted, designated authority and made available to everyone through a publicly accessible repository or directory. Cascading the client ID and authentication value can refer to linking the client ID and authentication value together so that they can be sent simultaneously, which can facilitate transmission. Furthermore, the client ID and authentication value can be encrypted using the client's public key, making it inaccessible to hackers. It should be understood that encryption can be the process of transforming input data into secret code that can help hide information in the input data. Any known suitable encryption technique can be used in a given process without any limitations.

[0081] Figure 2A This is a schematic diagram of a process flow 200A for registering a client device 202 to a key generation server 204, provided by an embodiment of this disclosure. (See reference...) Figure 2A The client device 202 has a client ID and an authentication value of "ID_i" and "AuthenValue_i" respectively. The key generation server 204 has a server private key and a server public key, represented as "SK" and "PK" respectively. In step S2.1, the client device 202 sends the client ID and authentication value (ID_i, AuthenValue_i) to the key generation server 204. The key generation server 204 stores the registration information locally.

[0082] Figure 2B The embodiments of this disclosure provide a list stored in Figure 2A The example registration information in the key generation server 204 is shown in table 200B. As shown, table 200B stores the client ID and the corresponding authentication value.

[0083] Back Figure 1 In step 106, method 100 further includes receiving one or more system parameters from the key generation server for secure communication. 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 on the same page.

[0084] According to an embodiment, one or more system parameters for secure communication include one or more of a mapping function, a hash function, and an encryption algorithm. The mapping function can be used to transform input data into output data based on a defined relation. As discussed, a hash function can transform input data of any size into a fixed-size binary array. The encryption algorithm can help transform input data into secret code. One or more system parameters can be received from a key generation server to ensure that the same mapping function, the same hash function, or the same encryption algorithm with implementation compatibility is used on both the key generation server and the client device, enabling secure communication between them.

[0085] Back Figure 2B In 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 the elliptic curve (EC) set G, the generator g, the hash function, the encryption algorithm, and the server public key (PK) to the client device 202.

[0086] Back Figure 1 In step 108, method 100 further includes generating a first message based on the client's private key and received system parameters. The first message may be data generated by linking a random number used only once, the client's private key, and the received system parameters.

[0087] According to an embodiment, generating the first message includes generating a second cryptographic hash function based on the client's private key, and encrypting it using the server's public key. Here, the second cryptographic hash function can take a random number used only once, the client's private key, and received system parameters as input data, and convert them into secret code as the first message. The server's public key can be publicly known and used for encryption purposes, ensuring that no entity other than the key generation server can decipher the information in the first message.

[0088] Figure 2C This is a schematic diagram of the processing flow for determining a valid private key and a valid public key after the first client device 206 registers on the key generation server 204, provided by an embodiment of this disclosure. The first client device 206 has a client ID, denoted as "ID1". Here, the first message can be generated by the first client device 206 using the following formula (4):

[0089] m1=F1(sk1, nonce1, system parameters) (4)

[0090] In this context, "m1" is the first message, "sk1" is the client private key of the first client device 206, "nonce1" is a random number used only once by the first client device 206, and "system parameters" are one or more system parameters received by the first client device 206.

[0091] According to an embodiment, encryption includes concatenating a second cryptographic hash function with a first randomly generated value and a client ID. Here, the first randomly generated value can be a random number (potentially not truly random) generated using a random number generator. The random number generator can be a computer algorithm known in the art. The random number generator can simulate the selection of the first randomly generated value to approximate a truly random value. The second cryptographic hash function can be concatenated with the first randomly generated value and the client ID used for encryption.

[0092] Here, firstly, the intermediate value “n1” of the first client device is determined by applying a pseudo-random function (PRF) algorithm to the client private key “K” and the client ID “ID_i” using the following formula (5):

[0093] n1 = PRF(K, ID_i) (5)

[0094] Next, based on the dot product of the first random variable a1 and the generator g, the first randomly generated value is determined using the following formula:

[0095] A1=a1*g (6)

[0096] Here, "A1" is the first randomly generated value, and "g" is the generator of the elliptic curve (EC) set (G). The generator "g" can also be called the generator of the base points (or it can be represented as "G"). In addition, "G(+,·)" respectively represent dot addition and dot product.

[0097] Finally, the first message can be generated by encrypting the server public key, client ID, intermediate value, and first randomly generated value using the formula (7) provided below:

[0098] C1=Enc(PK,ID_i||n1||A1) (7)

[0099] Here, "C1" is the first message, and "PK" is the server's public key. Using KGC's public key (PK), KGC can encrypt {ID_i, n1, A1}.

[0100] Back Figure 1In step 110, method 100 further includes sending a first message to a server (i.e., a key generating server (KGC)). Here, the first message is sent from the client device to the key generating server via a secure channel. Returning to... Figure 2C As shown in the figure, in step S2.3, the first client device 206 sends the first message to the key generation server 204.

[0101] Furthermore, in step 112, method 100 also includes receiving a second message generated from the server based on the server's private key and system parameters, and also receiving authentication credentials generated based on the first message, the server's private key, the server's public key, and the client ID. Here, the server's private key may be a secret code known to the key generation server, and this secret code may not generally be publicly known. Once the key generation server receives the first message, it can generate the second message based on the server's private key and system parameters. The authentication credentials can also be generated by verifying the integrity and identity of the first message. Additionally, the first message and authentication credentials can be sent to the client device. In other words, the key generation server performs helpful key exchange and implicit authentication, computes the second message, and generates authentication credentials.

[0102] Refer again Figure 2C As shown in the figure, the key generation server 204 uses the following formulas (8) and (9) to generate the second message and authentication credentials:

[0103] m2=F1(sk2, nonce2, system parameters) (8)

[0104] S=F2(SK,m1,pk2,ID1) (9)

[0105] In this context, "m2" is the second message, "sk2" is the server's private key, "nonce2" is a once-in-a-lifetime random number from the KGC, "system parameters" are one or more system parameters received by the first client device, "S" is the authentication credential, "SK" is the server's private key, "pk2" is the server's public key, and "ID1" is the client ID.

[0106] Furthermore, as shown in the figure, in step S2.4, the key generation server 204 sends the second message "m2" and the authentication credential "S" to the first client device 206.

[0107] According to the embodiment, the second message is generated by decrypting the first message using the server's private key and verifying the authentication value. Once the KGC receives the first message, the first message can be decrypted using the decryption algorithm. The authentication value can be verified to check the identity of the client device. Here, the authentication value can be determined first by the client ID and the intermediate value obtained by decrypting the first message. Next, the determined authentication value can be compared with the 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 on the secure channel is established by accepting the first message; otherwise, communication is terminated and the communication request is rejected. That is, returning to formulas (5), (6), and (7), once the KGC receives the first message "C1", the first message can be decrypted according to the formula (10) provided below:

[0108] Decrypt C1: ID_i||n1||A1=Dec(SK,C1) (10)

[0109] Here, "SK" is the server's private key.

[0110] Next, the authentication value can be determined according to the following formula (11):

[0111] AuthenValue i *=PRF(n1,ID_i||"MAC") (11)

[0112] Here, "AuthenValue_i*" is the authentication value of the determined client device "i". If "AuthenValue_i*" equals "AuthenValue_i", the communication request is accepted; otherwise, the communication request is rejected. It can be understood that, here, "AuthenValue_i" is the authentication value of the client device "i" stored in the KGC during registration.

[0113] According to one embodiment, authentication credentials are generated by multiplying the third cryptographic hash function (which is based on the client ID, server ID, and a second randomly generated value) by the server's private key. Similarly, the third cryptographic hash function can convert input data of any size into a fixed-size binary array, where the input data is the client ID, server ID, and the second randomly generated value. It should be noted that the server ID can be an identifier used to identify the KGC. Similar to the first randomly generated value, the second randomly generated value can be a random number generated using a computer algorithm such as a random number generator.

[0114] 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 can be calculated using the first randomly generated value according to the formula (12) provided below:

[0115] B_i=b1·g+A1 (12)

[0116] 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.

[0117] Next, generate the authentication certificate according to the following formula (13):

[0118] S_i=F2(SK, b1, B_i, ID_i, ID-KGC)=b1+Hash(ID_i||ID-KDC, B_i)·SK (13)

[0119] Where “S_i” is the authentication credential, “F2” is the third-party cryptographic hash function, and “ID_KGC” is the server ID.

[0120] Finally, the authentication credential "S_i", the second randomly generated number ("B_1" in this case), and the server ID "ID_KGC" can be sent to the client device.

[0121] Back Figure 1 In step 114, 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 message and the second message, the authentication credentials, the client's private key, and the server's public key. The valid private key and the valid public key can be determined according to the following formula (14):

[0122] sk_ID1 / pk_ID1=F3(sk1,m1,m2,S,PK) (14)

[0123] In this context, "sk_ID1" is the valid private key, "pk_ID1" is the valid public key, "sk1" is the client's private key, "m1" is the first message, "m2" is the second message, "S" is the authentication credential, and "PK" is the server's public key.

[0124] In this example, the public / private key can be calculated using S_i, B_i, a1, ID_i, and ID_KDC. Specifically, a valid private key and a valid public key can be determined according to the formulas (15), (16), and (17) provided below:

[0125] (pk1, sk1) = F3 (a1, B_i, S_i, ID_i, ID_KDC) (15)

[0126] pk1=B_i+Hash(ID_i||ID_KDC, B_i)·PK (16)

[0127] sk1 = a1 + S_i (17)

[0128] Wherein, "pk1" is the valid public key, "sk1" is the valid private key, "a1" is the first random variable, "B_i" is the second randomly generated value, "ID_i" is the client ID, and "ID_KDC" is the server ID.

[0129] According to one embodiment, the method 100 further includes sending a connection message to a second client device, wherein the connection message is based on a valid private key and a valid public key and system parameters; receiving a response from the second client device, wherein the response is based on system parameters and a valid private key and a valid public key of the second client device; and calculating one or more session keys for secure communication with the second client device based on the response from the second client device. Here, the client device may be referred to as a first client device, and secure communication can be established between the first client device and the second client device. Here, the connection message may be determined by the first client device according to the following formula (18):

[0130] sk1 / pk1=KeyGen1(); sends(ID1, S1, pk1) (18)

[0131] Here, "sk1" is the valid private key of the first client device, and "pk1" is the valid public key of the first client device.

[0132] 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 and second client devices can verify their respective communication partners, namely the second client device and the first client device. The first client device can verify the second client device by calculating the second client device's public key according to the formula (19) provided below:

[0133] pk ID2 =F(PK, ID2, S2) (19)

[0134] Among them, "pk" ID2 " is the public key calculated by the second client device.

[0135] Subsequently, the first client device can calculate the session key "K" according to the following formula (20). Auth ||K Enc ":

[0136] K Auth ||K Enc=KeyGen2(PK) ID1 SK ID1 ,sk1,pk2) (20)

[0137] Similarly, the second client device can verify the first client device by calculating the first client device's public key according to the formula (21) provided below:

[0138] pk ID1 =F(PK, ID1, S1) (21)

[0139] Among them, "pk" ID1 " is the public key calculated by the first client device.

[0140] Subsequently, the second client device can calculate the session key "K" according to the following formula (22). Auth ||K Enc ":

[0141] K Auth ||K Enc =KeyGen2(PK) ID1 SK ID1 ,sk2,pk1) (22)

[0142] Furthermore, the process involved in establishing specific secure communication between the first client device and the second client device is described below. The first client device may have a client ID, denoted as "ID_1", and may have an authentication credential, denoted as "S1". The second client device may have a client ID, denoted as "ID_2", and may have an authentication credential, denoted as "S2". First, the first client device can generate a random function "X" by multiplying the random variable by the generator according to the formula (23) provided below:

[0143] X = x·G (23)

[0144] Here, "x" is a random variable.

[0145] Then, the first client device can send “X”, “ID_1”, and “S1” to the second client device. Similarly, the second client device can generate a random function “Y” by dot product of the random variable “y” and the generator “G” according to the formula (24) provided below:

[0146] Y = y·G (24)

[0147] Then, the second client device can send "Y", "ID_2", and "S2" to the first client device. Next, the first client device can verify the confirmation of (ID_2, B2, Y); and during the verification, the first client device can calculate the valid public key "PK" according to the formula (25) provided below. ID2 ":

[0148] PK ID2 =F(B2,PK,ID_2)=B2+Hash(ID_2||ID KDC ,B2)·PK (25)

[0149] In addition, session key K Auth ||K Encn It can be calculated using the following formulas (26), (27) and (28):

[0150] MK = Hash(PK) ID2 SK ID1 (x, Y) (26)

[0151] W=B1||B2||ID_1||ID_2||X||Y (27)

[0152] KAuth||KEnc=Hash(MK;W||″0″) (28)

[0153] Finally, the second client device can verify the confirmation of (ID_1, B1, X); and during confirmation, the first client device can calculate the valid public key "pk" according to the formula (29) provided below. ID2 ":

[0154] PK ID1 =F(B1,PK,ID_1)=B1+Hash(ID1||ID KDC ,B1)·PK (29)

[0155] Furthermore, as mentioned above, the session key K Auth ||K Encn The following formulas (30), (31), and (32) can be used to calculate:

[0156] MK = Hash(PK) ID1 SK ID2 (30)

[0157] W=B1||B2||ID_1||ID_2||X||Y (31)

[0158] KAuth||KEnc=Hash(MK;W||″0″) (32)

[0159] According to an embodiment, the connection message also includes verifying the public key and identity of the second client device using a public key revocation list provided by the server. The public key revocation list can be a list of public keys stored on the server. Here, the public key revocation list can be used to establish a secondary check to assist the client device in establishing a secure communication channel.

[0160] This disclosure also relates to the client device described above. The various embodiments and variations disclosed above are adapted to the client device of this disclosure with necessary modifications and without any limitation.

[0161] Figure 3This is a block diagram of a client device 300 provided in an embodiment of this disclosure. The client device 300 includes a processor 302, a communication module 304, and a memory 306. As used herein, a "processor" refers to a structure and / or module including 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. Optionally, the processor includes means of a physical or virtual computing entity capable of enhancing information to perform various computational tasks. Furthermore, a processor refers to a computing element that can be used to respond to and process instructions 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 (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or any other type of processing circuitry, such as those described above. Furthermore, processors are arranged in various architectures to respond to and process instructions for translating source text in a first language into a second language within the system. It will also be understood that at least one processor can be implemented as a hardware processor and / or multiple hardware processors operating in a parallel or distributed architecture. Optionally, the processor is supplemented with additional computational methods, such as neural networks and hierarchical clusters of pseudo-simulated variable state machines implementing artificial intelligence algorithms. In one example, the processor may include components such as memory, data communication interfaces, network adapters, etc., to store, process information, and / or share information with other computing devices such as user devices and translation memories. Optionally, the processor is implemented as a computer program that provides various services (e.g., database services) to other devices, modules, or apparatuses. Furthermore, a "communication module" relates to the arrangement of interconnected, programmable, and / or non-programmable components that, during operation, facilitate data communication between one or more computing devices and / or a database. The communication module can enable communication between interactive computing devices (e.g., user devices or translation memories, etc.). In other words, user devices and translation memories can communicate with other computing devices (e.g., at least one processor) via the communication module.In addition, communication modules include, but are not limited to, peer-to-peer (P2P) networks, ring communication networks, hybrid peer-to-peer networks, local area networks (LANs), radio access networks (RANs), metropolitan area networks (MANs), wide area networks (WANs), and all or part of public networks, as referred to as such. This includes global computer networks, private networks, cellular networks, and any other communication systems. Additionally, the communication module may optionally employ wired or wireless communication, which can be performed via one or more known protocols, including but not limited to Internet Protocol (IP), Wireless Access Protocol (WAP), Frame Relay, or Asynchronous Transfer Mode (ATM). Furthermore, any other suitable protocol using voice, video, data, or a combination thereof, such as VoIP, may be employed. Additionally, as used herein, the term "memory" refers to a device capable of storing and retrieving information. The term "memory" includes internal and external storage devices, including magnetic disks and optical disks, magnetic tapes, compressed optical disks, and random access memory (RAM) and read-only memory (ROM).

[0162] As shown in the figure, memory 306 stores client private key 308 and instructions for processor 302. These instructions cause processor 302 to generate a client ID and authentication value based on client private key 308. Optionally, an authentication value is also generated based on the status information of client device 300. Optionally, generating the authentication value includes generating a first cryptographic hash function based on client private key 308. These instructions cause processor 302 to send the client ID and authentication value to key generation server using communication module 304. Optionally, sending the client ID and authentication value to the server includes concatenating the client ID and authentication value and encrypting them using the client public key. These instructions cause processor 302 to receive one or more system parameters for secure communication from the server via communication module 304. Optionally, the parameters for secure communication include one or more of mapping functions, hash functions, and encryption algorithms. These instructions cause 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 client private key 308 and encrypting it using the server public key. Optionally, encryption includes concatenating a second cryptographic hash function with a first randomly generated value and a client ID. These instructions also cause processor 302 to send a first message to the server using communication module 304. These instructions further cause processor 302 to receive a second message generated based on the server's private key and system parameters from the server via communication module 304, and also receive authentication credentials generated based on the first message, the server's private key, the server's public key, and the client ID. Optionally, the second message is generated by decrypting the first message and verifying the authentication value using the server's private key. Optionally, the authentication credentials are 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 hash function by the server's private key. Optionally, the second randomly generated value is based on one or more components of the first message. These instructions cause processor 302 to compute a valid private / public key pair based on the first and second messages, the authentication credentials, the client's private key 308, and the server's public key.

[0163] Figure 4AThis is a block diagram illustrating an implementation of a key generation server 204 for establishing secure communication between a client device 300 and a second client device 400, according to various embodiments of this disclosure. Here, the client device 300 sends a connection message to the second client device 400, wherein the connection message is based on a valid private / public key pair and system parameters. Based on the response from the second client device 400, the client device 300 calculates one or more session keys for secure communication with the second client device 400. Optionally, the connection message further includes verifying the public key and identity of the second client device 400 using a public key revocation list provided by the key generation server 204. A secure channel 402 is established to facilitate secure communication between the client device 200, the second client device 400, and the key generation server 204.

[0164] Figure 4B This is a block diagram illustrating the implementation of a key generation server 204 for establishing secure communication between multiple client devices, according to various embodiments of this disclosure. The multiple client devices include "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". A secure channel 402 is established for communication between the multiple client devices ID_1, ID_2, ..., ID_i, ..., ID_n. The secure channel 402 is also used for communication between one or more of the multiple client devices and the key generation server 204.

[0165] Reference Figure 3 as well as Figure 4A and Figure 4BThis disclosure also provides a computer-readable medium including instructions that, when executed by a processor 302, cause the processor 302 to perform method 100. Specifically, a processor (or one or more processors) of a client device 300 is used to perform method 100. Typically, a computer-readable medium can direct a computerized device, other programmable data processing apparatus, or other interactive computing device to operate in a particular manner, causing instructions stored in a non-transitory computer-readable storage medium to perform a series of steps to implement the function specified in a flowchart corresponding to the instructions. Examples of implementations of a non-transitory computer-readable storage medium include, but are not limited to, electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), read-only memory (ROM), hard disk drive (HDD), flash memory, secure digital (SD) cards, solid-state drives (SSDs), and / or CPU cache memory. Computer-readable media used to provide non-transient memory may include, but are not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof.

[0166] The client devices and methods disclosed herein provide secure communication without requiring certificates. That is, parties such as the client device, key generation server, or a second client device can perform secure and authenticated communication based on public keys without requiring certificates. The client devices and methods provide high security by providing message authentication and maintaining integrity and confidentiality. Furthermore, the client devices and methods do not suffer from key escrow issues. Moreover, the client devices and methods disclosed herein are resistant to transient key leakage attacks. Furthermore, compared to traditional certificate-based schemes, the client devices and methods provide extremely lightweight secure communication with limited computational complexity. Therefore, these methods are more compatible. In addition, the client devices and methods have a user-friendly integration environment.

[0167] In one example, compared to the EC-based TLS 1.3 protocol known in the art, a single communication requires approximately 2100 bytes, while the scheme proposed according to embodiments of this disclosure may only require approximately 168 bytes. Furthermore, the EC-based TLS 1.3 protocol involves 1 symbol operation + 1 verification operation + 2 EC multiplications + 3 PRF operations + 1 MAC operation to complete the computation; however, the scheme proposed according to embodiments of this disclosure may only require 2 EC multiplications + 3 hash operations. Moreover, the scheme proposed according to embodiments of this disclosure can meet the necessary security requirements provided by the traditional EC-based TLS 1.3 protocol, including confidentiality, authentication, resistance to reply attacks, resistance to MITM attacks, perfect forward security (PFS), resistance to unknown key share (UKS) attacks, and resistance to key compromise impersonation (KCI) attacks. Furthermore, the scheme proposed according to the embodiments of this disclosure can also resist ephermal key leakage (also known as ephermal secret leakage, ESL) attacks, which may not be possible in traditional EC-based TLS 1.3 protocols.

[0168] Modifications to the embodiments of the present disclosure described above may be made without departing from the scope of the appended claims. Expressions such as “comprising,” “including,” “combined,” “having,” and “are” used to describe and protect the present disclosure should be interpreted in a non-unique manner, allowing for the appearance of items, portions, or elements not explicitly described. Singular references should also be interpreted in relation to the plural. The word “exemplary” as used herein means “as an example, instance, or illustration.” Any embodiment described as “exemplary” is not necessarily to be construed as preferential or superior to other embodiments and / or does not exclude features in combination with other embodiments. The word “optionally” as used herein means “provided in some embodiments and not in others.” It should be understood that certain features of the present disclosure described in the context of individual embodiments for clarity may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure described in the context of individual embodiments for clarity may also be provided individually or by any suitable combination or as appropriate as any other described embodiment of the present disclosure.

Claims

1. A client device (202, 206, 300, 400, 404, 406, 408, 410), characterized in that, include: Processor (302); Communication module (304); Memory (306) for storing client private key (308) and instructions that cause the processor to: A client ID and authentication value are generated based on the client's private key. The communication module is used to send the client ID and the authentication value to the key generation server (204). The communication module receives one or more system parameters from the server for secure communication. The first message is generated based on the client's private key and the received system parameters. The first message is sent to the server using the communication module. The communication module receives a second message generated from the server based on the server private key and the system parameters, and receives authentication credentials generated based on the first message, the server private key, the server public key, and the client ID. Based on the first message and the second message, the authentication credential, the client private key and the server public key, calculate a valid private key / public key pair.

2. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1, characterized in that, The authentication value is also generated based on the status information of the client device.

3. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1 or 2, characterized in that, Generating the authentication value includes: generating a first cryptographic hash function based on the client private key (308).

4. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1 or 2, characterized in that, Sending the client ID and authentication value to the key generation server (204) includes: concatenating the client ID and authentication value and encrypting them using the client's public key.

5. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1 or 2, characterized in that, The parameters used for secure communication include 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) according to claim 1 or 2, characterized in that, Generating the first message includes: generating a second cryptographic hash function based on the client private key (308), and encrypting it using the server public key.

7. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 6, characterized in that, The encryption includes 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) according to claim 1 or 7, characterized in that, The second message is generated by decrypting the first message using the server's private key and verifying the authentication value.

9. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1 or 2, characterized in that, The authentication credential is generated by multiplying the third cryptographic hash function by the server private key, based on the client ID, server ID, and a second randomly generated value.

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

11. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 1 or 10, characterized in that, Also includes: A connection message is sent to a second client device (400), wherein the connection message is based on the valid private / public key pair and the system parameters; And based on the response from the second client device, calculate one or more session keys for secure communication with the second client device.

12. The client device (202, 206, 300, 400, 404, 406, 408, 410) according to claim 11, characterized in that, Sending the connection message also 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).

13. A method (100) for authenticating client devices (202, 206, 300, 400, 404, 406, 408, 410) having a client private key (308), characterized in that, The method (100) includes: Generate a client ID and authentication value based on the client's private key; Send the client ID and the authentication value to the key generation server (204). Receive one or more system parameters from the server for secure communication; A first message is generated based on the client's private key and the received system parameters; Send the first message to the server; The server receives a second message generated based on the server private key and the system parameters, and also receives authentication credentials generated based on the first message, the server private key, the server public key, and the client ID. Determine a valid private key and a valid public key, wherein the valid private key and the valid public key are based on the first message and the second message, the authentication credential, the client private key and the server public key.

14. The method (100) according to claim 13, characterized in that, The authentication value is also generated based on the status information of the client device (202, 206, 300, 400, 404, 406, 408, 410).

15. The method (100) according to claim 13 or 14, characterized in that, Generating the authentication value includes: generating a first cryptographic hash function based on the client private key (308).

16. The method (100) according to claim 13 or 14, characterized in that, Sending the client ID and authentication value to the key generation server (204) includes: concatenating the client ID and authentication value and encrypting them using the client's public key.

17. The method (100) according to claim 13 or 14, characterized in that, The parameters used for secure communication include one or more of a mapping function, a hash function, and an encryption algorithm.

18. The method (100) according to claim 13 or 14, characterized in that, Generating the first message includes: generating a second cryptographic hash function based on the client private key (308), and encrypting it using the server public key.

19. The method (100) according to claim 18, characterized in that, Encryption includes: The second password hash function is concatenated with the first randomly generated value and the client ID.

20. The method (100) according to claim 13 or 19, characterized in that, The second message is generated by decrypting the first message using the server's private key and verifying the authentication value.

21. The method (100) according to claim 13 or 14, characterized in that, The authentication credential is generated by multiplying the third cryptographic hash function by the server private key, based on the client ID, server ID, and a second randomly generated value.

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

23. The method (100) according to claim 13 or 22, characterized in that, Also includes: A connection message is sent to the second client device (400), wherein the connection message is based on the valid private key, the valid public key, and the system parameters; Receive a response from the second client device, wherein the response is based on the system parameters and the second client device's valid private key and valid public key; Based on the response from the second client device, calculate one or more session keys for secure communication with the second client device.

24. The method (100) according to claim 23, characterized in that, Sending the connection message also includes: verifying the public key and identity of the second client device using the public key revocation list provided by the key generation server (204).

25. A computer-readable medium, characterized in that, Includes instructions that, when executed by the processor (302), cause the processor (302) to perform the method according to any one of claims 13 to 24.

Images