Method for verifying transport layer security (TLS) certificates, corresponding secure element and server

Abstract

A method for verifying Transport Layer Security (TLS) certificates is disclosed. The method comprises initiating (202) a TLS handshake procedure with the server (11), and during a TLS handshake procedure between the client (10) and the server (11), receiving (204) from the server (11), a NewSessionTicket, after mutual authentication between the client (10) and the server (11). The NewSessionTicket comprises an encrypted current date corresponding to the TLS handshake. The method further comprises initiating (206) a subsequent TLS handshake procedure with the server (11). The subsequent handshake is performed as part of a resumption phase. The method further comprises, during a subsequent handshake procedure between the client (10) and the server (11), performed during the resumption phase, verifying (208) the validity of the certificates of the server (11) based on the encrypted current date.

Description

[0001] Method for verifying Transport Layer Security (TLS) certificates, corresponding secure element and server

[0002] TECHNICAL FIELD

[0003] The disclosure concerns telecommunication and in particular, a client to server communication for providing to the client with an accurate current date of the server. In a specific context of the disclosure, a client is a secure element, like a Subscriber Identity Module (SIM) card, a UICC (Universal Integrated Circuit Card), an eUlCC (embedded UICC) or an iUICC (integrated UICC), cooperating (i.e. communicating with or comprised in) a telecommunication terminal. This terminal can be a smartphone, a tablet, a Personal Digital Assistant (PDA) or a computer for example. However, the disclosure is not limited to these elements.

[0004] BACKGROUND

[0005] It is well known that secure elements, particularly those used in Internet of Things (loT) devices, lack capability to maintain an internal clock such as accurate date, because of their lack of power.

[0006] Secure elements are commonly used to establish secure communications via Transport Layer Security (TLS). For example, they are often employed in authentication processes with a server before exchanging data, for example for authentication on slices. During a TLS handshake, the secure element must validate the server’s certification, comprising checking its validity period to ensure the certificate has not expired.

[0007] The TLS certificates are part of a certificate chain that comprises two types of certificate authorities (CAs): root CAs and intermediate CAs. For a TLS certificate to be trusted, the certificate must be issued by a CA that’s comprised in the trusted store of the device trying to connect.

[0008] If the certificate wasn’t issued by a trusted CA, the connecting device (e.g., a web browser) checks to see if the certificate of the issuing CA was issued by a trusted CA. It continues checking until either a trusted CA is found (at which point a trusted, secure connection will be established), or no trusted CA can be found (at which point the device will usually display an error). Thus, if a trusted CA is ultimately found, the connection is established securely; if not, the connection is rejected.

[0009] The list of Secure Sockets Layer (SSL) certificates, from the root certificate to the end-user certificate, represents the TLS certificate chain. Each certificate can comprise an expiration date. Certificates date can be for example, for two certificates:

[0010] UTCTime '230304030412Z'

[0011] UTCTime '230226030412Z'

[0012] The client (secure element) verifies that the certificate(s) of the server to which it is connecting are still valid, i.e. that it’s certificate has not expired (current date falls within certificate’s validity period).

[0013] Thus, it is necessary that the secure element must have access to a trusted approximate precise date (at least the current day - a certificate having a validity period indicated by a year, a month, a day, minutes and seconds) at which the certificate(s) of the server has expired, in order to validate the certificate expiration.

[0014] One known solution would be to rely on retrieval of the device date (thanks to a PLI proactive command - Provide Local Information) from the device itself. But this date is not trustworthy because this date is configured by the end user on his terminal.

[0015] Another solution is to obtain the date from a Network Time Protocol (NTP) server. While this method can provide a reliable timestamp, it introduces additional network communication, which results in increased power consumption and the delayed TLS sessions.

[0016] SUMMARY

[0017] The present disclosure proposes a solution to these problems.

[0018] The present disclosure proposes a method for verifying Transport Layer Security (TLS) certificates. The method comprises initiating, by the client, a TLS handshake procedure with the server and during the TLS handshake procedure between the client and the server, receiving, by the client from the server, a Session Ticket, after mutual authentication between the client and the server. The Session Ticket comprises an encrypted current date corresponding to the TLS handshake procedure. The method further comprises initiating, by the client, a subsequent TLS handshake procedure with the server. The subsequent handshake is performed as part of a resumption phase. The method further comprises, during the subsequent handshake procedure between the client and the server, performed during the resumption phase, verifying, by the client, the validity of the server’s certificates based on the encrypted current date.

[0019] According to some example embodiments, the client is a secure element being one of: a UICC, or an elllCC, or an iUICC.

[0020] According to some example embodiments, the NewSessionTicket comprises an indicator informing the client that the NewSessionTicket comprises a field comprising said encrypted current date.

[0021] According to some example embodiments, the method further comprises performing, by the client, the mutual authentication between the client and the server during the TLS handshake procedure.

[0022] According to some example embodiments, the encrypted current date comprises a current date encrypted using a working key derived from a shared secret that both client and server know, and wherein the shared secret is derived from a TLS master secret generated as a part of the TLS handshake.

[0023] According to some example embodiments, the method further comprises decrypting, by the client, the encrypted current date contained in the NewSessionTicket, wherein the decrypted data comprises a predefined pattern allowing the client to confirm that the decrypted content corresponds to a valid current date.

[0024] The present disclosure proposes a secure element cooperating with a telecommunication terminal. The secure element is configured for initiating a TLS handshake procedure with the server, during the TLS handshake procedure between said secure element and a server, after mutual authentication between the secure element and the server, receiving, from the server, a NewSessionTicket comprising an encrypted current date corresponding to the TLS handshake procedure. The secure element is configured for initiating a subsequent TLS handshake procedure with the server. The subsequent handshake is performed as part of a resumption phase. The secure element is configured for, during the subsequent handshake procedure between said secure element and said server, performed during the resumption phase, verifying the validity of said server’s certificates based on the encrypted current date.

[0025] The present disclosure proposes a server for verifying Transport Layer Security (TLS) certificates. The server is configured for upon successful mutual authentication between a client and the server, generating a NewSessionTicket, the NewSessionTicket comprising at least an encrypted current date corresponding to a TLS handshake procedure between the client and the server. The server is configured for, during the TLS handshake procedure, sending to the client, the NewSessionTicket.

[0026] BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present disclosure will be better understood by reading the following description of the figures that represent:

[0028] FIG. 1 illustrates a flow diagram representing a Transport Layer Security (TLS) handshake protocol between a Peer (Client) and a Server, in accordance with embodiments of the present disclosure.

[0029] FIG. 2 illustrates a method for verifying Transport Layer Security (TLS) certificates, in accordance with another embodiment of the present disclosure.

[0030] FIG. 3 illustrates an exemplary computing system for implementation of a method for verifying Transport Layer Security (TLS) certificates, in accordance with an exemplary embodiment of the present disclosure.

[0031] Other features and advantages of the disclosure will be described below in view of the unique figure that represents a TLS 1.3 handshake like defined in RFC 8446. DETAILED DESCRIPTION

[0032] Unless the context suggests otherwise, the term “certificate” refers to a digital certificate, which is an electronic document used to authenticate the identity of a communicating entity and to bind that identity to a corresponding key. A certificate typically comprises, but is not limited to, a public key, identifying information of the subject (such as a domain name or organization name), the identity of the certificate issuer (commonly a Certificate Authority), a validity period defined by a start date and an expiration date, and a digital signature created by the issuer. The certificate enables a receiving party to verify the authenticity of the sender and the integrity of the public key through the issuer’s digital signature and corresponding trust chain.

[0033] Unless the context suggests otherwise, the term “handshake” refers to the TLS handshake procedure, which is a cryptographic protocol exchange that occurs between a client and a server at the start of a secure communication session. The handshake involves negotiating security parameters, authenticating one or both parties using digital certificates, and generating shared cryptographic secrets for secure communication. The handshake may comprise an initial handshake and, in certain cases, a resumed handshake as part of a session resumption process.

[0034] In secure communication systems, digital certificates play a crucial role in establishing trust between parties. A digital certificate is an electronic document used to prove the ownership of a public key. It is issued by a trusted entity known as a Certificate Authority (CA) and typically contains key information such as the public key of the subject, the subject's identity (e.g., domain name or organization name), the issuer’s identity, a serial number, a validity period (start and end dates), and the digital signature of the CA. The digital signature binds the subject's identity to the public key, allowing recipients to verify that the certificate has not been altered and is issued by a trusted source.

[0035] Digital certificates are a core component of the Transport Layer Security (TLS) protocol, which secures internet communication. When a client connects to a server (e.g., a browser accessing a website), the server presents its certificate during the TLS handshake. The client verifies this certificate by checking its issuer, ensuring it is not expired or revoked, and validating its digital signature against a list of trusted CAs. If the certificate is valid, the client can proceed with secure communication, confident that the server is authentic. The present disclosure provides a mechanism for the server to securely transmit its current date to the client within the TLS handshake process. This is achieved by embedding an encrypted current date in the TLS NewSessionTicket. The encrypted date is structured in a way that only clients implementing this feature can interpret and use it — thus maintaining full interoperability with legacy systems. By leveraging the secure key material derived from the TLS handshake, the client can decrypt and verify the server’s current date, and use it to validate the server’s certificate even in the absence of an independent time source.

[0036] A TLS session can comprise multiple steps in which the client and server exchange the information necessary for completing the handshake and making further conversation possible. A TLS session is divided into two distinct phases: The handshake and the data exchange.

[0037] During the handshake, the client and the server negotiate the security parameters and the keys that will be used to secure the subsequent data exchanges.

[0038] The latest version of TLS 1.3 (Request For Comments - RFC 8446) maintained by Internet Engineering Task Force's (IETF®) introduces significant improvements in security and performance. TLS provides a way to use certificates for both user and server authentication and for dynamic session key generation.

[0039] FIG. 1 illustrates a flow diagram representing a Transport Layer Security (TLS) handshake protocol between a Peer (Client) and a Server, in accordance with embodiments of the present disclosure. The TLS conversation (i.e. TLS handshake) begins with step 20 by the client. The client sends a TLS ClientHello handshake message. The handshake message can comprise supported protocol versions, cipher suites, key exchange parameters, etc.

[0040] The TLS server 11 , then, at step 21 , responds with TLS server records that can comprise any or a combination of a ServerHello handshake message, TLS encrypted extensions, TLS certificate request, TLS certificate, TLS certificate verify, and TLS Finished.

[0041] At step 22, the TLS client 10 responds to the server with one or more TLS client records comprising a TLS certificate, TLS certificate verify, and TLS Finished message. The TLS Certificate Verify message comprises a digital signature created using the client's private key. This signature proves to the server 11 that the client 10 has the private key corresponding to the public key in the certificate it just sent.

[0042] TLS Finished message is sent by the client to indicate that it has completed its part of the handshake.

[0043] At step 23, if the TLS server 11 authenticates the client successfully, the TLS server sends a TLS NewSessionTicket to the client 10 to allow a TLS resumption at subsequent TLS authentication.

[0044] The full TLS handshake involves the transmission and verification of the server certificate chain on the client and the client certificate chain on the server, which both imposes a serious performance penalty on all applications that require secure communication.

[0045] To help mitigate some of the costs, TLS Session Resumption provides a mechanism to resume or share the same negotiated secret key data across multiple connections. By using an abbreviated handshake, it eliminates the need for a full roundtrip of latency and significantly reduces computational costs for both sides. TLS Session Resumption can be implemented with session identifiers or session ticket mechanisms.

[0046] With TLS 1.3, both methods (session identifiers and session tickets) for session resumption are implemented using the NewSessionTicket. These methods enable the reuse of previously negotiated session data to reduce the overhead associated with full handshakes, thereby improving connection efficiency while maintaining security.

[0047] Method based on Session Identifier

[0048] With session identifiers, the server 11 assigns a random session ID during the initial handshake with the client 10. The server 11 sends the session ID to client 10 within the NewSessionTicket message. Server 11 stores this session ID along with the corresponding session keys and connection states.

[0049] When the client 10 wishes to resume a session, the client 10 sends the stored session ID with the first protocol message (ClientHello) in the identity field to the server 11 . If the server 11 recognizes the connection based on the session ID and chooses to resume the session, it replies with the same session ID and reinstates the stored session parameters. This enables a secure connection to be re-established without re-performing the entire handshake and with no loss of security since the previously negotiated session data are reused.

[0050] Method based on Session Ticket

[0051] The second method eliminates the need for the server 11 to store the per-client session state. Instead, if the client 10 indicates that it supports session tickets, the server 11 can comprise a session ticket, which comprises all of the negotiated session data encrypted with a secret key known only by the server 11 .

[0052] This session ticket generated by the server is then stored by the client 10 and can be used for verification of the certificate in the handshake message of a subsequent session during the resumption phase. Thus, all session data is stored only on the client side, however, the ticket remains secure because it is encrypted with a key known only by the server 11 . This mechanism is thus referred to as the stateless resumption mechanism. The main improvement of stateless resumption lies in the elimination of server-side session cache, which simplifies deployment by merely requiring the client 10 to provide the session ticket on every new connection to the server until the ticket expires.

[0053] Thus, session resumption allows a client and a server to reuse the cryptographic parameters of a previous TLS session, effectively avoiding the need for a full handshake or the repeated transmission and validation of certificate chains.

[0054] In order to indicate the current date to the client 10, the server 11 comprises an additional field in the NewSessionTicket message that can comprise an encrypted current date. This date can be considered as trusted and accurate by the client 10 since it is sent by the server 11 after a mutual authentication between the client 10 and the server 11.

[0055] During a subsequent handshake procedure between the client 10 and the server 11 , performed during a resumption phase, the client 10 decrypts the NewSessionTicket and retrieves the current date value of the previous TLS session. The date is then used by the client to verify the validity of the server’s certificates e.g. the time of initiation of the subsequent session. The precision of the current date provided to the client depends on how frequently the server 11 sends a date to the client 10. For instance, if this frequency is each day i.e. the server comprises the date once per day in the NewSessionTicket, the precision of the date is one day. In such cases, the client will use the previously received date (1 day before) to check the validity of the certificates of the server 11 . However, since digital certificates generally have a long validity period (typically spanning some years), this has no consequent impact on the certification validation.

[0056] It has to be noted that the proposed disclosure is fully interoperable since the client 10 does not recognize that a date field is present in the NewSessionTicket. In such cases, the client will simply ignore it i.e. the client considers a NewSessionTicket as a full opaque ticket for the client 10 that only stores the NewSessionTicket without attempting to interpret its contents and later sends it to the server 11 during the session resumption phase.

[0057] To aid recognition by supporting clients, the NewSessionTicket comprises preferably an indicator informing the client 10 that the NewSessionTicket comprises a field comprising an encrypted current date.

[0058] The date is encrypted with a working key derived from a shared secret. This shared secret is itself derived from the master secret produced during the TLS handshake process. Upon decryption, the decrypted data comprises a defined pattern allowing the client 10 to confirm that the decrypted content is indeed a valid date field in order to maintain interoperability with servers that don’t implement this feature. In other words, this pattern-based validation ensures backward compatibility and interoperability with servers that do not implement this feature, as unsupported clients will simply disregard the additional data.

[0059] In this regard, a client that does not implement this feature will consider the full ticket as opaque and will not be affected by this extra feature (In order to maintain interoperability with secure elements that do not implement this feature).

[0060] A key advantage of the disclosure is that it enables the client 10 to obtain an approximatively accurate current date securely and without requiring any additional data traffic. This supports a first level of certificate validity validation without imposing an extra communication burden. Furthermore, compatibility is preserved with both legacy servers and clients which do not support the feature.

[0061] Additionally, the proposed solution can also be used for non-powered devices such as electronic passports. For example, in a TLS exchange between an electronic passport and a reader, the chip of the passport can then store the Pre-Shared Keys (PSK) and the trusted date provided by the reader. This allows the chip to later validate certificates or timestamps securely, even in the absence of an internal clock or consistent power supply.

[0062] FIG. 2 illustrates a method 200 for verifying Transport Layer Security (TLS) certificates, in accordance with another embodiment of the present disclosure. The method is performed by the client device 10 that comprises a secure element.

[0063] Operations of the method 200, and combinations of the operations in the method 200, may be implemented by, for example, hardware, firmware, a processor, circuitry, and / or a different device associated with the execution of software that comprises one or more computer program instructions. The sequence of operations of the method 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped and performed in the form of a single step, or one operation may have several sub-steps that may be performed in parallel or a sequential manner.

[0064] At step 202, the client 10 initiates a TLS handshake procedure with the server.

[0065] In an embodiment, a mutual authentication is performed between the client 10 and the server 11 during the TLS handshake procedure. In an embodiment, the mutual authentication can comprise verification of identity credentials exchanged between the client 10 and the server 11.

[0066] At step 204, during the TLS handshake procedure between the client 10 and the server 11 , the client receives from the server 11 , a NewSessionTicket, after mutual authentication between the client 10 and the server 11. The NewSessionTicket comprises an encrypted current date corresponding to the TLS handshake procedure.

[0067] At step 206, the client 10 initiates a subsequent TLS handshake procedure with the server 11. The subsequent handshake is performed as part of a resumption phase. In an embodiment, upon initiation of the subsequent TLS handshake procedure between the client

[0068] 10 and the server 11, the client decrypts the encrypted current date contained in the NewSessionTicket. The decrypted data comprises a predefined pattern allowing the client to confirm that the decrypted content corresponds to a valid current date.

[0069] At step 208, during a next the subsequent handshake procedure between the client 10 and the server 11 , performed during the resumption phase, the client 10 verifies the validity of the server

[0070] 11 ’s certificates based on the current date.

[0071] In an embodiment, the client 10 is a secure element being one of: a UICC, or an elllCC, or an iUICC.

[0072] In an embodiment, the NewSessionTicket comprises an indicator informing the client 10 that said NewSessionTicket comprises a field comprising said encrypted current date.

[0073] In an embodiment, the encrypted current date comprises a current date encrypted using a working key derived from a shared secret that both client and server know, and wherein the shared secret is derived from a TLS master secret generated as a part of the TLS handshake.

[0074] FIG. 3 illustrates an exemplary computing system 300 for implementation of a method for verifying Transport Layer Security (TLS) certificates, in accordance with an exemplary embodiment of the present disclosure.

[0075] The computing system 300 may represent, for example, an end device that involves network connection. In an embodiment, the end device may comprise, but not limited to a smart phone, a laptop computer, a desktop computer, a workstation, a portable computer, a handheld, or a mobile device. In an embodiment, the computing system 300 may represent, for example, an end-device with the provision of mobility. Examples of the end-device with the provision of mobility may comprise but not limited to a Telematics Control Unit (TCU), an infotainment system, a Vehicle- to-Everything Device (V2X) device, an On-board Diagnostics Device (OBD), an Advanced Driver Assistance Systems (ADAS) sensor, and the like. The computing system 300 may comprise one or more processors, such as a processor 302 that may be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, the processor 302 is connected to a bus 304 or other communication medium. In an embodiment, examples of processor 302 may comprise, but are not limited to, microcontrollers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), system-on-chip (SoC) components, or any other suitable programmable logic devices, system-on-a-chip processors or other future processors.

[0076] The computing system 300 may also comprise a memory 306 (main memory), for example, Random Access Memory (RAM) or other dynamic memory, for storing information and instructions to be executed by the processor 302. The memory 306 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by the processor 302. The computing system 300 may likewise comprise a read only memory (“ROM”) or other static storage device coupled to bus 304 for storing static information and instructions for the processor 302.

[0077] The computing system 300 may also comprise a storage device 308, which may comprise, for example, a media drive 310 and a removable storage interface 314. The media drive 310 may comprise a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an SD card port, a USB port, a micro- USB, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. A storage media 312 may comprise, for example, a hard disk, magnetic tape, flash drive, or other fixed or removable medium that is read by and written to by the media drive 310. As these examples illustrate, the storage media 312 may comprise a computer-readable storage medium having stored therein particular computer software or data.

[0078] In some embodiments, the storage devices may comprise other similar instrumentalities for allowing computer programs or other instructions or data to be loaded into the computing system 300. Such instrumentalities may comprise, for example, a removable storage unit 314 and a storage unit interface 316, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units and interfaces that allow software and data to be transferred from the removable storage unit 314 to the computing system 300. The computing system 300 may also comprise a communications interface 318. The communications interface 318 may be used to allow software and data to be transferred between the computing system 300 and external devices. Examples of the communications interface 318 may comprise a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port, a micro-USB port), Near field Communication (NFC), etc. Software and data transferred via the communications interface 318 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by the communications interface 318. These signals are provided to the communications interface 318 via a channel 320. The channel 320 may carry signals and may be implemented using a wireless medium, wire or cable, fiber optics, or another communications medium. Some examples of the channel 320 may comprise a phone line, a cellular phone link, an RF link, a Bluetooth link, a network interface, a local or wide area network, and other communications channels.

[0079] The computing system 300 may further comprise Input / Output (I / O) devices 322. Examples may comprise, but are not limited to a display, keypad, microphone, audio speakers, vibrating motor, LED lights, etc. The I / O devices 322 may receive input from a user and also display an output of the computation performed by the processor 302. In this document, the terms “computer program product” and “computer-readable medium” may be used generally to refer to media such as, for example, the memory 306, the storage devices 308, the removable storage unit 314, or signal(s) on the channel 320. These and other forms of computer-readable media may be involved in providing one or more sequences of one or more instructions to the processor 302 for execution. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system 300 to perform features or functions of embodiments of the present disclosure.

[0080] In an embodiment where the elements are implemented using software, the software may be stored in a computer-readable medium and loaded into the computing system 300 using, for example, the removable storage unit 314, the media drive 310 or the communications interface 318. The control logic (in this example, software instructions or computer program code), when executed by the processor 302, causes the processor 302 to perform the functions of the disclosure as described herein.

[0081] Various embodiments of the present disclosure may comprise one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media.

Claims

AMENDED CLAIMS received by the International Bureau on 27 November 2025 (27.11.2025)CLAIMS1. A method (200) for verifying Transport Layer Security (TLS) certificates, said method (200) comprising: initiating (202), by a client (10), a TLS handshake procedure with a server (11); during said TLS handshake procedure between said client (10) and said server (11), receiving (204), by said client (10) from said server (11 ), a NewSessionTicket, after mutual authentication between said client (10) and said server (11), said NewSessionTicket comprising an encrypted current date; decrypting at said client (10) said encrypted current date to obtain a current date; initiating (206), by said client (10), a subsequent TLS handshake procedure with said server (11), said subsequent TLS handshake procedure being performed as part of a resumption phase; and during said subsequent TLS handshake procedure, verifying (208) by said client (10) the validity of certificates of said server (11) based on said current date.

2. The method (200) according to claim 1 , wherein said client (10) is a secure element being one of: a UICC, or an eUlCC, or an iUICC.

3. The method (200) according to claim 1 or 2, wherein said NewSessionTicket comprises an indicator informing said client (10) that said NewSessionTicket comprises a field comprising said encrypted current date.

4. The method (200) according to claim 1 , further comprising performing, by the client (10) the mutual authentication between the client (10) and the server (11) during the TLS handshake procedure.

5. The method (200) according to claim 1, wherein the encrypted current date comprises a current date encrypted using a working key derived from a shared secret that both client and server know, and wherein the shared secret is derived from a TLS master secret generated as a part of the TLS handshake.

6. The method (200) according to claim 1 , further comprising decrypting, by the client (10), the encrypted current date contained in said NewSessionTicket, wherein the decrypted data comprises a predefined pattern allowing the client (10) to confirm that the decrypted content corresponds to a valid current date.

7. A secure element cooperating with a telecommunication terminal, said secure element configured for: initiating a TLS handshake procedure with the server (11); during the TLS handshake procedure between said secure element and a server (11), after mutual authentication between said secure element and said server (11), receiving, from the server (11), a NewSessionTicket comprising an encrypted current date corresponding to the TLS handshake procedure; initiating a subsequent TLS handshake procedure with the server (11), the subsequent handshake being performed as part of a resumption phase; and during the subsequent TLS handshake procedure between said secure element and said server (11), performed during the resumption phase, verifying the validity of said server (11)’s certificates based on the encrypted current date.

Images