FR3140503A1 - 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 Download PDF

Info

Publication number
FR3140503A1
FR3140503A1 FR2209940A FR2209940A FR3140503A1 FR 3140503 A1 FR3140503 A1 FR 3140503A1 FR 2209940 A FR2209940 A FR 2209940A FR 2209940 A FR2209940 A FR 2209940A FR 3140503 A1 FR3140503 A1 FR 3140503A1
Authority
FR
France
Prior art keywords
srv
clt
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
FR2209940A
Other languages
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
Priority to FR2209940A priority Critical patent/FR3140503A1/fr
Priority to PCT/EP2023/076320 priority patent/WO2024068498A1/fr
Publication of FR3140503A1 publication Critical patent/FR3140503A1/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

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)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (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) ; etune 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). Figure pour l’abrégé : Fig. 1

Description

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
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
L’invention se place en particulier dans le contexte du chiffrement des communications entre deux dispositifs de communication dans un réseau.
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.
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.
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.
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.
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.
S elon 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
À 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.
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.
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.
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é.
À 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.
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.
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.
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.
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é.
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é.
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.
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.
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.
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é.
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.
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.
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.
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.
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.
Selon un mode de réalisation, le protocole QUIC est utilisé pour échanger des données entre le premier et le deuxième dispositif.
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.
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é.
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é.
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.
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.
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.
Selon un aspect de l’invention, il est proposé un support d’informations lisible par ordinateur comprenant un programme d’ordinateur conforme à l’invention.
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.
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é.
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 :
La 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 ;
La 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 ;
La , la et la 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 ;
La 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
La 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.
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.
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.
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.
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.
À 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.
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é.
La 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.
Tel qu’illustré par la , 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.
À 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.
À l’étape E20, le dispositif CLT envoie, au dispositif SRV, le défi CH reçu.
À 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.
À l’étape E80, le dispositif SRV envoie, au dispositif CLT, le défi chiffré ENC_CH.
À l’étape E100, le dispositif CLT envoie, à l’entité de vérification CSC, la clé KEY et le défi chiffré ENC_CH.
À 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.
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.
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é.
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.
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.
La 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.
Exemples d’a pplication au protocole TLS ou QUIC :La 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 dans ce contexte particulier d’application.
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.
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.
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.
Nous désignons ici par l’acronyme OSCORE le protocole « Object Security for Constrained RESTful Environments » tel que défini par la RFC8613.
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 l’ « Internet Engineering Task Force » et accessible au lien suivant : https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/.
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.
É tablissement d’une connexion entre les dispositifs CLT et SRV :Tel qu’illustré par la , 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.
À l’étape E10, l’entité de vérification CSC envoie, au dispositif CLT, un défi CH.
À l’étape E11, 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 .
À 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).
À 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.
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.
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.
À 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.
À 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é.
À 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.
À 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.
À 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.
À 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.
À 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.
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.
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.
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 à l’établissement de la connexion.
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.
À 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.
À 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 E111 et E112 décrites ci-après.
À l’étape E111, 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 E111 que le défi chiffré ENC_CH correspond au défi CH chiffré en utilisant la clé KEY et la suite CIPHER.
À 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.
À 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.
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.
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.
Communications entre les dispositifs CLT et SRV :Tel qu’illustré par la , 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.
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.
À 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é ENC_MSG 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.
À l’étape E131, l’entité de vérification CSC obtient le message chiffré ENC_MSG, 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.
À 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.
À 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.
À 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 ENC_MSG 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.
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.
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.
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.
Les figures 3A , 3B et 3Creprésentent des exemples de messages traitées et échangées par les dispositifs de communication selon des modes de réalisation de l’invention.
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.
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.
Selon un premier mode de réalisationillustré par la , 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.
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
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.
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.
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.
Selon un deuxième mode de réalisationillustré par la , le message chiffré ENC_MSG, é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.
Plus précisément, le message MSG comprend : des données DATA. Et, le message chiffré ENC_MSG 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.
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.
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.
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.
Selon un troisième mode de réalisationillustré par la , le message chiffré ENC_MSG é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.
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.
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.
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.
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.
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.
Utilisation de l’indicateur non-chiffré SPINBIT: Selon un mode de réalisation illustré par la , 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 E11 par la réception du défi CH à l’étape E10.
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.
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.
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.
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.
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.
La 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.
Tel qu’illustré par la , 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.
L ’entité de vérification CSCdispose, selon un mode de réalisation illustré par la , 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.
Tel qu’illustré par la , 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.
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.).
L e dispositif de communication CLT(dit premier dispositif) dispose, selon un mode de réalisation illustré par la , 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.
Tel qu’illustré par la , 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.
L e dispositif de communication SRV(dit deuxième dispositif) dispose, selon un mode de réalisation illustré par la , 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.
Tel qu’illustré par la , 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.
La 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.
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.
L’entité de vérification CSCcomprend, 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.
En particulier, l’entité de vérification CSC, selon un mode de réalisation illustré par la , 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.
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.
En particulier, le dispositif CLT comporte, selon un mode de réalisation illustré par la , 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é ENC_MSG 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é ENC_MSG 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.
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.
En particulier, le dispositif SRV comporte, selon un mode de réalisation illustré par la , 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.
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.).
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 (17)

  1. Procédé 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) 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é (ENC_MSG) échangé entre le premier (CLT) et le deuxième dispositif (SRV) ;
    • un déchiffrement dudit au moins un message chiffré obtenu (ENC_MSG) 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é (ENC_MSG), é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).
  6. 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.
  7. 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).
  8. 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.
  9. Procédé selon l’une des revendications 1 à 8, comprenant, si au moins un résultat d’une dite vérification (E111, 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).
  10. Procédé de preuve 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) 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), du 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 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 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 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), 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).
  15. 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 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).
  16. 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.
  17. 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).
FR2209940A 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 Pending FR3140503A1 (fr)

Priority Applications (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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2209940 2022-09-29
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

Publications (1)

Publication Number Publication Date
FR3140503A1 true FR3140503A1 (fr) 2024-04-05

Family

ID=85037154

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2209940A Pending 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

Country Status (2)

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

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0711051A1 (fr) * 1994-11-05 1996-05-08 International Computers Limited Sytème de traitement de données avec vérification de l'authenticité des algorithmes cryptographiques selon le principe Challenge-Response
US20020166048A1 (en) * 2001-05-01 2002-11-07 Frank Coulier Use and generation of a session key in a secure socket layer connection
US20080289027A1 (en) * 2007-05-18 2008-11-20 Microsoft Corporation Incorporating network connection security levels into firewall rules
CN104065486A (zh) * 2014-07-04 2014-09-24 山东超越数控电子有限公司 一种加密策略匹配算法模块验证平台及其实现方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0711051A1 (fr) * 1994-11-05 1996-05-08 International Computers Limited Sytème de traitement de données avec vérification de l'authenticité des algorithmes cryptographiques selon le principe Challenge-Response
US20020166048A1 (en) * 2001-05-01 2002-11-07 Frank Coulier Use and generation of a session key in a secure socket layer connection
US20080289027A1 (en) * 2007-05-18 2008-11-20 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
WO2024068498A1 (fr) 2024-04-04

Similar Documents

Publication Publication Date Title
EP1903746B1 (fr) Procédé de sécurisation de sessions entre un terminal radio et un équipement dans un réseau
US11848961B2 (en) HTTPS request enrichment
EP3613186B1 (fr) Système et procédé de communications
KR101430851B1 (ko) 노드들 사이에서 적어도 부분적으로 수행되는 암호화된 통신의 적어도 일부의 검사를 허용하기 위한 노드들 사이에서의 보안 통신 채널의 적어도 부분적인 설정
FR2916592A1 (fr) Procede de securisation d'echange d'information,dispositif, et produit programme d'ordinateur correspondant
EP2484084B1 (fr) Procédé et dispositifs de communications securisées contre les attaques par innondation et denis de service (dos) dans un réseau de télécommunications
GB2518255A (en) Communicating with a machine to machine device
EP3232632A1 (fr) Procédé et système d'acquisition de texte en clair de données secrètes de réseau
EP2012907A2 (fr) Procede de protection d'identite, dispositifs, et produit programme d'ordinateur correspondants
WO2010007267A1 (fr) Procede pour securiser des echanges entre un noeud demandeur et un noeud destinataire
EP3456025A1 (fr) Technique d'authentification d'un dispositif utilisateur
FR3140503A1 (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
FR2992811A1 (fr) Mise en place d'une association de securite lors de l'attachement d'un terminal a un reseau d'acces
CN113950802B (zh) 用于执行站点到站点通信的网关设备和方法
US20240097903A1 (en) Ipcon mcdata session establishment method
FR3081653A1 (fr) Procede de modification de messages par un equipement sur un chemin de communication etabli entre deux noeuds
CN114553507B (zh) 一种安全认证方法、装置、设备及机器可读存储介质
EP3662692B1 (fr) Obtention d'un profil d'accès à un réseau de communication par un terminal secondaire via un terminal principal
EP3917073A1 (fr) Établissement efficace de sessions sécurisées pour l'anonymat dans les réseaux 5g
WO2022238644A1 (fr) Procede de defense contre une tentative de deconnexion entre deux entites, systeme associe
CN117220914A (zh) 加解密方法及装置
Caparra Security for the signaling plane of the SIP protocol
FR2899047A1 (fr) Autorisation de deconnexion entre un terminal d'usager et un point d'acces dans un reseau local sans fil
WO2014140456A1 (fr) Procédé, dispositif et programme d'ordinateur pour optimiser la création d'un domaine applicatif sécurisé entre un système informatique et une entité électronique
FR2900776A1 (fr) Procede de securisation de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240405