Client privacy protected session resumption

Abstract

Various embodiments relate to a method and system for resuming a secure communication session with a server by a device, comprising: sending a message to the server requesting to resume a secure communication session; receiving a server identifier, a server nonce, and a salt from the server; determining that the device has a shared key with the server based on the server identifier; determining that the received salt is valid; computing a salted identifier based on the shared key and the salt; sending the salted identifier to the server; and resuming the secure communication session with the server.

Description

Technical Field

[0001] The various exemplary embodiments disclosed herein generally relate to protecting client privacy during communication session resumption. Background Technology

[0002] Today, key establishment and authentication are typically performed using asymmetric cryptography, especially when managing keys becomes a burden. However, asymmetric protocols can, at the same time, represent an unnecessaryly long authentication phase for self-organizing connections, including wireless connections. Various communication protocols include recovery mechanisms, where a secure communication session is resumed using an established symmetric cryptographic key without repeating the asymmetric authentication process. Summary of the Invention

[0003] The following provides an overview of various exemplary embodiments. Some simplifications and omissions may have been made in this overview to highlight and illustrate aspects of the various exemplary embodiments, but this does not limit the scope of the invention. Detailed descriptions of exemplary embodiments sufficient to allow those skilled in the art to generate and use the concepts of the invention will be presented in subsequent sections.

[0004] Various embodiments relate to a method and system for resuming a secure communication session with a server via a device, comprising: sending a message to the server requesting the resumption of the secure communication session; receiving a server identifier, a server random number, and a salt from the server; determining, based on the server identifier, that the device and the server have a shared key; determining that the received salt is valid; calculating a salted identifier based on the shared key and the salt; sending the salted identifier to the server; and resuming the secure communication session with the server.

[0005] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T; and updating the T value to an increment of the salt.

[0006] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T and a counter is less than a counter threshold; incrementing the counter; when the salt is greater than the salt threshold T, setting the salt threshold T to be equal to the salt and setting the counter to 0; and when the counter is equal to the counter threshold, incrementing the salt threshold T and setting the counter to 0.

[0007] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T; when the salt is greater than the salt threshold T, setting the salt threshold T to be equal to the salt and setting the current time to 0; and when the current time is greater than or equal to a time threshold, performing asymmetric mutual authentication.

[0008] Various implementations are described, including the establishment of new session keys.

[0009] Various embodiments are described, wherein the salted identifier is a hash of the salt and the shared key.

[0010] Other embodiments relate to a method for resuming a secure communication session with a device via a server, comprising: storing a salted identifier in a server database, wherein the salted identifier is based on a shared key and a salt; receiving a message from the device requesting the resumption of the secure communication session; sending a server identifier, a server random number, and the salt to the device, wherein the salt is a valid salt; receiving the salted identifier from the device; determining that the received salted identifier matches in the server database; and resuming the secure communication session with the device.

[0011] Various embodiments are described in which the salt is updated based on a strategy for increasing the salt content.

[0012] Various embodiments are described, wherein the salt increases every N transactions, where N is an integer greater than or equal to 1.

[0013] Various embodiments are described, in which the salt is added after a specified time period.

[0014] Various implementations are described, including the establishment of new session keys.

[0015] Various embodiments are described, wherein the salted identifier is a hash of the salt and the shared key.

[0016] Other embodiments relate to an apparatus configured to resume a secure communication session with a server, comprising: a memory; and a processor coupled to the memory, wherein the processor is further configured to: send a message to the server requesting resumption of the secure communication session; receive a server identifier, a server random number, and a salt from the server; determine, based on the server identifier, that the apparatus has a shared key with the server; determine that the received salt is valid; calculate a salted identifier based on the shared key and the salt; send the salted identifier to the server; and resume the secure communication session with the server.

[0017] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T; and updating the T value to an increment of the salt.

[0018] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T and a counter is less than a counter threshold; incrementing the counter; when the salt is greater than the salt threshold T, setting the salt threshold T to be equal to the salt and setting the counter to 0; and when the counter is equal to the counter threshold, incrementing the salt threshold T and setting the counter to 0.

[0019] Various embodiments are described, wherein determining that the received salt is valid further includes: determining that the salt is greater than or equal to a salt threshold T; when the salt is greater than the salt threshold T, setting the salt threshold T to be equal to the salt and setting the current time to 0; and when the current time is greater than or equal to a time threshold, performing asymmetric mutual authentication.

[0020] Various embodiments are described, wherein the processor is additionally configured to establish a new session key.

[0021] Various embodiments are described, wherein the salted identifier is a hash of the salt and the shared key.

[0022] Other embodiments relate to a server configured to restore a secure communication session with a device, comprising: a memory; a processor coupled to the memory, wherein the processor is further configured to: store a salted identifier in a server database, wherein the salted identifier is based on a shared key and a salt; receive a message from the device requesting the restoration of the secure communication session; send a server identifier, a server random number, and the salt to the device; receive the salted identifier from the device; determine that the received salted identifier matches in the server database; and restore the secure communication session with the device.

[0023] Various embodiments are described in which the salt is updated based on a strategy for increasing the salt content.

[0024] Various embodiments are described, wherein the salt increases every N transactions, where N is an integer greater than or equal to 1.

[0025] Various embodiments are described, in which the salt is added after a specified time period.

[0026] Various embodiments are described, wherein the processor is additionally configured to establish a new session key.

[0027] Various embodiments are described, wherein the salted identifier is a hash of the salt and the shared key. Attached Figure Description

[0028] To better understand the various exemplary embodiments, reference can be made to the accompanying drawings, in which:

[0029] Figure 1 A flowchart illustrating the process of resuming a secure communication session between a wireless device and a server is shown; and

[0030] Figure 2 An exemplary hardware diagram is shown for implementing the recovery method on a wireless device or server as described above.

[0031] For ease of understanding, the same reference numerals have been used to refer to elements having substantially the same or similar structure and / or substantially the same or similar function. Detailed Implementation

[0032] The description and figures illustrate the principles of the invention. It will thus be understood that those skilled in the art will be able to design various arrangements, which, although not explicitly described or illustrated herein, embody the principles of the invention and are included within its scope. Furthermore, all examples cited herein are intended primarily for illustrative purposes to aid the reader in understanding the principles of the invention and the concepts provided by the inventors to deepen understanding in the field, and all examples should be considered as not being limited to such specific cited examples and conditions. Additionally, as used herein, unless otherwise indicated (e.g., “or additionally” or “or in an alternative”), the term “or” means non-exclusive or (i.e., and / or). Similarly, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments may be combined with one or more other embodiments to form new embodiments.

[0033] This document describes an embodiment of a client-side privacy-preserving session recovery mechanism. Currently, key establishment and authentication are typically performed using asymmetric cryptography, where asymmetric cryptography is used to securely exchange session keys that would normally use symmetric cryptographic protocols. Asymmetric cryptography is used when managing keys becomes burdensome, such as when establishing a secure communication session between a user and a server using an Internet or wireless communication channel. However, asymmetric protocols imply unnecessary long authentication phases for self-organizing connections, such as secure wireless connections. The recovery mechanism uses a symmetric protocol to securely restore the secure connection. In the wireless case, Internet Protocol (IP) addresses cannot be used to restore the connection with the server, but the wireless device needs to probe the area to identify servers available for connection to that area. Once a server is discovered, it needs to identify itself. The wireless device then determines whether it knows the server, and can transmit an identifier of its previous session with the server to the server and attempt to restore the previous connection. Without a session identifier, the server cannot restore the connection with the wireless device. The session identifier needs to be sent securely in plaintext to make the wireless device traceable, as this identifier may need to be sent multiple times before the session is restored. Furthermore, current communication session resumption mechanisms, such as those in Transport Layer Security (TLS) version 1.3 (widely used for web browsing, email, instant messaging, Voice over IP, etc.), cannot ensure wireless device privacy in such self-organizing wireless settings. This document describes embodiments of session resumption mechanisms that can overcome this problem.

[0034] Suppose a session has been established between a wireless device and a server in a privacy-preserving manner, and both parties have agreed to share a symmetric key. Both parties wish to use this key to resume the session in the future without having to go through the expensive asymmetric authentication process again.

[0035] A widely used example of this feature is TLS 1.3 session recovery. Compared to previous TLS versions, TLS version 1.3 offers improved privacy. This is achieved through the use of two features. First, the recovery ticket is sent from the server to the client in encrypted form over the established channel. In this way, an attacker cannot directly link the current session to a future recovery handshake. Second, the ticket period, which will be transmitted in plaintext during the recovery handshake, is obfuscated.

[0036] However, the data transmitted to the server later also includes a static ticket identifier. In a wireless context, wireless devices do not necessarily have to address a specific server / site (e.g., via a domain name), and malicious attackers could easily probe and track the wireless device's ticket. It should be noted that TLS recommends that tickets be used only once, but checking for multiple uses is the server's task, and a malicious server would not perform such checks. Finally, due to the volatile nature of wireless connections, single-use tickets may unnecessarily increase the need for asymmetric authentication as a fallback mechanism due to network outages or other reasons.

[0037] Therefore, it is necessary to send session recovery identifiers in a random manner so that the server can still recover the data indicating the session recovery identifier. This problem can be overcome by the wireless device generating a salt and sending a salted hash of the recovery identifier to the server. In this way, an attacker cannot make different responses from the wireless device correlate with each other as if they came from the same wireless device. The server can then use the salt to hash each recovery identifier stored in its recovery identifier database. The server can then compare the hashed recovery identifier received from the wireless device with the hash of the recovery identifier in its database to determine whether a previous session with the wireless device exists and which session key was used to recover the communication session. One problem with this method is that the entire database of recovery identifiers must be hashed and retrieved until a match is found.

[0038] This method incurs significant computational overhead on the server side to find the corresponding recovery identifier. To address this challenge, the server can store a salt. For example, the server periodically updates the salt based on a strategy of incrementing its salt value. This could include gradually increasing the salt every N transactions or after a specified period of time. This salt is then used to hash all recovery identifiers stored by the server in its database. Then, when the server receives the hashed recovery identifier from the wireless device, it only needs to look it up in the database (or may not find it depending on the specific circumstances). This database lookup is much faster than the database retrieval described above. During the recovery process, the server and the wireless device share the salt.

[0039] When a server selects a salt, a malicious server might repeatedly send the same salt to a wireless device. This could allow the wireless device to be tracked, as its responses will always be identical when the same salt is used for every response. Furthermore, even with safeguards in place to prevent servers from abusing their salt-selection capabilities, this could still compromise the privacy of the wireless device.

[0040] Figure 1A flowchart illustrating the process of resuming a secure communication session between a wireless device and a server is shown. Resumption method 100 begins at 105, where the wireless device sends a message requesting the establishment of a secure communication session for communication with the server, and the wireless device sends a device random number to server 110. In this message, the wireless device indicates whether it wants to resume the previous session and whether it wants to update the symmetric key.

[0041] The server receives a request from the wireless device and determines whether the wireless device has requested to resume the previous session 115. If the wireless device requests resumption, the server responds with its server identifier, server random number, and salt S 120. If no resumption request is made, the server will only establish a brief secure communication channel based on Diffie-Hellman and continue asymmetric mutual authentication with the wireless device 155 to establish a secure communication session. In this case, the server will not explicitly send its server identifier in plaintext.

[0042] Once the wireless device receives the server identifier, server random number, and salt, it checks whether it has a shared key K for communicating with the server based on the server identifier 125. If not, the wireless device performs asymmetric mutual authentication with wireless device 155.

[0043] If the wireless device has a shared key K for communicating with the server, the wireless device checks whether the salt S provided by the server meets the requirements described below regarding the salt threshold T stored with K 130. If not, the wireless device performs asymmetric mutual authentication with wireless device 155.

[0044] If the received salt S meets the specified requirements, the wireless device calculates the salted identifier of the key K, for example, by calculating the hash H(S,K)135.

[0045] When a wireless device requests a new session key, it can establish the new session key based on a server random number, a wireless device random number, a salt S, and a key K140. This can be accomplished using the key derivation function KDF(K, S|device_nonce|server_nonce), where the key derivation function can be any type of key derivation function agreed upon between the wireless device and the server.

[0046] The wireless device responds with a salt identifier and a wireless device random number 145, and the wireless device can start an encrypted session using a new session key (if requested) or an existing session key.

[0047] The server receives a salt identifier and a random number from the wireless device, and searches for the salt identifier in its database 150. If the salt identifier is found, the server can also calculate a new session key if the wireless device requests one, or use the previously established key and participate in the encrypted session. The recovery process then ends at 160.

[0048] If the wireless device requests an update to the symmetric key, both the wireless device and the server update the key value K they have stored.

[0049] Wireless devices need to implement a strategy to prevent probing by malicious attackers. Specifically, wireless devices need to take measures to prevent improper replay of the value S. Therefore, after sending the salted identifier, the wireless device needs to perform a check on the salt S received from the server. Three different methods by which the wireless device checks the validity of the salt value received from the server using a salt threshold T will now be described. When the device and the server agree on a key K, the value T can be established during the first session establishment. At the same time, the server also sends its current value S. S can be an integer that the server increments periodically (e.g., every 5 minutes or every 100 transactions). At that time, the server will also update its salted hash database. The device sets its value T to the received value S.

[0050] In the first method, the wireless device determines whether S ≥ T. If so, T is updated as follows: T = S + 1. If S is not greater than or equal to T, the check for salt S fails, and as described above, the wireless devices perform asymmetric mutual authentication. This method allows for single-use of a given salt value, thereby preventing attackers from replaying previous server responses, as replays of previous server responses are rejected as the salt threshold and salt change.

[0051] The second method introduces a counter and a counter threshold. The counter counts the number of times the current salt value has been used. The counter threshold limits the number of times the salt value can be used. The second method can be described using the following pseudocode:

[0052]

[0053] As shown in the pseudocode, the wireless device determines whether S ≥ T and whether Counter < Counter_Threshold. If so, the counter is incremented by 1. Alternatively, if S > T, T is updated to the value of S, and Counter is reset to zero. Similarly, if Counter equals Counter_Threshold, T is incremented by one (or another agreed-upon value), and the value of Counter is set to 0. As in the first method, if S is not greater than or equal to T, the check for the salt S fails, and as described above, the wireless devices perform asymmetric mutual authentication. This method allows the given salt value to be used multiple times, up to a predetermined number of times specified by Counter_Threshold. Thus, if an attacker replays a previous server response to track the wireless device, they can only do so a limited number of times. Once the attacker probes the wireless device and the wireless device reaches Counter_Threshold, the salt changes, and replays of previous server responses are rejected, thus preventing the attacker from tracking the wireless device.

[0054] The third method introduces a time threshold (Time_Threshold). Time_Threshold provides a time limit for when the salt is valid. This means that wireless devices and servers can track absolute or elapsed time and then compare that time to the time threshold to verify the validity of the current salt. The third method can be described using the following pseudocode:

[0055]

[0056] As shown in the pseudocode, the wireless device determines whether S ≥ T. If so, the wireless device determines whether S > T, and if so, T is updated to the value of S and Current_Time is set to 0. If Current_Time is greater than or equal to Time_Threshold, the wireless device performs asymmetric mutual authentication with the wireless device. As in the first method, if S is not greater than or equal to T, the check for salt S fails, and as described above, the wireless device performs asymmetric mutual authentication with the wireless device. This method allows the given salt value to be used multiple times within a specified time period based on Time_Threshold. Thus, if an attacker replays a previous server response to track the wireless device, they can only do so within a limited time frame. Once the attacker probes the wireless device and the time frame expires, the salt will change and replays of previous server responses will be rejected, thus preventing the attacker from tracking the wireless device.

[0057] In another embodiment, when the salt is invalid, the wireless device can notify the server that the salt is invalid but provide its own salt. The server will then need to use the salt provided by the client to calculate a salted hash of the existing session key and retrieve all these calculated hashes based on the salt provided by the wireless device to find a match. As discussed above, this step will still require significant computation, but it will only occur if there are connectivity issues or the device attempts to connect more frequently than the server updates its database, and it may require less computation compared to performing asymmetric mutual authentication. For example, if the number of database entries is small, updating database entries may require less computation than performing asymmetric mutual authentication. Therefore, the server can determine the number of database entries and then decide whether to update the database or perform asymmetric mutual authentication based on a threshold.

[0058] In another embodiment, the wireless device random number and the server device random number exchanged in the session recovery method as described above are already ephemeral Diffie-Hellman public keys. In this way, if the wireless decides to fall back to an asymmetric authentication protocol, it may have already derived the shared key using Diffie-Hellman key exchange, thus responding cryptographically.

[0059] A recovery method for a wireless communication system with wireless devices and servers is described herein, but the recovery method disclosed herein is not limited to use with wireless devices. The recovery method can also be used in any other communication system where the device needs to challenge multiple servers to restore a secure communication session if an attacker may have access to the communication channel and attempt to track the device.

[0060] Figure 2 An exemplary hardware diagram 200 is shown for implementing a recovery method on a wireless device or server as described above. As shown, device 200 includes a processor 220, a memory 230, a user interface 240, a network interface 250, and a storage device 260 interconnected via one or more system buses 210. It should be understood that, in some aspects, Figure 2 The abstract diagram is constructed, and the actual organization of the components of device 200 may be more complex than shown.

[0061] Processor 220 can be any hardware device capable of executing instructions stored in memory 230 or storage device 260 or otherwise processing data. Therefore, the processor may include a microprocessor, microcontroller, graphics processing unit (GPU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other similar device.

[0062] Memory 230 may include various types of memory, such as L1, L2, or L3 cache memory or system memory. Thus, memory 230 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM), or other similar memory devices.

[0063] User interface 240 may include one or more means for enabling communication with a user as needed. For example, user interface 240 may include a display, touch interface, mouse, and / or keyboard for receiving user commands. In some embodiments, user interface 240 may include a command-line interface or a graphical user interface that can be presented to a remote terminal via network interface 250.

[0064] Network interface 250 may include one or more means for enabling communication with other hardware devices. For example, network interface 250 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol or other communication protocols, including wireless protocols. Additionally, network interface 250 may implement a TCP / IP stack for communication according to the TCP / IP protocol. Various alternative or additional hardware or configurations for network interface 250 will become apparent.

[0065] Storage device 260 may include one or more machine-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, or similar storage media. In various embodiments, storage device 260 may store instructions for execution by processor 220, or it may store data on which processor 220 may operate. For example, storage device 260 may store a basic operating system 261 for controlling various basic operations of hardware 200. Storage device 262 may include instructions for implementing the recovery methods described above.

[0066] It is evident that the various information described as stored in storage device 260 may be additionally or alternatively stored in memory 230. In this respect, memory 230 may also be considered as constituting a "storage device," and storage device 260 may be considered as a "memory." Various other arrangements will be apparent. Furthermore, both memory 230 and storage device 260 may be considered as "non-transitory machine-readable media." As used herein, the term "non-transitory" will be understood to exclude transient signals but include all forms of storage devices, including both volatile and non-volatile memory.

[0067] Although host device 200 is shown as including one of each described component, various components may be repeated in various embodiments. For example, processor 220 may include multiple microprocessors configured to independently perform the methods described herein or configured to perform steps or subroutines of the methods described herein, such that multiple processors cooperate to achieve the functionality described herein. Furthermore, when device 200 is implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 220 may include a first processor in a first server and a second processor in a second server.

[0068] The recovery system and method described herein provide a technical solution to improve the privacy of users of devices attempting to resume secure communication sessions with a server when an attacker has access to the communication channel. Such attackers might attempt to replay messages from the server to the device in order to track the device based on its responses to clearly valid messages. The recovery system and method described herein use varying salt values ​​and thresholds that help determine the validity of the salt used by the server. This varying salt value prevents attackers from effectively using replay attacks to track the device, thereby compromising the device's privacy.

[0069] Any combination of specific software running on a processor to implement embodiments of the present invention constitutes a specific specialized machine.

[0070] As used herein, the term “non-transitory machine-readable storage medium” will be understood to exclude transiently propagated signals but include all forms of volatile and non-volatile memory.

[0071] Those skilled in the art will understand that any block diagram herein represents a conceptual diagram of a schematic circuit system embodying the principles of the present invention.

[0072] While various exemplary embodiments have been described in detail with particular reference to specific exemplary aspects of various exemplary embodiments, it should be understood that the invention is capable of other embodiments and that modifications to the details of the invention are possible in various obvious aspects. Variations and modifications can be made, as will be readily apparent to those skilled in the art, while remaining within the spirit and scope of the invention. Therefore, the foregoing disclosure, description, and drawings are for illustrative purposes only and are not intended to limit the invention in any way, which is defined solely by the claims.

Claims

1. A method for resuming a secure communication session with a server via a device, characterized in that, include: Send a message to the server that requested the resumption of the secure communication session; Receive a server identifier, a server random number, and a salt from the server; Based on the server identifier, it is determined that the device and the server share a key; Confirm that the received salt is valid; A salted identifier is calculated based on the shared key and the salt, wherein the salted identifier is a hash of the salt and the shared key; Send the salted identifier to the server; and Restore the secure communication session with the server.

2. The method according to claim 1, characterized in that, Determining that the received salt is valid also includes: Determine that the salt is greater than or equal to the salt threshold T; and Update the T value to the increment of the salt.

3. The method according to claim 1, characterized in that, Determining that the received salt is valid also includes: It is determined that the salt is greater than or equal to the salt threshold T and the counter is less than the counter threshold; Increase the counter; When the salt concentration is greater than the salt threshold T, the salt threshold T is set to be equal to the salt concentration and the counter is set to 0; and When the counter equals the counter threshold, the salt threshold T is increased and the counter is set to 0.

4. The method according to claim 1, characterized in that, Determining that the received salt is valid also includes: The salt is determined to be greater than or equal to the salt threshold T; When the salt concentration is greater than the salt threshold T, the salt threshold T is set to be equal to the salt concentration, and the current time is set to 0; and When the current time is greater than or equal to the time threshold, asymmetric mutual authentication is performed.

5. The method according to claim 1, characterized in that, This also includes establishing a new session key.

6. A method for resuming a secure communication session with a device via a server, characterized in that, include: Salted identifiers are stored in a server database, wherein the salted identifiers are based on a shared key and a salt; Receive a message from the device that requests the resumption of a secure communication session; Send a server identifier, a server random number, and the salt to the device, wherein the salt is a valid salt; Receive a salted identifier from the device, wherein the salted identifier is a hash of the salt and the shared key; It was determined that the received salted identifier matched in the server database; and Resume the secure communication session with the device.

7. The method according to claim 6, characterized in that, The salt is updated based on the strategy for increasing the salt content.

8. An apparatus configured to resume a secure communication session with a server, characterized in that, include: Memory; as well as A processor coupled to the memory, wherein the processor is further configured to: Send a message to the server that requested the resumption of the secure communication session; Receive a server identifier, a server random number, and a salt from the server; Based on the server identifier, it is determined that the device and the server share a key; Confirm that the received salt is valid; A salted identifier is calculated based on the shared key and the salt, wherein the salted identifier is a hash of the salt and the shared key; Send the salted identifier to the server; and Restore the secure communication session with the server.

9. A server configured to resume a secure communication session with a device, characterized in that, include: Memory; A processor coupled to the memory, wherein the processor is further configured to: Salted identifiers are stored in a server database, wherein the salted identifiers are based on a shared key and a salt; Receive a message from the device that requests the resumption of a secure communication session; Send the server identifier, server random number, and salt to the device; Receive a salted identifier from the device, wherein the salted identifier is a hash of the salt and the shared key; Determine if the received salted identifier matches in the server database; and Resume the secure communication session with the device.

Images