certification

The method generates and authenticates shared keys using ECDHE and QKD to address confidentiality and authentication challenges, ensuring secure and continuous communication by relying on a shared history of previous authentications.

JP2026528831APending Publication Date: 2026-08-25UNIVERSITY OF LEEDS
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2026507938
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2023-08-11
Filing Date
2024-08-08
Publication Date
2026-08-25

AI Technical Summary

Technical Problem

Existing secure communication methods face challenges in ensuring confidentiality and authentication between parties, particularly in preventing unauthorized access and maintaining the integrity of shared secrets.

Method used

A method involving the generation of a current shared key through message exchange and authentication based on a previously authenticated shared key, utilizing methods like elliptic curve Diffie-Hellmann transient (ECDHE) key exchange and quantum key distribution (QKD), with continuous updating and authentication of shared secrets to ensure security.

Benefits of technology

This approach enhances security by continuously updating and authenticating shared secrets, ensuring confidentiality and integrity by relying on a shared history of previous successful authentications, reducing the risk of impersonation and maintaining secure communication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2026528831000001_ABST
    Figure 2026528831000001_ABST
Patent Text Reader

Abstract

A method for authentication between a first party and a second party is disclosed. This method comprises generating a current shared key by exchanging one or more messages between the first party and the second party, and authenticating the current shared key based on a previously authenticated shared key. In some examples, the current shared key may be authenticated based on both the previously authenticated shared key and the current shared key, and / or on at least one secret value obtained by the first party and / or the second party. In some examples, authenticating the current shared key comprises exchanging one or more messages between the first party and the second party, at least one of which is generated based on one or more of the current shared key, the previously authenticated shared key, and at least one secret value. In some examples, if it is determined that the current shared key is authenticated, the current shared key may be stored for use as the previously authenticated shared key when authenticating a new current shared key.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] Certain examples of this disclosure provide one or more techniques for performing authentication between at least a first party and a second party, for example, a first device and a second device. [Background technology]

[0002] A fundamental problem in communications theory is how to transmit information between two parties without allowing a third party to obtain and / or alter the information. For example, in the field of electronic financial transactions, maintaining confidentiality in communications between two parties is extremely important.

[0003] Conventionally, two parties wishing to exchange information are known as Alice (A) and Bob (B), respectively, while an eavesdropper seeking unauthorized access to the information is known as Eve (E). For example, Alice, Bob, and Eve may refer to a device or the user of a device.

[0004] A fundamental requirement of any secure communication method is that Alice and / or Bob must possess some kind of confidential information unknown to Eve. For example, this confidential information may be used as the basis for the encryption and / or subsequent decryption of the information.

[0005] In various techniques, it is also important that Alice and / or Bob can authenticate the other party before performing a secure operation, such as transmitting confidential information. In this disclosure, authentication may generally refer to a procedure or protocol that enables one party to verify the identity of another party. Mutual authentication, or two-way authentication, is a protocol that requires both parties to verify each other. Authentication helps prevent unauthorized access to confidential information, as well as other malicious activities that could compromise the security and integrity of systems and networks.

[0006] The information provided above is presented solely as background information to aid in understanding this disclosure. No determination has been made, nor has any claim been made, as to whether any of the above is applicable as prior art to this disclosure. [Overview of the project]

[0007] The purpose of the specific examples in this disclosure is to address, resolve, mitigate, or avoid at least one of the problems and / or drawbacks relating to the relevant technology, for example, at least one of the problems and / or drawbacks referred to herein. The specific examples in this disclosure are intended to provide at least one advantage to the relevant technology, for example, at least one of the advantages described herein.

[0008] The present invention is defined by the independent claims. Advantageous features are defined in the dependent claims.

[0009] A particular example of the present disclosure provides an authentication method between a first party and a second party, the method comprising generating a current shared key by exchanging one or more messages between the first party and the second party, and authenticating the current shared key based on a previously authenticated shared key.

[0010] In certain cases, the current shared key may be generated before the first and second parties are authenticated and / or before the identities of the first and second parties are established.

[0011] In certain cases, a shared key may consist of a dynamically generated key (for example, a key that is not an existing key already known to both parties).

[0012] In certain cases, the current shared key may be authenticated based on both a previously authenticated shared key and the current shared key.

[0013] In certain cases, the current shared key may be authenticated based on at least one secret value obtained by the first and / or second party.

[0014] In a particular example, authenticating the current shared key involves exchanging one or more messages between a first party and a second party, at least one of which may be generated based on one or more of the current shared key, a previously authenticated shared key, and at least one secret value.

[0015] In certain cases, generating a current shared key may involve generating two or more current shared keys, and these two or more current shared keys may be authenticated based on two or more previously authenticated shared keys.

[0016] In certain cases, the current shared key may be generated using one or more of the following methods of key exchange: asymmetric methods (e.g., elliptic curve Diffie-Hellmann transient (ECDHE) key exchange) and quantum key distribution (QKD).

[0017] In certain cases, this method may further include saving the current shared key for use as a previously authenticated shared key when authenticating a new current shared key, if it is determined that the current shared key is authenticated.

[0018] In certain cases, this method may further include re-authenticating one or more previously authenticated shared keys if the current shared key is not determined to be authenticated.

[0019] In certain cases, the method may further include identifying one or more previously authenticated sets of shared keys that are considered authenticated based on re-authentication.

[0020] In certain cases, authentication may involve symmetric authentication, where the first and second parties each perform substantially the same operation.

[0021] In a particular example, authenticating the current shared key may involve combining the current key with one or more previously authenticated shared keys to generate a combined key, authenticating the combined key as a shared key by exchanging one or more messages between the first and second parties, and determining that the current shared key has been authenticated based on the authentication of the combined key.

[0022] In certain cases, generating a combined key might involve an XOR operation between the current key and one or more previously authenticated shared keys.

[0023] In a particular example, authenticating a joint key as a shared key may involve the first party performing the following operations: generating a first token, encrypting the first token using the joint key, sending the encrypted first token to the second party, receiving from the second party an encrypted second token generated based on the first token, decrypting the second token using the joint key, and authenticating the joint key as a shared key based on the first and second tokens.

[0024] In a particular example, authenticating a joint key as a shared key may involve the first party performing the following operations: receiving an encrypted third token from the second party; decrypting the third token using the joint key; generating a fourth token based on the third token; encrypting the fourth token using the joint key; and sending the encrypted fourth token to the second party.

[0025] In certain cases, the first and second parties may authenticate each other based on the authentication of the current shared key.

[0026] The specific examples of this disclosure provide devices configured to operate in accordance with any example, aspect, embodiment, and / or method disclosed herein.

[0027] Certain examples of this disclosure provide computer programs that, when executed by a computer or processor, include instructions causing the computer or processor to perform any example, aspect, embodiment, and / or method according to the claims disclosed herein.

[0028] Certain examples of this disclosure provide a computer or processor-readable data carrier storing computer programs according to any example, aspect, embodiment, and / or claim disclosed herein.

[0029] Any embodiments, aspects, or examples disclosed in the description and / or drawings that fall outside the scope of the claims should be understood as useful examples for understanding the present invention. [Effects of the Invention]

[0030] Other aspects, advantages, and notable features of this disclosure will become apparent to those skilled in the art from the following detailed description, which discloses examples of this disclosure in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0031] [Figure 1] Figure 1 shows an authentication technique that includes an initial authentication event and one or more subsequent authentication events. [Figure 2] Figure 2 shows an authentication technique for performing subsequent authentication after initial authentication. [Figure 3] Figure 3 is a flowchart of the first authentication technique between Alice and Bob, based on the technique in Figure 2. [Figure 4] Figure 4 is a flowchart of the second authentication technique between Alice and Bob, based on the technique in Figure 2. [Figure 5] Figure 5 is a flowchart of the third authentication technique between Alice and Bob, based on the technique in Figure 2. [Figure 6] Figure 6 is a block diagram of an exemplary device for deriving confidential information to be shared with other devices. [Modes for carrying out the invention]

[0032] The following description of examples of this disclosure, with reference to the accompanying drawings, is intended to aid in a comprehensive understanding of the invention as defined in the claims. While this description includes various specific details to aid in understanding, these should be considered merely illustrative. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the examples described herein.

[0033] In certain examples of this disclosure, one or more techniques are provided for performing authentication between at least one first party and a second party. In this disclosure, the term “Party” can refer to any appropriate type of entity, such as a device, a user of a device, or a network node. Different parties can be distinguished using appropriate labels, such as “Alice” and “Bob.” In certain examples, authentication between parties (e.g., mutual authentication) may be achieved by authenticating shared secret information between the parties, and vice versa.

[0034] Devices capable of implementing one or more of the techniques described herein may be of any suitable type, such as mobile devices (e.g., cell phones), computer terminals, relay devices, servers, nodes in a network (e.g., the Internet or private networks), or other suitable types of devices for communication. Furthermore, such devices may be manually operated devices (e.g., devices operated by a user) or partially or fully automated devices. In certain examples, one or more of the techniques described herein may be applied to communication between internal components of one or more devices. Thus, references to “devices” communicating with another device may also include references to internal components of a device communicating with other internal components of the same device or different devices.

[0035] The techniques described herein may be used in a wide variety of applications, including but not limited to financial transactions, police, military, government, mobile data, mobile voice, navigation, location information (e.g., GPS), financial services, banking, maritime communications, subscriber services, mobile security services, distributed networks, remote access, internet communications, virtual private networks, satellite communications, remote command and control systems, aircraft (e.g., drones), remote control, data storage and archiving, and identity management and security.

[0036] Those skilled in the art will understand that a party certified in accordance with one or more techniques described herein can perform any suitable type of secure operation, including but not limited to secure communications.

[0037] In certain cases, authentication may be divided into different types, and these different types of authentication may be handled using different methods. In particular, the following two different types of authentication can be distinguished: 1. Initial Authentication. Here, the identities of the parties are confirmed or established for the first time. 2. Subsequent authentication. Here, the identity of a party whose identity has been previously verified is verified or established again.

[0038] An example of the first type of authentication is when a bank wants to establish the identity of a new customer, and similarly when a new customer wants to establish that the bank is a legitimate and trustworthy entity. An example of the second type of authentication is when a bank wants to verify that the party it is interacting with is a legitimate existing customer, and similarly when an existing customer wants to verify that the party it is interacting with is its bank. Similar interactions involving these two types of authentication can also occur in relationships with other entities, such as between a hotel and its guests.

[0039] The first type of authentication event typically occurs only once, or at least relatively rarely. The second type of authentication event, on the other hand, typically occurs multiple times, sometimes relatively frequently, after the first type of authentication has been successfully completed. Both types of authentication usually involve an exchange of information between the parties. However, the first type of authentication typically requires more complex procedures than the second type. This is because the second type of authentication usually relies, at least partially, on previously established shared secrets (such as online banking customer passwords). In contrast, the first type of authentication does not assume any pre-established shared secrets. Therefore, additional steps are usually required to establish the shared secrets for the first time to prevent them from being used by unauthorized third parties.

[0040] Figure 1 illustrates an authentication technique that includes an initial authentication event (comprising a first type of authentication) and one or more subsequent authentication events (each comprising a second type of authentication).

[0041] Referring to Figure 1, in the first operation 101, the first party (Alice) and the second party (Bob) authenticate each other. As part of the authentication process, Alice and Bob each obtain a shared secret. This is information known to Alice and Bob, but unknown to an unauthorized third party (Eve). The obtained shared secret may be denoted as K(0). Any appropriate procedure can be used to perform the authentication in operation 101. In this example, since the authentication performed in operation 101 involves the first type of authentication, a relatively complex authentication procedure may be required.

[0042] In the second operation 102, Alice and Bob authenticate each other again. As part of the authentication process, Alice and Bob each acquire a new shared secret, which is represented as K(1). Any suitable procedure can be used to perform the authentication in operation 102. In this example, since the authentication performed in operation 102 involves a second type of authentication, a relatively simple authentication procedure can be used. In particular, the authentication procedure can be based at least partially on the previously established shared secret K(0), which allows for the use of an even simpler procedure.

[0043] As shown in Figure 1, operation 102 can be repeated any number of times. New shared secret information may be obtained in each iteration of operation 102. The shared secret information obtained in the nth iteration is denoted as K(n). The authentication performed in the nth iteration may be based, at least in part, on previously established shared secret information (e.g., K(n-1)) obtained in one or more previous iterations.

[0044] Certain examples in this disclosure provide one or more techniques for performing a second type of authentication. As stated above, a second type of authentication can be considered an authentication procedure in which the two parties have already obtained shared secret information as a result of a previous authentication procedure being successfully completed, for example. For example, a previous authentication procedure may comprise a second type of authentication or a first type of authentication. As stated above, a first type of authentication can be considered an authentication procedure that does not presuppose shared secret information established in advance between the parties.

[0045] Figure 2 illustrates an authentication technique for performing subsequent authentication (i.e., a second type of authentication) after initial authentication (i.e., a first type of authentication). For example, the technique in Figure 2 may correspond to operation 102 in Figure 1.

[0046] Referring to Figure 2, in the first operation 201, the first party (Alice) and the second party (Bob) perform a procedure to obtain shared secret information. For example, Alice and Bob may perform a key exchange procedure to obtain a shared secret key. The obtained key is denoted as K(n). In certain examples, the overall method in Figure 2 may be performed iteratively, and the value n may represent the nth iteration. Any suitable procedure can be used to generate K(n). For example, asymmetric key exchange methods (e.g., elliptic curve Diffie-Hellmann temporary (ECDHE) key exchange), quantum key distribution (QKD), one or more techniques and their equivalents disclosed in International Patent Application Publication WO2013 / 175224A1, and / or one or more techniques disclosed in concurrently pending Patent Application GB2211041.5 and its equivalents. In certain examples, the shared secret information (e.g., the shared secret key) may be obtained dynamically. For example, the shared secret information may be generated, derived, etc., when operation 201 is performed.

[0047] Operation 201 can be considered as establishing the “endpoint” of the communication sequence. This is done to ensure that all subsequent communication takes place between the key owners.

[0048] In the second operation 202, Alice and Bob perform an authentication procedure to enable the parties to authenticate each other (for example, to establish and / or verify each other's identities). Any suitable authentication procedure can be used in operation 202. Various examples are described in more detail below in relation to Figures 3-5. The authentication procedure is performed based on previously obtained shared secret information. For example, the authentication procedure may be performed based on a shared secret key K(n-1) generated in a previous iteration of the method in Figure 2. A person skilled in the art will understand that any combination of one or more secret keys generated in one or more previous iterations may be used.

[0049] In certain cases, the authentication procedure of operation 202 may be performed based not only on the shared secret information obtained in operation 201, but also on previously obtained shared secret information. For example, the authentication procedure may be performed based on the key K(n) generated in operation 201, as well as other keys generated in K(n-1) and / or in any of the previous iterations, such as K(n-2), K(n-3), etc.

[0050] In certain cases, the authentication procedure for operation 202 may be performed based on one or more pieces of secret information obtained by Alice and / or Bob.

[0051] In certain cases, if the authentication procedure for operation 202 is successful (for example, if Alice and Bob are successfully authenticated and / or if Alice and Bob's identities are successfully established or verified), key K(n) may be saved. Therefore, K(n) may be used as a previously authenticated key when authenticating new keys in one or more subsequent iterations. This ensures continuous and dynamic key management based on previously authenticated keys rather than relying on existing keys, for example.

[0052] Therefore, if authentication is successful in a previous iteration, a foundation is provided for authentication to succeed in the current iteration. Such a chain of authentication may not rely on pre-established shared secrets and may begin with a first type of authentication that can be used to generate initial shared secrets (e.g., key K(0)).

[0053] The technique shown in Figure 2 is in contrast to certain conventional techniques. In particular, in the technique in Figure 2, the key exchange procedure of operation 201 is performed before the authentication procedure of operation 202. On the other hand, in certain conventional techniques, the authentication procedure is performed before the key exchange procedure.

[0054] There is a risk that Alice or Bob may not actually be a legitimate party, but rather an imposter. In the technique shown in Figure 2, the key exchange procedure takes place before the authentication procedure, meaning that the imposter's fraudulent nature will not be identified through the authentication procedure until the shared key K(n) is obtained by a party, including the imposter. However, the authentication procedure is based on a previously generated key K(n-1) (and may also be based on the key K(n) generated in the first operation 201 and / or one or more other secrets), and therefore, assuming that the previously generated key K(n-1) is unknown to the imposter, the imposter will fail the authentication procedure. In the various techniques disclosed herein, K(n) allows for comparison of K(n-1) without revealing K(n-1).

[0055] In certain cases, the technique in Figure 2 can ensure security by continuously updating and authenticating shared secrets (e.g., keys) based on a shared history. This shared history does not rely, for example, on fixed keys or a pre-distributed set of keys known to both parties in advance. The current authentication is successful only if both parties share the same history (e.g., a history of previous successful authentications of one or more previously shared keys).

[0056] In a specific example, the acquired shared secret information (e.g., after key exchange) is used to perform authentication over an encrypted channel (e.g., to establish identity).

[0057] In certain cases, the authentication code is not explicitly disclosed. Instead, changing it for each transaction preserves the confidentiality of those involved and establishes continuity in identity verification. This is particularly advantageous in scenarios that involve, for example, attempts at impersonation.

[0058] Figures 3 to 5 illustrate various exemplary methods based on the general method in Figure 2. In some methods (e.g., the methods in Figures 1 and 2), each party (Alice and Bob) sends an initial message to the other party and receives a response message in return. Here, each party generates a response message based at least in part on the information contained in the received initial message. Then, each party makes a judgment about the trustworthiness of the other party based on the received response message. In other methods (e.g., the method in Figure 5), each party sends a message to the other party without receiving a response message. Then, each party makes a judgment about the trustworthiness of the other party based at least in part on the information contained in the received message. In all cases, the trustworthiness of the other party may be determined based on information already possessed (e.g., information obtained during key exchange or pre-stored information such as keys already authenticated in previous iterations).

[0059] Figure 3 is a flowchart of the first authentication technique between Alice and Bob, based on the technique in Figure 2. Operation 301 in Figure 3 corresponds to operation 201 in Figure 2, and operations 302-307 in Figure 3 correspond to operation 202 in Figure 2.

[0060] Referring to Figure 3, in the first operation 301a / 301b, Alice and Bob perform the procedure to obtain the shared secret information. In this example, the shared secret information comprises a shared secret key denoted as K(n), but those skilled in the art will understand that this disclosure is not limited to this example.

[0061] In the following, the corresponding values ​​obtained (e.g., calculated or derived) by Alice and Bob may be distinguished by the subscripts A and B. For example, the shared secret key obtained by Alice is K A (n) is denoted as such, and the shared secret key that Bob obtained is K B This is denoted as (n). If Alice and Bob are legitimate parties and the authentication procedure is performed correctly, the corresponding values ​​(i.e., values ​​whose notation differs only by subscript A or B) should be equal. For example, K A (n) is KB It should be equal to (n). For the sake of convenience, the values shown without subscripts may be used to indicate values associated with Alice and / or Bob depending on the context.

[0062] To obtain the shared secret information, any suitable procedure can be used in operations 301a / 301b. For example, to obtain the shared secret key K(n), Alice and Bob can use either an asymmetric key exchange method (such as ECDHE key exchange), QKD, and / or any of the techniques disclosed in WO2013 / 175224A1 and / or GB2211041.5.

[0063] Alice and Bob each store their respective keys K A (n) and K B (n).

[0064] In operations 302 - 307, Alice and Bob perform a mutual authentication procedure to determine whether each other is a legitimate party. If the mutual authentication is successful, the key K(n) is considered secure. As will be described later, the authentication is performed based not only on the newly generated key K(n) but also on the previously generated key K(n - 1) that has already been successfully authenticated. This means that the success of authentication using the new key K(n) depends on the knowledge of not only K(n) but also K(n - 1). Therefore, even if an impersonator obtains knowledge of K(n) in the key exchange procedure of operation 301, based on the assumption that the impersonator does not have knowledge of K(n - 1), the subsequent authentication in operations 302 - 307 will fail. This assumption is justified by the fact that the previous authentication involving K(n - 1) was successful. When the authentication of K(n) is successful, the confidentiality of K(n) is guaranteed and it can be used as a basis for further authentication in the next iteration where a new key K(n + 1) is generated.

[0065] In the second operation 302a, Alice calculates a value T A (n) based on K A (n) and K A (n - 1). TA The value of (n) is the same for both the value of K(n) and the value of K(n-1) as T A The calculation is performed in such a way that it cannot be derived from (n). For example, if K(n) and K(n-1) are represented as binary strings, T A (n)

number

number

number

[0066] In the third operation 303a, Alice obtains the secret value RA, which is a random value generated by Alice using any appropriate method, such as a quasi-random number generator or a method that utilizes the random properties inherent in a physical system (e.g., sampling a quantum system or a signal containing noise).

[0067] Next, Alice sent the first secure message M (1AB) (T A Send (n);RA) to Bob. Here, message M (1AB) is T A (n) is generated based on RA. For example, Alice is T A Encrypt the RA using (n) as the encryption key and send the encrypted message to Bob. Any suitable encryption scheme can be used. For example, in the illustrated example, a symmetric encryption scheme could be used where the same key is used for both encrypting and decrypting the message.

[0068] In the fourth operation 304b, Bob sends message M (1AB) (T A (n);RA) is received and processed to recover the value RA. For example, in the illustrated example, Bob is T B The message is decrypted using (n) as the decryption key, and the RA is restored. Considering the symmetric encryption algorithm used, T A (n) = T B It is understood that RA can be successfully restored by the second party only if (n) is true. A (n) = K B (n) and K A (n-1) = K B T A (n) = T B It is understood that (n) is the case. A person skilled in the art will understand why K(n) is important in the security of key exchange.

[0069] In the fifth operation 305b, Bob generates a value RA' based on RA using any appropriate operation known to both Alice and Bob. For example, RA' is calculated as RA' = RA + 1.

[0070] Next, Bob presented the second secure message M (2BA) (T B Send (n);RA') to Alice. Here is message M (2BA) is T B It is generated based on (n) and RA'. For example, Bob is T B (n) can be used as the encryption key to encrypt RA' and send the encrypted message to Alice. Any suitable encryption method can be used, and this is how message M (1AB) The encryption algorithm used to generate the result may be the same as or different from that used. In the illustrated example, a symmetric encryption scheme may be used.

[0071] The reason why a value based on RA' is used in operation 305b, rather than RA itself, is as follows: Here, (i) RA is used instead of RA' in operation 305b, and (ii) T A (n) ≠ T B Consider a situation where (n) is true (indicating that Alice or Bob is not legitimate or that an error may have occurred in the authentication process). In this scenario, Bob is T B (n) (1AB) Decode it, and the resulting value is T B Re-encrypt using (n). Considering the symmetry of the encryption / decryption algorithm, even if the decrypted value is (inaccurate T B Even if (n) is incorrect, the re-encrypted value may still be correct. Essentially, the error caused by decrypting with the wrong key is canceled out by re-encrypting with the same (wrong) key. This canceling effect can be avoided by using a value RA' based on RA instead of RA.

[0072] In the sixth operation 306a, Alice receives message M (2BA) (T B (n);RA') is received and processed to reconstruct the value RA'. For example, in the illustrated example, Alice is T A Decrypt the message using (n) as the decryption key and recover RA'. Considering the symmetric encryption algorithm used, T A (n) = T B It is found that RA' is successfully restored by the first party only in case (n).

[0073] In the seventh operation 307a, Alice uses the value of RA that she generated and the message M (2BA) The verification is performed based on the value of RA' recovered from RA. For example, Alice calculates (generates) the value of RA' based on RA, and this value is sent to message M (2BA) The values ​​may be compared to the RA' values ​​recovered from the original data. If these values ​​match, the verification is considered successful. Alternatively, any other suitable equivalent comparison can be used.

[0074] Operations 302-307 are understood to involve a procedure in which the value RA is passed from Alice to Bob, and the associated value RA' is returned from Bob to Alice. These values ​​are T on Alice's side. A Encrypted and decrypted using (n), and on Bob's side T B (n) is used to decrypt and encrypt. A (n) = T B If (n), the entire procedure is successful. Therefore, by verification of operation 307a, Alice is T A (n) = T B (n) can be verified. As mentioned above, K in general A (n) = K B (n) and K A (n-1) = K B T A (n) = T B (n) Therefore, by verification of operation 307a, Alice is K A (n-1) = K B Under the assumption that (n-1) has been verified previously, K A (n) = K B (n) can be verified.

[0075] Bob is T A (n) = T B (n) and therefore K A (n) = K B To also verify that (n) is true, operations 302-307 may be performed with Alice and Bob's roles reversed. These operations are briefly described below. Those skilled in the art will understand that these operations may be performed simultaneously with, before, or after the operations described above.

[0076] In the third operation 303b, Bob obtains a secret value RB (for example, a random value), for example, T B By encrypting RB using (n) as the encryption key, the first secure message M (1BA) (T BGenerate (n);RB) and send this first secure message to Alice.

[0077] In the fourth operation 304a, Alice sends message M (1BA) (T B (n); Receive and process RB, for example T A The value RB is recovered by decrypting this message using (n) as the decryption key.

[0078] In the fifth operation 305a, Alice generates a value RB' based on RB using any appropriate operation such as RB' = RB + 1. Then Alice, for example, T A By encrypting RB' using (n) as the encryption key, the second secure message M (2AB) (T A Generate (n);RB') and send this second secure message to Bob.

[0079] In the sixth operation 306b, Bob receives message M (2AB) (T A (n); Receive and process RB', for example T B The value RB' is recovered by decrypting the message using (n) as the decryption key.

[0080] In the seventh operation 307b, Bob uses the value of RB that he generated and the message M (2AB) Perform verification based on the value of RB' recovered from RB. For example, generate the value of RB' based on RB and use this to send message M (2AB) Compare it with the value of RB' recovered from the original.

[0081] Alice and Bob exchange one or more messages to confirm whether their respective verifications were successful. For example, Alice might send Bob a 1-bit flag, where "1" indicates success or failure. Similarly, Bob might also send Alice a 1-bit flag indicating success or failure. Other appropriate representations and / or encoding schemes may be used in other examples.

[0082] If both Alice and Bob successfully validate the key, they retain the saved value of K(n). This retained value can then be used as the "validated value" in subsequent iterations of the method described above. For example, when repeating the method, the retained value may be used as K(n-1) and the newly generated value as K(n). Thus, in each iteration, the newly generated value may be validated based on the value validated in the previous iteration. In certain examples, Alice and Bob may use a key derived from K(n) or a key that was exchanged simultaneously.

[0083] In certain examples, the values ​​of RA and RB may differ from iteration to iteration. That is, Alice and Bob may generate new values ​​in each iteration.

[0084] If either Alice or Bob fails verification in operation 307, both Alice and Bob discard the stored K(n) value. In this case, any appropriate procedure (e.g., retry or return to initial authentication) may be performed.

[0085] In certain cases, the above procedure can be repeated to perform authentication based on the newly generated K(n).

[0086] In certain cases, a procedure may be performed to re-authenticate one or more previously stored values ​​K(n-1), K(n-2), ..., K(0). For example, Alice and Bob could perform the above procedure (omitting key generation operation 301) using previously stored values ​​K(na) and K(na-1) (a=1,2,3,...) instead of K(n) and K(n-1), and re-authenticate K(na).

[0087] In a specific example, Alice and Bob each store the values ​​of RA and RB in each iteration (denoted as RA(1), RA(2), ... and RB(1), RB(2), ...), and these values ​​are K A and K B It may be used for re-authentication along with the stored value. For example, Alice may use a previously stored value based on

number

[0088] In a particular example, the smallest value of "a" for which this re-authentication succeeds can be considered to represent a successful iteration immediately preceding the start of authentication failures. Alice and Bob exchange one or more messages to inform each other of the determined value of "a". This procedure is called "drift detection". The authentication procedure described in relation to Figure 3 can be executed starting from this iteration. This is sometimes called "sync correction".

[0089] By using the techniques described above, Alice and Bob can verify the shared secret generated in the current iteration based on the shared secret generated and verified in previous iterations. Alice and Bob can detect errors in a predictable manner and verify parts or all of the chain of secrets at any time.

[0090] In the case of a device with a relatively small memory, only a part of the past values of K is saved. In this case, when a new value of K is generated, verified, and saved, the oldest value of K is discarded. For example, if only two values of K are saved, when K(n) is generated, verified, and saved, K(n - 2) is discarded, and only K(n) and K(n - 1) are saved. Next, in the next iteration, when K(n + 1) is generated, verified, and saved, K(n - 1) is discarded, and only K(n + 1) and K(n) are saved.

[0091] Figure 4 is a flowchart of a second authentication technique between Alice and Bob based on the technique of Figure 2. Operation 401 in Figure 4 corresponds to operation 201 in Figure 2, and operations 402 - 407 in Figure 4 correspond to operation 202 in Figure 2.

[0092] Referring to Figure 4, in the first operations 401a / 401b, Alice and Bob execute procedures to obtain shared secret information. In this example, the shared secret information includes a shared secret key denoted as K(n), but those skilled in the art will understand that the present disclosure is not limited to this example. Operations 401a / 401b may be the same as or similar to operations 301a / 301b in Figure 3.

[0093] Alice and Bob each save their own key K A (n) and K B (n).

[0094] In operations 402 - 407, Alice and Bob execute mutual authentication procedures to determine whether each other is a legitimate party. If the mutual authentication is successful, the key K(n) is considered secure. On the other hand, if the mutual authentication fails, the key K(n) is discarded. In this example, the authentication is performed based on a previously generated key K(n - 1) that has already been successfully authenticated. That is, the success of the authentication depends on the knowledge of K(n - 1), and thus also on the success of the previous authentication. Operations 402 - 407 correspond to operations 302 - 307 in Figure 3.

[0095] In the second operation 402a, Alice obtains a secret value RA (e.g., a random value). Operation 402a may be the same as or similar to operation 303a in FIG. 3.

[0096] In the third operation 403a, Alice calculates K A (n - 1) and RA to generate the first secure message M (1AB) (K A (n - 1); RA). For example, Alice can encrypt RA using K A (n - 1) as the encryption key. Any suitable encryption algorithm (e.g., a symmetric encryption method such as AES 256 ) can be used. Next, Alice sends the first secure message M (1AB) to Bob.

[0097] In the fourth operation 404b, Bob receives the first secure message M (1AB) (K A (n - 1); RA) and processes it to recover the value RA. For example, in the illustrated example, Bob decrypts the first secure message using K B (n - 1) as the decryption key to recover RA.

[0098] In the fifth operation 405b, Bob uses any suitable operation known to both Alice and Bob to generate a value RA' based on RA. For example, RA' may be calculated as RA' = RA + 1.

[0099] Next, Bob calculates K B (n - 1) and RA' to generate the second secure message M (2BA) (K B (n - 1); RA'). For example, Bob may encrypt RA' using K B (n - 1) as the encryption key. Any suitable encryption method can be used, which is the same as the first secure message M (1AB)The encryption algorithm used to generate the first message may be the same as or different from the second message. In the illustrated example, a symmetric encryption scheme may be used. Next, Bob sends a second secure message to Alice.

[0100] In the sixth operation 406a, Alice receives message M (2BA) (K B (n-1);RA') is received and processed to reconstruct the value RA'. For example, in the illustrated example, Alice receives K A The message is decrypted using (n-1) as the decryption key, and RA' is restored.

[0101] In the seventh operation 407a, Alice uses the value of RA that she generated and the message M (2BA) The verification is performed based on the value of RA' recovered from RA. For example, Alice generates the value of RA' based on RA, and this value is used in message M (2BA) The value may be compared to the RA' value recovered from the original. If the values ​​match, the validation is considered successful. Alternatively, any other suitable equivalent comparison can be used.

[0102] As a result of the above operations 402-407, Alice is K B It can be determined that (n-1) is known. Only a legitimate or trustworthy party can determine K B Assuming that (n-1) is known, Alice can determine that Bob is a legitimate party. Thus, Alice can conclude that only the legitimate party, namely Bob, was involved in the key exchange of operation 401, and therefore only Bob, being a legitimate party, knew K B We become confident that we know (n). Therefore, this process justifies the above assumption in the next iteration.

[0103] Operations 402–407 may be performed with Alice and Bob's roles reversed so that Bob can perform the corresponding verification. These operations are briefly described below. Those skilled in the art will understand that these operations may be performed simultaneously with, before, or after the operations described above.

[0104] In the second operation 402b, Bob obtains a secret value RB (for example, a random value).

[0105] In the third operation 403b, Bob, for example, K B By encrypting RB using (n-1) as the encryption key, the first secure message M (1BA) (K B (n-1); RB) is generated, and this first secure message M (1BA) Send this to Alice.

[0106] In the fourth operation 404a, Alice sends the first secure message M (1BA) (K B (n-1); RB) is received and processed, and the value RB is recovered, for example, using decoding.

[0107] In the fifth operation 405a, Alice generates the value RB' based on RB. Next, Alice, for example, K A By encrypting RB' using (n-1) as the encryption key, the second secure message M (2AB) (K A Generate (n-1);RB') and send this second secure message to Bob.

[0108] In the sixth operation 406b, Bob receives the second secure message M (2AB) (K A (n-1); RB') is received and processed, for example using decoding, to recover the value RB'.

[0109] In the seventh operation 407b, Bob uses the value of RB that he generated and the message M (2AB) The validation is performed based on the value of RB' recovered from the source.

[0110] Alice and Bob exchange one or more messages (such as a 1-bit flag) to confirm to each other whether their respective verifications were successful. If both Alice and Bob's verifications are successful in operation 407, they retain the stored value of K(n) and can use it in the next iteration of the method. On the other hand, if either Alice or Bob's verification fails in operation 407, both Alice and Bob discard the stored value of K(n). Any appropriate techniques described above in relation to the method in Figure 3, such as re-authentication, drift detection, synchronization correction, and / or storage of a limited number of previous values ​​of K, are also applicable to the method in Figure 4.

[0111] Figure 5 is a flowchart of a third authentication technique between Alice and Bob, based on the technique in Figure 2. Operation 501 in Figure 5 corresponds to operation 201 in Figure 2, and operations 502-504 in Figure 5 correspond to operation 202 in Figure 2.

[0112] Referring to Figure 5, in the first operation 501a / 501b, Alice and Bob perform the procedure to obtain two items of the shared secret information. In this example, the shared secret information comprises a pair of shared secret keys indicated as K1(n) and K2(n), but those skilled in the art will understand that the disclosure is not limited to this example. The shared secret information can be obtained in the same or similar manner as in operation 301a / 301b in Figure 3, for example, by performing the key exchange procedure twice to obtain the two items of shared secret information.

[0113] Alice and Bob each store keys K1(n) and K2(n), respectively.

[0114] In the second operation 502a, Alice is K1 A (n) and K1 A Based on (n-1), the value T1 A (K1 A (n), K1 A (n-1)) is generated. For example, T1 A K1 A (n) and K1 AIt can be generated using any suitable hash function that takes (n-1) as input. Next, Alice is T1 A Send to Bob. Next, Alice will send the value T1 A Send it to Bob.

[0115] In the third operation 503b, Alice is K1 A (n) and K1 A Based on (n-1), the value T1 A In the same way that he generated K1 B (n) and K1 B Based on (n-1), the value T1 B (K1 B (n), K1 B Generate (n-1).

[0116] In the fourth operation 504b, Bob receives the value T1 from Alice. A And the value T1 generated by Bob B Compare these values. If these values ​​are equal, Bob says Alice is K1 A It is determined that they have knowledge of (n-1). Only legitimate or trustworthy parties are deemed to have knowledge of K1. A Assuming that (n-1) is known, Bob can determine that Alice is a legitimate party. Thus, Bob can conclude that only a legitimate party, namely Alice, was involved in the key exchange of operation 501, and therefore only Alice, being a legitimate party, has K1 A We become confident that we know (n). Therefore, this process justifies the above assumption in the next iteration.

[0117] Operations 502–504 may be performed with Alice and Bob's roles reversed so that Alice can perform the corresponding verification. These operations are briefly described below. Those skilled in the art will understand that these operations may be performed simultaneously with, before, or after the operations described above.

[0118] In the second operation 502b, Bob uses a hash function, for example, to determine the value T2 based on K2B(n) and K2B(n-1). B Generate (K2B(n),K2B(n-1)) and its value T2 B Send this to Alice.

[0119] In the third operation 503a, Alice says that Bob is value T2 B Using the same method as when we generated K2 A (n) and K2 A Based on (n-1), the value T2 A (K2 A (n), K2 A Generate (n-1).

[0120] In the fourth operation 504a, Alice receives the value T2 from Bob. B And the value T2 generated by Alice A Compare them.

[0121] Alice and Bob exchange one or more messages (such as a 1-bit flag) to confirm to each other whether their respective verifications were successful. If both Alice and Bob's verifications are successful in operation 504, they retain the stored K1(n) and K2(n) values, which may be used in subsequent iterations of the method. On the other hand, if either Alice or Bob's verification fails in operation 504, both Alice and Bob discard the stored K1(n) and K2(n) values. Any appropriate techniques described above in relation to the method in Figure 3, such as re-authentication, drift detection, synchronization correction, and / or storing a limited number of previous K1 and K2 values, are also applicable to the method in Figure 5.

[0122] Figure 6 shows an exemplary device (or apparatus) for deriving shared secret information and / or communicating with another device. For example, the techniques disclosed in relation to Figures 1 to 5 can be carried out using the device disclosed in relation to Figure 6. For example, Alice and Bob may each have devices such as those disclosed in relation to Figure 6. Device 600 includes a processor (or controller) 601 for controlling the overall operation of device 600. For example, the processor 601 may be configured to perform the operations described above for key exchange and authentication. Device 600 also includes a memory 603 for storing information and data necessary for the aforementioned operations. Device 600 also includes an external interface 605 for communicating with another device via any suitable communication link (e.g., wired or wireless). For example, under the control of the processor 601, the external interface 605 may be configured to send and receive messages as described above.

[0123] In certain examples, device 600 may further include a user input / output (I / O) unit 607 to enable a user to interact with device 600. For example, the user I / O unit 607 may include one or more input devices (e.g., a keyboard, a touchscreen, etc.) for entering commands into device 600. The user I / O unit 607 may also include one or more output devices (e.g., a display, LEDs, a speaker, etc.) for outputting information (e.g., status information) to the user. In certain examples, if device 600 is configured to operate autonomously, the user I / O unit 607 may be omitted. In some examples, device 600 may be configured to interface with another nearby device. In this case, the interface between device 600 and the other device may be a wired link or a relatively short-range communication link such as a Bluetooth link or an NFC link. In other examples, device 600 may be configured to interface with another device located remotely. In this case, device 600 can communicate with the other device over a network, such as the Internet.

[0124] The terms and words used herein are not limited to their dictionary definitions, but are used solely to enable a clear and consistent understanding of this disclosure.

[0125] Identical or similar components may be assigned the same or similar reference numbers, even if they are shown in different drawings.

[0126] For the sake of clarity and conciseness, and to avoid obscuring the subject matter of this disclosure, detailed descriptions of elements, features, components, structures, configurations, functions, operations, processes, characteristics, properties, complete sets, and steps known in the art may be omitted.

[0127] Throughout this specification, the words “equip,” “include,” “contain,” and “have,” as well as their variations (e.g., “equip,” “equip,” and “have,” mean “include, but not limited to,” and are not intended (and will not exclude) other elements, features, components, structures, configurations, functions, operations, processes, characteristics, properties, wholes, steps, and / or groups thereof.

[0128] Throughout this specification, the singular forms "a," "an," and "the" refer to multiple objects unless otherwise indicated by the context. For example, a reference to "object" refers to one or more such objects.

[0129] The term “substantially” means that the stated characteristic, parameter, or value does not need to be achieved exactly, but deviations or variations, including, for example, tolerances, measurement errors, limitations of measurement accuracy, and other factors known to those skilled in the art, may occur in an amount that does not interfere with the effect that the characteristic, parameter, or value is intended to provide.

[0130] Throughout this specification, the general form of expression “X for Y” (where Y is some action, process, function, activity, operation, or step, and X is some means for performing that action, process, function, activity, operation, or step) encompasses means X that are not exclusive but specifically adapted, configured, or arranged for performing Y.

[0131] Any elements, features, components, structures, configurations, functions, operations, processes, characteristics, properties, complete sets, steps, and / or groups thereof described herein in relation to a particular aspect, embodiment, example, or claim shall be understood to be applicable to any other aspect, embodiment, example, or claim disclosed herein, insofar as they do not conflict with each other.

[0132] It will be understood that examples of the present disclosure may be implemented in the form of hardware, software, or any combination of hardware and software. Such software may be stored in any suitable form of volatile or nonvolatile storage device or medium, such as ROM, RAM, memory chips, integrated circuits, or optically or magnetically readable media (e.g., CDs, DVDs, magnetic disks, or magnetic tapes).

[0133] Certain examples of this disclosure provide computer programs that, when executed by a computer or processor, include instructions causing that computer or processor to perform any example, embodiment, aspect, and / or method according to any of the claims disclosed herein. Certain examples of this disclosure provide a computer or processor-readable data carrier storing such computer programs.

[0134] The techniques described herein may be carried out using any appropriately configured apparatus and / or system. Such apparatus and / or system may be configured to perform any aspect, embodiment, example, or method according to any of the claims disclosed herein. Such apparatus may comprise one or more elements, such as a receiver, transmitter, transceiver, processor, controller, module, or unit, each element configured to perform one or more corresponding processes, operations, and / or method steps for carrying out the techniques described herein. For example, an operation / function of X may be performed by a module (or X module) configured to perform X. The apparatus and / or one or more elements thereof may be carried out in the form of hardware, software, virtualized functions instantiated on a suitable platform (e.g., cloud infrastructure), or any combination thereof.

[0135] Although the present invention has been shown and described with reference to specific examples, it will be understood by those skilled in the art that various modifications are possible in form and detail without departing from the scope of the invention as defined by the appended claims.

Claims

1. A method of authentication between the first party and the second party, The current shared key is generated by exchanging one or more messages between the first party and the second party, Authenticating the current shared key based on a previously authenticated shared key, A method that includes [a certain feature].

2. The method according to claim 1, wherein the current shared key is authenticated based on both the previously authenticated shared key and the current shared key.

3. The method according to claim 1 or 2, wherein the current shared key is authenticated based on at least one secret value obtained by at least one of the first party and the second party.

4. The method according to claim 1, 2, or 3, wherein authenticating the current shared key comprises exchanging one or more messages between the first party and the second party, at least one of the messages being generated based on one or more of the current shared key, the previously authenticated shared key, and the at least one secret value.

5. The method according to any one of claims 1 to 4, wherein generating the current shared key comprises generating two or more current shared keys, and the two or more current shared keys are authenticated based on two or more previously authenticated shared keys.

6. The method according to any one of claims 1 to 5, wherein the current shared key is generated using one or more of the following: an asymmetric method of key exchange (e.g., elliptic curve Diffie-Hellman temporary (ECDHE) key exchange) and quantum key distribution (QKD).

7. The method according to any one of claims 1 to 6, further comprising saving the current shared key for use as a previously authenticated shared key when authenticating a new current shared key if it is determined that the current shared key is authenticated.

8. The method according to any one of claims 1 to 7, further comprising re-authenticating one or more previously authenticated shared keys if the current shared key is not determined to be authenticated.

9. The method of claim 8, further comprising identifying one or more previously authenticated sets of shared keys that are deemed authenticated based on the re-authentication.

10. The method according to any one of claims 1 to 9, wherein the authentication comprises symmetric authentication, and each of the first party and the second party performs substantially the same operation.

11. Authenticating the current shared key mentioned above means The current key is combined with one or more previously authenticated shared keys to generate a combined key, The first party and the second party exchange one or more messages to authenticate the joint key as a shared key, Based on the authentication of the aforementioned joint key, it is determined that the current shared key has been authenticated, The method according to any one of claims 1 to 10, comprising:

12. The method according to claim 11, wherein generating the combined key comprises an XOR operation between the current key and one or more previously authenticated shared keys.

13. Authenticating the aforementioned joint key as a shared key comprises the following operations performed by the first party, the following operations: To generate the first token, Encrypting the first token using the aforementioned binding key, To transmit the encrypted first token to the second party, Receiving an encrypted second token from the second party, generated based on the first token, Decrypting the second token using the aforementioned binding key, and Authenticate the combined key as a shared key based on the first token and the second token. The method according to claim 11 or 12.

14. Authenticating the aforementioned joint key as a shared key comprises the following operations performed by the first party, the following operations: Receiving an encrypted third token from the aforementioned second party, Decrypting the third token using the aforementioned binding key, To generate a fourth token based on the third token, Encrypting the fourth token using the aforementioned binding key, and To transmit the encrypted fourth token to the second party, The method according to claim 13.

15. The method according to any one of claims 1 to 14, wherein the first and second parties authenticate each other based on the authentication of the current shared key.

16. A device configured to operate in accordance with the method described in any one of claims 1 to 15.

17. A computer program comprising, when executed by a computer or processor, instructions causing the computer or processor to perform the method described in any one of claims 1 to 15.

18. A computer or processor-readable data carrier storing the computer program described in claim 17.