Methods for proving and verifying the use of a cipher suite, and associated verification entity, communication devices, terminal and computer program

Abstract

The present invention relates to methods for proving and verifying the use of a cipher suite (CIPHER), and to an associated verification entity (CSC), communication devices (CLT, SRV), terminal and computer program. The proposed method for verifying the use of a cipher suite (CIPHER) for encrypting data (MSG, CH) exchanged between a first device (CLT) and a second device (SRV) is implemented by a verification entity (CSC) and comprises: - sending (E10) a challenge (CH) to the first device (CLT); - reception (E100) of a cipher key (KEY); - reception (E100) of an encrypted challenge (ENC_CH) by the second device (SRV); and - verification (E110) of the use of the suite (CIPHER) using the sent challenge (CH), the received encrypted challenge (ENC_CH), the key (KEY) and the suite (CIPHER).

Description

Description Title of the invention: Methods for proving and verifying the use of a cipher suite, verification entity, communication devices, terminal, and associated computer program Technical field

[0001] The present invention relates to the general field of telecommunications, and more particularly to the fields of computer networks and information security. In particular, the present invention relates to methods for proving and verifying the use of a cipher suite, as well as a verification entity, communication devices, a terminal, a computer program and an associated information medium. The present invention finds a particularly advantageous, although in no way limiting, application for the implementation of devices for orchestrating computer systems, applications and services (or "API orchestrator" in English, with API standing for "Application Programming Interface"). State of the prior art

[0002] The invention is particularly placed in the context of the encryption of communications between two communication devices in a network.

[0003] To secure communications between two communication devices, it is known to use a set of algorithms referred to as a "cipher suite". Typically, the set of algorithms in a cipher suite includes: a key exchange algorithm; a global encryption algorithm; and a message authentication algorithm.

[0004] There are currently a multitude of cipher suites available in the state of the art that can be used to encrypt communications. However, some cipher suites are obsolete and do not guarantee a satisfactory level of security for encrypting communications. Therefore, it is essential to be able to verify that two communication devices are not using an obsolete cipher suite to encrypt their communications.

[0005] However, it appears very complex for a third party entity, for example a security control entity, to verify whether the data exchanged between two communication devices on a network is actually secure. Let's take for example the TLS protocol (acronym for "Transport Layer Security") for securing exchanges over a computer network. So, within the framework of this protocol, reading messages when establishing a connection between two communication devices makes it possible to identify the type of cipher suite announced for the connection. However, this reading alone is insufficient since it does not allow one to prove that the cipher suite possibly used is indeed the one identified, and even if the identification is correct, if the identified suite is actually used by the communication devices during this network connection.

[0006] There is therefore a need for a solution to determine and prove the use of a cipher suite to encrypt data exchanged between two communication devices. Statement of the invention

[0007] The present invention aims to remedy all or part of the drawbacks of the prior art, in particular those set out above.

[0008] According to one aspect of the invention, a method is proposed for verifying the use of a cipher suite for encrypting data exchanged between a first device and a second device in a communication network, the method being implemented by a verification entity and comprising: sending, to the first device, a challenge; receiving, from the first or second device, an encryption key; receiving, from the first or second device, a challenge encrypted by the second device; and verifying the use of the cipher suite using at least the sent challenge, the received encrypted challenge, the encryption key, and the cipher suite.

[0009] For the purposes of the invention, a cipher suite designates one or more algorithms used by communication devices to encrypt and / or decrypt exchanged data. For information purposes, a cipher suite may include: a key exchange algorithm (e.g. Diffie-Helman); an encryption algorithm (e.g. AES); and a message authentication algorithm (e.g. HMAC). It should be noted that a cipher suite is notably defined by an identifier, such as a character string describing the algorithm(s) of this suite.

[0010] In particular, the verifying entity verifies the usage of the cipher suite by verifying that the received encrypted challenge matches the sent challenge encrypted using the encryption key and cipher suite.

[0011] Generally speaking, the proposed method makes it possible to determine and prove the use of a cipher suite to encrypt data exchanged between two communication devices.

[0012] More particularly, the proposed method allows the verification entity to verify the use of the encryption suite to encrypt data exchanged between the first and second devices and, correlatively, allows the first and second devices to provide proof of use of the encryption suite.

[0013] In a particular context of application to the TLS or QUIC protocols, the proposed solution allows a verification entity to verify the use of a cipher suite by communication devices during a connection (i.e. a communication session) between them. Thus, and more generally, the proposed solution allows a third-party entity (e.g. a network operator, a network application orchestrator, etc.) to control the security of exchanges between communication devices (e.g. a user and an application server) during a connection.

[0014] According to one embodiment, the verification entity obtains an identifier of the cipher suite in at least one message sent by the first or second device.

[0015] This embodiment allows the verification entity to obtain the identifier of the cipher suite, then to verify the use of this cipher suite by the first and second devices.

[0016] In this way, it is not necessary for the verification entity to have the identifier of the cipher suite used by the first and second devices beforehand. This embodiment thus makes it possible to avoid requiring preconfiguration of the verification entity.

[0017] According to one embodiment, the verification entity obtains the identifier of the cipher suite in at least one message exchanged between the first and the second device during establishment of a connection, said at least one exchanged message indicating the use of said cipher suite.

[0018] This embodiment makes it possible to identify the announced (i.e. negotiated) encryption suite, when establishing a connection between communication devices, to secure exchanges during a connection.

[0019] For information purposes, the verification entity obtains, according to one embodiment, said at least one message exchanged during the establishment of a connection using a network probe, the network probe capturing this message on the communication network and relaying it to the verification entity.

[0020] According to one embodiment, the verification entity obtains the encryption key and / or the cipher suite in a message sent by the first or second device to destination of the verification entity. For example, according to one embodiment, the first device sends, to the verification entity, a message (hereinafter referred to as proof of encryption) comprising: the challenge encrypted by the second device; the encryption key; and the identifier of the cipher suite.

[0021] However, within the framework of the invention, other embodiments could be envisaged according to which the encryption key and / or the encryption sequence are predetermined, such that the verification entity has these beforehand.

[0022] According to one embodiment, the verification entity implements: obtaining at least one encrypted message exchanged between the first and the second device; decrypting said at least one encrypted message obtained using the encryption key and the encryption suite; and verifying an integrity of said at least one decrypted message using at least one message authentication code associated with said at least one decrypted message.

[0023] For illustrative purposes, the verification entity obtains, according to one embodiment, said at least one encrypted message using a network probe, the network probe capturing said at least one encrypted message on the communication network and relaying it to the verification entity.

[0024] This embodiment is particularly advantageous in that it makes it possible to prove that communication devices actually use a cipher suite to encrypt the exchanged data.

[0025] In particular, this embodiment allows the verification entity to verify that the first and second devices use the cipher suite to encrypt exchanged data.

[0026] It is important to emphasize that, within the framework of the invention, the verification entity can verify the use of the cipher suite: either when establishing the connection between the first and second devices; or during communications (i.e. once the connection has been established) between the first and second devices; or both. Thus, the proposed solution makes it possible to provide proof of the use of a cipher suite by communication devices regardless of the time of the connection.

[0027] Thus, by regularly implementing the proposed solution, it is possible for a third-party entity to verify over time that communication devices actually use the encryption suite.

[0028] According to one embodiment, the verification entity implements: obtaining at least one encrypted message exchanged between the first and the second device, said at least one encrypted message comprising: - application data encrypted using another encryption key, distinct from the encryption key received by the verification entity; and - encrypted padding data using the received encryption key, said padding data comprising the challenge sent to the first device; decrypting said encrypted padding data using the received encryption key and said cipher suite; and verifying a match between the challenge included in said decrypted padding data and the challenge sent to the first device.

[0029] This embodiment allows the verification entity to verify that the cipher suite is used to encrypt the messages exchanged between the first and second devices, while preserving the confidentiality of the application data communicated between these devices.

[0030] The confidentiality of the application data is preserved by using: a first key, known to the verification entity, to encrypt the padding data comprising the challenge; and a second key, distinct from the first and unknown to the verification entity, to encrypt the application data. Thus, according to this embodiment, the verification entity is able to verify the use of the cipher suite by using the encrypted challenge included in the padding data and cannot, however, decrypt the application data.

[0031] More generally, this embodiment allows communication devices to provide proof that they use a cipher suite to encrypt their exchanges without compromising the confidentiality of the application data exchanged.

[0032] According to this embodiment, the verification entity only obtains messages exchanged between the first and second devices comprising an active unencrypted indicator.

[0033] More specifically, the messages exchanged between the first and second devices comprise an unencrypted indicator, either active (e.g. equal to 1) or non-active (e.g. equal to 0), the use of the unencrypted indicator in the exchanged messages being triggered in particular by the receipt of the challenge from the verification entity.

[0034] This embodiment allows the messages to be marked to be processed by the verification entity to verify the use of the cipher suite. In other words, the communication devices mark with an unencrypted indicator the messages allowing the verification entity to verify the use of the cipher suite.

[0035] For example, in combination with the previous embodiment, the first and second devices may mark, with an active unencrypted flag, messages including an encrypted challenge in the data padding and to be captured and relayed to the verification entity by the network probe. In this way, the verification entity obtains and processes only the messages allowing the use of the cipher suite to be verified.

[0036] Thus, this embodiment makes it possible to verify the use of the encryption suite by the first and second communication devices while limiting the number of messages to be processed by the verification entity.

[0037] According to one embodiment, the unencrypted indicator is included in the header of the messages (i.e. packets) exchanged between the first and second devices.

[0038] In particular, according to one embodiment, the QUIC protocol is used to exchange data between the first and second devices and the unencrypted indicator is a bit, called a spin bit, included in the header of the messages (i.e. packets) exchanged between the first and second devices.

[0039] We recall that the spin bit of the QUIC protocol is usually used to measure the communication latency between two communication devices. However, according to the embodiment described here, the spin bit is used to mark the messages to be processed by the verification entity.

[0040] This embodiment is particularly advantageous in that it allows, by diverting the usual function of the spin bit, to mark the messages to be captured by a network probe and relayed to the verification entity to verify the use of the encryption suite, without having to include an additional marker in the exchanged messages.

[0041] According to one embodiment, the verification entity verifies that the identifier of said cipher suite belongs to a list (e.g. white list) of identifiers of cipher suites considered to be valid. Also, the verification entity could, according to one embodiment, verify that the identifier of the cipher suite does not belong to a list (e.g. black list) of identifiers of cipher suites considered to be invalid (e.g. obsolete, insecure, etc.).

[0042] This embodiment makes it possible to verify that a cipher suite used by communication devices complies with defined security rules.

[0043] Thus, this embodiment allows a third-party entity (e.g. a network operator, a network application orchestrator) to control the security of exchanges between communication devices during a connection.

[0044] According to one embodiment, if at least one result of said verification is negative, the verification entity sends an instruction to interrupt the exchanges between the first and the second device. For information purposes, the interruption instruction may in particular be sent to a network control entity (i.e. a network function), and / or to the first device, and / or to the second device.

[0045] This embodiment makes it possible to interrupt communications between the first and second devices if the proof of use of the cipher suite provided by the devices is invalid (i.e. the result of the usage verification is negative) or if the cipher suite used is obsolete. This is to avoid compromising the security of exchanges between the communication devices.

[0046] According to another aspect of the invention, there is provided a method for proving the use of a cipher suite for encrypting data exchanged between a first device and a second device in a communication network, the method being implemented by the first device and comprising: a reception, from a verification entity, of a challenge; a sending, to the second device, of the challenge; a reception, from the second device, of the challenge encrypted by the second device using an encryption key and said cipher suite; and a sending, to the verification entity, of the encrypted challenge.

[0047] According to another aspect of the invention, there is provided a method for proving the use of a cipher suite for encrypting data exchanged between a first device and a second device in a communication network, the method being implemented by the second device and comprising: receiving, from the first device, a challenge; encrypting the challenge using an encryption key and said cipher suite; and sending, to the first device or to a verification entity, the encrypted challenge.

[0048] According to one embodiment, at least one of said first and second devices sends, to the verification entity, a proof of encryption comprising: the encrypted challenge; the encryption key; and an identifier of the cipher suite.

[0049] Within the scope of the invention, other embodiments could also be envisaged according to which the encrypted challenge, the encryption key and the identifier of the cipher suite are sent to the verification entity by the first device and / or the second device in one or more messages.

[0050] According to one embodiment, one of the first and second devices sends to the other device at least one message when establishing a connection between the first and second devices, said at least one exchanged message comprising an identifier of the encryption suite to be used.

[0051] According to one embodiment, at least one of said first and second devices encrypts at least one message using the encryption key and the cipher suite and sends said at least one encrypted message.

[0052] According to one embodiment, at least one of said first and second devices encrypts at least one message and obtains a message authentication code associated with said at least one message.

[0053] According to one embodiment, at least one of said first and second devices encrypts at least one message comprising application data and padding data, the application data being encrypted using another encryption key distinct from the encryption key sent to the verification entity, the padding data comprising the challenge received from the verification entity and being encrypted using the encryption key sent to the verification entity.

[0054] According to one embodiment, at least one of said first and second devices marks with an unencrypted indicator the sent messages to be obtained and processed by the verification entity to verify the use of the encryption suite.

[0055] According to one embodiment, at least one of said first and second devices receives at least one encrypted message and decrypts said at least one encrypted message using the encryption key and the cipher suite.

[0056] According to one embodiment, a TLS-type protocol is used to exchange data between the first and second devices. More specifically, according to one embodiment, the TLS, DTLS, OSCORE, EDHOC, or QUIC protocol is used to exchange data between the first and second devices.

[0057] According to one embodiment, the QUIC protocol is used to exchange data between the first and second devices.

[0058] According to another aspect of the invention, there is provided an entity for verifying the use of a cipher suite for encrypting data exchanged between a first device and a second device in a communication network, the verification entity comprising: a sending module configured to send, to the first device, a challenge; a receiving module configured to receive, from the first or second device, an encryption key and to receive, from the first or second device, a challenge encrypted by the second device; and a verification module configured to verify a use of said cipher suite by using at least the sent challenge, the received encrypted challenge, the encryption key, and said cipher suite.

[0059] According to another aspect of the invention, there is provided a communication device, called first device, comprising: a first reception module configured to receive, from a verification entity, a challenge; a first sending module configured to send, to the second device, the challenge; a second receiving module configured to receive, from the second device, the challenge encrypted by the second device using an encryption key and a cipher suite; and a second sending module configured to send, to the verification entity, the encrypted challenge.

[0060] According to another aspect of the invention, there is provided a communication device, called second device, comprising: a reception module configured to receive, from the first device, a challenge; an encryption module configured to encrypt the challenge using an encryption key and a cipher suite; and a sending module configured to send, to the first device or to a verification entity, the encrypted challenge.

[0061] According to another aspect of the invention, there is provided a terminal comprising a verification entity according to the invention or a communication device according to the invention.

[0062] According to one aspect of the invention, there is provided a computer program comprising instructions for implementing the steps of a method according to the invention, when the computer program is executed by at least one processor or computer.

[0063] The computer program may consist of one or more subparts stored in the same memory or in separate memories. The program may use any programming language, and may be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.

[0064] According to one aspect of the invention, there is provided a computer-readable information medium comprising a computer program according to the invention.

[0065] The information carrier may be any entity or device capable of storing the program. For example, the carrier may comprise a storage means, such as a non-volatile memory or ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a floppy disk or a hard disk. Furthermore, the storage medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by a telecommunications network or by a computer network or by other means. The program according to the invention may in particular be downloaded onto a computer network. Alternatively, the information carrier may be a integrated circuit in which the program is incorporated, the circuit being adapted to carry out or to be used in carrying out the method in question.

[0066] The proposed proof-of-use methods, verification entity, communication devices, terminal, program, and medium have the advantages described above in connection with the proposed usage verification method. Brief description of the drawings

[0067] Other characteristics and advantages of the present invention will emerge from the description provided below, illustrating embodiments of the invention given by way of example and without any limiting character, with reference to the attached drawings:

[0068] Figure 1 represents, in the form of a flowchart, steps of methods of proof and verification of use of a cipher suite according to an embodiment of the invention;

[0069] Figure 2 represents, in the form of a flowchart, steps of methods of proof and verification of use of a cipher suite according to an embodiment of the invention;

[0070] Figure 3A, Figure 3B and Figure 3C represent examples of messages processed and exchanged by the communication devices according to embodiments of the invention;

[0071] Figure 4 shows an example of software and hardware architectures of a verification entity and communication devices according to an embodiment of the invention; and

[0072] Figure 5 represents an example of functional architectures of a verification entity and communication devices according to an embodiment of the invention. Description of the embodiments

[0073] The proposed solution is particularly suited to a context in which a CLT communication device (called the first device) and an SRV communication device (called the second device) exchange data (i.e. messages) in an encrypted manner via a NET communication network. To do this, the CLT and SRV devices encrypt the exchanged data using a CIPHER cipher suite, i.e. the set of algorithms that make it possible to secure the exchanges.

[0074] In this context, it is particularly a question of enabling a CSC verification entity to determine and prove the use of the CIPHER suite to encrypt and decrypt data exchanged between CLT and SRV devices.

[0075] No limitation is attached to the encryption mechanism used to encrypt data exchanged between the CLT and SRV communication devices. For example, the CLT and SRV devices use, according to one embodiment, a symmetric encryption mechanism to encrypt exchanged data.

[0076] There is also no assumption as to the nature of the CSC verification entity and the CLT and SRV communication devices. They may consist of terminal equipment used by the customers of a network operator, such as, for example, a digital decoder (or "Set Top Box" (STB) in English), a user equipment (or "User Equipment" in English), a personal computer (or "PC" in English), a smartphone (or "Smartphone" in English), a connected television or a tablet, but also by equipment managed by an IT operator or an operator of a telecommunications network (for example, server, firewall, router), this equipment being able to be fixed or mobile. Communication devices may also be software applications, or service instances hosted in equipment.

[0077] For information purposes, at least one element among the CSC verification entity and the CLT and SRV devices is, according to one embodiment, implemented by (or included in) a terminal, such as a mobile telephone, for example a Smartphone, or a tablet, or a computer.

[0078] Furthermore, no limitation is attached to the nature of the NET communication network, which may be a mobile telephone network (2G, 3G, 4G, 5G, 6G, etc.), an Internet-type computer network, or any other network (proprietary, etc.) that may be envisaged.

[0079] Figure 1 represents, in the form of a flowchart, steps of methods of proof and verification of use of an encryption suite for encrypting data exchanged between a first and a second communication device according to an embodiment of the invention.

[0080] As illustrated by Figure 1, and according to one embodiment of the invention, the methods of proving and verifying the use of a proposed encryption suite comprise at least one of the steps E10 to E110 described below.

[0081] In step E10, the verification entity CSC sends a CH challenge to the CLT device. For example, the CH challenge is a character string.

[0082] In step E20, the CLT device sends the received CH challenge to the SRV device.

[0083] In step E70, the SRV device encrypts the challenge CH using a cipher suite CIPHER and an encryption key KEY, and thus obtains an encrypted challenge ENC_CH.

[0084] In step E80, the SRV device sends the encrypted challenge ENC_CH to the CLT device.

[0085] In step E100, the CLT device sends, to the verification entity CSC, the key KEY and the encrypted challenge ENC_CH.

[0086] In step E110, the verification entity CSC verifies the usage of the CIPHER suite using the challenge CH, the encrypted challenge ENC_CH, the key KEY and the CIPHER suite.

[0087] According to one embodiment, the verification entity CSC in step E110 verifies that the encrypted challenge ENC_CH corresponds to the encrypted challenge CH using the key KEY and the sequence CIPHER.

[0088] For example, the CSC verification entity decrypts the encrypted challenge ENC_CH and then compares the obtained decrypted challenge to the sent CH challenge. If the obtained decrypted challenge is identical to the sent CH challenge, then the CIPHER suite was indeed used by the SRV device to encrypt the CH challenge; otherwise, the verification result is negative and the use of the CIPHER suite has not been proven.

[0089] Thus, the proposed solution described here allows the CSC verification entity to verify that the SRV device uses the CIPHER suite to encrypt the CH challenge and, correlatively, allows this SRV device to provide proof of use of the CIPHER suite.

[0090] More generally, and as described below, the proposed solution allows the CSC verification entity to verify the use of the CIPHER suite to encrypt data exchanged between the CLT and SRV devices and, correlatively, allows the CLT and SRV devices to provide proof of use of the CIPHER suite.

[0091] Figure 2 represents, in the form of a flowchart, steps of methods of proof and verification of use of a cipher suite according to an embodiment of the invention.

[0092] Examples of application to the TLS or OUIC protocol: Figure 2 illustrates, by way of example, an embodiment of the invention in a particular application context according to which one of the TLS, DTLS, OSCORE, EDHOC or QUIC protocols is used to exchange data between the CLT and SRV devices. The exemplary embodiment provided below repeats, in this respect, the steps described with reference to Figure 1 in this particular application context.

[0093] In this example, the CLT device (eg the TLS / QUIC protocol client) initiates and establishes a connection (or communication session) with the SRV device (eg the TLS / QUIC protocol server), to exchange data securely.

[0094] We refer here to TLS as at least one of the following versions of the Transport Layer Security protocol: TLS 1.0 as defined by RFC 2246 in January 1999; TLS 1.1 as defined by RFC 4346 in April 2006; TLS 1.2 as defined by RFC 5246 in August 2008; or TLS 1.3 as defined by RFC 8446 in August 2018.

[0095] We refer here to at least one of the following versions of the Datagram Transport Layer Security protocol by the acronym DTLS: DTLS 1.2 as defined by RFC 6347; or DTLS 1.3 as defined by RFC 9147.

[0096] Here we refer to the acronym OSCORE as the “Object Security for Constrained RESTful Environments” protocol as defined by RFC8613.

[0097] We use the acronym EDHOC to designate the protocol, used in particular for Internet of Things terminals, as “Ephemeral Diffie-Hellman Over COSE” as defined in the document “draft-ietf-lake-edhoc-15” published by the “Internet Engineering Task Force” and accessible at the following link: https: / / datatracker.ietf.org / doc / draft-ietf-lake-edhoc / .

[0098] And, by the term QUIC, we mean at least one of the versions of the QUIC transport protocol as defined by: RFC 8999 in May 2021; RFC 9000 in May 2021; RFC 9001 in May 2021; RFC 9002 in May 2021; RFC 9221 in March 2022.

[0099] Establishing a connection between the CLT and SRV devices: As illustrated by Figure 2, and according to one embodiment of the invention, the methods of proving and verifying the use of a proposed encryption suite comprise at least one of the steps E10 to E120 described below.

[0100] In step E10, the verification entity CSC sends a CH challenge to the CLT device.

[0101] In step E11, according to a particular embodiment, the CLT device activates the use of an unencrypted SPINBIT indicator for the messages exchanged with the SRV device, this activation being triggered by the reception of the CH challenge in step E10. The use of this SPINBIT indicator is described in more detail below with reference to FIG. 3B.

[0102] In step E20, the CLT device sends, to the SRV device, a CLT_HELLO message to initiate a connection with the latter. The CLT_HELLO message comprises the challenge CH, received from the verification entity CSC. Furthermore, the CLT_HELLO message comprises, according to one embodiment: the identifier(s) of the cipher suites that can be used by the CLT device; and a string of random bytes (called “client random” in English).

[0103] In step E30, the SRV device sends, to the CLT device, an SRV_HELLO message in response to the CLT_HELLO message. More particularly, the SRV_HELLO message comprises, according to one embodiment: an identifier of the CIPHER cipher suite chosen by the SRV device for the connection; and another random string of bytes (called “server random” in English). According to a particular embodiment, the SRV_HELLO message further comprises a parameter for obtaining an encryption key, used for example by the Diffie-Helman key exchange algorithm to obtain an encryption key.

[0104] It is worth noting that the SRV_HELLO message thus indicates to use the CIPHER suite to encrypt and decrypt the data exchanged between the CLT and SRV devices during the connection.

[0105] More precisely, a CIPHER suite is defined by an identifier describing the algorithms in the suite. An example of a cipher suite identifier is: TLS_DH_RSA_WITH_AES_256_GCM_SHA384. The meaning of this identifier is as follows: TLS defines the protocol for which this cipher suite is intended; DH indicates the key exchange algorithm used; RSA is the authentication mechanism used when establishing the connection; AES is the cipher used during the connection; 256 (bits) is the size of the encryption key; GCM is the cipher type; SHA is the hash function used for the message authentication mechanism; and 384 (bits) is the size of the digest used to sign messages.

[0106] In step E31, according to a particular embodiment, the CSC verification entity obtains the SRV_HELLO message. The CSC verification entity thus obtains the identifier of the CIPHER suite used by the CLT and SRV devices during the connection. The CSC verification entity obtains, according to one embodiment, the SRV_HELLO message using a network probe which captures this message on the NET network and relays it to the CSC verification entity.

[0107] In step E40, the CLT device sends, to the SRV device, a CLT_KEY_EXG message comprising: according to one embodiment, a premaster secret; or according to another embodiment a key obtaining parameter.

[0108] In step E50, the CLT and SRV devices respectively obtain a key KEY for the connection (also called a session key). For example, the CLT and SRV devices use a key exchange and derivation algorithm, such as Diffie-Hellman, to obtain the key KEY from the client random, the server random and the aforementioned key obtaining parameters. According to another example, the CLT and SRV devices obtain the key KEY from the client random, the server random and the pre-master secret.

[0109] In step E60, the CLT device sends, to the SRV device, an encrypted message CLT_FSH using the key KEY and the sequence CIPHER. According to one embodiment, following receipt of the CLT_FSH message, the SRV device decrypts this message using the key KEY, then verifies the integrity of the decrypted message. Thus, the SRV device verifies that the CLT device has correctly obtained the same key KEY.

[0110] In step E70, the SRV device encrypts the challenge CH, received from the CLT device, using the key KEY and the sequence CIPHER and thus obtains an encrypted challenge ENC_CH. [YES] In step E80, the SRV device sends, to the CLT device, the encrypted challenge ENC_CH. More particularly, the SRV device adds, according to one embodiment, the encrypted challenge ENC_CH to a message sent to the CLT device and comprising a session ticket.

[0112] In step E90, the SRV device sends, to the CLT device, an SRV_FSH message encrypted using the key KEY and the CIPHER sequence. According to one embodiment, following receipt of the SRV_FSH message, the CLT device decrypts this message using the key KEY, then verifies the integrity of the decrypted message. Thus, the CLT device verifies that the SRV device has correctly obtained the same key KEY.

[0113] Within the framework of the invention, an embodiment could also be envisaged according to which steps E80 and E90 are carried out concomitantly.

[0114] In one embodiment, steps E20 to E90 constitute an establishment of the HSK connection (or “handshake” in English) between the CLT and SRV devices.

[0115] We recall that the invention applies in particular to the TLS, DTLS, OSCORE, EDHOC and QUIC protocols, such that the CLT and SRV devices can establish a connection in accordance with these protocols and, as such, can implement any step necessary to reestablish the connection.

[0116] According to a particular embodiment, the verification entity CSC obtains, in particular by using the network probe, all or part of the messages exchanged between the CLT and SRV devices during the establishment of the HSK connection, for example by using a network probe as described above with reference to step E31.

[0117] In step E100, the CLT device sends, to the verification entity CSC, an encryption proof PRF comprising: the encryption key KEY; the encrypted challenge ENC_CH; and the identifier of the CIPHER suite. The encryption proof PRF further comprises, according to one embodiment, the challenge CH. According to a particular embodiment, the verification entity CSC obtains the key KEY and the identifier of the CIPHER suite by receiving the encryption proof PRF. However, other embodiments of the invention could be envisaged in which the key KEY and / or the CIPHER suite are predetermined or are obtained by the verification entity CSC using a network probe in one or more messages exchanged between the CLT and SRV devices, for example as described with reference to step E31.

[0118] In step E110, the verification entity CSC verifies the use of the CIPHER suite using the PRF encryption proof. According to one embodiment, step E110 comprises at least one of steps E111 and E12 described below.

[0119] In step Elll, the verification entity CSC verifies that the encryption proof PRF is valid. More specifically, the verification entity CSC verifies in step Elll that the encrypted challenge ENC_CH matches the challenge CH encrypted using the key KEY and the sequence CIPHER.

[0120] In step E112, the verification entity CSC verifies the validity of the CIPHER suite, in particular by verifying that the identifier of the CIPHER suite belongs to a list of identifiers of cipher suites considered to be valid (i.e. considered to comply with defined security rules). The verification entity CSC could also, according to one embodiment, verify in step E112 that the identifier of the CIPHER suite does not belong to a list (e.g. blacklist) of identifiers of cipher suites considered to be invalid (e.g. obsolete, insecure, etc.). Step E112 thus makes it possible to verify that the CIPHER suite used complies with the defined security rules.

[0121] In step E120, if the result of the verification in step E110 is negative, the verification entity CSC sends an instruction to interrupt the exchanges between the CLT and SRV devices. The interruption instruction may in particular be sent to the CLT device, and / or to the SRV device, and / or to a network control entity (i.e. a network function). Step E120 makes it possible to interrupt the communications between the two CLT and SRV devices, if the PRF proof is invalid or if the CIPHER suite is obsolete. Thus, this step advantageously makes it possible not to compromise the security of the communications between the CLT and SRV devices.

[0122] The proposed solution as described above allows the CSC verification entity to determine and verify the use of the CIPHER suite during the connection between the CLT and SRV devices to encrypt exchanged data. Correlatively, the proposed solution allows the CLT and SRV devices to prove to the CSC verification entity that they use the CIPHER suite to encrypt exchanges during the connection.

[0123] More specifically, the proposed solution allows the CSC verification entity to verify that the CIPHER suite announced when establishing the HSK connection is actually used by the CLT and SRV devices and that it complies with security rules.

[0124] Communications between the CLT and SRV devices: As illustrated in Figure 2, and according to one embodiment of the invention, the methods of proving and verifying the use of a proposed encryption suite comprise at least one of the steps E130 to E150 described below. This embodiment can, of course, be combined with the embodiments previously described.

[0125] Following the establishment of the connection between the CLT and SRV devices described above, the latter communicate in an encrypted manner using the KEY key and the CIPHER suite.

[0126] In step E130, the devices CLT and SRV exchange an encrypted message ENC_MSG. In particular, the encrypted message ENC_MSG is obtained by encrypting an MSG message using at least the key KEY and the sequence CIPHER. Obtaining the encrypted message ENCJ SG by one of the devices CLT and SRV from the MSG message is notably described in more detail below with reference to FIGS. 3A and 3B.

[0127] In step E131, the verification entity CSC obtains the encrypted message ENCJ SG, for example by using a network probe capturing the encrypted message ENC_MSG on the network NET and relaying it to the verification entity CSC.

[0128] In step E140, the verification entity CSC verifies the use of the CIPHER suite using the encrypted message ENC_MSG. According to one embodiment, step E140 comprises a step E141 described below.

[0129] In step E141, the verification entity CSC verifies that the CIPHER suite was used to obtain the encrypted message ENC_MSG. Step E141 is notably described in more detail below with reference to FIGS. 3A and 3B.

[0130] In step E150, if the result of the verification in step E140 is negative, the verification entity CSC sends an instruction to interrupt the exchanges between the CLT and SRV devices. The interruption instruction may in particular be sent to the CLT device, and / or to the SRV device, and / or to a network control entity (i.e. a network function). Step E150 makes it possible to interrupt the communications between the two CLT and SRV devices, if the ENCJ SG message is not encrypted with the CIPHER suite. Thus, this step advantageously makes it possible not to compromise the security of the communications between the CLT and SRV devices.

[0131] The proposed solution as described above allows the CSC verification entity to verify that the CLT and SRV devices are actually using the CIPHER suite to encrypt and decrypt exchanged data.

[0132] Usage verification when establishing the connection and / or during communications: It is important to emphasize that, within the framework of the invention, the verification entity CSC can verify the usage of the CIPHER suite: either when establishing the connection between the CLT and TLS devices (in accordance with the embodiments described with reference to steps E10 to E120); or during communications (i.e. once the connection has been established) between the CLT and SRV devices (in accordance with the embodiments described with reference to steps E130 to E150); or both.

[0133] Thus, the proposed solution makes it possible to provide proof of the use of the CIPHER suite by the CLT and SRV devices regardless of the time of connection.

[0134] Figures 3A, 3B and 3C represent examples of messages processed and exchanged by the communication devices according to embodiments of the invention.

[0135] As previously mentioned, according to one embodiment, the CLT and SRV devices exchange in step E130 one or more encrypted messages ENC_MSG, these messages being captured by a network probe and relayed to the verification entity CSC in step E131. Then, the verification entity CSC verifies in step E141 that the cipher suite CIPHER was used to obtain the encrypted message(s) ENC_MSG.

[0136] Also, we describe below with reference to figures 3A, 3B and 3C respectively three embodiments of steps E130 and E141.

[0137] According to a first embodiment illustrated by FIG. 3A, the encrypted message ENC_MSG, exchanged in step E130 between the devices CLT and SRV, is obtained by encrypting an MSG message using the CIPHER sequence and the key KEY.

[0138] More precisely, the MSG message includes: data DATA and a message authentication code MAC. Therefore, the encrypted message ENC_MSG includes: encrypted data ENC_DATA; and an encrypted code ENC_MAC

[0139] The MAC code is used to verify the integrity of the MSG message. For example, the message authentication code MAC is obtained from the DATA data using a signature algorithm, such as a hash function. This embodiment thus implements an encryption and authentication technique called "mac-then-encrypt" in English.

[0140] In step E141, the verification entity CSC decrypts the encrypted message ENC_MSG using the key KEY and the sequence CIPHER, then verifies the integrity of the decrypted message MSG using the data DATA and the MAC code.

[0141] Thus, this embodiment allows the CSC verification entity to verify that the CIPHER suite is actually used to encrypt messages exchanged between the CLT and SRV devices.

[0142] According to a second embodiment illustrated by FIG. 3B, the encrypted message ENCJ SG, exchanged in step E130 between the devices CLT and SRV, is obtained from the message MSG using the sequence CIPHER and the key KEY.

[0143] More specifically, the MSG message includes: DATA data. And, the ENCJ SG encrypted message includes: DATA encrypted data; and a MAC message authentication code to verify the integrity of the MSG message.

[0144] According to this embodiment, the encrypted data ENC_DATA is obtained by encrypting the data DATA using the sequence CIPHER and the key KEY; and the MAC code is obtained by using a hash function from the DATA data and / or associated data. This embodiment makes it possible in particular to implement an encryption and authentication technique called “encrypt-and-mac” in English and, more particularly, a technique called “Authenticated Encryption with Associated Data” in English.

[0145] In step E141, the verification entity CSC decrypts the encrypted message ENC_MSG (i.e. the encrypted data ENC_DATA) using the key KEY and the sequence CIPHER, then verifies the integrity of the decrypted message MSG using the data DATA and the code MAC.

[0146] This embodiment thus allows the CSC verification entity to verify that the CIPHER suite is actually used to encrypt messages exchanged between the CLT and SRV devices.

[0147] According to a third embodiment illustrated by FIG. 3C, the encrypted message ENCJ SG exchanged in step E130 between the devices CLT and SRV comprises: encrypted application data ENC_DATA_APP; and encrypted padding data ENC_DATA_PAD.

[0148] The encrypted application data ENC_DATA_APP is, according to one embodiment, obtained by encrypting application data DATA_APP using the CIPHER suite and an encryption key KEY' distinct from the aforementioned key KEY.

[0149] The encrypted padding data ENC_DATA_PAD is, according to one embodiment, obtained by encrypting padding data DATA_PAD (also called stuffing, for example random data) using the sequence CIPHER and the key KEY. More particularly, the padding data DATA_PAD comprises the challenge CH.

[0150] In step E141, the verification entity CSC decrypts the encrypted padding data ENC_DATA_PAD using the key KEY and the sequence CIPHER, then verifies the correspondence between the challenge CH included in the decrypted padding data DATA_PAD and the challenge CH as sent by the verification entity CSC to the device CLT.

[0151] Thus, this embodiment allows the CSC verification entity to verify the use of the CIPHER suite to encrypt messages exchanged between the CLT and SRV devices, while preserving the confidentiality of the DATA_APP application data communicated between the CLT and SRV devices.

[0152] Obviously, the first, second and third embodiments described above can be combined. It could indeed be envisaged that the CLT and SRV devices exchange, over time, one or more MSG messages according to the first embodiment, and / or one or more MSG messages according to the second embodiment, and / or one or more MSG messages according to the third embodiment. In this case, the verification entity CSC verifies, from one or more captured messages, the use of the sequence CIPHER according to the first, second, or third embodiment depending on the captured encrypted message(s).

[0153] Use of the unencrypted SPINBIT indicator: According to an embodiment illustrated by FIG. 3C, one or more messages exchanged between the CLT and SRV devices comprise an unencrypted SPINBIT indicator, active (e.g. equal to 1) or non-active (e.g. equal to 0). As indicated previously, the use of the SPINBIT indicator is, according to one embodiment, triggered in step E11 by the reception of the CH challenge in step E10.

[0154] Thus, according to one embodiment, the CSC verification entity obtains (e.g. by capture) only messages exchanged between the CLT and SRV devices comprising an active unencrypted SPINBIT indicator (e.g. equal to 1), then verifies the use of the CIPHER suite from the message(s) obtained. This embodiment makes it possible to verify the use of the CIPHER suite while limiting the number of messages to be obtained and processed by the CSC verification entity.

[0155] For example, the CLT and SRV devices activate the unencrypted SPINBIT flag for ENC_MSG messages including the CH challenge in the DATA_PAD padding data. In this way, the verification entity CSC obtains in step E131 these ENC_MSG messages whose SPINBIT flag is active, then verifies the use of the CIPHER suite from the ENC_MSG message(s) obtained.

[0156] According to another example, the CLT and SRV devices activate the unencrypted SPINBIT indicator for messages not comprising application data (i.e. control message), such as the messages exchanged during the establishment of the HSK connection between the CLT and SRV devices. Thus, the verification entity CSC obtains (e.g. with the network probe) the messages during the establishment of the HSK connection, in particular the SRV_HELLO message in step E31, which allows the verification entity to identify the CIPHER suite used for the connection.

[0157] Furthermore, as previously mentioned, the proposed solution applies in particular to the QUIC protocol. In the context of this protocol, the unencrypted indicator SPINBIT is, according to one embodiment, the so-called “spin bit” of the QUIC protocol.

[0158] We recall that the spin bit of the QUIC protocol is an unencrypted bit of the header of QUIC packets (i.e. messages). The spin bit is usually used to measure the communication latency between two devices. However, according to the embodiment described here, the spin bit is used to mark the messages to be captured by a network probe and relayed to the CSC verification entity. As a non-limiting example, the use of the spin bit to measure latency may, according to this embodiment, be limited to the messages exchanged during the establishment of the HSK connection.

[0159] Figure 4 represents an example of software and hardware architecture of a verification entity and communication devices according to an embodiment of the invention.

[0160] As illustrated by FIG. 4, according to one embodiment, the verification entity CSC, the communication devices CLT and SRV are connected via a communication network NET.

[0161] The verification entity CSC has, according to an embodiment illustrated by figure 4, the hardware architecture of a computer and comprises: a processor PROC_CSC, a random access memory, a read-only memory MEM_CSC, and a non-volatile memory. The memory MEM_CSC constitutes an information medium in accordance with the invention, readable by computer and by the processor PROC_CSC, on which is recorded a computer program PROG_CSC in accordance with the invention. The computer program PROG_CSC comprises instructions for carrying out steps of a method for verifying the use of a cipher suite in accordance with the invention and implemented by the verification entity CSC, when the computer program PROG_CSC is executed by the processor PROC_CSC.

[0162] As illustrated by FIG. 4, the verification entity CSC has, according to one embodiment, a communication module COM_CSC configured to communicate with at least one of the communication devices CLT and SRV via the network NET.

[0163] No limitation is attached to the nature of the communication interfaces between the CSC verification entity and the CLT and SRV communication devices, which may be wired or wireless, and may implement any protocol known to those skilled in the art (Ethernet, Wi-Fi, Bluetooth, 3G, 4G, 5G, 6G, etc.).

[0164] The CLT communication device (called first device) has, according to an embodiment illustrated by Figure 4, the hardware architecture of a computer and comprises: a processor PROC_CLT, a random access memory, a read-only memory MEM_CLT, and a non-volatile memory. The memory MEM_CLT constitutes an information medium in accordance with the invention, readable by a computer and by the processor PROC_CLT, on which is recorded a computer program PROG_CLT in accordance with the invention. The computer program PROG_CLT comprises instructions for carrying out steps of a method for proving use of a cipher suite in accordance with the invention and implemented by the CLT communication device, when the computer program PROG_CLT is executed by the processor PROC_CLT.

[0165] As illustrated by Figure 4, the CLT device has, according to one embodiment, a COM_CLT communication module configured to communicate with the CSC verification entity and / or the SRV communication device.

[0166] The SRV communication device (called the second device) has, according to an embodiment illustrated by Figure 4, the hardware architecture of a computer and comprises: a processor PROC_SRV, a random access memory, a read-only memory MEM_SRV, and a non-volatile memory. The memory MEM_SRV constitutes an information medium in accordance with the invention, readable by a computer and by the processor PROC_SRV, on which a program is recorded computer program PROG_SRV according to the invention. The computer program PROG_SRV comprises instructions for carrying out steps of a method for proving the use of a cipher suite according to the invention and implemented by the communication device SRV, when the computer program PROG_SRV is executed by the processor PROC_SRV.

[0167] As illustrated by Figure 4, the SRV device has, according to one embodiment, a communication module COM_SRV configured to communicate with the verification entity CSC and / or the communication device CLT.

[0168] Figure 5 represents an example of functional architectures of a verification entity and communication devices according to an embodiment of the invention.

[0169] In the following description, the modules referenced ME_XX are included in the CSC verification entity, the modules referenced MC_XX are included in the CLT device, and the modules referenced MS_XX are included in the SRV device.

[0170] The CSC verification entity comprises, according to one embodiment, modules respectively configured to implement the steps of a method for verifying the use of a cipher suite in accordance with the invention.

[0171] In particular, the verification entity CSC, according to an embodiment illustrated by FIG. 5, comprises at least one of the following modules: a sending module ME_TX configured to send a challenge CH to the device CLT; a receiving module ME_RX configured to receive the encryption proof PRF from the device CLT; an obtaining module ME_CPT configured to obtain messages exchanged between the devices CLT and SRV, comprising in particular: a first obtaining module ME_CPT1 configured to obtain at least one message exchanged SRV_HELLO between the devices CLT and SRV during an establishment of an HSK connection; a second obtaining module ME_CPT2 configured to obtain at least one encrypted message ENC_MSG exchanged between the devices CLT and SRV; a decryption module ME_DEC configured to decrypt at least one encrypted message ENC_MSG obtained using the key KEY and the sequence CIPHER.a verification module ME_CHK configured to verify the use of the CIPHER suite using the challenge CH, the encrypted challenge ENC_CH, the key KEY, and the cipher suite CIPHER, and including in particular:. a first verification module ME_CHK1 configured to verify a correspondence between the encrypted challenge ENC_CH and the encrypted challenge CH using the key KEY and the CIPHER suite; a second verification module ME_CHK2 configured to verify the integrity of at least one decrypted MSG message using at least one message authentication code; a third verification module ME_CHK3 configured to verify a correspondence between a challenge included in a decrypted MSG message and the challenge CH. a fourth verification module ME_CHK4 configured to verify a membership of the identifier of the CIPHER suite in a list of identifiers of cipher suites considered as valid; a communications interruption module ME_STP configured to, if at least one result of said verification is negative, send an instruction to interrupt the exchanges between the CLT device and the SRV.

[0172] The CLT device (called first device) comprises, according to one embodiment, modules respectively configured to implement the steps of a method of proof of use of a cipher suite in accordance with the invention.

[0173] In particular, the CLT device comprises, according to an embodiment illustrated by FIG. 5, at least one of the following modules: a sending module MC_TX configured to send messages to the SRV device and / or to the CSC verification entity, comprising in particular: - a first sending module MC_TX1 configured to send the CH challenge to the SRV device; - a second sending module MC_TX2 configured to send the PRF encryption proof to the verification entity CSC; - a third sending module MC_TX3 configured to send at least one encrypted message ENCJ SG to the SRV device; a receiving module MC_RX configured to receive messages from the SRV device and / or the verification entity CSC, including in particular - a first MC_RX1 reception module configured to receive the CH challenge from the verification entity; - a second MC_RX2 receiving module configured to receive the encrypted challenge ENC_CH from the SRV device; and - a third receiving module MC_RX3 configured to receive at least one encrypted message ENCJ SG from the device SRV; an encryption module MC_ENC configured to encrypt at least one message MSG using the key KEY, the CIPHER suite and, according to one embodiment, the key KEY'; a decryption module MC_DEC configured to decrypt at least one encrypted message ENC_MSG using the key KEY, the CIPHER suite and, according to one embodiment, the key KEY'; and a marking module MC_MRK configured to activate the unencrypted indicator SPINBIT in messages sent to the SRV device.

[0174] The SRV device (called second device) comprises, according to one embodiment, modules respectively configured to implement the steps of a method of proof of use of a cipher suite in accordance with the invention.

[0175] In particular, the SRV device comprises, according to an embodiment illustrated by FIG. 5, at least one of the following modules: a sending module MS_TX configured to send messages to the CLT device, comprising in particular: - a first sending module MS_TX1 configured to send the encrypted challenge ENC_CH to the CLT device; - a second sending module MS_TX2 configured to send an SRV_HELLO message to the CLT device when establishing the HSK connection; and - a third sending module MS_TX3 configured to send at least one encrypted message ENC_MSG to the CLT device; a receiving module MS_RX configured to receive messages from the CLT device, comprising in particular: - a first receiving module MS_RX1 configured to receive a CH challenge from the CLT device; and - a second reception module MS_RX2 configured to receive at least one encrypted message ENC_MSG from the CLT device; an encryption module MS_ENC configured to encrypt messages, comprising in particular: - a first encryption module MS_ENC1 configured to encrypt the challenge CH using the key KEY and the sequence CIPHER; - a second encryption module MS_ENC2 configured to encrypt at least one message MSG using the key KEY, the sequence CIPHER and, according to one embodiment, the key KEY'; a decryption module MS_DEC configured to decrypt at least one encrypted message ENC_MSG using the key KEY, the sequence CIPHER and, according to one embodiment, the key KEY'; and an MS_MRK marking module configured to enable the unencrypted SPINBIT flag in messages sent to the CLT device.

[0176] The term module can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).

[0177] It should be noted that the order in which the steps of a method according to the invention are carried out, in particular with reference to the attached drawings, constitutes only an example of an embodiment without any limiting character, variants being possible. Furthermore, the reference signs are not limiting of the scope of the protection, their sole function being to facilitate the understanding of the claims.

Claims

Claims 1. Method for verifying the use of a cipher suite (CIPHER) for encrypting data (MSG, CH) exchanged during a connection between a first device (CLT) and a second device (SRV) in a communication network (NET), the method being implemented by a verification entity (CSC) and comprising: sending (E10), to the first device (CLT), a challenge (CH); receiving (E100), from the first (CLT) or the second device (SRV), an encryption key (KEY); receiving (E100), from the first (CLT) or the second device (SRV), an encrypted challenge (ENC_CH) by the second device (SRV); and a verification (E110) of a use of said cipher suite (CIPHER) using at least the sent challenge (CH), the received encrypted challenge (ENC_CH), the encryption key (KEY), and said cipher suite (CIPHER).

2. Method according to claim 1, comprising obtaining (E31, E100) an identifier of said cipher suite (CIPHER) in at least one message (SRV_HELLO, PRF) sent by the first (CLT) or the second device (SRV).

3. Method according to claim 2, in which the identifier of said cipher suite (CIPHER) is obtained (E31) in at least one message (SRV_HELLO) exchanged between the first (CLT) and the second device (SRV) during establishment of a connection (HSK), said at least one message (SRV_HELLO) indicating the use of said cipher suite (CIPHER).

4. Method according to one of claims 1 to 3, comprising: obtaining (E131) at least one encrypted message (ENCJ SG) exchanged between the first (CLT) and the second device (SRV); decrypting said at least one obtained encrypted message (ENCJ SG) using the encryption key (KEY) and said cipher suite (CIPHER); and verifying (E141) an integrity of said at least one decrypted message (MSG) using at least one message authentication code (MAC) associated with said at least one decrypted message (MSG).

5. Method according to one of claims 1 to 4, comprising: obtaining (E131) at least one encrypted message (ENCJ SG), exchanged between the first (CLT) and the second device (SRV), comprising: encrypted application data (ENC_DATA_APP) using another encryption key (KEY') distinct from said received encryption key (KEY); and encrypted padding data (ENC_DATA_PAD) using the received encryption key (KEY), said padding data (DATA_PAD) comprising the challenge (CH) sent to the first device (CLT); a decryption of said encrypted padding data (ENC_DATA_PAD) using the received encryption key (KEY) and said cipher suite (CIPHER); and a verification (E141) of a correspondence between the challenge (CH) included in said decrypted padding data (DATA_PAD) and the challenge sent (CH) to the first device (CLT). Method according to one of claims 3 to 5, in which the verification entity (CSC) obtains (E31, E131) only messages exchanged between the first (CLT) and the second device (SRV) (HSK, ENC_MSG) comprising an active unencrypted indicator (SPINBIT).Method according to claim 6, wherein the unencrypted indicator (SPINBIT) is included in the header of the exchanged messages (HSK, ENC_MSG). Method according to one of claims 1 to 7, comprising a verification (E112) of a membership of the identifier of said cipher suite (CIPHER) to a list of identifiers of cipher suites considered as valid. Method according to one of claims 1 to 8, comprising, if at least one result of a said verification (Elll, E112, E141) is negative, a sending (E120, E150) of an instruction to interrupt the exchanges between the first (CLT) and the second device (SRV).Method for proving the use of a cipher suite (CIPHER) for encrypting data (MSG, CH) exchanged during a connection between a first device (CLT) and a second device (SRV) in a communication network (NET), the method being implemented by the first device (CLT) and comprising: a reception (E10), from a verification entity (CSC), of a challenge (CH); a sending (E20), to the second device (SRV), of a connection initiation message (CLT_HELLO) comprising the challenge (CH); a reception (E80), from the second device (SRV), of the encrypted challenge (ENC_CH) by the second device (SRV) using an encryption key (KEY) and said cipher suite (CIPHER); and a sending (E100), to the verification entity (CSC), of the encrypted challenge (ENC_CH).

11. Method for proving the use of a cipher suite (CIPHER) for encrypting data (MSG, CH) exchanged during a connection between a first device (CLT) and a second device (SRV) in a communication network (NET), the method being implemented by the second device (SRV) and comprising: a reception (E20), from the first device (CLT), of a connection initiation message (CLT_HELLO) comprising a challenge (CH); an encryption (E70) of the challenge (CH) using an encryption key (KEY) and said cipher suite (CIPHER); and a sending (E80), to the first device (CLT) or to a verification entity (CSC), of the encrypted challenge (ENC_CH).

12. Method according to one of claims 1 to 11, in which a TLS type protocol is used to exchange data (MSG) between the first (CLT) and the second device (SRV).

13. Verification entity (CSC) for using a cipher suite (CIPHER) to encrypt data (MSG, CH) exchanged during a connection between a first device (CLT) and a second device (SRV) in a communication network (NET), the verification entity (CSC) comprising: a sending module (ME_TX) configured to send (E10), to the first device (CLT), a challenge (CH); a receiving module (ME_RX) configured to receive (E100), from the first (CLT) or the second device (SRV), an encryption key (KEY) and to receive (E100), from the first (CLT) or the second device (SRV), a challenge encrypted (ENC_CH) by the second device (SRV); and a verification module (ME_CHK) configured to verify (E110) a use of said cipher suite (CIPHER) using at least the sent challenge (CH), the received encrypted challenge (ENC_CH), the encryption key (KEY), and said cipher suite (CIPHER).

14. Communication device (CLT), called first device, comprising: a first receiving module (MC_RX1) configured to receive (E10), from a verification entity (CSC), a challenge (CH); a first sending module (MC_TX1) configured to send (E20), to the second device (SRV), a connection initiation message (CLT_HELLO) comprising the challenge (CH); a second receiving module (MC_RX2) configured to receive (E80), from the second device (SRV), the encrypted challenge (ENC_CH) by the second device (SRV) using an encryption key (KEY) and a cipher suite (CIPHER); and a second sending module (MC_TX2) configured to send (E100), to the verification entity (CSC), the encrypted challenge (ENC_CH). Communication device (SRV), called second device, comprising: a receiving module (MS_RX1) configured to receive (E20), from the first device (CLT), a connection initiation message (CLT_HELLO) comprising a challenge (CH); an encryption module (MS_ENC1) configured to encrypt (E70) the challenge (CH) using an encryption key (KEY) and a cipher suite (CIPHER); and a sending module (MS_TX1) configured to send (E80), to the first device (CLT) or to a verification entity (CSC), the encrypted challenge (ENC_CH). Terminal comprising a verification entity (CSC) according to claim 13 or a communication device (CLT, SRV) according to claim 14 or 15. Computer program (PROG_CSC, PROG_CLT, PROG_SRV) comprising instructions for implementing the steps of a method according to any one of claims 1 to 12, when said computer program (PROG_CSC, PROG_CLT, PROG_SRV) is executed by at least one processor (PROC_CSC, PROC_CLT, PROC_SRV).

Images