EP4595355A1 - Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés - Google Patents

Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés

Info

Publication number
EP4595355A1
EP4595355A1 EP23772537.9A EP23772537A EP4595355A1 EP 4595355 A1 EP4595355 A1 EP 4595355A1 EP 23772537 A EP23772537 A EP 23772537A EP 4595355 A1 EP4595355 A1 EP 4595355A1
Authority
EP
European Patent Office
Prior art keywords
clt
srv
cipher
challenge
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23772537.9A
Other languages
German (de)
English (en)
Inventor
Romuald CORBEL
Emile Stephan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4595355A1 publication Critical patent/EP4595355A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • H04L9/16—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms the keys or algorithms being changed during operation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to the general field of telecommunications, and more particularly to the fields of computer networks and information security.
  • 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 a storage medium. associated information.
  • the present invention finds a particularly advantageous application, although in no way limiting, for the implementation of systems orchestration devices, applications and IT services (or “API orchestrator” in English, with API the acronym for “ Application Programming Interface”).
  • the invention is placed in particular in the context of encryption of communications between two communication devices in a network.
  • the set of algorithms in a cipher suite includes: a key exchange algorithm; a global encryption algorithm; and a message authentication algorithm.
  • the present invention aims to remedy all or part of the disadvantages of the prior art, in particular those explained above.
  • a method 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 implemented by a verification entity and comprising: sending, to the first device, a challenge; receiving, from the first or second device, an encryption key; a reception, from the first or the second device, of a challenge encrypted by the second device; and verifying usage of the cipher suite using at least the challenge sent, the encrypted challenge received, the encryption key, and the cipher suite.
  • a cipher suite designates one or more algorithms used by communication devices to encrypt and/or decrypt exchanged data.
  • 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).
  • a key exchange algorithm e.g. Diffie-Helman
  • an encryption algorithm e.g. AES
  • HMAC message authentication algorithm
  • a cipher suite is notably defined by an identifier, such as a character string describing the algorithm(s) of this suite.
  • the verification entity verifies the use of the cipher suite by verifying that the encrypted challenge received corresponds to the challenge sent encrypted using the encryption key and the cipher suite.
  • the proposed method makes it possible to determine and prove the use of a cipher suite to encrypt data exchanged between two communication devices.
  • the proposed method allows the verification entity to verify the use of the cipher 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 cipher suite.
  • the proposed solution allows a verification entity to verify the use of a cipher suite by communication devices during a connection (i.e. a session communication) between them.
  • a third party entity e.g. a network operator, a network application orchestrator, etc.
  • communication devices e.g. a user and a application server
  • the verification entity obtains an identifier of the cipher suite in at least one message sent by the first or the second device.
  • 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.
  • 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 message exchanged indicating to use said cipher suite.
  • This embodiment makes it possible to identify the announced (i.e. negotiated) cipher suite, when establishing a connection between communication devices, to secure exchanges during a connection.
  • 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 network communication and relaying it to the verification entity.
  • the verification entity obtains the encryption key and/or the encryption suite in a message sent by the first or second device to destination of the verification entity.
  • the first device sends, to the verification entity, a message (hereinafter referred to as encryption proof) comprising: the challenge encrypted by the second device; the encryption key; and the cipher suite identifier.
  • the verification entity implements: obtaining at least one encrypted message exchanged between the first and the second device; decryption of said at least one encrypted message obtained using the encryption key and the cipher suite; and verifying the integrity of said at least one decrypted message using at least one message authentication code associated with said at least one decrypted message.
  • 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.
  • This embodiment is particularly advantageous in that it makes it possible to prove that communication devices actually use a cipher suite to encrypt the data exchanged.
  • this embodiment allows the verification entity to verify that the first and second devices use the cipher suite to encrypt exchanged data.
  • the verification entity can verify the use of the cipher suite: either when establishing the connection between the first and second devices; either during communications (i.e. once the connection has been established) between the first and second devices; or both.
  • the proposed solution makes it possible to provide proof of the use of a cipher suite by communication devices regardless of the time of connection.
  • 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
  • filling data encrypted using the received encryption key, said filling 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 filling data and the challenge sent to the first device.
  • 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.
  • the confidentiality of the application data is preserved by the use of: a first key, known to the verification entity, to encrypt the filling data including the challenge; and a second key, distinct from the first and unknown to the verification entity, to encrypt the application data.
  • the verification entity is able to verify the use of the cipher suite using the encrypted challenge included in the filling data and cannot however decrypt the application data.
  • 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.
  • the verification entity only obtains messages exchanged between the first and the second device comprising an active non-encrypted indicator.
  • the messages exchanged between the first and second devices include a non-encrypted indicator, either active (e.g. equal to 1) or non-active (e.g. equal to 0), the use of the non-encrypted indicator -encrypted in the messages exchanged being triggered in particular by the receipt of the challenge from the verification entity.
  • a non-encrypted indicator either active (e.g. equal to 1) or non-active (e.g. equal to 0)
  • This embodiment makes it possible to mark the messages to be processed by the verification entity to verify the use of the cipher suite.
  • communication devices mark messages with an unencrypted flag allowing the verification entity to verify the use of the cipher suite.
  • the first and second devices can mark, with an active non-encrypted indicator, messages comprising an encrypted challenge in the filling data and to be captured and relayed to the verification entity by the network probe.
  • the verification entity obtains and processes only messages enabling the use of the cipher suite to be verified.
  • this embodiment makes it possible to verify the use of the cipher suite by the first and second communication devices while limiting the number of messages to be processed by the verification entity.
  • the unencrypted indicator is included in the header of the messages (i.e. packets) exchanged between the first and the second device.
  • the QUIC protocol is used to exchange data between the first and the second device and the unencrypted indicator is a bit, called spin bit, included in the header.
  • messages i.e. packets
  • the spin bit of the QUIC protocol is usually used to measure the communication latency between two communication devices.
  • the spin bit is used to mark the messages to be processed by the verification entity.
  • 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 usage of the cipher suite, without having to include an additional marker in the messages exchanged.
  • 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 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 invalid (e.g. obsolete , unsecured, etc.).
  • This embodiment makes it possible to verify that a cipher suite used by communication devices complies with defined security rules.
  • 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.
  • a third party entity e.g. a network operator, a network application orchestrator
  • the verification entity sends an instruction to interrupt the exchanges between the first and the second device.
  • the interrupt instruction can in particular be sent to a network control entity (ie a network function), and/or to the first device, and/or to the second device.
  • a network control entity ie a network function
  • This embodiment makes it possible to interrupt communications between the first and the second device, if the proof of use of the cipher suite provided by the devices is invalid (ie the result of the usage verification is negative ) or if the cipher suite used is obsolete. This means not compromising the security of exchanges between communication devices.
  • 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; receiving, from the second device, the challenge encrypted by the second device using an encryption key and said cipher suite; and sending, to the verification entity, the encrypted challenge.
  • 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: a reception, from the first device, of a challenge; encryption of the challenge using an encryption key and said cipher suite; and sending, to the first device or a verification entity, the encrypted challenge.
  • At least one of said first and second devices sends, to the verification entity, an encryption proof comprising: the encrypted challenge; the encryption key; and a cipher suite identifier.
  • 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 message exchanged including an identifier of the cipher suite to be used.
  • At least one of said first and second device 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.
  • At least one of said first and second devices encrypts at least one message comprising application data and filling 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.
  • At least one of said first and second devices marks with an unencrypted indicator the messages sent to be obtained and processed by the verification entity to verify the use of the cipher suite.
  • 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.
  • a TLS type protocol is used to exchange data between the first and the second device. More precisely, according to one embodiment, the TLS, DTLS, OSCORE, EDHOC, or QUIC protocol is used to exchange data between the first and the second device.
  • the QUIC protocol is used to exchange data between the first and the second device.
  • 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 entity verification comprising: a sending module configured to send, to the first device, a challenge; a reception module configured to receive, from the first or the second device, an encryption key and to receive, from the first or the second device, a challenge encrypted by the second device; and a verification module configured to verify use of said cipher suite using at least the challenge sent, the encrypted challenge received, the encryption key, and said cipher suite.
  • a communication 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 reception 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.
  • a communication 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 a verification entity, the encrypted challenge.
  • a terminal comprising a verification entity conforming to the invention or a communication device conforming to the invention.
  • 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 a processor or computer.
  • the computer program can be made up of one or more sub-parts stored in the same memory or in separate memories.
  • the program may use any programming language, and 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 shape.
  • the information carrier can be any entity or device capable of storing the program.
  • the support may comprise a storage means, such as a non-volatile memory or ROM, for example a CD-ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a floppy disk or a hard disc.
  • 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 can in particular be downloaded onto a computer network.
  • the information carrier may be a integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Figure 1 represents, in flowchart form, steps of methods of proof and verification of use of a cipher suite according to one embodiment of the invention
  • Figure 2 represents, in flowchart form, steps of methods of proof and verification of use of a cipher suite according to one embodiment of the invention
  • Figure 3A, Figure 3B and Figure 3C represent examples of messages processed and exchanged by the communication devices according to embodiments of the invention.
  • Figure 4 represents an example of software and hardware architectures of a verification entity and communication devices according to one embodiment of the invention.
  • Figure 5 represents an example of functional architectures of a verification entity and communication devices according to one embodiment of the invention.
  • the proposed solution fits in particular in a context in which a CLT communication device (called first device) and an SRV communication device (called second device) exchange data (i.e. messages) in an encrypted manner by the intermediary of a NET communication network.
  • the CLT and SRV devices encrypt the data exchanged using a CIPHER encryption suite, i.e. the set of algorithms which make it possible to secure the exchanges.
  • the verification entity CSC and the communication devices CLT and SRV can 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), user equipment (or “User Equipment” (UE ) in English), a personal computer (or “Personal Computer” (PC) in English), a smartphone (or “Smartphone” in English), a connected television or a tablet, but also by equipment managed by a computer operator or an operator of a telecommunications network (for example, server, firewall, router), this equipment may be fixed or mobile.
  • Communication devices can also be software applications, or service instances hosted in equipment.
  • 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.
  • a terminal such as a mobile telephone , for example a Smartphone, or a tablet, or a computer.
  • NET communication network which can 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 considered.
  • Figure 1 represents, in flowchart form, steps of methods of proof and verification of use of a cipher suite to encrypt data exchanged between a first and a second communication device according to a mode of realization of the invention.
  • the proposed methods of proof and verification of use of a cipher suite comprise at least one of the steps E10 to E110 described below.
  • step E10 the verification entity CSC sends, to the CLT device, a challenge CH (or “challenge” in English).
  • a challenge CH or “challenge” in English.
  • the CH challenge is a character string.
  • step E20 the CLT device sends the received CH challenge to the SRV device.
  • step E70 the device SRV encrypts the challenge CH using a cipher suite CIPHER and an encryption key KEY, and thus obtains an encrypted challenge ENC_CH.
  • step E80 the SRV device sends the encrypted challenge ENC_CH to the CLT device.
  • step E100 the CLT device sends, to the verification entity CSC, the key KEY and the encrypted challenge ENC_CH.
  • step E110 the verification entity CSC verifies the use of the CIPHER sequence using the challenge CH, the encrypted challenge ENC_CH, the key KEY and the sequence CIPHER.
  • the verification entity CSC in step E110 verifies that the encrypted challenge ENC_CH corresponds to the challenge CH encrypted using the key KEY and the sequence CIPHER.
  • the verification entity CSC decrypts the encrypted challenge ENC_CH and then compares the decrypted challenge obtained to the challenge CH sent. If the decrypted challenge obtained is identical to the CH challenge sent, then the CIPHER suite has actually been 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.
  • 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.
  • 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 CLT and SRV devices to provide proof of use of the CIPHER suite.
  • Figure 2 represents, in flowchart form, steps of methods of proof and verification of use of a cipher suite according to one embodiment of the invention.
  • Figure 2 illustrates, by way of example, an embodiment of the invention in a particular application context according to which one of the protocols TLS, DTLS, OSCORE, EDHOC or QUIC is used to exchange data between CLT and SRV devices.
  • the exemplary embodiment provided below repeats, as such, the steps described with reference to Figure 1 in this particular application context.
  • the CLT device e.g. the TLS/QUIC protocol client
  • the SRV device e.g. the TLS/QUIC protocol server
  • TLS 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.
  • DTLS at least one of the following versions of the “Datagram Transport Layer Security” protocol: DTLS 1.2 as defined by RFC 6347; or DTLS 1.3 as defined by RFC9147.
  • EDHOC the protocol, used in particular for Internet of Things type terminals (or “Internet of Things” in English), “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/.
  • QUIC we designate 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.
  • step E10 the verification entity CSC sends, to the CLT device, a CH challenge.
  • the CLT device activates the use of a non-encrypted SPINBIT indicator for messages exchanged with the SRV device, this activation being triggered by receipt of the CH challenge in step E10.
  • This SPINBIT indicator is described in more detail below with reference to Figure 3B.
  • step E20 the CLT device sends, to the SRV device, a CLT_HELLO message to initiate a connection with it.
  • the CLT_HELLO message includes the CH challenge, received from the CSC verification entity.
  • the CLT_HELLO message includes, 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).
  • the SRV device sends, to the CLT device, a message SRV_HELLO in response to the message CLT_HELLO.
  • 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).
  • 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.
  • the SRV_HELLO message thus indicates using the CIPHER suite to encrypt and decrypt the data exchanged between the CLT and SRV devices during the connection.
  • a CIPHER suite is defined by an identifier describing the algorithms of 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 encryption used when connecting; 256 (bits) is the size of the encryption key; GCM is the encryption 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.
  • the verification entity CSC obtains the message SRV_HELLO.
  • 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.
  • step E40 the CLT device sends, to the SRV device, a CLT_KEY_EXG message comprising: according to one embodiment, a pre-master secret (or “premaster secret” in English); or according to another embodiment a key obtaining parameter.
  • the CLT and SRV devices respectively obtain a KEY for the connection (also called a session key).
  • a KEY for the connection also called a session key.
  • CLT and SRV devices use a key exchange and derivation algorithm, such as Diffie-Hellman, to obtain the KEY from the random client, random server, and get parameters. key mentioned above.
  • the CLT and SRV devices obtain the KEY from the random client, the random server and the pre-master secret.
  • step E60 the CLT device sends, to the SRV device, an encrypted message CLT_FSH using the key KEY and the CIPHER sequence.
  • the SRV device decrypts this message using the KEY key, then verifies the integrity of the decrypted message.
  • the SRV device verifies that the CLT device has correctly obtained the same key KEY.
  • step E70 the SRV device encrypts the challenge CH, received from the device CLT, using the key KEY and the sequence CIPHER and thus obtains an encrypted challenge ENC_CH.
  • step E80 the SRV device sends the encrypted challenge ENC_CH to the CLT device. More particularly, the SRV device adds, according to one embodiment, the encrypted challenge ENC_CH to a message sent to the CLT device and including a session ticket.
  • step E90 the SRV device sends, to the CLT device, an SRV_FSH message encrypted using the key KEY and the CIPHER sequence.
  • the CLT device decrypts this message using the KEY key, then verifies the integrity of the decrypted message.
  • the CLT device verifies that the SRV device has correctly obtained the same KEY key.
  • steps E20 to E90 constitute an establishment of the HSK (or “handshake” in English) connection between the CLT and SRV devices.
  • the CSC verification entity 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.
  • step E100 the CLT device sends, to the CSC verification entity, a PRF encryption proof comprising: the encryption key KEY; the ENC_CH encrypted challenge; and the CIPHER suite identifier.
  • the PRF encryption proof further includes, according to one embodiment, the CH challenge.
  • the CSC verification entity obtains the key KEY and the identifier of the CIPHER suite by receiving the PRF encryption proof.
  • the key KEY and/or the CIPHER sequence are predetermined or are obtained by the CSC verification entity 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.
  • step E110 the verification entity CSC verifies the use of the CIPHER suite using the encryption proof PRF.
  • step E110 comprises at least one of steps El 11 and El 12 described below.
  • step Elll the verification entity CSC verifies that the PRF encryption proof is valid. More particularly, the verification entity CSC verifies in step Elll that the encrypted challenge ENC_CH corresponds to the challenge CH encrypted using the key KEY and the sequence CIPHER.
  • 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 valid (i.e. considered to comply with defined safety rules).
  • the CSC verification entity 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 cipher suites considered 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.
  • 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 interrupt instruction can 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 communications between the two devices CLT and SRV, 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 communications between the CLT and SRV devices.
  • 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.
  • the proposed solution allows CLT and SRV devices to prove to the CSC verification entity that they use the CIPHER suite to encrypt exchanges during the connection.
  • 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 safety rules.
  • step E130 the CLT and SRV devices exchange an encrypted message ENC_MSG.
  • the encrypted message ENC_MSG is obtained by encrypting an MSG message using at least the key KEY and the sequence CIPHER. Obtaining the ENCJ SG encrypted message by one of the CLT and SRV devices from the MSG message is described in more detail below with reference to Figures 3A and 3B.
  • 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 NET network and relaying it to the verification entity CSC .
  • step E140 the verification entity CSC verifies the use of the CIPHER suite using the encrypted message ENC_MSG.
  • step E140 comprises a step E141 described below.
  • step E141 the verification entity CSC verifies that the CIPHER suite was used to obtain the encrypted message ENC_MSG.
  • Step E141 is in particular described in more detail below with reference to Figures 3A and 3B.
  • 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 interrupt instruction can 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 communications between the two devices CLT and SRV, 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 communications between the CLT and SRV devices.
  • the CSC verification entity can verify the usage of the following CIPHER: either when establishing the connection between the CLT and TLS devices (in accordance with the embodiments described with reference to steps E10 to E120); either 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.
  • Figures 3A, 3B and 3C represent examples of messages processed and exchanged by the communication devices according to embodiments of the invention.
  • the CLT and SRV devices exchange in step E130 one or more ENC_MSG encrypted messages, these messages being captured by a network probe and relayed to the CSC verification entity at 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.
  • the encrypted message ENC_MSG exchanged in step E130 between the CLT and SRV devices, is obtained by encryption of an MSG message using the CIPHER sequence and the key KEY.
  • the MSG message includes: DATA data and a MAC message authentication code. Therefore, the encrypted message ENC_MSG includes: encrypted data ENC_DATA; and an encrypted code ENC_MAC
  • the MAC code makes it possible to verify the integrity of the MSG message.
  • the MAC message authentication code 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.
  • 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.
  • 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.
  • the encrypted message ENCJ SG exchanged in step E130 between the devices CLT and SRV, is obtained from the message MSG using the CIPHER sequence and the key KEY .
  • the MSG message includes: DATA data.
  • the ENCJ SG encrypted message includes: DATA encrypted data; and a MAC message authentication code for verifying the integrity of the MSG message.
  • the ENC_DATA encrypted data are obtained by encryption of the DATA data using the CIPHER sequence and the KEY key; and the MAC code is obtained using a hash function from 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.
  • 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 MAC code.
  • ENC_MSG i.e. the encrypted data ENC_DATA
  • 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.
  • the encrypted message ENCJ SG exchanged in step E130 between the CLT and SRV devices comprises: encrypted application data ENC_DATA_APP; and encrypted padding data ENC_DATA_PAD.
  • the encrypted application data ENC_DATA_APP are, according to one embodiment, obtained by encrypting DATA_APP application data using the CIPHER suite and an encryption key KEY' distinct from the aforementioned key KEY.
  • the ENC_DATA_PAD encrypted filling data is, according to one embodiment, obtained by encrypting DATA_PAD filling data (also called padding, for example random data) using the CIPHER sequence and the KEY key. Most notably, the DATA_PAD padding data includes the CH challenge.
  • step E141 the verification entity CSC decrypts the encrypted filling data ENC_DATA_PAD using the key KEY and the sequence CIPHER, then verifies the correspondence between the challenge CH included in the decrypted filling data DATA_PAD and the CH challenge as sent by the CSC verification entity to the CLT device.
  • 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.
  • 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 a or several MSG messages according to the third embodiment. In this case, the CSC verification entity verifies, from one or more captured messages, the use of the suite CIPHER according to the first, second, or third embodiment depending on the encrypted message(s) captured.
  • one or more messages exchanged between the CLT and SRV devices include an unencrypted SPINBIT indicator, active (e.g. equal to 1) or non-active (e.g. equal to 0).
  • an unencrypted SPINBIT indicator active (e.g. equal to 1) or non-active (e.g. equal to 0).
  • the use of the SPINBIT indicator is, according to one embodiment, triggered in step Eli by the reception of the challenge CH in step E10.
  • the CSC verification entity obtains (e.g. by capture) only messages exchanged between the CLT and SRV devices comprising an active non-encrypted SPINBIT indicator (e.g. equal to 1), then verifies the use of the CIPHER suite from the message(s) obtained.
  • an active non-encrypted SPINBIT indicator e.g. equal to 1
  • the CLT and SRV devices activate the unencrypted indicator SPINBIT for ENC_MSG messages including the CH challenge in the DATA_PAD filling data.
  • the verification entity CSC obtains in step E131 these ENC_MSG messages whose SPINBIT indicator is active, then verifies the use of the CIPHER suite from the ENC_MSG message(s) obtained.
  • the CLT and SRV devices activate the unencrypted indicator SPINBIT for messages not including application data (i.e. control message), such as messages exchanged during the establishment of the connection HSK between CLT and SRV devices.
  • application data i.e. control message
  • the CSC verification entity 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.
  • the proposed solution applies in particular to the QUIC protocol.
  • the unencrypted SPINBIT indicator is, according to one embodiment, the so-called “spin bit” of the QUIC protocol.
  • 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.
  • the spin bit is used to mark messages to be captured by a network probe and relayed to the CSC verification entity.
  • the use of the spin bit to measure latency can, according to this embodiment, be limited to the messages exchanged during the establishment of the HSK connection.
  • Figure 4 represents an example of software and hardware architecture of a verification entity and communication devices according to one embodiment of the invention.
  • the verification entity CSC, the communication devices CLT and SRV are connected via a communication network NET.
  • the CSC verification entity has, according to an embodiment illustrated in Figure 4, the hardware architecture of a computer and comprises: a processor PROC_CSC, a RAM, a read only memory MEM_CSC, and a memory nonvolatile.
  • the memory MEM_CSC constitutes an information medium in accordance with the invention, readable by computer and by the processor PROC_CSC, on which a computer program PROG_CSC in accordance with the invention is recorded.
  • the computer program PROG_CSC includes instructions for carrying out steps of a method of verifying the use of a cipher suite conforming to the invention and implemented by the verification entity CSC, when the program computer PROG_CSC is executed by the processor PROC_CSC.
  • the CSC verification entity has, according to one embodiment, a COM_CSC communication module configured to communicate with at least one of the CLT and SRV communication devices via the intermediary of the NET network.
  • the CLT communication device (called the first device) has, according to an embodiment illustrated in Figure 4, the hardware architecture of a computer and comprises: a PROC_CLT processor, a RAM, a MEM_CLT read only memory , and non-volatile memory.
  • the MEM_CLT memory constitutes an information medium in accordance with the invention, readable by computer and by the PROC_CLT processor, on which a PROG_CLT computer program in accordance with the invention is recorded.
  • the computer program PROG_CLT comprises instructions for carrying out steps of a method of proof of use of a cipher suite in accordance with the invention and implemented by the communication device CLT, when the computer program PROG_CLT is executed by the PROC_CLT processor.
  • the CLT device has, according to one embodiment, a communication module COM_CLT configured to communicate with the verification entity CSC and/or the communication device SRV.
  • a communication module COM_CLT configured to communicate with the verification entity CSC and/or the communication device SRV.
  • the communication device SRV (called second device) has, according to an embodiment illustrated in Figure 4, the hardware architecture of a computer and comprises: a processor PROC_SRV, a RAM, a read only memory MEM_SRV , and non-volatile memory.
  • the MEM_SRV memory constitutes an information medium in accordance with the invention, readable by computer and by the processor PROC_SRV, on which a program is recorded PROG_SRV computer according to the invention.
  • the computer program PROG_SRV comprises instructions for carrying out steps of a method of proof of use of a cipher suite in accordance with the invention and implemented by the communication device SRV, when the computer program PROG_SRV is executed by the PROC_SRV processor.
  • 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.
  • a communication module COM_SRV configured to communicate with the verification entity CSC and/or the communication device CLT.
  • Figure 5 represents an example of functional architectures of a verification entity and communication devices according to one embodiment of the invention.
  • the modules referenced ME_XX are included in the verification entity CSC, the modules referenced MC_XX are included in the device CLT, and the modules referenced MS_XX are included in the device SRV.
  • 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.
  • the CSC verification entity comprises at least one of the following modules: a ME_TX sending module configured to send a CH challenge to the CLT device; a receiving module ME_RX configured to receive the PRF encryption proof from the CLT device; an obtaining module ME_CPT configured to obtain messages exchanged between the CLT and SRV devices, comprising in particular: a first obtaining module ME_CPT1 configured to obtain at least one message exchanged SRV_HELLO between the CLT and SRV devices 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 CLT and SRV devices; a ME_DEC decryption module configured to decrypt at least one ENC_MSG encrypted message obtained using the KEY key and the CIPHER sequence.
  • a ME_TX sending module configured to send a CH challenge to the CLT device
  • a receiving module ME_RX configured to receive the PRF encryption proof from the CLT device
  • a ME_CHK verification module configured to verify the use of the CIPHER suite using the CH challenge, the ENC_CH encrypted challenge, the KEY key, and the CIPHER encryption suite, and including in particular: a first verification module ME_CHK1 configured to verify a correspondence between the encrypted challenge ENC_CH and the challenge CH encrypted using the key KEY and the CIPHER sequence; 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 CH challenge.
  • a fourth verification module ME_CHK4 configured to check whether the identifier of the CIPHER suite belongs to a list of identifiers of cipher suites considered valid; a communications interruption module ME_STP configured to, if at least one result of said verification is negative, send an instruction to interrupt exchanges between CLT device and SRV.
  • the CLT device (called the 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.
  • the CLT device comprises, according to an embodiment illustrated in Figure 5, at least one of the following modules: an MC_TX sending module configured to send messages to the SRV device and/or to the entity CSC verification, including in particular:
  • MC_TX1 configured to send the CH challenge to the SRV device
  • MC_TX2 configured to send the encryption proof PRF to the verification entity CSC
  • MC_TX3 configured to send at least one ENCJ SG encrypted message to the SRV device
  • MC_RX reception module configured to receive messages from the SRV device and/or the CSC verification entity, comprising in particular
  • MC_RX1 configured to receive the CH challenge coming from the verification entity
  • MC_RX2 configured to receive the encrypted challenge ENC_CH coming from the SRV device
  • MC_RX3 configured to receive at least one ENCJ SG encrypted message coming from the SRV device; an MC_ENC encryption module configured to encrypt at least one MSG message using the KEY key, the CIPHER sequence and, according to one embodiment, the KEY'key; a MC_DEC decryption module configured to decrypt at least one ENC_MSG encrypted message using the KEY key, the CIPHER sequence and, according to one embodiment, the KEY'key; and a marking module MC_MRK configured to activate the unencrypted flag SPINBIT in messages sent to the SRV device.
  • 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 according to the invention.
  • the SRV device comprises, according to an embodiment illustrated in Figure 5, at least one of the following modules: an MS_TX sending module configured to send messages to the CLT device, comprising in particular:
  • a second sending module MS_TX2 configured to send an SRV_HELLO message to the CLT device when establishing the HSK connection
  • MS_TX3 configured to send at least one encrypted message ENC_MSG to the CLT device
  • MS_RX reception module configured to receive messages from the CLT device, comprising in particular:
  • MS_RX2 configured to receive at least one encrypted message ENC_MSG coming from the CLT device
  • MS_ENC encryption module configured to encrypt messages, comprising in particular:
  • a first encryption module MS_ENC1 configured to encrypt the CH challenge using the KEY key and the CIPHER sequence
  • MS_ENC2 configured to encrypt at least one MSG message using the KEY key, the CIPHER sequence and, according to one embodiment, the KEY'key
  • MS_DEC decryption module configured to decrypt at least one ENC_MSG encrypted message using the KEY key, the CIPHER sequence and, according to one embodiment, the KEY'key
  • MS_MRK marking module configured to activate the unencrypted SPINBIT flag in messages sent to the CLT device.
  • module can correspond as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer or computer programs or subprograms. more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned.
  • 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. .).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne des procédés de preuve et de vérification d'usage d'une suite de chiffrement (CIPHER), une entité de vérification (CSC), des dispositifs de communication (CLT, SRV), un terminal, et un programme d'ordinateur associés. Le procédé proposé de vérification d'usage d'une suite de chiffrement (CIPHER) pour chiffrer des données (MSG, CH) échangées entre un premier dispositif (CLT) et un deuxième dispositif (SRV) est mis en œuvre par une entité de vérification (CSC) et comprend : - un envoi (E10), au premier dispositif (CLT), d'un défi (CH); - une réception (E100) d'une clé de chiffrement (KEY); - une réception (E100) d'un défi chiffré (ENC_CH) par le deuxième dispositif (SRV); et - une vérification (E110) d'usage de ladite suite (CIPHER) en utilisant le défi envoyé (CH), le défi chiffré reçu (ENC_CH), la clé (KEY), et ladite suite (CIPHER).

Description

Description
Titre de l'invention : Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés
Domaine technique
[0001] La présente invention se rapporte au domaine général des télécommunications, et plus particulièrement aux domaines des réseaux informatiques et de la sécurité de l’information. En particulier, la présente invention concerne des procédés de preuve et de vérification d'usage d'une suite de chiffrement, ainsi qu'une entité de vérification, des dispositifs de communication, un terminal, un programme d'ordinateur et un support d'information associés. La présente invention trouve une application particulièrement avantageuse, bien que nullement limitative, pour la mise en œuvre de dispositifs d'orchestration de systèmes, d'applications et de services informatiques (ou « API orchestrator » en anglais, avec API l'acronyme de « Application Programming Interface »).
État de la technique antérieure
[0002] L'invention se place en particulier dans le contexte du chiffrement des communications entre deux dispositifs de communication dans un réseau.
[0003] Pour sécuriser des communications entre deux dispositifs de communication, il est connu d'utiliser un ensemble d’algorithmes désigné par l'expression « suite de chiffrement » (ou « cipher suite » en anglais). Typiquement, l’ensemble d’algorithmes d'une suite de chiffrement comprend : un algorithme d’échange de clés ; un algorithme de chiffrement global ; et un algorithme d'authentification de message.
[0004] Il existe aujourd'hui dans l'état de la technique une multitude de suites de chiffrement pouvant être utilisées pour chiffrer des communications. Toutefois, certaines suites de chiffrement sont obsolètes et ne permettent pas de garantir un niveau de sécurité satisfaisant pour chiffrer des communications. Aussi il est essentiel de pouvoir vérifier que deux dispositifs de communication n'exploitent pas une suite de chiffrement obsolète pour chiffrer leurs communications.
[0005] Or, il apparait très complexe pour une entité tiers, par exemple une entité de contrôle de sécurité, de vérifier si les données échangées entre deux dispositifs de communication sur un réseau sont effectivement sécurisées. Prenons pour exemple le protocole TLS (acronyme de « Transport Layer Security ») de sécurisation des échanges par réseau informatique. Alors, dans le cadre de ce protocole, la lecture des messages lors de l'établissement d'une connexion entre deux dispositifs de communication permet d'identifier le type de suite de chiffrement annoncée pour la connexion. Toutefois, cette seule lecture est insuffisante puisqu'elle ne permet notamment pas de prouver que la suite de chiffrement possiblement utilisée est bien celle identifiée, et si même si l'identification est correcte, si la suite identifiée est effectivement utilisée par les dispositifs de communication lors de cette connexion réseau.
[0006] Il existe par conséquent un besoin pour une solution permettant de déterminer et de prouver l'usage d'une suite de chiffrement pour chiffrer des données échangées entre deux dispositifs de communication.
Exposé de l'invention
[0007] La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l'art antérieur, notamment ceux exposés précédemment.
[0008] Selon un aspect de l'invention, il est proposé un procédé de vérification d'usage d'une suite de chiffrement pour chiffrer des données échangées entre un premier dispositif et un deuxième dispositif dans un réseau de communication, le procédé étant mis en œuvre par une entité de vérification et comprenant : un envoi, au premier dispositif, d'un défi ; une réception, en provenance du premier ou du deuxième dispositif, d'une clé de chiffrement ; une réception, en provenance du premier ou du deuxième dispositif, d'un défi chiffré par le deuxième dispositif ; et une vérification d'un usage de la suite de chiffrement en utilisant au moins le défi envoyé, le défi chiffré reçu, la clé de chiffrement, et la suite de chiffrement.
[0009] Au sens de l'invention, une suite de chiffrement désigne un ou plusieurs algorithmes utilisés par des dispositifs de communication pour chiffrer et/ou déchiffrer des données échangées. À titre indicatif, une suite de chiffrement peut comprendre : un algorithme d’échange de clés (e.g. Diffie-Helman) ; un algorithme de chiffrement (e.g. AES) ; et un algorithme d'authentification de message (e.g. HMAC). Il est à noter qu'une suite de chiffrement est notamment définie par un identifiant, telle qu'une chaîne de caractères décrivant le ou les algorithmes de cette suite.
[0010] En particulier, l'entité de vérification vérifie l'usage de la suite de chiffrement en vérifiant que le défi chiffré reçu correspond au défi envoyé chiffré en utilisant la clé de chiffrement et la suite de chiffrement. [0011] D'une façon générale, le procédé proposé permet de déterminer et de prouver l'usage d'une suite de chiffrement pour chiffrer des données échangées entre deux dispositifs de communication.
[0012] Plus particulièrement, le procédé proposé permet à l'entité de vérification de vérifier l'usage de la suite de chiffrement pour chiffrer des données échangées entre les premier et deuxième dispositifs et, corrélativement, permet aux premier et deuxième dispositifs d'apporter une preuve d'usage de la suite de chiffrement.
[0013] Dans un contexte particulier d'application aux protocoles TLS ou QUIC, la solution proposée permet à une entité de vérification de vérifier l'usage d'une suite de chiffrement par des dispositifs de communication lors d'une connexion (i.e. une session de communication) entre ceux-ci. Ainsi, et à titre plus général, la solution proposée permet à une entité tiers (e.g. un opérateur réseau, un orchestrateur d'applications en réseau, etc.) de contrôler la sécurité des échanges entre des dispositifs de communication (e.g. un utilisateur et un serveur d'application) lors d'une connexion.
[0014] Selon un mode de réalisation, l'entité de vérification obtient un identifiant de la suite de chiffrement dans au moins un message envoyé par le premier ou le deuxième dispositif.
[0015] Ce mode de réalisation permet à l'entité de vérification d'obtenir l'identifiant de la suite de chiffrement, puis de vérifier l'usage de cette suite de chiffrement par les premier et deuxième dispositifs.
[0016] De cette manière, il n'est pas nécessaire que l'entité de vérification dispose au préalable de l'identifiant de la suite de chiffrement utilisée par les premier et deuxième dispositifs. Ce mode de réalisation permet ainsi de ne pas nécessiter de préconfiguration de l'entité de vérification.
[0017] Selon un mode de réalisation, l'entité de vérification obtient l'identifiant de la suite de chiffrement dans au moins un message échangé entre le premier et le deuxième dispositif lors d'un établissement d'une connexion, ledit au moins un message échangé indiquant d'utiliser ladite suite de chiffrement.
[0018] Ce mode de réalisation permet d'identifier la suite de chiffrement annoncée (i.e. négociée), lors de l'établissement d'une connexion entre des dispositifs de communication, pour sécuriser les échanges lors d’une connexion.
[0019] À titre indicatif, l'entité de vérification obtient, selon un mode de réalisation, ledit au moins un message échangé lors de l'établissement d'une connexion en utilisant une sonde réseau, la sonde réseau capturant ce message sur le réseau de communication et le relayant à l'entité de vérification.
[0020] Selon un mode de réalisation, l'entité de vérification obtient la clé de chiffrement et/ou la suite de chiffrement dans un message envoyé par le premier ou le deuxième dispositif à destination de l'entité de vérification. Par exemple, selon un mode de réalisation, le premier dispositif envoie, à l'entité de vérification, un message (dit ci-après preuve de chiffrement) comprenant : le défi chiffré par le deuxième dispositif ; la clé de chiffrement ; et l'identifiant de la suite de chiffrement.
[0021] Toutefois, dans le cadre de l'invention, il pourrait être envisagé d'autres modes de réalisation selon lesquels la clé de chiffrement et/ou la suite de chiffrement sont prédéterminées, de telle sorte que l'entité de vérification dispose préalablement de celles-ci.
[0022] Selon un mode de réalisation, l'entité de vérification met en œuvre : une obtention d'au moins un message chiffré échangé entre le premier et le deuxième dispositif ; un déchiffrement dudit au moins un message chiffré obtenu en utilisant la clé de chiffrement et la suite de chiffrement ; et une vérification d'une intégrité dudit au moins un message déchiffré en utilisant au moins un code d'authentification de message associé audit au moins un message déchiffré.
[0023] À titre indicatif, l'entité de vérification obtient, selon un mode de réalisation, ledit au moins un message chiffré en utilisant une sonde réseau, la sonde réseau capturant ledit au moins un message chiffré sur le réseau de communication et le relayant à l'entité de vérification.
[0024] Ce mode de réalisation est particulièrement avantageux en ce qu'il permet de prouver que des dispositifs de communication utilisent effectivement une suite de chiffrement pour chiffrer les données échangées.
[0025] En particulier, ce mode de réalisation permet à l'entité de vérification de vérifier que les premier et deuxième dispositifs utilisent la suite de chiffrement pour chiffrer des données échangées.
[0026] Il est important de souligner que, dans le cadre de l'invention, l'entité de vérification peut vérifier l'usage de la suite de chiffrement : soit lors de l'établissement de la connexion entre les premier et deuxième dispositifs ; soit lors de communications (i.e. une fois la connexion établie) entre les premier et deuxième dispositifs ; ou encore les deux. Ainsi, la solution proposée permet d'apporter une preuve de l'usage d'une suite de chiffrement par des dispositifs de communication quel que soit l'instant de la connexion.
[0027] Ainsi, en mettant régulièrement en œuvre la solution proposée, il est possible pour une entité tiers de vérifier au cours du temps que des dispositifs de communication utilisent effectivement la suite de chiffrement.
[0028] Selon un mode de réalisation, l'entité de vérification met en œuvre : une obtention d'au moins un message chiffré échangé entre le premier et le deuxième dispositif, ledit au moins un message chiffré comprenant : - des données applicatives chiffrées en utilisant une autre clé de chiffrement, distincte de la clé de chiffrement reçue par l'entité de vérification ; et
- des données de remplissage chiffrées en utilisant la clé de chiffrement reçue, lesdites données de remplissage comprenant le défi envoyé au premier dispositif ; un déchiffrement desdites données de remplissage chiffrées en utilisant la clé de chiffrement reçue et ladite suite de chiffrement ; et une vérification d'une correspondance entre le défi compris dans lesdites données de remplissage déchiffrées et le défi envoyé au premier dispositif.
[0029] Ce mode de réalisation permet à l'entité de vérification de vérifier que la suite de chiffrement est utilisée pour chiffrer les messages échangés entre les premier et deuxième dispositifs, tout en préservant la confidentialité des données applicatives communiquées entre ces dispositifs.
[0030] La confidentialité des données applicatives est préservée par l'utilisation : d'une première clé, connue de l'entité de vérification, pour chiffrer les données de remplissage comprenant le défi ; et d'une deuxième clé, distincte de la première et inconnue de l'entité de vérification, pour chiffrer les données applicatives. Ainsi, selon ce mode de réalisation, l'entité de vérification est en mesure de vérifier l'usage de la suite de chiffrement en utilisant le défi chiffré compris dans les données de remplissage et ne peut toutefois pas déchiffrer les données applicatives.
[0031] Plus généralement, ce mode de réalisation permet à des dispositifs de communication d'apporter la preuve qu'ils utilisent une suite de chiffrement pour chiffrer leurs échanges sans pour autant compromettre la confidentialité des données applicatives échangées.
[0032] Selon ce mode de réalisation, l'entité de vérification obtient uniquement des messages échangés entre le premier et le deuxième dispositif comprenant un indicateur non-chiffré actif.
[0033] Plus précisément, les messages échangés entre les premier et deuxième dispositifs comprennent un indicateur non-chiffré, soit actif (e.g. égal à 1), soit non-actif (e.g. égale à 0), l'utilisation de l'indicateur non-chiffré dans les messages échangés étant notamment déclenchée par la réception du défi en provenance de l'entité de vérification.
[0034] Ce mode de réalisation permet de marquer les messages à traiter par l'entité de vérification pour vérifier l'usage de la suite de chiffrement. Autrement dit, les dispositifs de communication marquent avec un indicateur non-chiffré les messages permettant à l'entité de vérification de vérifier l'usage de la suite de chiffrement.
[0035] Par exemple, en combinaison avec le mode de réalisation précédent, les premier et deuxième dispositifs peuvent marquer, avec un indicateur non-chiffré actif, les messages de comprenant un défi chiffré dans les données remplissages et devant être capturés et relayés à l'entité de vérification par la sonde réseau. De la sorte, l'entité de vérification obtient et traite uniquement les messages permettant de vérifier l'usage de la suite de chiffrement.
[0036] Ainsi, ce mode de réalisation permet de vérifier l'usage de la suite de chiffrement par les premier et deuxième dispositifs de communication tout en limitant le nombre de messages à traiter par l'entité de vérification.
[0037] Selon un mode de réalisation, l'indicateur non-chiffré est compris dans l'en-tête des messages (i.e. paquets) échangés entre le premier et le deuxième dispositif.
[0038] En particulier, selon un mode de réalisation, le protocole QUIC est utilisé pour échanger des données entre le premier et le deuxième dispositif et l'indicateur non-chiffré est un bit, dit spin bit, compris dans l'en-tête des messages (i.e. paquets) échangés entre le premier et le deuxième dispositif.
[0039] Nous rappelons que le spin bit du protocole QUIC est usuellement utilisé pour mesurer la latence de communication entre deux dispositifs de communication. Toutefois, selon le mode de réalisation décrit ici, le spin bit est utilisé pour marquer les messages devant être traités par l'entité de vérification.
[0040] Ce mode de réalisation est notamment avantageux en ce qu'il permet, en détournant la fonction usuelle du spin bit, de marquer les messages devant être capturés par une sonde réseau et relayés à l'entité de vérification pour vérifier l'usage de la suite de chiffrement, sans avoir à inclure dans les messages échangés un marqueur supplémentaire.
[0041] Selon un mode de réalisation, l'entité de vérification vérifie une appartenance de l'identifiant de ladite suite de chiffrement à une liste (e.g. liste blanche) d'identifiants de suites de chiffrement considérées comme valides. Également, l'entité de vérification pourrait, selon un mode de réalisation, vérifier que l'identifiant de la suite de chiffrement n'appartient pas à une liste (e.g. liste noire) d'identifiants de suites de chiffrement considérées comme invalides (e.g. obsolètes, non-sécurisées, etc.).
[0042] Ce mode de réalisation permet de vérifier qu'une suite de chiffrement utilisée par des dispositifs de communication est conforme à des règles de sécurité définies.
[0043] Ainsi, ce mode de réalisation permet à une entité tiers (e.g. un opérateur réseau, un orchestrateur d'applications en réseau) de contrôler la sécurité des échanges entre des dispositifs de communication lors d'une connexion.
[0044] Selon un mode de réalisation, si au moins un résultat d'une dite vérification est négatif, l'entité de vérification envoie une instruction d'interruption des échanges entre le premier et le deuxième dispositif. À titre indicatif, l'instruction d'interruption peut notamment être envoyée à une entité de contrôle du réseau (i.e. une fonction réseau), et/ou au premier dispositif, et/ou au deuxième dispositif. [0045] Ce mode de réalisation permet d'interrompre les communications entre le premier et le deuxième dispositif, si la preuve d'usage de la suite de chiffrement fournie par les dispositifs est invalide (i.e. le résultat de la vérification d'usage est négatif) ou si la suite de chiffrement utilisée est obsolète. Il s'agit ainsi de ne pas compromettre la sécurité des échanges entre les dispositifs de communication.
[0046] Selon un autre aspect de l'invention, il est proposé un procédé de preuve d'usage d'une suite de chiffrement pour chiffrer des données échangées entre un premier dispositif et un deuxième dispositif dans un réseau de communication, le procédé étant mis en œuvre par le premier dispositif et comprenant : une réception, en provenance d'une entité de vérification, d'un défi ; un envoi, au deuxième dispositif, du défi ; une réception, en provenance du deuxième dispositif, du défi chiffré par le deuxième dispositif en utilisant une clé de chiffrement et ladite suite de chiffrement ; et un envoi, à l'entité de vérification, du défi chiffré.
[0047] Selon un autre aspect de l'invention, il est proposé un procédé de preuve d'usage d'une suite de chiffrement pour chiffrer des données échangées entre un premier dispositif et un deuxième dispositif dans un réseau de communication, le procédé étant mis en œuvre par le deuxième dispositif et comprenant : une réception, en provenance du premier dispositif, d'un défi ; un chiffrement du défi en utilisant une clé de chiffrement et ladite suite de chiffrement ; et un envoi, au premier dispositif ou à une entité de vérification, du défi chiffré.
[0048] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs envoie, à l'entité de vérification, une preuve de chiffrement comprenant : le défi chiffré ; la clé de chiffrement ; et un identifiant de la suite de chiffrement.
[0049] Dans le cadre de l’invention, d'autres modes de réalisation pourraient également être envisagés selon lesquels le défi chiffré, la clé de chiffrement et l'identifiant de la suite de chiffrement sont envoyés à l'entité de vérification par le premier dispositif et/ou le deuxième dispositif dans un ou plusieurs messages.
[0050] Selon un mode de réalisation, l'un des premier et deuxième dispositifs envoie à l'autre dispositif, au moins un message lors d'un établissement d'une connexion entre les premier et deuxième dispositifs, ledit au moins un message échangé comprenant un identifiant de la suite de chiffrement à utiliser.
[0051] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs dispositif chiffre au moins un message en utilisant la clé de chiffrement et la suite de chiffrement et envoie ledit au moins un message chiffré. [0052] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs chiffre au moins un message et obtient un code d'authentification de message associé audit au moins un message.
[0053] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs chiffre au moins un message comprenant des données applicatives et des données de remplissage, les données applicatives étant chiffrées en utilisant une autre clé de chiffrement distincte de la clé de chiffrement envoyée à l'entité de vérification, les données de remplissage comprenant le défi reçu en provenance de l'entité de vérification et étant chiffrées en utilisant la clé de chiffrement envoyée à l'entité de vérification.
[0054] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs marque avec un indicateur non-chiffré les messages envoyés devant être obtenus et traités par l'entité de vérification pour vérifier l'usage de la suite de chiffrement.
[0055] Selon un mode de réalisation, au moins un desdits premier et deuxième dispositifs reçoit au moins un message chiffré et déchiffre ledit au moins un message chiffré en utilisant la clé de chiffrement et la suite de chiffrement.
[0056] Selon un mode de réalisation, un protocole de type TLS est utilisé pour échanger des données entre le premier et le deuxième dispositif. Plus précisément, selon un mode de réalisation, le protocole TLS, DTLS, OSCORE, EDHOC, ou QUIC est utilisé pour échanger des données entre le premier et le deuxième dispositif.
[0057] Selon un mode de réalisation, le protocole QUIC est utilisé pour échanger des données entre le premier et le deuxième dispositif.
[0058] Selon un autre aspect de l'invention, il est proposé une entité de vérification d'usage d'une suite de chiffrement pour chiffrer des données échangées entre un premier dispositif et un deuxième dispositif dans un réseau de communication, l'entité de vérification comprenant : un module d'envoi configuré pour envoyer, au premier dispositif, un défi ; un module de réception configuré pour recevoir, en provenance du premier ou du deuxième dispositif, une clé de chiffrement et pour recevoir, en provenance du premier ou du deuxième dispositif, un défi chiffré par le deuxième dispositif ; et un module de vérification configuré pour vérifier un usage de ladite suite de chiffrement en utilisant au moins le défi envoyé, le défi chiffré reçu, la clé de chiffrement, et ladite suite de chiffrement.
[0059] Selon un autre aspect de l'invention, il est proposé un dispositif de communication, dit premier dispositif, comprenant : un premier module de réception configuré pour recevoir, en provenance d'une entité de vérification, un défi ; un premier module d'envoi configuré pour envoyer, au deuxième dispositif, le défi ; un deuxième module de réception configuré pour recevoir, en provenance du deuxième dispositif, le défi chiffré par le deuxième dispositif en utilisant une clé de chiffrement et une suite de chiffrement ; et un deuxième module d'envoi configuré pour envoyer, à l'entité de vérification, le défi chiffré.
[0060] Selon un autre aspect de l'invention, il est proposé un dispositif de communication, dit deuxième dispositif, comprenant : un module de réception configuré pour recevoir, en provenance du premier dispositif, un défi ; un module de chiffrement configuré pour chiffrer le défi en utilisant une clé de chiffrement et une suite de chiffrement ; et un module d'envoi configuré pour envoyer, au premier dispositif ou à une entité de vérification, le défi chiffré.
[0061] Selon un autre aspect de l'invention, il est proposé un terminal comprenant une entité de vérification conforme à l'invention ou un dispositif de communication conforme à l'invention.
[0062] Selon un aspect de l'invention, il est proposé un programme d'ordinateur comprenant des instructions pour la mise en œuvre des étapes d'un procédé conforme à l'invention, lorsque le programme d'ordinateur est exécuté par au moins un processeur ou un ordinateur.
[0063] Le programme d'ordinateur peut être formé d'une ou plusieurs sous-parties stockées dans une même mémoire ou dans des mémoires distinctes. Le programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
[0064] Selon un aspect de l'invention, il est proposé un support d'informations lisible par ordinateur comprenant un programme d'ordinateur conforme à l'invention.
[0065] Le support d'informations peut être n’importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu’une mémoire non-volatile ou ROM, par exemple un CD-ROM ou une ROM de circuit microélectronique, ou encore un moyen d’enregistrement magnétique, par exemple une disquette ou un disque dur. D’autre part, le support de stockage peut être un support transmissible tel qu’un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par un réseau de télécommunication ou par un réseau informatique ou par d’autres moyens. Le programme selon l’invention peut être en particulier téléchargé sur un réseau informatique. Alternativement, le support d’informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
[0066] Les procédés de preuve d'usage, l'entité de vérification, les dispositifs de communication, le terminal, le programme, et le support proposés disposent des avantages décrits ci-dessus en lien avec le procédé de vérification d'usage proposé.
Brève description des dessins
[0067] D'autres caractéristiques et avantages de la présente invention ressortiront de la description fournie ci-après, illustrant des modes de réalisation de l'invention donnés à titre d'exemple et dépourvus de tout caractère limitatif, en référence aux dessins ci-joints :
[0068] La figure 1 représente, sous forme d'ordinogramme, des étapes de procédés de preuve et de vérification d'usage d'une suite de chiffrement selon un mode de réalisation de l'invention ;
[0069] La figure 2 représente, sous forme d'ordinogramme, des étapes de procédés de preuve et de vérification d'usage d'une suite de chiffrement selon un mode de réalisation de l'invention ;
[0070] La figure 3A, la figure 3B et la figure 3C représentent des exemples de messages traitées et échangés par les dispositifs de communication selon des modes de réalisation de l'invention ;
[0071] La figure 4 représente un exemple d'architectures logicielles et matérielles d'une entité de vérification et de dispositifs de communication selon un mode de réalisation de l'invention ; et
[0072] La figure 5 représente un exemple d'architectures fonctionnelles d'une entité de vérification et de dispositifs de communication selon un mode de réalisation de l'invention.
Description des modes de réalisation
[0073] La solution proposée s'inscrit notamment dans un contexte dans lequel un dispositif de communication CLT (dit premier dispositif) et un dispositif de communication SRV (dit deuxième dispositif) échangent des données (i.e. des messages) de manière chiffrée par l'intermédiaire d'un réseau de communication NET. Pour ce faire, les dispositifs CLT et SRV chiffrent les données échangées en utilisant une suite de chiffrement CIPHER, i.e. l'ensemble d’algorithmes qui permettent de sécuriser les échanges.
[0074] Dans ce contexte, il s'agit en particulier de permettre à une entité de vérification CSC de déterminer et de prouver l'usage de la suite CIPHER pour chiffrer et déchiffrer des données échangées entre les dispositifs CLT et SRV. [0075] Aucune limitation n'est attachée au mécanisme de chiffrement utilisé pour chiffrer les données échangées entre les dispositifs de communication CLT et SRV. Par exemple, les dispositifs CLT et SRV utilisent, selon un mode de réalisation, un mécanisme chiffrement symétrique pour chiffrer des données échangées.
[0076] Il n'y a pas non plus d'hypothèse quant à la nature de l'entité de vérification CSC et des dispositifs de communication CLT et SRV. Ils peuvent être constitués par des équipements terminaux utilisés par les clients d'un opérateur réseau, comme par exemple, un décodeur numérique (ou « Set Top Box » (STB) en anglais), un équipement utilisateur (ou « User Equipment » (UE) en anglais), un ordinateur personnel (ou « Personal Computer » (PC) en anglais), un téléphone intelligent (ou « Smartphone » en anglais), une télévision connectée ou une tablette, mais également par des équipements gérés par un opérateur informatique ou un opérateur d'un réseau de télécommunications (par exemple, serveur, pare-feu, routeur), ces équipements pouvant être fixes ou mobiles. Les dispositifs de communication peuvent également être des applications logicielles, ou des instances de service hébergées dans un équipement.
[0077] À titre indicatif, au moins un élément parmi l'entité de vérification CSC et les dispositifs CLT et SRV est, selon un mode de réalisation, mis en œuvre par (ou compris dans) un terminal, tel qu'un téléphone mobile, par exemple un Smartphone, ou une tablette, ou un ordinateur.
[0078] En outre, aucune limitation n'est attachée à la nature du réseau de communication NET, qui peut être un réseau de téléphonie mobile (2G, 3G, 4G, 5G, 6G, etc.), un réseau informatique de type Internet, ou tout autre réseau (propriétaire, etc.) pouvant être envisagé.
[0079] La figure 1 représente, sous forme d'ordinogramme, des étapes de procédés de preuve et de vérification d'usage d'une suite de chiffrement pour chiffrer des données échangées entre un premier et un deuxième dispositif de communication selon un mode de réalisation de l'invention.
[0080] Tel qu'illustré par la figure 1, et selon un mode de réalisation de l'invention, les procédés de preuve et de vérification d'usage d'une suite de chiffrement proposés comprennent au moins une des étapes E10 à E110 décrites ci-dessous.
[0081] À l'étape E10, l'entité de vérification CSC envoie, au dispositif CLT, un défi CH (ou« challenge » en anglais). À titre d'exemple, le défi CH est une chaine de caractères.
[0082] À l'étape E20, le dispositif CLT envoie, au dispositif SRV, le défi CH reçu.
[0083] À l'étape E70, le dispositif SRV chiffre le défi CH en utilisant une suite de chiffrement CIPHER et une clé de chiffrement KEY, et obtient ainsi un défi chiffré ENC_CH.
[0084] À l'étape E80, le dispositif SRV envoie, au dispositif CLT, le défi chiffré ENC_CH. [0085] À l'étape E100, le dispositif CLT envoie, à l'entité de vérification CSC, la clé KEY et le défi chiffré ENC_CH.
[0086] À l'étape E110, l'entité de vérification CSC vérifie l'usage de la suite CIPHER en utilisant le défi CH, le défi chiffré ENC_CH, la clé KEY et la suite CIPHER.
[0087] Selon un mode de réalisation, l'entité de vérification CSC à l'étape E110 vérifie que le défi chiffré ENC_CH correspond au défi CH chiffré en utilisant la clé KEY et la suite CIPHER.
[0088] Par exemple, l'entité de vérification CSC déchiffre le défi chiffré ENC_CH et compare ensuite le défi déchiffré obtenu au défi CH envoyé. Si le défi déchiffré obtenu est identique au défi CH envoyé, alors la suite CIPHER a effectivement été utilisée par le dispositif SRV pour chiffrer le défi CH ; sinon, le résultat de la vérification est négatif et l'usage de la suite CIPHER n'a pas été prouvé.
[0089] Ainsi, la solution proposée décrite ici permet à l'entité de vérification CSC de vérifier que le dispositif SRV utilise la suite CIPHER pour chiffrer le défi CH et, corrélativement, permet à ce dispositif SRV d'apporter une preuve d'usage de la suite CIPHER.
[0090] D'une façon plus générale, et tel que décrit ci-après, la solution proposée permet à l'entité de vérification CSC de vérifier l'usage de la suite CIPHER pour chiffrer des données échangées entre les dispositifs CLT et SRV et, corrélativement, permet aux dispositifs CLT et SRV d'apporter une preuve d'usage de la suite CIPHER.
[0091] La figure 2 représente, sous forme d'ordinogramme, des étapes de procédés de preuve et de vérification d'usage d'une suite de chiffrement selon un mode de réalisation de l'invention.
[0092] Exemples d'application au protocole TLS ou OUIC : La figure 2 illustre, à titre d'exemple, un mode de réalisation de l'invention dans un contexte particulier d'application selon lequel l'un des protocoles TLS, DTLS, OSCORE, EDHOC ou QUIC est utilisé pour échanger des données entre les dispositifs CLT et SRV. L'exemple de réalisation fourni ci-après reprend, à ce titre, les étapes décrites en référence à la figure 1 dans ce contexte particulier d'application.
[0093] Selon cet exemple, le dispositif CLT (e.g. le client du protocole TLS/QUIC) initie et établit une connexion (ou une session de communication) avec le dispositif SRV (e.g. le serveur du protocole TLS/QUIC), pour échanger des données de manière sécurisée.
[0094] Nous désignons ici par l’acronyme TLS au moins une des versions suivantes du protocole « Transport Layer Security » : TLS 1.0 telle que définie par la RFC 2246 en janvier 1999 ; TLS 1.1 telle que définie par la RFC 4346 en avril 2006 ; TLS 1.2 telle que définie par la RFC 5246 en août 2008 ; ou TLS 1.3 telle que définie par la RFC 8446 en août 2018. [0095] Nous désignons ici par l'acronyme DTLS au moins une des versions suivantes du protocole « Datagram Transport Layer Security » : DTLS 1.2 telle que définie par la RFC 6347 ; ou DTLS 1.3 telle que définie par la RFC9147.
[0096] Nous désignons ici par l'acronyme OSCORE le protocole « Object Security for Constrained RESTful Environments » tel que défini par la RFC8613.
[0097] Nous désignons par l'acronyme EDHOC le protocole, utilisé notamment pour les terminaux de type Internet des Objets (ou « Internet of Things » en anglais), « Ephemeral Diffie-Hellman Over COSE » tel que défini dans le document « draft-ietf-lake-edhoc-15 » publié par I' « Internet Engineering Task Force » et accessible au lien suivant : https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/.
[0098] Et, par le terme QUIC, nous désignons au moins une des versions du protocole de transport QUIC telles que définies par : la RFC 8999 en mai 2021 ; la RFC 9000 en mai 2021 ; la RFC 9001 en mai 2021 ; la RFC 9002 en mai 2021 ; la RFC 9221 en mars 2022.
[0099] Établissement d'une connexion entre les dispositifs CLT et SRV : Tel qu'illustré par la figure 2, et selon un mode de réalisation de l'invention, les procédés de preuve et de vérification d'usage d'une suite de chiffrement proposés comprennent au moins une des étapes E10 à E120 décrites ci-dessous.
[0100] À l'étape E10, l'entité de vérification CSC envoie, au dispositif CLT, un défi CH.
[0101] À l'étape Eli, selon un mode de réalisation particulier, le dispositif CLT active l'utilisation d'un indicateur non-chiffré SPINBIT pour les messages échangés avec le dispositif SRV, cette activation étant déclenchée par la réception du défi CH à l'étape E10. L'utilisation de cet indicateur SPINBIT est décrite plus en détails ci-dessous en référence à la figure 3B.
[0102] À l'étape E20, le dispositif CLT envoie, au dispositif SRV, un message CLT_HELLO pour initier une connexion avec celui-ci. Le message CLT_HELLO comprend le défi CH, reçu en provenance de l'entité de vérification CSC. En outre, le message CLT_HELLO comprend selon un mode de réalisation : le ou les identifiants des suites de chiffrement pouvant être utilisées par le dispositif CLT ; et une chaîne d'octets aléatoires (dite « client random » en anglais).
[0103] À l'étape E30, le dispositif SRV envoie, au dispositif CLT, un message SRV_HELLO en réponse au message CLT_HELLO. Plus particulièrement, le message SRV_HELLO comprend selon un mode de réalisation : un identifiant de la suite de chiffrement CIPHER choisie par le dispositif SRV pour la connexion ; et une autre chaîne aléatoire d’octets (dite « server random » en anglais). Selon un mode de réalisation particulier, le message SRV_HELLO comprend en outre un paramètre d'obtention de clé de chiffrement, utilisée par exemple par l'algorithme d'échange de clés Diffie-Helman pour obtenir une clé de chiffrement. [0104] Il convient de souligner que le message SRV_HELLO indique ainsi d'utiliser la suite CIPHER pour chiffrer et déchiffrer les données échangées entre les dispositifs CLT et SRV lors de la connexion.
[0105] Plus précisément, une suite CIPHER est définie par un identifiant décrivant les algorithmes de la suite. Un exemple d'identifiant d'une de suite de chiffrement est le suivant : TLS_DH_RSA_WITH_AES_256_GCM_SHA384. La signification de cet identifiant est la suivante: TLS définit le protocole pour lequel cette suite de chiffrement est destinée ; DH indique l’algorithme d’échange de clés utilisé ; RSA est le mécanisme d'authentification utilisé lors de l'établissement de la connexion ; AES est le chiffrement utilisé lors de la connexion ; 256 (bits) est la taille de la clé de chiffrement ; GCM est le type de chiffrement ; SHA est la fonction de hachage utilisé pour le mécanisme de d'authentification des messages ; et 384 (bits) est la taille du condensé utilisé pour signer les messages.
[0106] À l'étape E31, selon un mode de réalisation particulier, l'entité de vérification CSC obtient le message SRV_HELLO. L'entité de vérification CSC obtient ainsi l'identifiant de la suite CIPHER utilisée par les dispositifs CLT et SRV lors de la connexion. L'entité de vérification CSC obtient, selon un mode de réalisation, le message SRV_HELLO en utilisant une sonde réseau qui capture ce message sur le réseau NET et le relaie à l'entité de vérification CSC.
[0107] À l'étape E40, le dispositif CLT envoie, au dispositif SRV, un message CLT_KEY_EXG comprenant : selon un mode de réalisation, un secret pré-maitre (ou « premaster secret » en anglais) ; ou selon un autre mode de réalisation un paramètre d'obtention de clé.
[0108] À l'étape E50, les dispositifs CLT et SRV obtiennent respectivement une clé KEY pour la connexion (dite également clé de session). À titre d'exemple, les dispositifs CLT et SRV utilise un algorithme d'échange et de dérivation de clés, tel que Diffie-Hellman, pour obtenir la clé KEY à partir du client random, du server random et des paramètres d'obtention de clé précités. Selon un autre exemple, les dispositifs CLT et SRV obtiennent la clé KEY à partir du client random, du server random et du secret pré-maître.
[0109] À l'étape E60, le dispositif CLT envoie, au dispositif SRV, un message chiffré CLT_FSH en utilisant la clé KEY et la suite CIPHER. Selon un mode de réalisation, suite à la réception du message CLT_FSH, le dispositif SRV déchiffre ce message en utilisant la clé KEY, puis vérifie l'intégrité du message déchiffré. Ainsi, le dispositif SRV vérifie que le dispositif CLT a correctement obtenu la même clé KEY.
[0110] À l'étape E70, le dispositif SRV chiffre le défi CH, reçu en provenance du dispositif CLT, en utilisant la clé KEY et la suite CIPHER et obtient, de la sorte, un défi chiffré ENC_CH. [OUI] À l'étape E80, le dispositif SRV envoie, au dispositif CLT, le défi chiffré ENC_CH. Plus particulièrement, le dispositif SRV ajoute, selon un mode de réalisation, le défi chiffré ENC_CH à un message envoyé au dispositif CLT et comprenant un ticket de session.
[0112] À l'étape E90, le dispositif SRV envoie, au dispositif CLT, un message SRV_FSH chiffré en utilisant la clé KEY et la suite CIPHER. Selon un mode de réalisation, suite à la réception du message SRV_FSH, le dispositif CLT déchiffre ce message en utilisant la clé KEY, puis vérifie l'intégrité du message déchiffré. Ainsi, le dispositif CLT vérifie que le dispositif SRV a correctement obtenu la même clé KEY.
[0113] Dans le cadre de l'invention, il pourrait également être envisagé un mode de réalisation selon lequel les étapes E80 et E90 sont réalisées de manière concomitante.
[0114] Dans un mode de réalisation les étapes E20 à E90 constituent un établissement de la connexion HSK (ou « handshake » en anglais) entre les dispositifs CLT et SRV.
[0115] Nous rappelons que l'invention s'applique notamment aux protocoles TLS, DTLS, OSCORE, EDHOC et QUIC, de telle sorte que les dispositifs CLT et SRV peuvent établir une connexion conformément à ces protocoles et, à ce titre, peuvent mettre en œuvre toute étape nécessaire à rétablissement de la connexion.
[0116] Selon un mode de réalisation particulier, l'entité de vérification CSC obtient, notamment en utilisant la sonde réseau, tout ou partie des messages échangés entre les dispositifs CLT et SRV durant l'établissement de la connexion HSK, par en exemple en utilisant une sonde réseau tel que décrit ci-avant en référence à l'étape E31.
[0117] À l'étape E100, le dispositif CLT envoie, à l'entité de vérification CSC, une preuve de chiffrement PRF comprenant : la clé de chiffrement KEY ; le défi chiffré ENC_CH ; et l'identifiant de la suite CIPHER. La preuve de chiffrement PRF comprend en outre, selon un mode de réalisation, le défi CH. Selon un mode de réalisation particulier, l'entité de vérification CSC obtient la clé KEY et l'identifiant de la suite CIPHER par réception de la preuve de chiffrement PRF. Toutefois, il pourrait être envisagé d'autres modes de réalisation de l'invention dans lesquels la clé KEY et/ou la suite CIPHER sont prédéterminées ou sont obtenues par l'entité de vérification CSC en utilisant une sonde réseau dans un ou plusieurs messages échangés entre les dispositifs CLT et SRV, par exemple comme décrit en référence à l'étape E31.
[0118] À l'étape E110, l'entité de vérification CSC vérifie l'usage de la suite CIPHER en utilisant la preuve de chiffrement PRF. Selon un mode de réalisation, l'étape E110 comprend au moins une des étapes El 11 et El 12 décrites ci-après. [0119] À l'étape Elll, l'entité de vérification CSC vérifie que la preuve de chiffrement PRF est valide. Plus particulièrement, l'entité de vérification CSC vérifie à l'étape Elll que le défi chiffré ENC_CH correspond au défi CH chiffré en utilisant la clé KEY et la suite CIPHER.
[0120] À l'étape E112, l'entité de vérification CSC vérifie la validité de la suite CIPHER, notamment en vérifiant que l'identifiant de la suite CIPHER appartient à une liste d'identifiants de suites de chiffrement considérées comme valides (i.e. considérées comme conformes à des règles de sécurité définies). L'entité de vérification CSC pourrait également, selon un mode de réalisation, vérifier à l'étape E112 que l'identifiant de la suite CIPHER n'appartient pas à une liste (e.g. liste noire ou « blacklist » en anglais) d'identifiants de suites de chiffrement considérées comme invalides (e.g. obsolètes, non-sécurisées, etc.). L'étape E112 permet ainsi de vérifier que la suite CIPHER utilisée est conforme aux règles de sécurité définies.
[0121] À l'étape E120, si le résultat de la vérification à l'étape E110 est négatif, l'entité de vérification CSC envoie une instruction d'interruption des échanges entre les dispositifs CLT et SRV. L'instruction d'interruption peut notamment être envoyée au dispositif CLT, et/ou au dispositif SRV, et/ ou à une entité de contrôle du réseau (i.e. une fonction réseau). L'étape E120 permet d'interrompre les communications entre les deux dispositifs CLT et SRV, si la preuve PRF est invalide ou si la suite CIPHER est obsolète. Ainsi, cette étape permet avantageusement de ne pas compromettre la sécurité des communications entre les dispositifs CLT et SRV.
[0122] La solution proposée telle que décrite ci-dessus permet à l'entité de vérification CSC de déterminer et de vérifier l'usage de la suite CIPHER lors de la connexion entre les dispositifs CLT et SRV pour chiffrer des données échangées. Corrélativement, la solution proposée permet aux dispositifs CLT et SRV de prouver à l'entité de vérification CSC qu'ils utilisent la suite CIPHER pour chiffrer les échanges lors de la connexion.
[0123] Plus particulièrement, la solution proposée permet à l'entité de vérification CSC de vérifier que la suite CIPHER annoncée lors de l'établissement de la connexion HSK est effectivement utilisée par les dispositifs CLT et SRV et que celle-ci est conforme à des règles de sécurités.
[0124] Communications entre les dispositifs CLT et SRV : Tel qu'illustré par la figure 2, et selon un mode de réalisation de l'invention, les procédés de preuve et de vérification d'usage d'une suite de chiffrement proposés comprennent au moins une des étapes E130 à E150 décrites ci- dessous. Ce mode de réalisation peut, bien évidemment, être combiné aux modes de réalisation précédemment décrits.
[0125] Suite à l'établissement de la connexion entre les dispositifs CLT et SRV décrit ci-dessus, ces derniers communiquent de manière chiffrée en utilisant la clé KEY et la suite CIPHER. [0126] À l'étape E130, les dispositifs CLT et SRV échangent un message chiffré ENC_MSG. En particulier, le message chiffré ENC_MSG est obtenu en chiffrant un message MSG en utilisant au moins la clé KEY et la suite CIPHER. L'obtention du message chiffré ENCJ SG par un des dispositifs CLT et SRV à partir du message MSG est notamment décrite plus en détails ci-après en référence aux figures 3A et 3B.
[0127] À l'étape E131, l'entité de vérification CSC obtient le message chiffré ENCJ SG, par exemple en utilisant une sonde réseau capturant le message chiffré ENC_MSG sur le réseau NET et relayant celui-ci à l'entité de vérification CSC.
[0128] À l'étape E140, l'entité de vérification CSC vérifie l'usage de la suite CIPHER en utilisant le message chiffré ENC_MSG. Selon un mode de réalisation, l'étape E140 comprend une étape E141 décrite ci-après.
[0129] À l'étape E141, l'entité de vérification CSC vérifie que la suite CIPHER a été utilisée pour obtenir le message chiffré ENC_MSG. L'étape E141 est notamment décrite plus en détails ci- après en référence aux figures 3A et 3B.
[0130] À l'étape E150, si le résultat de la vérification à l'étape E140 est négatif, l'entité de vérification CSC envoie une instruction d'interruption des échanges entre les dispositifs CLT et SRV. L'instruction d'interruption peut notamment être envoyée au dispositif CLT, et/ou au dispositif SRV, et/ou à une entité de contrôle du réseau (i.e. une fonction réseau). L'étape E150 permet d'interrompre les communications entre les deux dispositifs CLT et SRV, si le message ENCJ SG n'est pas chiffré avec la suite CIPHER. Ainsi, cette étape permet avantageusement de ne pas compromettre la sécurité des communications entre les dispositifs CLT et SRV.
[0131] La solution proposée telle que décrite ci-dessus permet à l'entité de vérification CSC de vérifier que les dispositifs CLT et SRV utilisent effectivement la suite CIPHER pour chiffrer et déchiffrer des données échangées.
[0132] Vérification d'usage lors de l'établissement de la connexion et/ou lors de communications : Il est important de souligner que, dans le cadre de l'invention, l'entité de vérification CSC peut vérifier l'usage de la suite CIPHER : soit lors de l'établissement de la connexion entre les dispositifs CLT et TLS (conformément aux modes de réalisation décrits en référence aux étapes E10 à E120) ; soit lors de communications (i.e. une fois la connexion établie) entre les dispositifs CLT et SRV (conformément aux modes de réalisation décrits en référence aux étapes E130 à E150) ; ou encore les deux.
[0133] Ainsi, la solution proposée permet d'apporter la preuve de l'usage de la suite CIPHER par les dispositifs CLT et SRV quel que soit l'instant de la connexion. [0134] Les figures 3A, 3B et 3C représentent des exemples de messages traitées et échangées par les dispositifs de communication selon des modes de réalisation de l'invention.
[0135] Tel que précédemment mentionné, selon un mode de réalisation, les dispositifs CLT et SRV échangent à l'étape E130 un ou plusieurs messages chiffrés ENC_MSG, ces messages étant capturés par une sonde réseau et relayés à l'entité de vérification CSC à l'étape E131. Ensuite, l'entité de vérification CSC vérifie à l'étape E141 que la suite de chiffrement CIPHER a été utilisée pour obtenir le ou les messages chiffrés ENC_MSG.
[0136] Aussi, nous décrivons ci-dessous en référence aux figures 3A, 3B et 3C respectivement trois modes de réalisation des étapes E130 et E141.
[0137] Selon un premier mode de réalisation illustré par la figure 3A, le message chiffré ENC_MSG, échangé à l'étape E130 entre les dispositifs CLT et SRV, est obtenu par chiffrement d'un message MSG en utilisant la suite CIPHER et la clé KEY.
[0138] Plus précisément, le message MSG comprend : des données DATA et un code d'authentification de message MAC. De ce fait, le message chiffré ENC_MSG comprend : des données chiffrées ENC_DATA ; et un code chiffré ENC_MAC
[0139] Le code MAC permet de vérifier l'intégrité du message MSG. Par exemple, le code d'authentification de message MAC est obtenu à partir des données DATA en utilisant un algorithme de signature, tel qu'une fonction de hachage. Ce mode de réalisation met ainsi en œuvre une technique de chiffrement et d'authentification dite « mac-then-encrypt » en anglais.
[0140] Lors de l'étape E141, l'entité de vérification CSC déchiffre le message chiffré ENC_MSG en utilisant la clé KEY et la suite CIPHER, puis vérifie l'intégrité du message déchiffré MSG en utilisant les données DATA et le code MAC.
[0141] Ainsi, ce mode de réalisation permet à l'entité de vérification CSC de vérifier que la suite CIPHER est effectivement utilisée pour chiffrer des messages échangés entre les dispositifs CLT et SRV.
[0142] Selon un deuxième mode de réalisation illustré par la figure 3B, le message chiffré ENCJ SG, échangé à l'étape E130 entre les dispositifs CLT et SRV, est obtenu à partir du message MSG en utilisant la suite CIPHER et la clé KEY.
[0143] Plus précisément, le message MSG comprend : des données DATA. Et, le message chiffré ENCJ SG comprend : des données chiffrées DATA ; et un code d'authentification de message MAC permettant de vérifier l'intégrité du message MSG.
[0144] Selon ce mode de réalisation, les données chiffrées ENC_DATA sont obtenues par chiffrement des données DATA en utilisant la suite CIPHER et la clé KEY ; et le code MAC est obtenu en utilisant une fonction de hachage à partir des données DATA et/ou de données associées. Ce mode de réalisation permet notamment de mettre en œuvre une technique de chiffrement et d'authentification dite « encrypt-and-mac » en anglais et, plus particulièrement, une technique dite « Authenticated Encryption with Associated Data » en anglais.
[0145] Lors de l'étape E141, l'entité de vérification CSC déchiffre le message chiffré ENC_MSG (i.e. les données chiffrées ENC_DATA) en utilisant la clé KEY et la suite CIPHER, puis vérifie l'intégrité du message déchiffré MSG en utilisant les données DATA et le code MAC.
[0146] Ce mode de réalisation permet ainsi à l'entité de vérification CSC de vérifier que la suite CIPHER est effectivement utilisée pour chiffrer des messages échangés entre les dispositifs CLT et SRV.
[0147] Selon un troisième mode de réalisation illustré par la figure 3C, le message chiffré ENCJ SG échangé à l'étape E130 entre les dispositifs CLT et SRV comprend : des données applicatives chiffrées ENC_DATA_APP ; et des données de remplissage chiffrées ENC_DATA_PAD.
[0148] Les données applicatives chiffrées ENC_DATA_APP sont, selon un mode de réalisation, obtenues en chiffrant des données applicatives DATA_APP en utilisant la suite CIPHER et une clé de chiffrement KEY' distincte de la clé KEY susmentionnée.
[0149] Les données de remplissage chiffrées ENC_DATA_PAD sont, selon un mode de réalisation, obtenues en chiffrant des données de remplissage DATA_PAD (également dites de bourrage, par exemple des données aléatoires) en utilisant la suite CIPHER et la clé KEY. Plus particulièrement, les données de remplissage DATA_PAD comprennent le défi CH.
[0150] Lors de l'étape E141, l'entité de vérification CSC déchiffre les données de remplissage chiffrées ENC_DATA_PAD en utilisant la clé KEY et la suite CIPHER, puis vérifie la correspondance entre le défi CH compris dans les données de remplissage déchiffrées DATA_PAD et le défi CH tel qu'envoyé par l'entité de vérification CSC au dispositif CLT.
[0151] Ainsi, ce mode de réalisation permet à l'entité de vérification CSC de vérifier l'usage de la suite CIPHER pour chiffrer des messages échangés entre les dispositifs CLT et SRV, tout en préservant la confidentialité des données applicatives DATA_APP communiquées entre les dispositifs CLT et SRV.
[0152] Bien évidemment, les premier, deuxième et troisième modes de réalisation décrits ci- dessus peuvent être combinés. Il pourrait en effet être envisagé que les dispositifs CLT et SRV échangent, au cours du temps, un ou plusieurs messages MSG selon le premier mode de réalisation, et/ou un ou plusieurs messages MSG selon le deuxième mode de réalisation, et/ou un ou plusieurs messages MSG selon le troisième mode de réalisation. Dans ce cas, l'entité de vérification CSC vérifie, à partir d'un ou plusieurs messages capturés, l'usage de la suite CIPHER selon le premier, le second, ou le troisième mode de réalisation en fonction du ou des messages chiffrés capturés.
[0153] Utilisation de l'indicateur non-chiffré SPINBIT : Selon un mode de réalisation illustré par la figure 3C, un ou plusieurs messages échangés entre les dispositifs CLT et SRV comprennent un indicateur non-chiffré SPINBIT, actif (e.g. égal à 1) ou non-actif (e.g. égal à 0). Comme indiqué précédemment, l'utilisation de l'indicateur SPINBIT est, selon un mode de réalisation, déclenchée à l'étape Eli par la réception du défi CH à l'étape E10.
[0154] Ainsi, selon un mode de réalisation, l'entité de vérification CSC obtient (e.g. par capture) uniquement des messages échangés entre les dispositifs CLT et SRV comprenant un indicateur non-chiffré SPINBIT actif (e.g. égal à 1), puis vérifie l'usage de la suite CIPHER à partir du ou des messages obtenus. Ce mode de réalisation permet de vérifier l'usage de la suite CIPHER tout en limitant le nombre de messages à obtenir et traiter par l'entité de vérification CSC.
[0155] Par exemple, les dispositifs CLT et SRV activent l'indicateur non-chiffré SPINBIT pour les messages ENC_MSG comprenant le défi CH dans les données de remplissage DATA_PAD. De la sorte, l'entité de vérification CSC obtient à l'étape E131 ces messages ENC_MSG dont l'indicateur SPINBIT est actif, puis vérifie l'usage de la suite CIPHER à partir du ou des messages ENC_MSG obtenus.
[0156] Selon un autre exemple, les dispositifs CLT et SRV activent l'indicateur non-chiffré SPINBIT pour les messages ne comprenant pas de données applicatives (i.e. message de contrôle), tels que les messages échangés lors de l'établissement de la connexion HSK entre les dispositifs CLT et SRV. Ainsi, l'entité de vérification CSC obtient (e.g. avec la sonde réseau) les messages lors de l'établissement de la connexion HSK, notamment le message SRV_HELLO à l'étape E31, ce qui permet à l'entité de vérification d'identifier la suite CIPHER utilisée pour la connexion.
[0157] En outre, tel que précédemment mentionné, la solution proposée s'applique notamment au protocole QUIC. Dans le cadre de ce protocole, l'indicateur non-chiffré SPINBIT est, selon un mode de réalisation, le bit dit « spin bit » du protocole QUIC.
[0158] Nous rappelons que le spin bit du protocole QUIC est un bit non-chiffré de l'en-tête des paquets (i.e. messages) QUIC. Le spin bit est usuellement utilisé pour mesure la latence de communication entre deux dispositifs. Toutefois, selon le mode de réalisation décrit ici, le spin bit est utilisé pour marquer les messages devant être capturés par une sonde réseau et relayés à l'entité de vérification CSC. À titre d'exemple non-limitatif, l'usage du spin bit pour mesurer la latence peut, selon ce mode de réalisation, être limité aux messages échangés lors de l'établissement de la connexion HSK.
[0159] La figure 4 représente un exemple d'architecture logicielle et matérielle d'une entité de vérification et de dispositifs de communication selon un mode de réalisation de l'invention. [0160] Tel qu'illustré par la figure 4, selon un mode de réalisation, l'entité de vérification CSC, les dispositifs de communication CLT et SRV sont reliés par l'intermédiaire d'un réseau de communication NET.
[0161] L'entité de vérification CSC dispose, selon un mode de réalisation illustré par la figure 4, de l'architecture matérielle d'un ordinateur et comporte : un processeur PROC_CSC, une mémoire vive, une mémoire morte MEM_CSC, et une mémoire non volatile. La mémoire MEM_CSC constitue un support d'informations conforme à l'invention, lisible par ordinateur et par le processeur PROC_CSC, sur lequel est enregistré un programme d'ordinateur PROG_CSC conforme à l'invention. Le programme d'ordinateur PROG_CSC comporte des instructions pour réaliser des étapes d'un procédé de vérification d'usage d'une suite de chiffrement conforme à l'invention et mises en œuvre par l'entité de vérification CSC, lorsque le programme d'ordinateur PROG_CSC est exécuté par le processeur PROC_CSC.
[0162] Tel qu'illustré par la figure 4, l'entité de vérification CSC dispose, selon un mode de réalisation, d'un module de communication COM_CSC configuré pour communiquer avec au moins un des dispositifs de communication CLT et SRV par l'intermédiaire du réseau NET.
[0163] Aucune limitation n’est attachée à la nature des interfaces de communication entre l'entité de vérification CSC et les dispositifs de communication CLT et SRV, qui peuvent être filaire ou non filaire, et peuvent mettre en œuvre tout protocole connu de l’homme du métier (Ethernet, Wi-Fi, Bluetooth, 3G, 4G, 5G, 6G, etc.).
[0164] Le dispositif de communication CLT (dit premier dispositif) dispose, selon un mode de réalisation illustré par la figure 4, de l'architecture matérielle d'un ordinateur et comporte : un processeur PROC_CLT, une mémoire vive, une mémoire morte MEM_CLT, et une mémoire non volatile. La mémoire MEM_CLT constitue un support d'informations conforme à l'invention, lisible par ordinateur et par le processeur PROC_CLT, sur lequel est enregistré un programme d'ordinateur PROG_CLT conforme à l'invention. Le programme d'ordinateur PROG_CLT comporte des instructions pour réaliser des étapes d'un procédé de preuve d'usage d'une suite de chiffrement conforme à l'invention et mises en œuvre par le dispositif de communication CLT, lorsque le programme d'ordinateur PROG_CLT est exécuté par le processeur PROC_CLT.
[0165] Tel qu'illustré par la figure 4, le dispositif CLT dispose, selon un mode de réalisation, d'un module de communication COM_CLT configuré pour communiquer avec l'entité de vérification CSC et/ou le dispositif de communication SRV.
[0166] Le dispositif de communication SRV (dit deuxième dispositif) dispose, selon un mode de réalisation illustré par la figure 4, de l'architecture matérielle d'un ordinateur et comporte : un processeur PROC_SRV, une mémoire vive, une mémoire morte MEM_SRV, et une mémoire non volatile. La mémoire MEM_SRV constitue un support d'informations conforme à l'invention, lisible par ordinateur et par le processeur PROC_SRV, sur lequel est enregistré un programme d'ordinateur PROG_SRV conforme à l'invention. Le programme d'ordinateur PROG_SRV comporte des instructions pour réaliser des étapes d'un procédé de preuve d'usage d'une suite de chiffrement conforme à l'invention et mises en œuvre par le dispositif de communication SRV, lorsque le programme d'ordinateur PROG_SRV est exécuté par le processeur PROC_SRV.
[0167] Tel qu'illustré par la figure 4, le dispositif SRV dispose, selon un mode de réalisation, d'un module de communication COM_SRV configuré pour communiquer avec l'entité de vérification CSC et/ou le dispositif de communication CLT.
[0168] La figure 5 représente un exemple d'architectures fonctionnelles d'une entité de vérification et de dispositifs de communication selon un mode de réalisation de l'invention.
[0169] Dans la description ci-après, les modules référencés ME_XX sont compris dans l'entité de vérification CSC, les modules référencés MC_XX sont compris dans le dispositif CLT, et les modules référencés MS_XX sont compris dans le dispositif SRV.
[0170] L'entité de vérification CSC comprend, selon un mode de réalisation, des modules respectivement configurés pour mettre en œuvre les étapes d'un procédé de vérification d'usage d'une suite de chiffrement conforme à l'invention.
[0171] En particulier, l'entité de vérification CSC, selon un mode de réalisation illustré par la figure 5, comprend au moins un des modules suivants : un module d'envoi ME_TX configuré pour envoyer un défi CH au dispositif CLT ; un module de réception ME_RX configuré pour recevoir la preuve de chiffrement PRF en provenance du dispositif CLT ; un module d'obtention ME_CPT configuré pour obtenir des messages échangés entre les dispositifs CLT et SRV, comprenant notamment : un premier module d'obtention ME_CPT1 configuré pour obtenir au moins un message échangé SRV_HELLO entre les dispositifs CLT et SRV lors d'un établissement d'une connexion HSK ; un deuxième module d'obtention ME_CPT2 configuré pour obtenir au moins un message chiffré ENC_MSG échangé entre les dispositifs CLT et SRV ; un module de déchiffrement ME_DEC configuré pour déchiffrer au moins un message chiffré ENC_MSG obtenu en utilisant la clé KEY et la suite CIPHER. un module de vérification ME_CHK configuré pour vérifier l'usage de la suite CIPHER en utilisant le défi CH, le défi chiffré ENC_CH, la clé KEY, et la suite de chiffrement CIPHER, et comprenant notamment : un premier module de vérification ME_CHK1 configuré pour vérifier une correspondance entre le défi chiffré ENC_CH et le défi CH chiffré en utilisant la clé KEY et la suite CIPHER ; un deuxième module de vérification ME_CHK2 configuré pour vérifier l'intégrité d'au moins un message MSG déchiffré en utilisant au moins un code d'authentification de message ; un troisième module de vérification ME_CHK3 configuré pour vérifier une correspondance entre un défi compris dans un message MSG déchiffré et le défi CH. un quatrième module de vérification ME_CHK4 configuré pour vérifier une appartenance de l'identifiant de la suite CIPHER à une liste d'identifiants de suites de chiffrement considérées comme valides ; un module d'interruption de communications ME_STP configuré pour, si au moins un résultat d'une dite vérification est négatif, envoyer une instruction d'interruption des échanges entre dispositif CLT et SRV.
[0172] Le dispositif CLT (dit premier dispositif) comprend, selon un mode de réalisation, des modules respectivement configurés pour mettre en œuvre les étapes d'un procédé de preuve d'usage d'une suite de chiffrement conforme à l'invention.
[0173] En particulier, le dispositif CLT comporte, selon un mode de réalisation illustré par la figure 5, au moins un des modules suivants : un module d'envoi MC_TX configuré pour envoyer des messages au dispositif SRV et/ou à l'entité de vérification CSC, comprenant notamment :
- un premier module d'envoi MC_TX1 configuré pour envoyer le défi CH au dispositif SRV ;
- un deuxième module d'envoi MC_TX2 configuré pour envoyer la preuve de chiffrement PRF à l'entité de vérification CSC ;
- un troisième module d'envoi MC_TX3 configuré pour envoyer au moins un message chiffré ENCJ SG au dispositif SRV ; un module de réception MC_RX configuré pour recevoir des messages en provenance du dispositif SRV et/ou de l'entité de vérification CSC, comprenant notamment
- un premier module de réception MC_RX1 configuré pour recevoir le défi CH en provenance de l'entité de vérification ;
- un deuxième module de réception MC_RX2 configuré pour recevoir le défi chiffré ENC_CH en provenance du dispositif SRV ; et
- un troisième module de réception MC_RX3 configuré pour recevoir au moins un message chiffré ENCJ SG en provenance du dispositif SRV ; un module de chiffrement MC_ENC configuré pour chiffrer au moins un message MSG en utilisant la clé KEY, la suite CIPHER et, selon un mode de réalisation, la clé KEY' ; un module de déchiffrement MC_DEC configuré pour déchiffrer au moins un message chiffré ENC_MSG en utilisant la clé KEY, la suite CIPHER et, selon un mode de réalisation, la clé KEY' ; et un module de marquage MC_MRK configuré pour activer l'indicateur non-chiffré SPINBIT dans des messages envoyés au dispositif SRV.
[0174] Le dispositif SRV (dit deuxième dispositif) comprend, selon un mode de réalisation, des modules respectivement configurés pour mettre en œuvre les étapes d'un procédé de preuve d'usage d'une suite de chiffrement conforme à l'invention.
[0175] En particulier, le dispositif SRV comporte, selon un mode de réalisation illustré par la figure 5, au moins un des modules suivants : un module d'envoi MS_TX configuré pour envoyer des messages au dispositif CLT, comprenant notamment :
- un premier module d'envoi MS_TX1 configuré pour envoyer le défi chiffré ENC_CH au dispositif CLT ;
- un deuxième module d'envoi MS_TX2 configuré pour envoyer un message SRV_HELLO au dispositif CLT lors de l'établissement de la connexion HSK ; et
- un troisième module d'envoi MS_TX3 configuré pour envoyer au moins un message chiffré ENC_MSG au dispositif CLT ; un module de réception MS_RX configuré pour recevoir des messages en provenance du dispositif CLT, comprenant notamment :
- un premier module de réception MS_RX1 configuré pour recevoir un défi CH en provenance du dispositif CLT ; et
- un deuxième module de réception MS_RX2 configuré pour recevoir au moins un message chiffré ENC_MSG en provenance du dispositif CLT ; un module de chiffrement MS_ENC configuré pour chiffrer des messages, comprenant notamment :
- un premier module de chiffrement MS_ENC1 configuré pour chiffrer le défi CH en utilisant la clé KEY et la suite CIPHER ;
- un deuxième module de chiffrement MS_ENC2 configuré pour chiffrer au moins un message MSG en utilisant la clé KEY, la suite CIPHER et, selon un mode de réalisation, la clé KEY' ; un module de déchiffrement MS_DEC configuré pour déchiffrer au moins un message chiffré ENC_MSG en utilisant la clé KEY, la suite CIPHER et, selon un mode de réalisation, la clé KEY' ; et un module de marquage MS_MRK configuré pour activer l'indicateur non-chiffré SPINBIT dans des messages envoyés au dispositif CLT.
[0176] Le terme module peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
[0177] Il est à noter que l'ordre dans lequel s'enchaînent les étapes d'un procédé conforme à l'invention, notamment en référence aux dessins ci-joints, ne constitue qu'un exemple de réalisation dépourvu de tout caractère limitatif, des variantes étant possibles. Par ailleurs, les signes de référence ne sont pas limitatifs de l'étendue de la protection, leur unique fonction étant de facilité la compréhension des revendications.

Claims

Revendications
1. Procédé de vérification d'usage d'une suite de chiffrement (CIPHER) pour chiffrer des données (MSG, CH) échangées lors d'une connexion entre un premier dispositif (CLT) et un deuxième dispositif (SRV) dans un réseau de communication (NET), le procédé étant mis en œuvre par une entité de vérification (CSC) et comprenant : un envoi (E10), au premier dispositif (CLT), d'un défi (CH) ; une réception (E100), en provenance du premier (CLT) ou du deuxième dispositif (SRV), d'une clé de chiffrement (KEY) ; une réception (E100), en provenance du premier (CLT) ou du deuxième dispositif (SRV), d'un défi chiffré (ENC_CH) par le deuxième dispositif (SRV) ; et une vérification (E110) d'un usage de ladite suite de chiffrement (CIPHER) en utilisant au moins le défi envoyé (CH), le défi chiffré reçu (ENC_CH), la clé de chiffrement (KEY), et ladite suite de chiffrement (CIPHER).
2. Procédé selon la revendication 1, comprenant une obtention (E31, E100) d'un identifiant de ladite suite de chiffrement (CIPHER) dans au moins un message (SRV_HELLO, PRF) envoyé par le premier (CLT) ou le deuxième dispositif (SRV).
3. Procédé selon la revendication 2, dans lequel l'identifiant de ladite suite de chiffrement (CIPHER) est obtenu (E31) dans au moins un message (SRV_HELLO) échangé entre le premier (CLT) et le deuxième dispositif (SRV) lors d'un établissement d'une connexion (HSK), ledit au moins un message (SRV_HELLO) indiquant d'utiliser ladite suite de chiffrement (CIPHER).
4. Procédé selon l'une des revendications 1 à 3, comprenant : une obtention (E131) d'au moins un message chiffré (ENCJ SG) échangé entre le premier (CLT) et le deuxième dispositif (SRV) ; un déchiffrement dudit au moins un message chiffré obtenu (ENCJ SG) en utilisant la clé de chiffrement (KEY) et ladite suite de chiffrement (CIPHER) ; et une vérification (E141) d'une intégrité dudit au moins un message déchiffré (MSG) en utilisant au moins un code d'authentification de message (MAC) associé audit au moins un message déchiffré (MSG).
5. Procédé selon l'une des revendications 1 à 4, comprenant : une obtention (E131) d'au moins un message chiffré (ENCJ SG), échangé entre le premier (CLT) et le deuxième dispositif (SRV), comprenant : des données applicatives chiffrées (ENC_DATA_APP) en utilisant une autre clé de chiffrement (KEY') distincte de ladite clé de chiffrement reçue (KEY) ; et des données de remplissage chiffrées (ENC_DATA_PAD) en utilisant la clé de chiffrement reçue (KEY), lesdites données de remplissage (DATA_PAD) comprenant le défi (CH) envoyé au premier dispositif (CLT) ; un déchiffrement desdites données de remplissage chiffrées (ENC_DATA_PAD) en utilisant la clé de chiffrement reçue (KEY) et ladite suite de chiffrement (CIPHER) ; et une vérification (E141) d'une correspondance entre le défi (CH) compris dans lesdites données de remplissage déchiffrées (DATA_PAD) et le défi envoyé (CH) au premier dispositif (CLT). Procédé selon l'une des revendications 3 à 5, dans lequel l'entité de vérification (CSC) obtient (E31, E131) uniquement des messages échangés entre le premier (CLT) et le deuxième dispositif (SRV) (HSK, ENC_MSG) comprenant un indicateur non-chiffré (SPINBIT) actif. Procédé selon la revendication 6, dans lequel l'indicateur non chiffré (SPINBIT) est compris dans l'en-tête des messages échangés (HSK, ENC_MSG). Procédé selon l'une des revendications 1 à 7, comprenant une vérification (E112) d'une appartenance de l'identifiant de ladite suite de chiffrement (CIPHER) à une liste d'identifiants de suites de chiffrement considérées comme valides. Procédé selon l'une des revendications 1 à 8, comprenant, si au moins un résultat d'une dite vérification (Elll, E112, E141) est négatif, un envoi (E120, E150) d'une instruction d'interruption des échanges entre le premier (CLT) et le deuxième dispositif (SRV). Procédé de preuve d'usage d'une suite de chiffrement (CIPHER) pour chiffrer des données (MSG, CH) échangées lors d'une connexion entre un premier dispositif (CLT) et un deuxième dispositif (SRV) dans un réseau de communication (NET), le procédé étant mis en œuvre par le premier dispositif (CLT) et comprenant : une réception (E10), en provenance d'une entité de vérification (CSC), d'un défi (CH) ; un envoi (E20), au deuxième dispositif (SRV), d'un message d'initiation de connexion (CLT_HELLO) comprenant le défi (CH) ; une réception (E80), en provenance du deuxième dispositif (SRV), du défi chiffré (ENC_CH) par le deuxième dispositif (SRV) en utilisant une clé de chiffrement (KEY) et ladite suite de chiffrement (CIPHER) ; et un envoi (E100), à l'entité de vérification (CSC), du défi chiffré (ENC_CH).
11. Procédé de preuve d'usage d'une suite de chiffrement (CIPHER) pour chiffrer des données (MSG, CH) échangées lors d'une connexion entre un premier dispositif (CLT) et un deuxième dispositif (SRV) dans un réseau de communication (NET), le procédé étant mis en œuvre par le deuxième dispositif (SRV) et comprenant : une réception (E20), en provenance du premier dispositif (CLT), d'un message d'initiation de connexion (CLT_HELLO) comprenant un défi (CH) ; un chiffrement (E70) du défi (CH) en utilisant une clé de chiffrement (KEY) et ladite suite de chiffrement (CIPHER) ; et un envoi (E80), au premier dispositif (CLT) ou à une entité de vérification (CSC), du défi chiffré (ENC_CH).
12. Procédé selon l'une des revendications 1 à 11, dans lequel un protocole de type TLS est utilisé pour échanger des données (MSG) entre le premier (CLT) et le deuxième dispositif (SRV).
13. Entité de vérification (CSC) d'usage d'une suite de chiffrement (CIPHER) pour chiffrer des données (MSG, CH) échangées lors d'une connexion entre un premier dispositif (CLT) et un deuxième dispositif (SRV) dans un réseau de communication (NET), l'entité de vérification (CSC) comprenant : un module d'envoi (ME_TX) configuré pour envoyer (E10), au premier dispositif (CLT), un défi (CH) ; un module de réception (ME_RX) configuré pour recevoir (E100), en provenance du premier (CLT) ou du deuxième dispositif (SRV), une clé de chiffrement (KEY) et pour recevoir (E100), en provenance du premier (CLT) ou du deuxième dispositif (SRV), un défi chiffré (ENC_CH) par le deuxième dispositif (SRV) ; et un module de vérification (ME_CHK) configuré pour vérifier (E110) un usage de ladite suite de chiffrement (CIPHER) en utilisant au moins le défi envoyé (CH), le défi chiffré reçu (ENC_CH), la clé de chiffrement (KEY), et ladite suite de chiffrement (CIPHER).
14. Dispositif de communication (CLT), dit premier dispositif, comprenant : un premier module de réception (MC_RX1) configuré pour recevoir (E10), en provenance d'une entité de vérification (CSC), un défi (CH) ; un premier module d'envoi (MC_TX1) configuré pour envoyer (E20), au deuxième dispositif (SRV), un message d'initiation de connexion (CLT_HELLO) comprenant le défi (CH) ; un deuxième module de réception (MC_RX2) configuré pour recevoir (E80), en provenance du deuxième dispositif (SRV), le défi chiffré (ENC_CH) par le deuxième dispositif (SRV) en utilisant une clé de chiffrement (KEY) et une suite de chiffrement (CIPHER) ; et un deuxième module d'envoi (MC_TX2) configuré pour envoyer (E100), à l'entité de vérification (CSC), le défi chiffré (ENC_CH). Dispositif de communication (SRV), dit deuxième dispositif, comprenant : un module de réception (MS_RX1) configuré pour recevoir (E20), en provenance du premier dispositif (CLT), un message d'initiation de connexion (CLT_HELLO) comprenant un défi (CH) ; un module de chiffrement (MS_ENC1) configuré pour chiffrer (E70) le défi (CH) en utilisant une clé de chiffrement (KEY) et une suite de chiffrement (CIPHER) ; et un module d'envoi (MS_TX1) configuré pour envoyer (E80), au premier dispositif (CLT) ou à une entité de vérification (CSC), le défi chiffré (ENC_CH). Terminal comprenant une entité de vérification (CSC) selon la revendication 13 ou un dispositif de communication (CLT, SRV) selon la revendication 14 ou 15. Programme d'ordinateur (PROG_CSC, PROG_CLT, PROG_SRV) comportant des instructions pour la mise en œuvre des étapes d'un procédé selon l'une quelconque des revendications 1 à
12, lorsque ledit programme d'ordinateur (PROG_CSC, PROG_CLT, PROG_SRV) est exécuté par au moins un processeur (PROC_CSC, PROC_CLT, PROC_SRV).
EP23772537.9A 2022-09-29 2023-09-25 Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés Pending EP4595355A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2209940A FR3140503A1 (fr) 2022-09-29 2022-09-29 Procédés de preuve et de vérification d’usage d’une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d’ordinateur associés
PCT/EP2023/076320 WO2024068498A1 (fr) 2022-09-29 2023-09-25 Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés

Publications (1)

Publication Number Publication Date
EP4595355A1 true EP4595355A1 (fr) 2025-08-06

Family

ID=85037154

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23772537.9A Pending EP4595355A1 (fr) 2022-09-29 2023-09-25 Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés

Country Status (3)

Country Link
EP (1) EP4595355A1 (fr)
FR (1) FR3140503A1 (fr)
WO (1) WO2024068498A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9422389D0 (en) * 1994-11-05 1995-01-04 Int Computers Ltd Authenticating access control for sensitive functions
EP1391073B8 (fr) * 2001-05-01 2018-09-05 OneSpan International GmbH Procédé et système d'augmentation de la sécurité d'une connection sécurisée
US8166534B2 (en) * 2007-05-18 2012-04-24 Microsoft Corporation Incorporating network connection security levels into firewall rules
CN104065486A (zh) * 2014-07-04 2014-09-24 山东超越数控电子有限公司 一种加密策略匹配算法模块验证平台及其实现方法

Also Published As

Publication number Publication date
FR3140503A1 (fr) 2024-04-05
WO2024068498A1 (fr) 2024-04-04

Similar Documents

Publication Publication Date Title
FR2916592A1 (fr) Procede de securisation d'echange d'information,dispositif, et produit programme d'ordinateur correspondant
WO2007115982A2 (fr) Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants
FR3002398A1 (fr) Procede de creation d'un profil dans un domaine de securite d'un element securise
WO2011039460A2 (fr) Procede et dispositifs de communications securisees dans un reseau de telecommunications
EP3613186A1 (fr) Système et procédé de communications
FR2906096A1 (fr) Procede de securisation de sessions entre un terminal radio et un equipement dans un reseau
CN114726520B (zh) 一种密钥确定方法及装置
EP3456025B1 (fr) Technique d'authentification d'un dispositif utilisateur
EP3917073A1 (fr) Établissement efficace de sessions sécurisées pour l'anonymat dans les réseaux 5g
WO2023110614A1 (fr) Procédés et dispositifs facilitant l'appairage wi-fi sécurisé
EP4595355A1 (fr) Procédés de preuve et de vérification d'usage d'une suite de chiffrement, entité de vérification, dispositifs de communication, terminal, et programme d'ordinateur associés
EP2868130A1 (fr) Mise en place d'une association de securite lors de l'attachement d'un terminal a un reseau d'acces
EP3662692B1 (fr) Obtention d'un profil d'accès à un réseau de communication par un terminal secondaire via un terminal principal
EP4062584A1 (fr) Procede securise d'echange de donnees entre un terminal et un serveur
WO2018065707A1 (fr) Procédé et dispositif de détection d'intrusions sur un réseau utilisant un algorithme de chiffrement homomorphe
EP2710779A1 (fr) Procede de securisation d'une platforme d'authentification, dispositifs materiels et logiciels correspondants
EP4338375A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
US12549366B2 (en) IPCON MCData session establishment method
CN114553507B (zh) 一种安全认证方法、装置、设备及机器可读存储介质
WO2002065413A1 (fr) Module d'identification pourvu d'un code d'authentification securise
EP4718891A1 (fr) Procédés pour charger un profil de communication dans un élément sécurisé, élément sécurisé, serveur et dispositif de communication associés
US20230169185A1 (en) Device Independent Crypto Engine
FR3143148A1 (fr) Procédés d’authentification mutuelle, dispositif électronique, système et programmes d’ordinateur associés.
FR3144730A1 (fr) Procédé de transmission sécurisée d'un élément secret entre un premier équipement de télécommunication et au moins un deuxième équipement de télécommunication
CN119030693A (zh) 数据发送方法和装置、存储介质和电子装置

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250414

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)