KR102577882B1 - Tls session recovery method using paired token - Google Patents

Abstract

The TLS session recovery method using a paired token of the present invention is a method of recovering a TLS session between a client and a server, wherein the server uses a server secret key to create a public token and a secret token - the secret token is disclosed to the public without expiration date information. generating a pair token of - generated by repeatedly signing tokens, and transmitting the pair token to the client; The client receiving the pair token, decrypting it, and storing it in an internal auxiliary memory; The client calculates one-time authentication information from the client, which is a hash-based message encryption code, using the current time and the pair token, and transmitting the public token, the current time, and one-time authentication information from the client to the server; When the server receives the public token, current time, and one-time authentication information from the client, it calculates a secret token using the current time and the public token, and sends a hash-based message using the current time, public token, and secret token. Calculating one-time authentication information from the server, which is an encryption code; Comparing, by the server, one-time authentication information from the client and one-time authentication information from the server; and the client or the server calculating a one-time PSK using the public token, the current time, a secret token, and a mutually agreed upon string.

Description

TLS session recovery method using paired token {TLS SESSION RECOVERY METHOD USING PAIRED TOKEN}

The present invention relates to a TLS session recovery method using a twin token. More specifically, the server issues a twin token to a client on which a full handshake has been completed and sets and uses a time-based one-time session key based on the twin token. This method relates to a TLS session recovery method using a pair token, which has the characteristic of allowing the same pair token to be used multiple times during its validity period.

TLS (transport layer security) protocol, a transport layer security protocol, is the most basic security protocol widely used to protect communications on the Internet.

TLS largely consists of a handshake protocol and a record protocol. Through the handshake protocol, a certificate is used to confirm each other's identity, and a session secret key to be used for message encryption is generated. Through the record protocol, all subsequent communication contents are encrypted and protected using the session secret key.

The handshake protocol is divided into full handshake and session resumption.

Full handshake involves the client and server connecting for the first time mutually authenticating each other and generating a session secret key using the Diffie-Hellman key exchange method, which requires 1 to 2 rounds of communication and requires a large amount of calculation on the server.

Session recovery refers to quickly recovering a secure session by reusing the shared session secret key as a result of a previously performed full handshake.

There are two methods according to the prior art used for TLS session recovery.

According to the first method, the server stores the session secret key in the DB, generates a Session ID and issues it to the client so that it can be read again. When the client presents the Session ID to the server and requests session recovery, the server can read the session secret key from the DB and reuse it. This method requires the server to manage a large session secret key DB and read it from the DB every time a connection request is made, so the communication burden is high and performance problems occur when the number of users increases.

According to the second method, the server generates a session ticket encrypting information related to the session secret key with a secret key that only the server has and issues it to the client. When the client presents a session ticket to the server and requests session recovery, the server can decrypt the session ticket and recover the session. This method is an efficient method that allows the server to quickly recover a session using only the information provided by the client without directly managing the session secret key for each client.

Public Patent No. 10-2020-0145775 Method and device for providing communication services Registered Patent No. 10-2057159 Authentication of client device based on entropy from server or other device

However, the session recovery technique using session tickets has the following problems. Since the same session secret key is used repeatedly during its validity period, problems may arise in terms of security. In other words, if the same session secret key is used multiple times during the validity period, there is a possibility that the session secret key will be leaked, and because the same information is sent to the server multiple times, an attacker can track the user's activities.

The purpose of the present invention is to solve the problem of the same session secret key being used multiple times through a session ticket as described above and to provide a more efficient TLS session recovery method.

In addition, the present invention provides a TLS session recovery method using a twin token in which the server can confirm trust in the client using the twin token without the need to store information about the client and can generate and use a time-based one-time session key. There is another purpose.

The TLS session recovery method using a paired token of the present invention is a method of recovering a TLS session between a client and a server, wherein the server uses a server secret key to create a public token and a secret token - the secret token is disclosed to the public without expiration date information. generating a pair token of - generated by repeatedly signing tokens, and transmitting the pair token to the client through an encrypted channel; The client receiving the pair token, decrypting it, and storing it in an internal auxiliary memory; The client calculates one-time authentication information from the client using the current time and the pair token, and transmitting the public token, current time, and one-time authentication information to the server; When the server receives the public token, current time, and one-time authentication information from the client, it calculates a secret token using the public token, and calculates one-time authentication information from the server using the current time, public token, and secret token. steps; Comparing, by the server, one-time authentication information from the client and one-time authentication information from the server; The client or the server calculating a one-time PSK (Pre-shared key, session key) using the public token, current time, secret token, and a mutually agreed upon string; the client or server transmitting encrypted application level data using the one-time PSK; and the client or server decrypting the application level data using the one-time PSK.

In addition, the TLS session recovery method using a paired token of the present invention is a method of recovering a TLS session between a client and a server, wherein the server uses a server secret key to create a public token and a secret token - the secret token is validity period information. Generating a pair token of -generated by repeatedly signing the public token without using the public token, and transmitting the pair token to the client through an encrypted channel; The client receiving the pair token, decrypting it, and storing it in an internal auxiliary memory; The client calculates one-time authentication information from the first client using the current time, the pair token, and the temporary DH public key from the client, and uses the public token, the current time, the temporary DH public key from the client, and the one-time authentication from the first client. transmitting information to the server; When the server receives the public token, current time, temporary DH public key from the client, and one-time authentication information from the client, it calculates a secret token using the current time and the public token, and calculates the secret token using the current time, public token, and secret token. , and calculating one-time authentication information from the first server using the temporary DH public key from the client; The server determines whether the one-time authentication information from the first client matches the one-time authentication information from the first server, and if the one-time authentication information from the first client matches the one-time authentication information from the first server, the server Generates a temporary DH public key from the server, calculates one-time authentication information from the second server using the current time, temporary DH public key from the client, temporary DH public key from the server, and pair token, and uses the public token, the current transmitting the time, a temporary DH public key from a client, a temporary DH public key from a server, and one-time authentication information from a second server to the client; The client calculating one-time authentication information from a second client using the current time, the temporary DH public key from the client, the temporary DH public key from the server, and the pair token; The client determines whether the one-time authentication information from the second client and the one-time authentication information from the second server match, and if the one-time authentication information from the second client and the one-time authentication information from the second server match, the client Alternatively, the server calculates a one-time PSK using the public token, current time, secret token, temporary DH public key from the client, temporary DH public key from the server, and a mutually agreed upon string; the client or server transmitting encrypted application level data using the one-time PSK; and the server or client decrypting the application level data using the one-time PSK.

According to the TLS session recovery method using a pair token of the present invention, time-based one-time session key setting is provided using a pair token during session recovery, so the same pair token can be used multiple times for session recovery over a longer period of time, It can satisfy basic security features such as resistance to replay attacks and resistance to denial-of-service attacks. With the use of anonymous pair tokens and secure pair token updates, the session recovery protocol provides privacy, non-traceability, and forward security. It can provide enormous performance gains and easy scalability with the help of stateless services in a large-scale distributed service environment, and can be used safely for a longer period of time without exposing a single secret token.

This method has the following advantages compared to session secret key recovery using existing session tickets.

The secret token is confidential information shared between the client and the server, and is not used directly as a secret key for communication encryption, but is used by generating a one-time session secret key based on the secret token and the current time. Therefore, it can be used safely for a longer period of time without exposing a single secret token.

Server management is simplified as there is no need to manage whether session tickets can be reused. In addition, twin tokens can be updated efficiently. Inside the currently established encryption channel, the server can issue a new pair token and update it. Using this method, the client uses a new pair token each time, preventing privacy issues caused by attacker tracking.

1 is a schematic diagram of a TLS session establishment system between a client and a server according to an embodiment of the present invention;
Figure 2 is a PSK setup procedure in a TLS session using a pair token according to an embodiment of the present invention, and
Figure 3 is a PSK setup procedure in a TLS session using a pair token according to another embodiment of the present invention.

Prior to a detailed description of the present invention, it should be noted that the present invention is capable of various modifications and may have various embodiments, and the examples described below and shown in the drawings are not intended to limit the present invention to specific embodiments. No, it should be understood to include all changes, equivalents, and substitutes included in the spirit and technical scope of the present invention.

When a component is said to be "connected" or "connected" to another component, it is understood that it may be directly connected to or connected to the other component, but that other components may exist in between. It should be. On the other hand, when it is mentioned that a component is “directly connected” or “directly connected” to another component, it should be understood that there are no other components in between.

The terms used in this specification are merely used to describe specific embodiments and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this specification, terms such as “comprise” or “have” are intended to indicate the presence of features, numbers, steps, operations, components, parts, or combinations thereof described in the specification, but are not intended to indicate the presence of one or more other features. It should be understood that this does not exclude in advance the possibility of the existence or addition of elements, numbers, steps, operations, components, parts, or combinations thereof.

In addition, terms such as "... unit", "... unit", and "... module" used in the specification refer to a unit that processes at least one function or operation, which is hardware or software or hardware and It can be implemented through a combination of software.

In addition, when describing with reference to the accompanying drawings, identical components will be assigned the same reference numerals regardless of the reference numerals, and overlapping descriptions thereof will be omitted. In describing the present invention, if it is determined that a detailed description of related known technologies may unnecessarily obscure the gist of the present invention, the detailed description will be omitted.

Figure 1 is a schematic diagram of a TLS session establishment system between a client and a server according to an embodiment of the present invention.

The TLS session establishment system between a client and a server according to an embodiment of the present invention includes a plurality of clients (100: 100-1, 100-2, ..., 100-N) and a TLS server (200). Here, multiple clients (100-1, 100-2, ..., 100-N) are individually connected to the TLS server 200 and are individually authenticated. Therefore, hereinafter, authentication between the individual client 100-1 and the TLS server 200 will be described by way of example.

Here, each client includes a normal operation processing unit, a main memory, an auxiliary memory, and an interface, and the TLS server also includes a normal operation processing unit, a main memory, an auxiliary memory, and an interface.

The TLS server 200 may grant user authentication authority to the client 100-1. In addition, the TLS server 200 may provide various services (eg, information provision service, payment service, etc.) in addition to the authentication service to the client 100-1.

Meanwhile, the TLS server 200 performs a full handshake by performing mutual authentication with the client 100-1 that connects for the first time and generating a session secret key using a method such as Diffie-Hellman key exchange.

If the full handshake is successful, the TLS server 200 issues a paired token (PT) of a public token (Tp) and a secret token (Ts) to the client 100-1.

The client (100-1), which has a pair token, transmits three pieces of information <public token, current time, and one-time authentication value> to the TLS server (200) and requests session recovery.

The TLS server 200, which has received this, 1) checks whether the token it issued is correct from the received public token (Tp), 2) calculates the client's secret token (Ts) from the received public token (Tp), 3) Check whether the received current time information (t) of the client (100-1) matches the current time information of the TLS server (200) within the error range. 4) Whether the received one-time authentication value (auth) is valid. Verify.

Afterwards, the TLS server 200 generates a server-generated one-time session secret key (PSK_S). This is the same as the client-generated one-time session secret key (PSK_C) generated by the client 100-1, allowing mutual encrypted communication to be performed.

When the TLS server 200 performs a full handshake, it issues a pair token (PT) to the client, which is basically the same as the full handshake in TLS 1.3 except that the pair token (PT) is transmitted within the NewSessionTicket message. do. Full handshake includes mandatory server authentication using a server certificate and optional client authentication using a client certificate. The key exchange within the first two movements is used to calculate a shared secret key between the client (100-1) and the TLS server (200), and this shared secret key is used to securely transmit the pair token (PT) to the client (100-1). It is used. The TLS server 200 owns the server secret key (K) used for token issuance and generates a public token (Tp) and a secret token (Ts) as follows.

Here, G _JWT (K, Info) is an abstract notation that expresses the JWT issuance process as a formula.

Meanwhile, the server secret key (K) used when calculating tokens is a secret key owned only by the server and used only for token issuance, and is different from the shared secret key shared between the client and server during a full handshake in TLS.

The TLS server 200 transmits <Tp, Ts> generated using the server secret key (K) to the client 100-1. The user authentication server and client share a shared secret key through a full handshake, and <Tp, Ts> is encrypted with the shared secret key and transmitted. Afterwards, the client 100-1 decrypts it, recovers <Tp, Ts>, and stores it in the internal storage (not shown).

The TLS server 200 may include any client-specific information, such as IP address, OS information, browser information, issuance time, token expiration date, etc., in the public token (Tp) according to its policy. The TLS server 200 generates a public token (Tp) using the server secret key (K), and the validity of the public token (Tp) can be verified only by the TLS server 200, which knows the server secret key (K). do. The secret token (Ts) is generated by signing the public token (Tp) without validity period information, and can be generated only by the TLS server 200.

Since the same Pair Token (PT) will be used multiple times for session recovery during its validity period, the Pair Token (PT) issuance procedure is executed very occasionally within a full handshake. If the client has a valid Pair Token (PT), session recovery using Pair Token (PT) will be more dominant.

If the client has a PT, a secure session key can be established very quickly in a stateless manner using the PT. This procedure is executed on every recovery request and generates a different session key through the same PT that is used repeatedly. According to the present invention, a one-time session secret key (PSK) can be generated in various ways, which are illustrated in FIGS. 2 and 3.

i) Model 1 (single message-type session recovery using paired tokens)

Figure 2 is a PSK setup procedure in a TLS session using a pair token according to an embodiment of the present invention.

According to one embodiment of the present invention, the client 100-1 and the TLS server 200 perform the PSK setting procedure in the TLS session as follows.

First, the client 100-1 transmits a Client Hello message including parameters such as Version, Random Number, Session ID, CipherSuites, and Compression Method to the TLS server 200 (S210). Here, Session ID is set to empty when creating a new session, and CipherSuites and Compression Method indicate a list of encryption parameters supported by the client and an ID for the data compression method.

In response to the Client Hello, the TLS server 200 transmits a Server Hello message containing parameters such as Version, Random Number, Session ID, CipherSuites, and Compression Method selected by the TLS server to the client 100-1 (S215) ).

And, after sending Server Hello, the TLS server 200 may sequentially transmit messages such as Encrypted Extensions, CertificateRequest*, Certificate*, CertificateVerify*, and Finished to the client 100-1 (S220). At this time, “*” indicates optional.

When Finished is input from the TLS server 200, the client 100-1 transmits messages such as Certificate*, CertificateVerify*, and Finished to the TLS server 200 (S225).

When the client 100-1 sends Finished to the TLS server 200, the client and the TLS server are authenticated and have a TLS shared session key. Afterwards, the TLS server issues a pair token so that the client can use it to recover the session.

The TLS server 200 generates a public token (Tp) of Equation 1 and a secret token (Ts) of Equation 2 using the server secret key (K) (S230). The TLS server 200 may include any client-specific information, such as IP address, OS information, browser information, issuance time, token expiration date, etc., in the public token (Tp) according to its policy. The public token (Tp) is signed by the TLS server 200 with the server secret key (K), and its validity can be verified by the TLS server 200 only knowing the server secret key (K). The secret token (Ts) is generated by repeatedly signing the public token (Tp) without validity period information, and can be generated only by the TLS server 200.

The TLS server 200 encrypts the pair token <Tp, Ts> with a TLS session key and transmits it to the client 100-1 (S235). Afterwards, the client 100-1 decrypts it, recovers <Tp, Ts>, and stores it in an internal auxiliary memory (not shown) (S240).

The client 100-1 can request session recovery from the TLS server 200 using the twin token <Tp, Ts> it possesses. The client 100-1 prepares current time information t and calculates one-time authentication information (auth_C) from the client as shown in Equation 3 using the pair token <Tp, Ts> (S245).

Afterwards, the client 100-1 transmits the public token, current time, and one-time authentication information <Tp, t, auth_C> from the client to the TLS server 200 (S250).

When the TLS server 200 receives the public token, current time, and one-time authentication information <Tp, t, auth_C> from the client, the TLS server 200 secures its own current time and determines the time difference from the client's request time t. Check whether it is within the specified tolerance. Additionally, the TLS server 200 can use the server secret key (K) to verify the validity of the public token (Tp) and identify the identity of the client 100-1. And the TLS server 200 calculates the secret token (Ts) of Equation 2 using the server secret key (K) and public token (Tp), and performs the math using the public token (Tp) and secret token (Ts). Calculate one-time authentication information (auth_S) from the server in Equation 4 (S255).

Here, the one-time authentication information (auth_S) from the server is the client's vision-based one-time authentication information (evidence of knowing Ts), and can only be generated by the client (100-1) who knows the secret token (Ts), and its validity is determined by the server secret. It can only be verified by a TLS server that knows the key (K).

The TLS server 200 determines whether the one-time authentication information from the client (auth_C) received from the client 100-1 matches the one-time authentication information from the server (auth_S) calculated by the TLS server (S260), and provides the one-time authentication information from the client. If (auth_C) matches the one-time authentication information from the server (auth_S) you calculated, all authentication is completed successfully.

Afterwards, the client 100-1 and the TLS server 200 each send a public token (Tp), the current time (t), a secret token (Ts), and a mutually agreed upon string (herein denoted as “key”). Calculate the one-time PSK (PSK_C, PSK_S) of Equation 5 (S265-C, S265-S). Here, the one-time PSK from the client (PSK_C) calculated by the client (100-1) and the one-time PSK from the server (PSK_S) calculated by the TLS server (200) are the same value.

Attackers could attempt an attack that retransmits an intercepted protocol message, but the protocol's response from a different perspective is determined to be invalid. Additionally, even if the retransmission attack is determined to be valid, the attacker cannot calculate the one-time PSK and cannot eavesdrop on encrypted communications because he does not have the secret token (Ts).

The TLS server 200 shares the same secret token (Ts) with the client 100-1 in a stateless manner, and the client 100-1 and the TLS server 200 use a one-time use in any pre-agreed manner. PSK can be set.

If the client 100-1 and the TLS server 200 share the same one-time PSK, encrypted communication can be achieved using the one-time PSK if encrypted application level data in the request message is to be transmitted. Meanwhile, the technology for encrypting application-level data using one-time PSK is self-evident to technicians working in the field, so detailed explanation will be omitted.

That is, when the client (100-1) transmits application level data to the TLS server (200) using the one-time PSK (PSK_C) from the client, the TLS server (200) calculates the one-time PSK (PSK_S) from the server to the application level data. Decrypt the data.

This method is useful for session-type encrypted communication that uses a session key for a long time as a single message, one-way, deterministic key setting, but also in an intermittent communication environment with a light client such as an IoT application service, encrypted messages can be used without a session setup process. It is very useful because you can send it directly.

Meanwhile, the PSK establishment procedure in a TLS session using a pair token according to an embodiment of the present invention shown in FIG. 2 does not provide forward security. If a hacker accesses the secret token (Ts) in any way, the hacker will be able to calculate the PSK of all previous sessions during the validity period of the pair token (PT).

ii) Model 2 (Diffie-Hellman type session recovery using paired tokens)

Therefore, in order to obtain omnidirectional security, the protocol can be reconfigured using temporary Diffie-Hellman key exchange. In the PSK establishment procedure in a TLS session using a pair token according to another embodiment of the present invention shown in Figure 3, Diffie-Hellman Forward security is ensured by using Hellman key exchange and verifying one-time authentication information (auth) in both directions.

Since the performing procedures of steps S310 to S325 are the same as the performing procedures of steps S210 to S225 in FIG. 2, detailed description thereof will be omitted and the procedures will be described later.

When the client (100-1) sends Finished to the TLS server (200), the TLS server (200) uses the server secret key (K) to generate the public token (Tp) of Equation 1 and the secret token (Ts) of Equation 2. ) is created (S330).

The TLS server 200 encrypts the generated pair token <Tp, Ts> with a TLS session key and transmits it to the client 100-1 (S335). Afterwards, the client 100-1 decrypts it, recovers the pair token <Tp, Ts>, and stores it in the internal storage (not shown) (S340).

The client 100-1 may request session recovery from the TLS server 200 using the twin token <Tp, Ts> it possesses. The client 100-1 prepares the current time t, generates a client random number (x) and a temporary DH public key from the client (g ^x ), and generates a temporary DH public key from the client (g ^x ) and a pair token <Tp, Using Ts>, one-time authentication information (auth1_C) from the first client is calculated as shown in Equation 6 (S345).

Afterwards, the client 100-1 sends the public token (Tp), current time (t), temporary DH public key from the client (g ^x ), and one-time authentication information (auth1_C) from the first client to the TLS server 200 < Transmit Tp, t, g ^x , auth1_C> (S350).

The TLS server 200 receives a public token (Tp) from the client 100-1, the current time (t), a temporary DH public key from the client (g ^x ), and one-time authentication information (auth1_C) from the first client <Tp, t. , ^g Thereafter, the TLS server 200 can verify the validity of the public token (Tp) using the server secret key (K) and identify the identity of the client 100-1. And the TLS server 200 calculates the secret token (Ts) of Equation 2 using the server secret key (K) and public token (Tp), and uses the public token (Tp) and the temporary DH public key from the client (g ^x ), and the secret token (Ts) is used to calculate one-time authentication information (auth1_S) from the first server as shown in Equation 7 (S355).

Here, the one-time authentication information (auth_S) from the first server is the client's time-based one-time authentication information (evidence of knowing Ts), and can be generated only by the client (100-1) that knows the secret token (Ts), and its validity is It can only be verified by a TLS server that knows the server secret key (K).

The TLS server 200 determines whether the one-time authentication information (auth1_C) from the first client received from the client 100-1 and the one-time authentication information (auth1_S) from the first server match (S360).

If the one-time authentication information (auth1_C) from the first client matches the one-time authentication information (auth1_S) from the first server, a server random number (y) and a temporary DH public key (g ^y ) from the server are generated, and the current time (t) is generated. , one-time authentication information (auth2_S) from the second server using the temporary DH public key ^from the client ( ^g Calculate (S365).

The TLS server 200 generates a public token (Tp), the current time (t), a temporary DH public key from the client (g ^x ), a temporary DH public key from the server (g ^y ), and one-time authentication information from the second server (auth2_S ) <Tp, t, g ^x , g ^y , auth2_S> is transmitted to the client (100-1) (S370).

The client 100-1 receives from the TLS server 200 a public token (Tp), the current time (t), a temporary DH public key from the client (g ^x ), a temporary DH public key from the server (g ^y ), and a second When receiving one-time authentication information (auth2_S) <Tp, t, g ^{x ,} g ^y , auth2_S> from the server, the current time (t), temporary DH public key from the client (g ^y ), and the pair token <Tp, Ts> is used to calculate one-time authentication information (auth2_C) from the second client as shown in Equation 9 (S375).

Here, g ^xy is a Diffie-Hellman shared key value that only the client and TLS server can calculate.

Thereafter, the client 100-1 compares the one-time authentication information from the second server (auth2_S) received from the TLS server 200 with the one-time authentication information from the second client (auth2_C) and provides the one-time authentication information from the second server (auth2_S). ) is verified (S380), and if they match, all authentication is successfully completed.

Afterwards, the client (100-1) and the TLS server (200) each disclose a public token (Tp), the current time (t), a secret token (Ts), a temporary DH public key from the client (g ^x ), and a temporary DH from the server. The free shared key (PSK: PSK_C, PSK_S) of Equation 10 is calculated using the key (g ^y ) and the mutually promised string (“key”) (S385-C, S385-S).

If the client 100-1 and the TLS server 200 share the same one-time PSK, encrypted communication can be achieved using the one-time PSK if encrypted application level data in the request message is to be transmitted.

That is, when the client (100-1) transmits application level data to the TLS server (200) using the one-time PSK (PSK_C) from the client, the TLS server (200) calculates the one-time PSK (PSK_S) from the server to the application level data. Decrypt the data.

The client and server share the same PSK and use the underlying PSK mode functionality of TLS1.3 to calculate a secure session key for the record protocol. This key establishment protocol provides forward security using one additional round of communication.

iii) Model 3 (privacy-providing session recovery using anonymous pair tokens)

2 and 3, the public token (Tp) is transmitted as a client identifier to the server within a plaintext communication channel, so a network hacker can identify the client from communication traffic. If providing the client's privacy is of greater interest than identifying the client, the server can issue an anonymous pair token (PT) without including any information that could publicly identify the client in the public token. If the server needs to identify a client from an anonymous public token (Tp), the server simply maintains a record of the relationship between the client and the issued anonymous public token (Tp). It depends on the server's policy.

If a fixed anonymous pair token (PT) is used over a long period of time, network hackers may attempt to track the behavior of the same client. To provide non-traceability, the server can update the anonymous pair token (PT) upon each session connection. In other words, the server issues a new anonymous pair token (PT) to the same client, and ensures that each anonymous pair token is used only once. Issuing updated twin tokens (PTs) to already authenticated clients through a pre-established safe security channel is not heavy on performance and can be done automatically. If the server maintains a record of updated Pair Tokens (PT), the client's identity can be traced, but network hackers cannot track the updated Pt Tokens (PT). Anonymous pair tokens (PT) issued by the server have no mutual relationship. Therefore, if an anonymous one-time Pair Token (PT) is used and the previous Pair Token (PT) is discarded, forward security can be achieved very easily.

Table 1 compares the characteristics of session tickets and anonymous pair tokens (Model 3), and Table 2 compares the characteristics of Model 1 to Model 3.

Features Session Ticket PT-based (anonymous) Credentials Session Key Secret Token Session Key fixed one-time Multiple Usage Yes Yes Authentication No auth one-time authentication Anti-replay No Yes Anti-DOS No Yes Anti-tracing No Yes Forward security No Yes 0-RTT Yes Yes

Features Model 1 Model 2 Model 3 Forward Security NO Yes Yes Anti-tracing No No Yes Performance High Low Low

The embodiments described in this specification and the accompanying drawings merely illustratively illustrate some of the technical ideas included in the present invention. Accordingly, the embodiments disclosed in this specification are not intended to limit the technical idea of the present invention, but rather to explain it, and therefore, it is obvious that the scope of the technical idea of the present invention is not limited by these embodiments. All modifications and specific embodiments that can be easily inferred by a person skilled in the art within the scope of the technical idea included in the specification and drawings of the present invention should be construed as being included in the scope of the present invention.

100-1, 100-2, ..,100-N: Client
200: TLS server

Claims (6)

In a method for recovering a TLS session between a client and a server,
The server uses the server secret key to generate a pair token of a public token and a secret token - the secret token is generated by repeatedly signing the public token without expiration date information - and sends the pair token to the client through an encryption channel. Transmitting via;
The client receiving the pair token, decrypting it, and storing it in an internal auxiliary memory;
The client calculates one-time authentication information from the client using the current time and the pair token, and transmitting the public token, current time, and one-time authentication information to the server;
When the server receives the public token, current time, and one-time authentication information from the client, it calculates a secret token using the public token, and calculates one-time authentication information from the server using the current time, public token, and secret token. steps;
Comparing, by the server, one-time authentication information from the client and one-time authentication information from the server; and
The client or the server calculates a one-time PSK in a mutually agreed upon manner using the public token, current time, and secret token as input information.
TLS session recovery method using a pair token including.
In claim 1,
A TLS session recovery method using a pair token, characterized in that the one-time authentication information (auth_C) from the client and the one-time PSK are calculated according to the following equation.

Here, t is the current time, Tp is a public token, and Ts is a secret token.

Here, the “key” is a string promised between the client and the server.
In claim 2,
The public token is generated using the server secret key and user authentication information, and the secret token is generated using the server secret key and the public token.
In a method for recovering a TLS session between a client and a server,
The server uses the server secret key to generate a pair token of a public token and a secret token - the secret token is generated by repeatedly signing the public token without expiration date information - and sends the pair token to the client through an encryption channel. Transmitting via;
The client receiving the pair token, decrypting it, and storing it in an internal auxiliary memory;
The client calculates one-time authentication information from the first client using the current time, the pair token, and the temporary DH public key from the client, and uses the public token, the current time, the temporary DH public key from the client, and the one-time authentication from the first client. transmitting information to the server;
When the server receives the public token, current time, temporary DH public key from the client, and one-time authentication information from the client, it calculates a secret token using the current time and the public token, and calculates the secret token using the current time, public token, and secret token. , and calculating one-time authentication information from the first server using the temporary DH public key from the client;
The server determines whether the one-time authentication information from the first client matches the one-time authentication information from the first server, and if the one-time authentication information from the first client matches the one-time authentication information from the first server, the server Generates a temporary DH public key from the server, calculates one-time authentication information from the second server using the current time, temporary DH public key from the client, temporary DH public key from the server, and pair token, and uses the public token, the current transmitting the time, a temporary DH public key from a client, a temporary DH public key from a server, and one-time authentication information from a second server to the client;
The client calculating one-time authentication information from a second client using the current time, the temporary DH public key from the client, the temporary DH public key from the server, and the pair token; and
The client determines whether the one-time authentication information from the second client and the one-time authentication information from the second server match, and if the one-time authentication information from the second client and the one-time authentication information from the second server match, the client Or, the server calculates a one-time PSK in a mutually agreed upon manner using the public token, current time, secret token, temporary DH public key from the client, and temporary DH public key from the server as input information.
TLS session recovery method using a pair token including.
In claim 4,
A TLS session recovery method using a pair token, characterized in that the one-time authentication information (auth1_C) from the first client, the one-time authentication information (auth2_S) from the second server, and the one-time PSK are calculated according to the following equation.

Here, t is the current time, Tp is a public token, Ts is a secret token, and g ^x is a temporary DH public key from the client,

Here, t is the current time, Tp is a public token, Ts is a secret token, and g ^xy is a Diffie-Hellman shared key value that can only be calculated by the client and server,

Here, the “key” is a string promised between the client and the server.
In claim 5,
The public token is generated using the server secret key and user authentication information, and the secret token is generated using the server secret key and the public token.