Stateless session recovery method, apparatus and device for tlcp protocol

Abstract

This application provides a stateless session recovery method, apparatus, and device for the TLCP protocol. The method includes: determining a second client signature hash value based on a client signature certificate; determining a second client encryption hash value based on a client encryption certificate; determining a second server signature hash value based on a server signature certificate; determining a second server encryption hash value based on a server encryption certificate; if the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then the client's session is recovered, and a TLCP connection is established with the client. The technical solution of this application can save network bandwidth resources, reduce the computing resource consumption of business servers, and significantly shorten the connection establishment time.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, apparatus and device for stateless session recovery using the TLCP protocol. Background Technology

[0002] With the rapid development of information technology, network security is becoming increasingly important, requiring the protection of confidentiality, integrity, and authentication of data transmission. To ensure secure data transmission, the TLCP (Transport Layer Communication Protocol) can be used. TLCP is an autonomous and controllable transport layer security standard used to provide a cryptographic protocol for secure communication. TLCP employs a dual certificate system (signature certificate and encryption certificate) in its cryptographic algorithms and certificate structure.

[0003] Based on the TLCP protocol, the server and client need to perform a complete TLCP handshake process to establish a TLCP connection. Messages are then transmitted between the client and server via this TLCP connection to ensure secure data transmission. However, if the client does not transmit messages for a period of time, the server needs to delete the TLCP connection. Therefore, when the client accesses the server again, both the server and client need to re-execute the complete TLCP handshake process and re-establish the TLCP connection. Clearly, the client needs to re-execute the complete TLCP handshake process every time it accesses the server.

[0004] However, the complete TLCP handshake process requires the server and client to exchange a large number of messages, which consume significant network bandwidth. The server also needs to process these messages, consuming substantial processing resources. Furthermore, the lengthy TLCP handshake process results in a prolonged connection establishment time, requiring the client to wait an extended period before being able to access the server. Summary of the Invention

[0005] This application provides a stateless session recovery method for the TLCP protocol, applied to a business server. The method includes: receiving a TLCP connection recovery request sent by a client, wherein the TLCP connection recovery request includes a encrypted session ticket, a client signature certificate used by the client, and a client encryption certificate.

[0006] The encrypted session ticket is decrypted to obtain a plaintext session ticket; wherein, the plaintext session ticket includes a recovery master key, a session cipher suite, a first client signature hash value, a first client encrypted hash value, a first server signature hash value, and a first server encrypted hash value;

[0007] The second client signature hash value is determined based on the client signature certificate used by the client, and the second client encryption hash value is determined based on the client encryption certificate used by the client.

[0008] The second server signature hash value is determined based on the server signature certificate used by the business server, and the second server encryption hash value is determined based on the server encryption certificate used by the business server.

[0009] If the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then the client's session is restored, a TLCP connection is established with the client, and the recovery master key and the session cipher suite are recorded in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt messages corresponding to the client.

[0010] This application provides a stateless session recovery device for the TLCP protocol. The device is applied to a business server and includes: a communication module for receiving a TLCP connection recovery request sent by a client, the TLCP connection recovery request including a ciphertext session ticket, a client signature certificate used by the client, and a client encryption certificate; a cryptographic module for decrypting the ciphertext session ticket to obtain a plaintext session ticket; wherein the plaintext session ticket includes a recovery master key, a session cipher suite, a first client signature hash value, a first client encryption hash value, a first server signature hash value, and a first server encryption hash value; and a determination module for determining a second client signature hash value based on the client signature certificate used by the client, and determining a second client encryption certificate based on the client encryption certificate used by the client. The first client signature hash value is determined based on the server-side signature certificate used by the business server, and the second server-side encryption hash value is determined based on the server-side encryption certificate used by the business server. A processing module is configured to, if the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then restore the client's session, establish a TLCP connection with the client, and record the recovery master key and the session cipher suite in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt messages corresponding to the client.

[0011] This application provides an electronic device, including: a processor and a machine-readable storage medium, wherein the machine-readable storage medium stores machine-executable instructions that can be executed by the processor; the processor is used to execute the machine-executable instructions to implement the stateless session recovery method for the TLCP protocol described above.

[0012] This application provides a computer program product, including a computer program that, when executed by a processor, implements the above-described stateless session recovery method for the TLCP protocol.

[0013] This application provides a machine-readable storage medium storing machine-executable instructions that can be executed by a processor; wherein the processor is used to execute the machine-executable instructions to implement the aforementioned stateless session recovery method for the TLCP protocol.

[0014] As can be seen from the above technical solutions, in this embodiment, the client sends a TLCP connection recovery request to the service server (i.e., the server). The TLCP connection recovery request includes an encrypted session ticket. The service server decrypts the encrypted session ticket to obtain a plaintext session ticket, and restores the client's session based on the plaintext session ticket, establishing a TLCP connection with the client. It does not require executing the complete TLCP handshake process; instead, it directly restores the client's session. Session recovery allows the client and service server to reuse previously negotiated session parameters in subsequent connections. Because it does not require executing the complete TLCP handshake process, it avoids the exchange of a large number of messages between the service server and the client, saving network bandwidth resources. It also avoids the service server processing a large number of messages, saving processing resources and reducing computational resource consumption. The TLCP connection establishment time is short, significantly reducing connection establishment time and accelerating client access speed.

[0015] This paper proposes a stateless session recovery method designed for the TLCP protocol and associated with a dual-certificate system. This method achieves secure and efficient stateless session recovery within the TLCP protocol, improving its session recovery efficiency and security. It binds the session lifecycle to the lifecycle of the identity credential (certificate). If either party's certificate is changed, revoked, or expires, the plaintext session ticket based on the old certificate will automatically become invalid. This eliminates the risk of unauthorized reuse of old sessions after certificate updates, significantly improving the security of the TLCP protocol and meeting its requirements for strong authentication. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating a stateless session recovery method for the TLCP protocol.

[0017] Figure 2This is a schematic diagram of the communication system in one embodiment of this application;

[0018] Figure 3 This is a flowchart illustrating a stateless session recovery method for the TLCP protocol.

[0019] Figure 4 This is a flowchart illustrating a stateless session recovery method for the TLCP protocol.

[0020] Figure 5 This is a schematic diagram of a stateless session recovery device for the TLCP protocol;

[0021] Figure 6 This is a hardware structure diagram of an electronic device according to one embodiment of this application. Detailed Implementation

[0022] This application proposes a stateless session recovery method for the TLCP protocol. This method can be applied to business servers. See [link to relevant documentation]. Figure 1 The diagram shown is a flowchart of the method, which includes:

[0023] Step 101: Receive the TLCP connection recovery request sent by the client. The TLCP connection recovery request may include the encrypted session ticket, the client signing certificate and the client encryption certificate used by the client.

[0024] Step 102: Decrypt the ciphertext session ticket to obtain the plaintext session ticket; wherein, the plaintext session ticket may include the recovery master key, session cipher suite, first client signature hash value, first client encrypted hash value, first server signature hash value, and first server encrypted hash value.

[0025] Step 103: Determine the second client signature hash value based on the client signature certificate used by the client, and determine the second client encryption hash value based on the client encryption certificate used by the client.

[0026] Step 104: Determine the second server signature hash value based on the server signature certificate used by the business server, and determine the second server encryption hash value based on the server encryption certificate used by the business server.

[0027] Step 105: If the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then the client session is restored, a TLCP connection is established with the client, and the recovery master key and session cipher suite from the plaintext session ticket are recorded in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt the corresponding messages of the client.

[0028] For example, the plaintext session ticket may also include authentication context information. Based on this, after the client's session is restored and a TLCP connection is established with the client, the client's authentication level may be determined based on the authentication context information. Access permissions may be configured for the session based on the authentication level, or a security policy may be configured for the session based on the authentication level, or both access permissions and security policies may be configured for the session based on the authentication level.

[0029] For example, the TLCP connection recovery request may also include the client's temporary public key, and the client has a temporary private key paired with the temporary public key. Based on this, after recording the recovery master key and session cipher suite in the session information, the recovery master key can be encrypted based on the temporary public key to obtain the encrypted recovery master key; a TLCP connection recovery response is sent to the client, which may include the encrypted recovery master key, so that the client can decrypt the encrypted recovery master key based on the temporary private key to obtain the recovery master key; wherein, the client encrypts and decrypts the messages corresponding to the business server based on the recovery master key and the locally stored session cipher suite (i.e., the session cipher suite of the previous session).

[0030] For example, the TLCP connection recovery request may also include a first random number generated by the client. Based on this, after recording the recovery master key and session cipher suite in the session information, an updated recovery master key for session recovery can be generated using a key derivation algorithm based on the first random number, a second random number generated by the business server, and the recovery master key. Then, an updated plaintext session ticket is generated, which includes the updated recovery master key, session cipher suite, first client signature hash value, first client encrypted hash value, first server signature hash value, and first server encrypted hash value. The updated plaintext session ticket can be encrypted to obtain an updated ciphertext session ticket, and a TLCP connection recovery response is sent to the client. The TLCP connection recovery response may include the updated ciphertext session ticket, enabling the client to perform session recovery based on the updated ciphertext session ticket.

[0031] For example, if at least one of the following is true: the first client's signature hash value is different from the second client's signature hash value; the first client's encryption hash value is different from the second client's encryption hash value; the first server's signature hash value is different from the second server's signature hash value; or the first server's encryption hash value is different from the second server's encryption hash value, then the business server and the client execute a complete TLCP handshake process and negotiate session parameters based on the TLCP handshake process. These session parameters may include the target master key and the session cipher suite. The business server establishes a session with the client based on the TLCP handshake process, establishes a TLCP connection with the client, and records the target master key and the session cipher suite in the session information.

[0032] For example, after performing a complete TLCP handshake with the client, if the session parameters also include the client's client signing certificate and client encryption certificate, then a first client signature hash value is determined based on the client's client signing certificate, and a first client encryption hash value is determined based on the client's client encryption certificate; similarly, a first server signature hash value is determined based on the server's server signing certificate, and a first server encryption hash value is determined based on the server's server encryption certificate. If the session parameters also include a third random number generated by the client and a fourth random number generated by the business server, then a recovery master key for session recovery can be generated based on the third random number, the fourth random number, and the target master key using a key derivation algorithm; then, a plaintext session ticket can be generated; wherein, the plaintext session ticket may include the recovery master key, the session cipher suite, the first client signature hash value, the first client encryption hash value, the first server signature hash value, and the first server encryption hash value; the plaintext session ticket is encrypted to obtain a ciphertext session ticket, and the ciphertext session ticket is sent to the client so that the client can perform session recovery based on the ciphertext session ticket.

[0033] For example, after decrypting the encrypted session ticket to obtain the plaintext session ticket, if the plaintext session ticket still has a ticket lifecycle, it is determined whether the current time is within the ticket lifecycle; if so, the operation of determining the second client signature hash value based on the client signature certificate used by the client is performed; if not, the complete TLCP handshake process is performed with the client, and the session parameters are negotiated based on the TLCP handshake process, the client's session is established based on the TLCP handshake process, and a TLCP connection is established with the client.

[0034] As can be seen from the above technical solutions, in this embodiment, the client sends a TLCP connection recovery request to the service server (i.e., the server). The TLCP connection recovery request includes an encrypted session ticket. The service server decrypts the encrypted session ticket to obtain a plaintext session ticket, and restores the client's session based on the plaintext session ticket, establishing a TLCP connection with the client. It does not require executing the complete TLCP handshake process; instead, it directly restores the client's session. Session recovery allows the client and service server to reuse previously negotiated session parameters in subsequent connections. Because it does not require executing the complete TLCP handshake process, it avoids the exchange of a large number of messages between the service server and the client, saving network bandwidth resources. It also avoids the service server processing a large number of messages, saving processing resources and reducing computational resource consumption. The TLCP connection establishment time is short, significantly reducing connection establishment time and accelerating client access speed.

[0035] This paper proposes a stateless session recovery method designed for the TLCP protocol and associated with a dual-certificate system. This method achieves secure and efficient stateless session recovery within the TLCP protocol, improving its session recovery efficiency and security. It binds the session lifecycle to the lifecycle of the identity credential (certificate). If either party's certificate is changed, revoked, or expires, the plaintext session ticket based on the old certificate will automatically become invalid. This eliminates the risk of unauthorized reuse of old sessions after certificate updates, significantly improving the security of the TLCP protocol and meeting its requirements for strong authentication.

[0036] The technical solutions described above in the embodiments of this application will be explained below in conjunction with specific application scenarios.

[0037] TLCP is a self-controlled transport layer security standard. Both the server and client need to perform a complete TLCP handshake to establish a TLCP connection. If the client does not transmit messages for a period of time, the server needs to delete the TLCP connection. When the client accesses the server again, both the server and client need to re-execute the complete TLCP handshake to establish a TLCP connection, and so on. Clearly, the client re-executes the complete TLCP handshake every time it accesses the server. However, the TLCP handshake is complex, involving certificate verification, key negotiation, etc., requiring the server and client to exchange a large number of messages. These messages consume significant network bandwidth and server processing resources, resulting in a long connection establishment time. The TLCP handshake introduces additional communication latency, and the performance overhead is more significant in scenarios with frequent TLCP connection establishment.

[0038] To optimize user experience and system efficiency, session recovery technology has emerged. Session recovery allows clients and servers to reuse previously negotiated session parameters (such as master keys) in subsequent connections, thereby skipping some or even most of the handshake steps, significantly shortening TLCP connection establishment time and reducing resource consumption.

[0039] To enable session recovery, after establishing a TLCP connection based on the TLCP handshake process, the server assigns a session ID to the TLCP connection and stores the mapping between the session ID and session parameters. The server also sends the session ID to the client, which stores it. Thus, each time the client initiates a business request message through the TLCP connection, the message can carry the session ID. The server queries the corresponding session parameters and uses these parameters to encrypt and decrypt the message. Furthermore, even if the client has not transmitted any business request messages for a period of time, the server still needs to store the mapping between the session ID and session parameters when deleting the TLCP connection. This allows the client to send the session ID back to the server when accessing it again. The server can then directly restore the TLCP connection based on the corresponding session parameters, without needing to re-execute the complete TLCP handshake process.

[0040] However, in the above method, even if the server deletes the TLCP connection, the server still needs to store the correspondence between the session identifier and the session parameters, which results in a large overhead on the server. It needs to maintain session parameters for a large number of potential reconnecting clients, consuming a lot of server memory resources.

[0041] To address the above findings, this application proposes a stateless session recovery method for the TLCP protocol, enabling secure and efficient stateless session recovery within the TLCP protocol. In this application, session tickets are tightly integrated with the TLCP protocol's unique dual-certificate system, and the binding relationship of the certificates is effectively verified during the session recovery process, thereby improving the efficiency and security of TLCP session recovery.

[0042] For example, the TLCP protocol employs a dual-certificate system (i.e., a signature certificate and an encryption certificate) in its cryptographic algorithms and certificate system, enabling the tight integration of session tickets with the TLCP-specific dual-certificate system. Regarding the dual-certificate system, the TLCP protocol stipulates that communication entities (such as clients or servers) must hold two asymmetric cryptographic certificates: a signature certificate (e.g., based on the SM2 algorithm, used for digital signatures and authentication) and an encryption certificate (e.g., based on the SM2 algorithm, used for key exchange).

[0043] For example, a client might use a signing certificate and an encryption certificate. The signing certificate is used to implement the signing function, and the encryption certificate is used to implement the encryption function. For ease of distinction, the signing certificate used by the client is called the client-side signing certificate, and the encryption certificate used by the client is called the client-side encryption certificate. Similarly, a server might use a signing certificate and an encryption certificate. The signing certificate is used to implement the signing function, and the encryption certificate is used to implement the encryption function. For ease of distinction, the signing certificate used by the server is called the server-side signing certificate, and the encryption certificate used by the server is called the server-side encryption certificate.

[0044] For example, session resumption is a mechanism that allows communicating parties to reuse previously negotiated cryptographic parameters to skip the full, complex handshake process and quickly rebuild a secure connection. Session resumption can include stateful session resumption and stateless session resumption. Stateful session resumption requires the server to cache each client's session information (session parameters or session state) locally for matching and recovery when the client reconnects. Stateless session resumption involves the server encrypting the session state and sending it to the client for storage, without retaining any information itself. During session recovery, the client returns the encrypted information to the server for decryption, thus restoring the session and achieving "statelessness." This embodiment uses a stateless session resumption method for the TLCP protocol.

[0045] This application proposes a TLCP protocol communication system in its embodiments, see [link to relevant documentation]. Figure 2 The diagram illustrates the structure of this communication system, which may include a client, a service server (i.e., a server providing services to the client), and an application server (optional). For example, the client initiates a TLCP connection request. The client holds a client signing certificate and a client encryption certificate. The client can store and submit encrypted session tickets in subsequent connections, and the client establishes a TLCP connection with the service server. The service server receives TLCP connection requests and establishes a TLCP connection with the client. The service server holds a server signing certificate and a server encryption certificate. The service server is responsible for generating, distributing, and verifying session tickets (such as plaintext or encrypted session tickets). Session tickets can also be called certificate-bound session tickets, i.e., session tickets bound to a certificate. The service server may include a session ticket management module, which is responsible for generating, distributing, and verifying session tickets.

[0046] The application server handles upper-layer business logic (such as user login and transactions). It can obtain the client's authentication context information and send it to the business server. For example, the application server may include an authentication context interface module, which sends the authentication context information to the business server's session ticket management module.

[0047] In the above application scenarios, this application proposes a stateless session recovery method for the TLCP protocol. When the client establishes a TLCP connection for the first time, the service server and the client execute a complete TLCP handshake process, establish the client's session based on the complete TLCP handshake process, and establish a TLCP connection between the service server and the client. For the process of establishing the first TLCP connection, see [link to relevant documentation]. Figure 3 The diagram shown illustrates a flowchart of a stateless session recovery method for the TLCP protocol, which includes:

[0048] Step 301: The business server and the client execute a complete TLCP handshake process.

[0049] For example, in a complete TLCP handshake process, hello messages can be exchanged to negotiate cipher suites, random numbers can be exchanged, and a decision can be made regarding session reuse. Necessary parameters can be exchanged, and a pre-master key can be negotiated. Certificates or IBC information can be exchanged for mutual authentication. A master key can be generated using the pre-master key and the exchanged random numbers. Security parameters can be provided to the record layer. The consistency of the security parameters calculated by both parties, and the authenticity and integrity of the handshake process, can be verified. For instance, the business server and client can exchange the following messages to implement the complete TLCP handshake process: Client Hello, Server Hello, Server Certificate, Server Key Exchange, Server HelloDone, Client Key Exchange, the client sends a Change Cipher Spec and an Encrypted Handshake Message, and the business server sends a Change Cipher Spec and an Encrypted Handshake Message.

[0050] In summary, it can be seen that in the complete TLCP handshake process, session parameters can be negotiated. That is, the business server negotiates session parameters based on the TLCP handshake process. These session parameters can include a master key and a cipher suite. The master key is referred to as the target master key, and the cipher suite is referred to as the session cipher suite.

[0051] For example, the target master key and session cipher suite are used to encrypt and decrypt messages corresponding to the client. For messages sent from the client to the business server (i.e., business messages, such as transaction requests), the client encrypts the message using the target master key and session cipher suite, and the business server decrypts the message (i.e., the encrypted message) using the target master key and session cipher suite. Similarly, for messages sent from the business server to the client, the business server encrypts the message using the target master key and session cipher suite, and the client decrypts the message (i.e., the encrypted message) using the target master key and session cipher suite. This embodiment does not impose restrictions on how the target master key and session cipher suite are used for message encryption and decryption.

[0052] For example, after the business server and the client perform a complete TLCP handshake process, the business server establishes a session with the client based on the TLCP handshake process (such as the business server assigning a session identifier to the client, which uniquely represents the session). The business server establishes a TLCP connection with the client, and the business server records the target master key and session cipher suite in the session information.

[0053] For example, based on the TLCP handshake process, the business server establishes a TLCP connection with the client, establishes a client session, and assigns a session identifier to the client, which corresponds to the TLCP connection. The business server records the correspondence between this session identifier and the target master key and session cipher suite in the session information.

[0054] Each time a client sends a message (such as a business request message) through a TLCP connection, the message can carry the session identifier. The server queries the session parameters corresponding to the session identifier, such as the target master key and session cipher suite, and then uses the target master key and session cipher suite to encrypt and decrypt the message.

[0055] In this embodiment, when the client has no message transmission for a period of time, the server, when deleting the TLCP connection, no longer stores the correspondence between the session identifier and the session parameters (target master key and session cipher suite), but instead synchronously deletes the correspondence between the session identifier and the session parameters.

[0056] In summary, in step 301, the service server and the client complete a full TLCP handshake process, which is a TLCP handshake without session recovery. During this TLCP handshake process, the service server and the client negotiate session parameters, which may include the target master key and session cipher suite. These session parameters may also include other content, as detailed in subsequent embodiments.

[0057] Step 302: The business server determines the first client signature hash value based on the client signature certificate used by the client, and determines the first client encryption hash value based on the client encryption certificate used by the client.

[0058] For example, in the TLCP handshake process, the client needs to provide the application server with a client signing certificate and a client encryption certificate; that is, the application server can obtain the client signing certificate and the client encryption certificate. For instance, the client signing certificate and the client encryption certificate can be used as session parameters; that is, session parameters can also include the client signing certificate and the client encryption certificate used by the client. Alternatively, the client signing certificate and the client encryption certificate may not be used as session parameters.

[0059] For example, based on the client-side signing certificate used by the client, the business server can obtain the public key of the client-side signing certificate, and use the public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the client-side signing certificate. This hash value can be recorded as the first client-side signing hash value.

[0060] For example, based on the client's encryption certificate, the business server can obtain the public key of the client's encryption certificate, and use the public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the client's encryption certificate. This hash value can be recorded as the first client encryption hash value.

[0061] Step 303: The business server determines the first server signature hash value based on its own server signature certificate and determines the first server encryption hash value based on its own server encryption certificate.

[0062] For example, based on the server-side signature certificate used by the business server itself, the business server can obtain the public key of the server-side signature certificate, and use the public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the server-side signature certificate. This hash value can be recorded as the first server-side signature hash value.

[0063] For example, based on the server-side encryption certificate used by the business server itself, the business server can obtain the public key of the server-side encryption certificate, and use the public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the server-side encryption certificate. This hash value can be recorded as the first server-side encryption hash value.

[0064] In summary, the business server can obtain the public keys of the four certificates used in this TLCP handshake process (client signing certificate, client encryption certificate, server signing certificate, and server encryption certificate), and use the SM3 algorithm to calculate their hash values, resulting in four certificate hash values: the first client signing hash value, the first client encryption hash value, the first server signing hash value, and the first server encryption hash value.

[0065] Step 304: The business server obtains the authentication context information corresponding to the client. This authentication context information can be the authentication level or other information that can reflect the authentication level, and there are no restrictions on this.

[0066] For example, if the business server authenticates the client, it can directly obtain the client's authentication context information. Alternatively, if the application server authenticates the client, it can obtain the client's authentication context information and send it to the business server, which then retrieves the authentication context information.

[0067] For example, authentication context information refers to information stored in the session ticket that describes the authentication strength or business security level achieved when the initial session is established. For instance, if the client uses a password for authentication, the authentication context information could be authentication level 1, representing the lowest authentication level and indicating password authentication. If the client uses password + SMS authentication, the authentication context information could be authentication level 2, indicating both password and SMS authentication. If the client uses password + ID card authentication, the authentication context information could be authentication level 3, indicating both password and ID card authentication. If the client uses password + ID card + SMS authentication, the authentication context information could be authentication level 4, indicating password, SMS, and ID card authentication. And so on, without any restrictions on the authentication context information.

[0068] Step 305: The business server obtains the recovery master key used for session recovery. For example, the recovery master key can be the master key used in the next session, rather than the master key used in the current session.

[0069] For example, based on the target master key used in the current session, a key derivation algorithm can be used to generate a recovery master key for session recovery. For instance, based on a third random number, a fourth random number, and the target master key, a key derivation algorithm can be used to generate a recovery master key for session recovery.

[0070] During the TLCP handshake process, the application server and client can exchange random numbers. The random number generated by the client can be designated as the third random number, and the random number generated by the application server can be designated as the fourth random number. Therefore, the application server can obtain both the third and fourth random numbers. For example, the third and fourth random numbers can be used as session parameters; that is, session parameters can also include the third and fourth random numbers. Alternatively, the third and fourth random numbers may not be used as session parameters.

[0071] For example, a key derivation function (KDF) based on a specified hash algorithm (such as the SM3 algorithm) can derive a "recovery master key" specifically used for session recovery by taking a third random number, a fourth random number, and the target master key as input. In other words, the business server obtains the recovery master key used for session recovery.

[0072] A Key Derivation Function (KDF) is a cryptographic function used to securely generate one or more new keys from an initial key material, such as a master key.

[0073] Step 306: The business server generates a plaintext session ticket. For example, this plaintext session ticket may include, but is not limited to, the recovery master key, session cipher suite, first client signature hash, first client encrypted hash, first server signature hash, and first server encrypted hash. Optionally, in addition to the above information, the plaintext session ticket may also include authentication context information. Optionally, in addition to the above information, the plaintext session ticket may also include a ticket lifecycle, indicating that the plaintext session ticket is valid within that ticket lifecycle. The ticket lifecycle may include a start time and an end time.

[0074] For example, the business server can construct relevant information into a data structure, which is called a plaintext session ticket. A plaintext session ticket is a certificate-bound session ticket, also known as a certificate-bound session ticket. A plaintext session ticket (Session Ticket) is a data block containing encrypted session state, generated by the business server and stored by the client during stateless session recovery. In this embodiment, it specifically refers to a session ticket generated by the TLCP protocol, while an unencrypted session ticket is called a plaintext session ticket.

[0075] Referring to step 301, the session parameters include the session cipher suite; therefore, the plaintext session ticket includes the cipher suite for this session, i.e., the session cipher suite. Referring to step 305, a recovery master key for session recovery has been generated; therefore, the plaintext session ticket includes the recovery master key. Referring to steps 302 and 303, the first client signature hash, the first client encrypted hash, the first server signature hash, and the first server encrypted hash have been obtained; therefore, the plaintext session ticket includes the first client signature hash, the first client encrypted hash, the first server signature hash, and the first server encrypted hash. Referring to step 304, the authentication context information has been obtained; therefore, the plaintext session ticket includes the authentication context information.

[0076] In addition, the plaintext session ticket may also include a ticket lifecycle. The start time of the ticket lifecycle can be the current time, indicating that the plaintext session ticket is effective from the current time. The interval between the end time and the start time of the ticket lifecycle can be configured according to actual needs, such as 30 minutes, indicating that session recovery is only allowed within 30 minutes. That is, the plaintext session ticket is only used for session recovery within 30 minutes, and session recovery cannot be performed based on the plaintext session ticket after 30 minutes.

[0077] Step 307: The business server encrypts the plaintext session ticket to obtain the ciphertext session ticket.

[0078] For example, the business server can internally store the STEK (Session Ticket Encryption Key). The business server uses the STEK to encrypt the plaintext session ticket to obtain the ciphertext session ticket. For instance, the STEK is a long-term symmetric key used by the business server to encrypt and decrypt all session tickets. The STEK is kept secret by the business server and rotated periodically, and is not disclosed to any client.

[0079] For example, the business server uses the AEAD (Authenticated Encryption with Associated Data) algorithm to encrypt the plaintext session ticket to obtain the ciphertext session ticket. That is, based on the STEK stored internally by the business server, the AEAD algorithm is used to encrypt the plaintext session ticket to obtain the ciphertext session ticket. For example, the AEAD algorithm is an encryption mode that simultaneously provides data confidentiality, integrity, and authenticity, such as SM4-GCM, etc. There are no restrictions on the AEAD algorithm used.

[0080] Step 308: The service server sends the encrypted session ticket to the client so that the client can resume the session based on the encrypted session ticket. For example, after receiving the encrypted session ticket, the client can save the encrypted session ticket and not use it in the current session. In the next session, the client can resume the session based on the encrypted session ticket. The session resumption process can be found in the following embodiments.

[0081] This application proposes a stateless session recovery method for the TLCP protocol. When a client establishes a TLCP connection before its first time, the client's session can be recovered based on encrypted / plaintext session tickets, and the TLCP connection can be recovered based on the same encrypted / plaintext session tickets. See also... Figure 4 The diagram shown is a flowchart of a stateless session recovery method for the TLCP protocol, which may include:

[0082] Step 401: The client sends a TLCP connection restoration request to the service server, and the service server receives the TLCP connection restoration request sent by the client. The TLCP connection restoration request may include a encrypted session ticket, the client's client signing certificate, and the client's client encryption certificate.

[0083] For example, after a client establishes a TLCP connection with a business server, the business server will delete the TLCP connection if the client does not transmit messages for a period of time. When the client accesses the business server again, it wants to quickly reconnect to the TLCP connection, i.e., it needs to quickly restore the session. Therefore, the client sends a TLCP reconnection request to the business server. This TLCP reconnection request can be a Client Hello message. This TLCP reconnection request may include the encrypted session ticket that the client already holds. The client cannot decrypt the encrypted session ticket; it only saves the encrypted session ticket.

[0084] In addition, the TLCP connection recovery request may also include the client's currently used client signing certificate and client's currently used client encryption certificate. Furthermore, the TLCP connection recovery request may also include a client-generated random number, which will be referred to as the first random number.

[0085] Step 402: The business server decrypts the encrypted session ticket to obtain the plaintext session ticket.

[0086] For example, the business server can internally store a STEK (Security Token). The business server uses the STEK to decrypt the encrypted session ticket to obtain the plaintext session ticket. For instance, if the decryption of the encrypted session ticket is successful, step 403 can be executed. If the decryption of the encrypted session ticket fails, step 408 can be executed. For instance, if the STEK stored internally by the business server has been rotated, the decryption of the encrypted session ticket will fail; if the encrypted session ticket has been tampered with, the decryption of the encrypted session ticket will also fail.

[0087] For example, if the encrypted session ticket is successfully decrypted, the business server can obtain the plaintext session ticket. The plaintext session ticket may include, but is not limited to, the recovery master key, session cipher suite, first client signature hash, first client encrypted hash, first server signature hash, and first server encrypted hash. Optionally, in addition to the above information, the plaintext session ticket may also include authentication context information. Optionally, in addition to the above information, the plaintext session ticket may also include the ticket lifecycle.

[0088] Step 403: The business server determines the second client signature hash value based on the client signature certificate used by the client, and determines the second client encryption hash value based on the client encryption certificate used by the client.

[0089] For example, the TLCP connection recovery request includes the client's currently used client signing certificate and the client's currently used client encryption certificate. Based on the client's currently used client signing certificate, the business server can obtain the public key of the client signing certificate, and use this public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the client signing certificate, which can be recorded as the second client signing hash value. Based on the client's currently used client encryption certificate, the business server can obtain the public key of the client encryption certificate, and use this public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the client encryption certificate, which can be recorded as the second client encryption hash value.

[0090] Step 404: The business server determines the second server signature hash value based on the currently used server signature certificate, and determines the second server encryption hash value based on the currently used server encryption certificate.

[0091] For example, based on the server-side signing certificate currently used by the business server, the business server can obtain the public key of the server-side signing certificate, and use this public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the server-side signing certificate. This hash value can be recorded as the second server-side signing hash value. Similarly, based on the server-side encryption certificate currently used by the business server, the business server can obtain the public key of the server-side encryption certificate, and use this public key and a specified hash algorithm (such as the SM3 algorithm) to calculate the hash value of the server-side encryption certificate. This hash value can be recorded as the second server-side encryption hash value.

[0092] In summary, the business server can obtain the public keys of the four currently used certificates (client signing certificate, client encryption certificate, server signing certificate, and server encryption certificate), and use the SM3 algorithm to calculate their hash values, resulting in four certificate hash values: the second client signing hash value, the second client encryption hash value, the second server signing hash value, and the second server encryption hash value.

[0093] Step 405: The business server compares the four sets of certificate hash values. If the comparison results of all certificate hash values ​​are the same, proceed to step 406. If the comparison results of any certificate hash value are different, proceed to step 408.

[0094] For example, the business server can compare a first client signature hash value and a second client signature hash value. The first client signature hash value is parsed from a plaintext session ticket, and the second client signature hash value is determined based on the client's signature certificate. The business server can also compare a first client cryptographic hash value and a second client cryptographic hash value. The first client cryptographic hash value is parsed from a plaintext session ticket, and the second client cryptographic hash value is determined based on the client's cryptographic certificate.

[0095] The business server can compare the first server-side signature hash value and the second server-side signature hash value. The first server-side signature hash value is parsed from the plaintext session ticket, while the second server-side signature hash value is determined based on the server-side signature certificate used by the business server. The business server can also compare the first server-side encrypted hash value and the second server-side encrypted hash value. The first server-side encrypted hash value is parsed from the plaintext session ticket, while the second server-side encrypted hash value is determined based on the server-side encryption certificate used by the business server.

[0096] For example, if the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then it means that the comparison results of all certificate hash values ​​are the same, and step 406 can be executed.

[0097] Alternatively, if at least one of the following is true: the first client signature hash value is different from the second client signature hash value; the first client encryption hash value is different from the second client encryption hash value; the first server signature hash value is different from the second server signature hash value; or the first server encryption hash value is different from the second server encryption hash value, then it means that the comparison result of any certificate hash value is different, and step 408 can be executed.

[0098] Step 406: The business server restores the client's session. The business server establishes a TLCP connection with the client and records the recovery master key and session cipher suite from the plaintext session ticket in the session information. The recovery master key and the session cipher suite are used to encrypt and decrypt the corresponding messages of the client.

[0099] For example, if the first client signature hash value is the same as the second client signature hash value, it means that the client's current client signature certificate is the same as the client signature certificate corresponding to the plaintext session ticket. If the first client encryption hash value is the same as the second client encryption hash value, it means that the client's current client encryption certificate is the same as the client encryption certificate corresponding to the plaintext session ticket. If the first server signature hash value is the same as the second server signature hash value, it means that the business server's current server signature certificate is the same as the server signature certificate corresponding to the plaintext session ticket. If the first server encryption hash value is the same as the second server encryption hash value, it means that the business server's current server encryption certificate is the same as the server encryption certificate corresponding to the plaintext session ticket. In this case, none of the four certificates have changed. Therefore, it is directly determined that the certificate verification is successful, and no further certificate verification is required. That is to say, the complete TLCP handshake process does not need to be executed. The business server directly resumes the client's session, establishes a TLCP connection with the client, and records the session parameters in the session information.

[0100] For example, the business server can obtain session parameters from the plaintext session ticket. These session parameters may include the recovery master key and session cipher suite. The recovery master key and session cipher suite are used to encrypt and decrypt messages corresponding to the client. For messages sent from the client to the business server, the client encrypts the message using the recovery master key and session cipher suite, and the business server decrypts the message (i.e., the encrypted message) using the recovery master key and session cipher suite. For messages sent from the business server to the client, the business server encrypts the message using the recovery master key and session cipher suite, and the client decrypts the message (i.e., the encrypted message) using the recovery master key and session cipher suite.

[0101] For example, when a business server restores a client's session, it establishes a TLCP connection with the client and assigns a session identifier (which uniquely identifies the session). This session identifier corresponds to the TLCP connection. The business server records the mapping between this session identifier and the recovery master key and session cipher suite in the session information. Each time the client sends a message through the TLCP connection, the message can carry this session identifier. The server queries the corresponding session parameters for this session identifier, such as the recovery master key and session cipher suite, and then uses the recovery master key and session cipher suite to encrypt and decrypt the message.

[0102] In summary, in step 406, the business server recovers the client's session based on the plaintext session ticket, establishes a TLCP connection, and obtains session parameters based on the plaintext session ticket. These session parameters may include the recovery master key and the session cipher suite. In this way, the business server uses the "recovery master key" recovered from the plaintext session ticket to complete a short handshake and quickly establish a TLCP connection. The TLCP connection establishment process ends without the need to perform a complex TLCP handshake process.

[0103] In one possible implementation, after resuming the client's session and establishing a TLCP connection with the client, the service server can still determine the client's authentication level based on the authentication context information, since the plaintext session ticket also includes authentication context information. For example, if the authentication context information is the authentication level, the service server directly determines the authentication level. If the authentication context information is other information that reflects the authentication level, the service server can analyze the authentication level based on the authentication context information.

[0104] The application server can configure access permissions for the restored session based on the authentication level, or configure security policies for the restored session based on the authentication level, or configure both access permissions and security policies for the restored session based on the authentication level. For example, for authentication level 1 (which represents the lowest authentication level), the application server can configure the lowest level of access permissions for the session and / or configure the highest level of security policies. For authentication level 4 (which represents the highest authentication level), the application server can configure the highest level of access permissions for the session and / or configure the lowest level of security policies. For authentication levels 2 and 3, the application server can configure intermediate levels of access permissions for the session and / or configure intermediate levels of security policies.

[0105] In one possible implementation, when the client sends a TLCP connection recovery request to the service server, the request may further include a first random number generated by the client. Additionally, the service server may generate a second random number. Based on this, after recording the recovery master key and session cipher suite in the session information, the service server can also generate an updated recovery master key for session recovery using a key derivation algorithm based on the first random number, the second random number, and the recovery master key. In other words, the service server can update the recovery master key to obtain the updated recovery master key.

[0106] For example, a key derivation function (KDF) based on a specified hash algorithm (such as the SM3 algorithm) can derive a "recovery master key" specifically for session recovery by taking a first random number, a second random number, and a recovery master key as input. This means that the business server obtains the updated recovery master key.

[0107] Then, the business server generates an updated plaintext session ticket. The updated plaintext session ticket may include, but is not limited to, the updated recovery master key, session cipher suite (which remains unchanged from the previous session cipher suite), first client signature hash value (which remains unchanged from the previous first client signature hash value), first client encrypted hash value (which remains unchanged from the previous first client encrypted hash value), first server signature hash value (which remains unchanged from the previous first server signature hash value), first server encrypted hash value (which remains unchanged from the previous first server encrypted hash value), authentication context information (which remains unchanged from the previous authentication context information), and ticket lifecycle (the ticket lifecycle needs to be redefined. The start time of the ticket lifecycle can be the current time, and the interval between the end time and the start time of the ticket lifecycle can be configured according to actual needs).

[0108] Then, the business server encrypts the updated plaintext session ticket to obtain the updated ciphertext session ticket. For example, the business server internally stores a STEK (Search Engine Execution Code), and uses the STEK to encrypt the updated plaintext session ticket to obtain the updated ciphertext session ticket. Alternatively, based on the STEK, the AEAD algorithm can be used to encrypt the updated plaintext session ticket to obtain the updated ciphertext session ticket.

[0109] Then, when the service server sends a TLCP connection recovery response to the client, the response may also include an updated encrypted session ticket, enabling the client to resume the session based on the updated ticket. For example, after receiving the updated encrypted session ticket, the client can save it (i.e., replace the previously stored ticket) and not use it in the current session. The next session will then resume based on the updated ticket. The session recovery process can be found in [reference needed]. Figure 4 The process is shown below.

[0110] In one possible implementation, after the business server decrypts the encrypted session ticket to obtain the plaintext session ticket (i.e., after step 402 and before step 403), if the plaintext session ticket also includes a ticket lifecycle, the business server can determine whether the current time is within the ticket lifecycle, i.e., whether the current time is between the start and end times of the ticket lifecycle. If so, step 403 and subsequent steps can be executed, i.e., the operation of determining the second client signature hash value based on the client's client signature certificate can be performed. If not, step 408 can be executed. For example, the business server needs to perform a complete TLCP handshake process with the client, negotiate session parameters based on the TLCP handshake process, establish a session with the client based on the TLCP handshake process, and establish a TLCP connection with the client.

[0111] Step 407: The service server encrypts the recovery master key and session cipher suite based on the temporary public key to obtain the encrypted recovery master key and encrypted session cipher suite. The service server sends a TLCP connection recovery response (i.e., a response message to the TLCP connection recovery request) to the client. This TLCP connection recovery response may include the encrypted recovery master key and encrypted session cipher suite.

[0112] For example, when a client sends a TLCP connection recovery request to a business server, the TLCP connection recovery request may also include the client's temporary public key, and the client has a temporary private key that is paired with the temporary public key. The temporary public key and the temporary private key can be generated by the client itself, and there are no restrictions on the generation method.

[0113] After the business server records the recovery master key and session cipher suite in the session information, it can encrypt the recovery master key using a temporary public key to obtain the encrypted recovery master key. Similarly, the business server can encrypt the session cipher suite using the temporary public key to obtain the encrypted session cipher suite.

[0114] When the business server sends a TLCP recovery response to the client, the TLCP recovery response may include an updated encrypted session ticket. In addition to the updated encrypted session ticket, the TLCP recovery response may also include an encrypted recovery master key and an encrypted session cipher suite.

[0115] The client obtains the encrypted recovery master key and encrypted session cipher suite from the TLCP connection recovery response. The client decrypts the encrypted recovery master key using a temporary private key (a temporary private key paired with a temporary public key), obtaining the recovery master key. The client then decrypts the encrypted session cipher suite using the temporary private key, obtaining the session cipher suite. At this point, the client has the recovery master key and the session cipher suite. The client can then use these two keys to encrypt and decrypt messages from the business server. For example, for a message sent from the client to the business server, the client encrypts the message using the recovery master key and the session cipher suite. For a message sent from the business server to the client, the client decrypts the message using the recovery master key and the session cipher suite.

[0116] In another possible implementation, regarding step 407, the service server encrypts the recovery master key based on the temporary public key to obtain the encrypted recovery master key. The service server sends a TLCP recovery connection response to the client, which may include the encrypted recovery master key. The client obtains the encrypted recovery master key from the TLCP recovery connection response, and decrypts the encrypted recovery master key based on the temporary private key (the temporary private key paired with the temporary public key) to obtain the recovery master key.

[0117] In the previous session, the client not only saved the encrypted session ticket but also the session cipher suite. Thus, after obtaining the recovery master key, the client possesses both the recovery master key and the session cipher suite. At this point, the client can obtain the recovery master key and the session cipher suite, and use these two keys to encrypt and decrypt messages corresponding to the business server.

[0118] In this implementation, since the business server does not need to send session cipher suites to the client, the risk of session cipher suites being leaked is reduced, and the amount of data transmission is reduced, saving bandwidth resources.

[0119] Step 408: The business server and the client execute a complete TLCP handshake process.

[0120] For example, if the first client signature hash value is different from the second client signature hash value, it indicates that the client's current client signature certificate is different from the client signature certificate corresponding to the plaintext session ticket. If the first client encryption hash value is different from the second client encryption hash value, it indicates that the client's current client encryption certificate is different from the client encryption certificate corresponding to the plaintext session ticket. If the first server signature hash value is different from the second server signature hash value, it indicates that the business server's current server signature certificate is different from the server signature certificate corresponding to the plaintext session ticket. If the first server encryption hash value is different from the second server encryption hash value, it indicates that the business server's current server encryption certificate is different from the server encryption certificate corresponding to the plaintext session ticket. In this case, if at least one certificate changes, it can be determined that the certificate verification has failed and the certificate needs to be re-verified. That is, a complete TLCP handshake process needs to be executed to restore the client's session, establish a TLCP connection with the client, and record the session parameters in the session information.

[0121] For example, in a complete TLCP handshake process, session parameters can be negotiated. That is, the business server negotiates session parameters based on the TLCP handshake process, and these session parameters may include the target master key and session cipher suite. After the business server and client execute the complete TLCP handshake process, the business server establishes a session with the client based on the TLCP handshake process, establishes a TLCP connection with the client, and records the target master key and session cipher suite in the session information.

[0122] For example, after the business server and client complete the full TLCP handshake process, if the session parameters also include the client's client signing certificate and client encryption certificate, then a first client signature hash value is determined based on the client's client signing certificate, and a first client encryption hash value is determined based on the client's client encryption certificate; similarly, a first server signature hash value is determined based on the business server's server signing certificate, and a first server encryption hash value is determined based on the business server's server encryption certificate. If the session parameters also include a third random number generated by the client and a fourth random number generated by the business server, then a recovery master key for session recovery can be generated based on the third random number, the fourth random number, and the target master key using a key derivation algorithm. Then, a plaintext session ticket is generated; wherein the plaintext session ticket may include the recovery master key, the session cipher suite, the first client signature hash value, the first client encryption hash value, the first server signature hash value, and the first server encryption hash value; the plaintext session ticket is encrypted to obtain a ciphertext session ticket, and the ciphertext session ticket is sent to the client so that the client can perform session recovery based on the ciphertext session ticket.

[0123] For example, step 408 can be referred to steps 301-308, and will not be repeated here.

[0124] As can be seen from the above technical solutions, in this embodiment, the service server decrypts the encrypted session ticket to obtain a plaintext session ticket, restores the client's session based on the plaintext session ticket, and establishes a TLCP connection with the client. Instead of executing the complete TLCP handshake process, the client's session is directly restored, allowing the client and service server to reuse previously negotiated session parameters in subsequent connections. Because the complete TLCP handshake process is not executed, network bandwidth resources are saved, service server processing resources are saved, and computational resource consumption is reduced. The TLCP connection establishment time is short, significantly shortening the connection establishment time and accelerating client access speed. A stateless session restoration method designed for the TLCP protocol and associated with a dual-certificate system is proposed, achieving secure and efficient stateless session restoration and improving the session restoration efficiency and security of the TLCP protocol. It can bind the session lifecycle to the lifecycle of identity credentials (certificates). If either party's certificate is changed, revoked, or expires, the plaintext session ticket based on the old certificate will automatically become invalid, eliminating the risk of unauthorized reuse of old sessions after certificate updates, greatly improving the security of the TLCP protocol, meeting the TLCP protocol's requirements for strong authentication, and enhancing security.

[0125] The business server encrypts the complete session state using a secret key (STEK) and generates a session ticket, which is sent to the client. The client includes this session ticket on subsequent connections, and the business server decrypts it to restore the session state, without storing any information locally. When restoring a session, the business server can determine the authentication level at the time of session establishment. This allows for differentiated access control for sessions with different authentication levels, improving application flexibility in high-security scenarios. The session recovery process can adapt to a dual-certificate system using the TLCP protocol, including client-side signing certificates, client-side encryption certificates, server-side signing certificates, and server-side encryption certificates. The session ticket effectively carries and verifies the identity information of all four certificates, ensuring that the restored session remains built on the expected certificate trust chain. If the business server's certificate is rotated or the client uses different certificates in different connections, these changes can be effectively identified through the session ticket, avoiding security risks caused by certificate changes. By integrating authentication context information (such as authentication level and permission level) into the session ticket, user authentication or permission verification does not need to be re-performed during rapid session recovery, reducing additional overhead and improving overall system efficiency. In summary, this application provides a stateless session recovery method designed for the TLCP protocol, strongly bound to a dual-certificate system, and capable of carrying authentication context, in order to improve the session recovery efficiency and security of the TLCP protocol.

[0126] For example, a session ticket can include unique identifiers (such as hash values) for both parties' signature certificates and encryption certificates. When resuming a session, the identifiers stored in the session ticket are compared and verified against the identifiers of the certificates used in the current connection, enhancing security. For instance, by forcibly binding the session lifecycle to the lifecycle of identity credentials (certificates), if any certificate of either party is changed, revoked, or expires, the session ticket based on the old certificate will automatically become invalid. This eliminates the risk of old sessions being illegally reused after certificate updates, greatly improving protocol security and fulfilling the requirements for strong authentication.

[0127] For example, designing a standardized session ticket structure and processing flow oriented towards cryptographic algorithms, using the Key Derivation Function (KDF) of the SM3 algorithm to generate the recovery master key, and using the SM4-GCM algorithm to authenticate and encrypt tickets containing session state, can achieve standardization and compatibility, and ensure security and controllability. Regarding standardization and compatibility, it fills the gap in the TLCP protocol for stateless session recovery, providing a standardized technical solution that is fully compatible with the cryptographic algorithm system.

[0128] For example, an authentication context mechanism that can transmit upper-layer business information can be introduced into the session ticket. The session ticket's data structure includes an authentication context field, providing an interface that allows upper-layer application servers to write authentication context information into this field. When the business server resumes the session, it executes differentiated security policies based on the value of this field. This enhances application flexibility and security: by bridging the security state of the communication layer with that of the business layer, the business server can "remember" the initial authentication strength of the session and grant different permissions accordingly after the session resumes, achieving fine-grained access control. It has significant practical value: in fields with high security requirements, such as the Industrial Internet, it can significantly improve user experience (high-security sessions allow passwordless operation) and system security (low-security sessions are restricted), demonstrating extremely high application value.

[0129] Based on the same application concept as the above method, this application proposes a stateless session recovery device for the TLCP protocol. The device is applied to a service server. See [link to relevant documentation]. Figure 5 The diagram shown is a structural schematic of the stateless session recovery device for the TLCP protocol. The device may include:

[0130] The communication module 51 is used to receive a TLCP connection recovery request sent by the client. The TLCP connection recovery request includes a ciphertext session ticket, a client signature certificate used by the client, and a client encryption certificate.

[0131] The cryptographic module 52 is used to decrypt the ciphertext session ticket to obtain a plaintext session ticket; wherein, the plaintext session ticket includes a recovery master key, a session cipher suite, a first client signature hash value, a first client encrypted hash value, a first server signature hash value, and a first server encrypted hash value;

[0132] The determining module 53 is used to determine a second client signature hash value based on the client signature certificate used by the client, and to determine a second client encryption hash value based on the client encryption certificate used by the client; and to determine a second server signature hash value based on the server signature certificate used by the business server, and to determine a second server encryption hash value based on the server encryption certificate used by the business server.

[0133] The processing module 54 is configured to, if the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then restore the client's session, establish a TLCP connection with the client, and record the recovery master key and the session cipher suite in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt messages corresponding to the client.

[0134] For example, the plaintext session ticket also includes authentication context information, and the processing module 54 is further configured to determine the authentication level of the client based on the authentication context information; configure access permissions for the session based on the authentication level, or configure security policies for the session based on the authentication level, or configure access permissions and security policies for the session based on the authentication level.

[0135] For example, the TLCP recovery connection request includes the client's temporary public key, and the client has a temporary private key paired with the temporary public key; the cryptographic module 52 is further configured to encrypt the recovery master key based on the temporary public key to obtain an encrypted recovery master key; the communication module 51 is further configured to send a TLCP recovery connection response to the client, the TLCP recovery connection response including the encrypted recovery master key, so that the client decrypts the encrypted recovery master key based on the temporary private key to obtain the recovery master key; wherein, the client encrypts and decrypts the message corresponding to the business server based on the recovery master key and a locally stored session cipher suite.

[0136] For example, the TLCP connection recovery request includes a first random number generated by the client. The processing module 54 is further configured to generate an updated recovery master key for session recovery based on the first random number, a second random number generated by the service server, and the recovery master key using a key derivation algorithm; generate an updated plaintext session ticket, which includes the updated recovery master key, the session cipher suite, the first client signature hash value, the first client encryption hash value, the first server signature hash value, and the first server encryption hash value; the cryptographic module 52 is further configured to encrypt the updated plaintext session ticket to obtain an updated ciphertext session ticket; the communication module 51 is further configured to send a TLCP connection recovery response to the client, which includes the updated ciphertext session ticket, so that the client can perform session recovery based on the updated ciphertext session ticket.

[0137] For example, the processing module 54 is further configured to: if at least one of the following is true: the first client signature hash value is different from the second client signature hash value; the first client encryption hash value is different from the second client encryption hash value; the first server signature hash value is different from the second server signature hash value; or the first server encryption hash value is different from the second server encryption hash value; then perform a complete TLCP handshake process with the client and negotiate session parameters based on the TLCP handshake process; wherein the session parameters include a target master key and a session cipher suite; and establish a session with the client based on the TLCP handshake process, establish a TLCP connection with the client, and record the target master key and the session cipher suite in the session information.

[0138] For example, the determining module 53 is further configured to, if the session parameters also include a client signing certificate and a client encryption certificate used by the client, determine a first client signature hash value based on the client signing certificate used by the client, and determine a first client encryption hash value based on the client encryption certificate used by the client; determine a first server signature hash value based on the server signing certificate used by the business server, and determine a first server encryption hash value based on the server encryption certificate used by the business server; the processing module 54 is further configured to, if the session parameters also include a third random number generated by the client and a fourth random number generated by the business server, determine a first client signature hash value based on the client signing certificate and a fourth random number generated by the business server; The third random number, the fourth random number, and the target master key are used to generate a recovery master key for session recovery using a key derivation algorithm; a plaintext session ticket is generated; wherein, the plaintext session ticket includes the recovery master key, the session cipher suite, the first client signature hash value, the first client encryption hash value, the first server signature hash value, and the first server encryption hash value; the cryptographic module 52 is further used to encrypt the plaintext session ticket to obtain a ciphertext session ticket; the communication module 51 is further used to send the ciphertext session ticket to the client so that the client can perform session recovery based on the ciphertext session ticket.

[0139] For example, the determining module 53 is further configured to determine whether the current time is within the ticket lifecycle if the plaintext session ticket still includes a ticket lifecycle; if so, perform the operation of determining the second client signature hash value based on the client signature certificate used by the client; the processing module 54 is further configured to perform a complete TLCP handshake process with the client if the current time is not within the ticket lifecycle, negotiate session parameters based on the TLCP handshake process, establish a session with the client based on the TLCP handshake process, and establish a TLCP connection with the client.

[0140] Based on the same concept as the above method, this application proposes an electronic device (such as a business server), see [link to relevant documentation]. Figure 6 As shown, it includes: a processor 61 and a machine-readable storage medium 62, the machine-readable storage medium 62 storing machine-executable instructions that can be executed by the processor 61; the processor 61 is used to execute the machine-executable instructions to implement the stateless session recovery method for the TLCP protocol described above.

[0141] Based on the same application concept as the above method, this application embodiment also provides a machine-readable storage medium storing a plurality of computer instructions, which, when executed by a processor, can implement the above-described stateless session recovery method for the TLCP protocol.

[0142] Based on the same application concept as the above method, this application embodiment also provides a computer program product, which may include a computer program; wherein, when the computer program is executed by a processor, it implements the above-described stateless session recovery method for the TLCP protocol.

[0143] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0144] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A stateless session recovery method for the Transport Layer Cryptography (TLCP) protocol, characterized in that, The method is applied to a business server, and the method includes: Receive a TLCP connection recovery request sent by the client, the TLCP connection recovery request including a encrypted session ticket, the client's client signing certificate and client encryption certificate; The encrypted session ticket is decrypted to obtain a plaintext session ticket; wherein, the plaintext session ticket includes a recovery master key, a session cipher suite, a first client signature hash value, a first client encrypted hash value, a first server signature hash value, and a first server encrypted hash value; The second client signature hash value is determined based on the client signature certificate used by the client, and the second client encryption hash value is determined based on the client encryption certificate used by the client. The second server signature hash value is determined based on the server signature certificate used by the business server, and the second server encryption hash value is determined based on the server encryption certificate used by the business server. If the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then the client's session is restored, a TLCP connection is established with the client, and the recovery master key and the session cipher suite are recorded in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt messages corresponding to the client.

2. The method according to claim 1, characterized in that, The plaintext session ticket also includes authentication context information. After resuming the client's session and establishing a TLCP connection with the client, the method further includes: The authentication level of the client is determined based on the authentication context information; access permissions are configured for the session based on the authentication level, or a security policy is configured for the session based on the authentication level, or both access permissions and a security policy are configured for the session based on the authentication level.

3. The method according to claim 1, characterized in that, The TLCP connection recovery request includes the client's temporary public key, and the client has a temporary private key that is paired with the temporary public key; After recording the recovery master key and the session cipher suite in the session information, the method further includes: The recovery master key is encrypted using the temporary public key to obtain the encrypted recovery master key; A TLCP recovery connection response is sent to the client, the TLCP recovery connection response including an encrypted recovery master key, so that the client can decrypt the encrypted recovery master key based on the temporary private key to obtain the recovery master key; wherein, the client encrypts and decrypts the messages corresponding to the business server based on the recovery master key and a locally stored session cipher suite.

4. The method according to claim 1, characterized in that, The TLCP connection recovery request includes a first random number generated by the client. After recording the recovery master key and the session cipher suite in the session information, the method further includes: Based on the first random number, the second random number generated by the business server, and the recovery master key, an updated recovery master key for session recovery is generated using a key derivation algorithm; Generate an updated plaintext session ticket, the updated plaintext session ticket including the updated recovery master key, the session cipher suite, the first client signature hash value, the first client cryptographic hash value, the first server signature hash value, and the first server cryptographic hash value; The updated plaintext session ticket is encrypted to obtain an updated ciphertext session ticket, and a TLCP connection recovery response is sent to the client. The TLCP connection recovery response includes the updated ciphertext session ticket, so that the client can perform session recovery based on the updated ciphertext session ticket.

5. The method according to claim 1, characterized in that, If at least one of the following is true: the first client signature hash value is different from the second client signature hash value; the first client encryption hash value is different from the second client encryption hash value; the first server signature hash value is different from the second server signature hash value; or the first server encryption hash value is different from the second server encryption hash value, the method further includes: Perform a complete TLCP handshake process with the client and negotiate session parameters based on the TLCP handshake process; wherein, the session parameters include the target master key and the session cipher suite; A session is established for the client based on the TLCP handshake process, a TLCP connection is established with the client, and the target master key and the session cipher suite are recorded in the session information.

6. The method according to claim 5, characterized in that, After performing the complete TLCP handshake process with the client, the method further includes: If the session parameters also include the client signing certificate and the client encryption certificate used by the client, then the first client signature hash value is determined based on the client signing certificate used by the client, and the first client encryption hash value is determined based on the client encryption certificate used by the client. The first server signature hash value is determined based on the server signature certificate used by the business server, and the first server encryption hash value is determined based on the server encryption certificate used by the business server. If the session parameters also include a third random number generated by the client and a fourth random number generated by the business server, then a recovery master key for session recovery is generated based on the third random number, the fourth random number, and the target master key using a key derivation algorithm. Generate a plaintext session ticket; wherein the plaintext session ticket includes the recovery master key, the session cipher suite, the first client signature hash value, the first client cryptographic hash value, the first server signature hash value, and the first server cryptographic hash value; The plaintext session ticket is encrypted to obtain a ciphertext session ticket, and the ciphertext session ticket is sent to the client so that the client can resume the session based on the ciphertext session ticket.

7. The method according to claim 1, characterized in that, After decrypting the encrypted session ticket to obtain the plaintext session ticket, the method further includes: If the plaintext session ticket also includes a ticket lifecycle, then determine whether the current time is within the ticket lifecycle; if yes, then perform the operation of determining the second client signature hash value based on the client signature certificate used by the client; if no, then perform a complete TLCP handshake process with the client, negotiate session parameters based on the TLCP handshake process, establish a session with the client based on the TLCP handshake process, and establish a TLCP connection with the client.

8. A stateless session recovery device for the Transport Layer Cryptography (TLCP) protocol, characterized in that, The device is used in a business server, and the device includes: The communication module is used to receive a TLCP connection recovery request sent by the client. The TLCP connection recovery request includes a encrypted session ticket, a client signature certificate used by the client, and a client encryption certificate. The cryptographic module is used to decrypt the ciphertext session ticket to obtain a plaintext session ticket; wherein, the plaintext session ticket includes a recovery master key, a session cipher suite, a first client signature hash value, a first client encrypted hash value, a first server signature hash value, and a first server encrypted hash value; The determining module is used to determine a second client signature hash value based on the client signature certificate used by the client, and to determine a second client encryption hash value based on the client encryption certificate used by the client; and to determine a second server signature hash value based on the server signature certificate used by the business server, and to determine a second server encryption hash value based on the server encryption certificate used by the business server. The processing module is configured to, if the first client signature hash value is the same as the second client signature hash value, the first client encryption hash value is the same as the second client encryption hash value, the first server signature hash value is the same as the second server signature hash value, and the first server encryption hash value is the same as the second server encryption hash value, then restore the client's session, establish a TLCP connection with the client, and record the recovery master key and the session cipher suite in the session information; wherein, the recovery master key and the session cipher suite are used to encrypt and decrypt messages corresponding to the client.

9. The apparatus according to claim 8, characterized in that, The plaintext session ticket also includes authentication context information. The processing module is further configured to determine the authentication level of the client based on the authentication context information; configure access permissions for the session based on the authentication level, or configure security policies for the session based on the authentication level, or configure both access permissions and security policies for the session based on the authentication level.

10. An electronic device, characterized in that, include: A processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor; The processor is configured to execute machine-executable instructions to implement the method of any one of claims 1-7.

Images