EP4751418A1 - Méthode et dispositif de vérification de la fiabilité de noeuds de communication de données d'un réseau superposé - Google Patents

Méthode et dispositif de vérification de la fiabilité de noeuds de communication de données d'un réseau superposé

Info

Publication number
EP4751418A1
EP4751418A1 EP24748375.3A EP24748375A EP4751418A1 EP 4751418 A1 EP4751418 A1 EP 4751418A1 EP 24748375 A EP24748375 A EP 24748375A EP 4751418 A1 EP4751418 A1 EP 4751418A1
Authority
EP
European Patent Office
Prior art keywords
node
group key
operator
nodes
authentication code
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
EP24748375.3A
Other languages
German (de)
English (en)
Inventor
Pierre Roux
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.)
Commissariat à l'Énergie Atomique et Aux Énergies Alternatives
Original Assignee
Commissariat a lEnergie Atomique CEA
Commissariat à l'Énergie Atomique et Aux Énergies Alternatives
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 Commissariat a lEnergie Atomique CEA, Commissariat à l'Énergie Atomique et Aux Énergies Alternatives filed Critical Commissariat a lEnergie Atomique CEA
Publication of EP4751418A1 publication Critical patent/EP4751418A1/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/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
    • H04L63/0435—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 wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065—Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/3236—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 cryptographic hash functions
    • H04L9/3242—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 cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC

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)
  • Power Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un dispositif de vérification de la fiabilité de nœuds de communication d'un réseau superposé composé d'une pluralité de groupes de nœuds de communication, chaque groupe étant opéré par un opérateur différent, et une clé de groupe secrète étant associée à chaque opérateur. Les nœuds sont configurés pour émettre et recevoir des paquets de données, à destination et en provenance de nœuds de la pluralité de groupes. Le procédé consiste à réaliser une attestation logicielle à distance implicite qui est combinée avec les échanges de données entre les nœuds du réseau superposé, en permettant d'inclure un code d'authentification dans chaque paquet de données échangé. Chaque nœud qui reçoit un paquet de données reçoit en même temps la preuve de l'état logiciel légitime du nœud émetteur. Dans le cas où la légitimité du nœud émetteur ne peut pas être prouvée, le paquet est ignoré.

Description

DESCRIPTION
TITRE : Méthode et dispositif de vérification de la fiabilité de nœuds de communication de données d’un réseau superposé
Domaine de l’invention
[0001] La présente invention concerne le domaine de la sécurité et de la fiabilité des réseaux de communications numériques, et plus particulièrement la sécurité et la fiabilité de réseaux superposés.
Etat de la technique
[0002] Un réseau de communications numérique est typiquement constitué de nœuds de communications opérés par divers opérateurs afin de fournir un ensemble de services aux usagers de ce réseau. Les nœuds du réseau peuvent être par exemple des routeurs IP.
[0003] On appelle « réseaux superposés » ou « overlay networks » en anglais, des sous-ensembles de réseaux numériques regroupant un sous-ensemble de nœuds dédiés à des services de plus haut niveau. On peut citer, comme exemple de tels réseaux superposés, les réseaux de serveurs SMTP (acronyme de « Simple Mail Transfer Protocol » en anglais) qui fournissent des services d’envois de messages de type courriel, ou encore citer le réseau TOR (acronyme de « Tor Onion Routing » en anglais) qui fournit à ses utilisateurs un service d’anonymisation.
[0004] La sécurité des réseaux superposés est un sujet sensible, car des cyberattaques sur ces réseaux compromettent les services qu’ils fournissent à leurs utilisateurs, voire compromettent les utilisateurs eux-mêmes. Il en est ainsi quand par exemple un réseau superposé TOR qui fournit un service d’anonymisation, est la cible de cyberattaques effectives, l’anonymat des utilisateurs est alors compromis.
[0005] Les réseaux superposés « sensibles » intègrent souvent des contre-mesures pour déjouer voire éviter dans la mesure du possible, toute faille susceptible de permettre des cyberattaques efficaces.
[0006] L’une de ces contre-mesures consiste en des mécanismes d’attestation logicielle à distance, auxquels peuvent être soumis les nœuds du réseau superposé. [0007] L’attestation logicielle à distance d’un nœud permet de s’assurer à distance, qu’un nœud du réseau n’est pas compromis, et que son statut logiciel et matériel est connu et légitime.
[0008] L’attestation logicielle à distance n’est possible que si le nœud cible dispose de caractéristiques matérielles qui la rendent possible.
[0009] Cette assertion peut parfois être remise en cause, dans la mesure où il existe des approches qui tentent de contourner cette règle, cependant l’efficacité de telles approches est limitée, et elles ne sont pas considérées ici.
[0010] On peut citer par exemple comme caractéristique matérielle pour activer une attestation logicielle à distance, l’existence d’un module TPM (acronyme de « Trusted Platform Module » en anglais) sur la plateforme matérielle associée au nœud.
[0011] Des caractéristiques matérielles différentes permettent aussi de rendre possible une attestation logicielle à distance. On peut citer comme autre exemple la solution SGX (acronyme de « Software Guard Extensions » en anglais) proposée par la société Intel® et intégrée aux microprocesseurs Intel®.
[0012] Les modules TPM ont été standardisés par le TCG (acronyme de « Trusted Computing Group » en anglais) et sont en première approche, assimilables à une carte à puce (« smartcard ») attachée à la plateforme (à la différence par exemple d’une carte SIM).
[0013] Un module TPM détient/stocke des secrets cryptographiques qui ne sont connus de personne (si l’on omet le fabriquant du module TPM qui n’est pas sensé archiver ce secret), pas même connus de l’administrateur du nœud.
[0014] L’exploitation d’un module TPM pour réaliser une attestation logicielle à distance est présentée dans différents documents de la littérature.
[0015] Une attestation logicielle à distance suppose l’intervention d’un certain nombre de services opérés par des acteurs indépendants et supportés par des serveurs. Plusieurs de ces services peuvent être pris en charge dans un même serveur. On retrouve ainsi des services de vérification et d’évaluation lors d’une opération d’attestation logicielle. [0016] Un service de vérification est pris en charge par une machine serveur qui doit s’assurer à distance de la non-compromission de noeuds cibles. Un vérificateur obtient d’une machine cible son « état logiciel » tel qu’observé par le module TPM sur le nœud cible, attesté par le fabriquant de ce module TPM. Cet état est caractéristique d’un historique logiciel sur ce nœud qui prend la forme d’un certain nombre de « digests » cryptographiques. Sans être exhaustif, on peut citer entre autres, un digest calculé sur l’image du système d’exploitation OS (acronyme de « Operating System » en anglais) qui a été chargé, et un autre digest calculé sur un ensemble d’autres digests associés à tous les exécutables lancés sur la machine, à l’instant de la demande de vérification logicielle.
[0017] A partir d’un ensemble de digests de vérification, le service de vérification peut faire appel à un service d’évaluation pour déterminer quels sont les digests approuvés et quels sont ceux inconnus, voire explicitement désapprouvés. Sur la base de ce retour, le service de vérification peut statuer sur le statut du nœud cible : soit il est approuvé, soit il est potentiellement compromis. Il est entendu que l’information retournée par le service d’évaluation doit être « signée » par l’entité en charge de l’administration du service.
[0018] Le service de vérification peut être amené à faire des vérifications régulières sur le statut de tous les nœuds d’un réseau superposé, et à mettre à la disposition des clients des services du réseau superposé, une liste des nœuds approuvés et des nœuds non approuvés. Cette liste doit évidemment être signée par l’entité en charge du service d’évaluation, étant entendu que plusieurs services de vérification administrés par des entités séparées peuvent coexister, de sorte que les clients des différents services de vérification peuvent choisir celui auquel ils donnent leur confiance, voire choisir plusieurs de ces services pour combiner les résultats.
[0019] Les clients des services fournis par le réseau superposé peuvent finalement être amenés, avant tout usage du réseau superposé, à obtenir une évaluation du statut de tous les nœuds du réseau, et à décider de limiter leur utilisation du réseau aux seuls nœuds qui sont approuvés et considérés comme fiables.
[0020] Par ailleurs, au cours de l’utilisation d’un réseau superposé, les clients peuvent renouveler la liste des nœuds fiables en faisant de nouveau appel à un ou des services de vérification, de façon à mettre à jour le statut des noeuds utilisés, et à mettre un terme à l’utilisation de noeuds qui auraient perdu leur statut de nœud fiable.
[0021] Néanmoins, ce système présente une limite puisqu’à tout moment un nœud qui était évalué comme fiable peut ne plus l’être.
[0022] Et quelle que soit la cadence avec laquelle les nœuds utilisés sont réévalués, il subsiste le risque de l’utilisation d’un ou plusieurs nœuds non fiables, pendant un certain laps de temps, fût-il court.
[0023] Aussi, il existe un besoin d’une solution appropriée pour surmonter un tel risque.
[0024] La présente invention répond à ce besoin.
Résumé de l’invention
[0025] Un but de la présente invention est de remédier aux inconvénients précités des approches connues, en proposant un procédé et un dispositif associé, qui lève le risque de l’utilisation d’un nœud corrompu dans un réseau superposé.
[0026] Avantageusement, la présente invention offre une solution à ce problème en permettant une réactivité immédiate lors de la détection qu’un nœud devient corrompu, en interrompant directement les échanges de données avec ce nœud corrompu.
[0027] Le principe général de l’invention pour vérifier la fiabilité des nœuds d’un réseau superposé, consiste à réaliser une attestation logicielle à distance implicite qui est combinée avec les échanges de données entre les nœuds du réseau superposé.
[0028] La présente invention permet d’inclure un code d’authentification dans chaque datagramme ou paquet de données échangé, de telle sorte que chaque nœud qui reçoit un paquet de données reçoit en même temps la preuve de l’état logiciel « légitime » du nœud émetteur du paquet de données.
[0029] Dans le cas où la légitimité du nœud émetteur ne peut pas être prouvée dans un paquet de données qui est reçu par un nœud récepteur, le paquet est alors ignoré. [0030] Avantageusement, la présente invention permet d’assurer à la fois l’intégrité du datagramme mais aussi la non-compromission logicielle du nœud au moment où il a produit ce datagramme.
[0031] Dans une option de réalisation, un rapport peut être généré par le nœud récepteur avant d’ignorer un paquet reçu compromis, permettant ainsi de disposer dans le nœud d’une statistique concernant les nœuds fiables et les autres.
[0032] Si l’utilisateur d’un réseau superposé dispose d’une machine terminale qui est capable d’évaluer un code d’authentification, elle peut alors être configurée pour ignorer tout paquet reçu qui est suspicieux.
[0033] Dans un mode de réalisation où les paquets émis sont destinés à se propager de bond en bond dans le réseau superposé, et si l’un des nœuds intermédiaires n’est pas légitime, alors le prochain nœud légitime de la route met fin à la propagation des paquets.
[0034] L’invention trouvera des applications avantageuses dans de nombreux domaines techniques où des réseaux superposés sont utilisés.
[0035] Ainsi, les réseaux superposés d’anonymisation constituent une application intéressante de la présente invention. En effet, dans le contexte d’un réseau d’anonymisation, le caractère « non réactif » des solutions d’attestation logicielle à distance de l’art antérieur pose le problème que la compromission d’un nœud peut être exploitée dans les quelques secondes suivant la compromission, et dès lors contribuer à casser l’anonymat d’un utilisateur servi par le nœud compromis. La présente invention permet d’éviter ce risque.
[0036] Pour obtenir les résultats recherchés, il est proposé un dispositif de vérification de la fiabilité de nœuds de communication d’un réseau superposé, le réseau superposé comprenant une pluralité de groupes de nœuds de communication, chaque groupe de nœuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les nœuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de nœuds de la pluralité de groupes. Le dispositif comprend : - des moyens de calcul configurés pour qu’un nœud d’un groupe opéré par un opérateur, calcule un code d’authentification sur la base des données d’un paquet à émettre et de la clé de groupe secrète dudit opérateur, le calcul du code d’authentification étant effectué dans une enclave matérielle sécurisée dudit nœud, stockant une copie de chaque clé de groupe secrète associée auxdits opérateurs ; - des moyens d’insertion configurés pour insérer dans un paquet de données à émettre un code d’authentification calculé dans l’enclave matérielle du nœud émetteur ; - des moyens de comparaison configurés pour comparer un code d’authentification contenu dans un paquet de données reçu, avec un code d’authentification calculé sur la base des données du paquet reçu et de la clé de groupe secrète de l’opérateur dudit nœud émetteur, ledit calcul du code d’authentification étant effectué dans l’enclave matérielle sécurisée du nœud récepteur ; et - des moyens de validation configurés pour valider ou rejeter un paquet de données reçu par un nœud récepteur, selon le résultat de la comparaison des codes d’authentification.
[0037] Le dispositif peut être implémenté selon différents modes de réalisation.
[0038] Dans un mode de réalisation, les moyens de calcul sont configurés pour calculer un code d’authentification avec une fonction de hachage cryptographique basée sur le contenu binaire d’un paquet de données et de la clé de groupe secrète de l’opérateur d’un nœud émetteur.
[0039] Dans un mode de réalisation, le dispositif comprend de plus des moyens configurés pour recevoir une copie de chaque clé de groupe secrète desdits opérateurs.
[0040] Dans un mode de réalisation, les moyens pour recevoir une copie d’une clé de groupe secrète, sont configurés pour communiquer avec un gestionnaire de clé de groupe de chaque opérateur, chacun desdits gestionnaires de clé de groupe étant configuré pour effectuer une attestation logicielle à distance d’un nœud, à réception d’une requête de clé de groupe secrète par ledit nœud.
[0041] Dans un mode de réalisation, l’enclave matérielle sécurisée est un module matériel dont les caractéristiques sont standardisées selon les spécifications des plateformes sécurisées TPM définies par le consortium « Trusted Computing Group ». [0042] Dans un mode de réalisation, l’enclave matérielle sécurisée comprend de plus des moyens configurés pour mettre en oeuvre un mécanisme de scellé sur des registres de configuration de plateforme PCR.
[0043] Dans un mode de réalisation, le dispositif comprend de plus des moyens pour calculer un digest cumulatif sur plusieurs périodes d’émission de données des moyens pour envoyer un code d’authentification calculé à partir du digest cumulatif.
[0044] L’invention concerne aussi un système de télécommunication basé sur un réseau superposé, le réseau superposé comprenant une pluralité de groupes de noeuds de communication, chaque groupe de noeuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les noeuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de noeuds de la pluralité de groupes, le système de télécommunication étant caractérisé en ce que tout ou partie des noeuds du réseau superposé comprend un dispositif selon l’invention.
[0045] Dans un mode de réalisation, le système de télécommunication basé sur un réseau superposé comprend de plus des moyens de vérification configurés pour effectuer une attestation logicielle à distance des gestionnaires de clé de groupe secrète.
[0046] L’invention adresse de plus un procédé de vérification de fiabilité de noeuds de communication d’un réseau superposé, le réseau superposé comprenant une pluralité de groupes de noeuds de communication, chaque groupe de noeuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les noeuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de noeuds de la pluralité de groupes. Le procédé est mis en oeuvre sur un processeur, et comprend des étapes au niveau d’un nœud émetteur de données, consistant à : calculer un code d’authentification, sur la base des données d’un paquet à émettre et de la clé de groupe secrète de l’opérateur dudit nœud, le calcul du code d’authentification étant effectué dans une enclave matérielle sécurisée dudit nœud, ladite enclave matérielle sécurisée stockant une copie de chaque clé de groupe secrète desdits opérateurs ; et à insérer dans le paquet de données à émettre, ledit code d’authentification. Le procédé comprend au niveau d’un nœud récepteur de données, des étapes consistant à comparer un code d’authentification contenu dans un paquet de données reçu, avec un code d’authentification calculé sur la base des données du paquet reçu et de la clé de groupe secrète de l’opérateur du nœud émetteur, le calcul du code d’authentification étant effectué dans une enclave matérielle sécurisée dudit nœud récepteur ; et comprend des moyens de validation configurés pour valider ou rejeter un paquet de données reçu, selon le résultat de la comparaison des codes d’authentification.
[0047] Dans un mode de réalisation, le procédé comprend de plus des étapes consistant à distribuer les clés de groupe secrètes des opérateurs à chaque nœud du réseau superposé, l’étape de distribution de chaque clé étant opérée par un gestionnaire de clés de chaque opérateur, et comprenant au moins une étape d’attestation logicielle à distance entre le gestionnaire de clés et un nœud.
[0048] Dans un mode de réalisation, l’étape d’insérer un code d’authentification dans un paquet de données à émettre, est remplacée par des étapes consistant à calculer un digest cumulatif sur plusieurs périodes d’émission de données, et à insérer un code d’authentification calculé à partir du digest cumulatif.
[0049] Un autre objet de la présente invention est un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé de l’invention, lorsque ledit programme est exécuté sur un ordinateur.
Description des figures
[0050] Différents aspects et avantages de l’invention vont apparaître en appui de la description d’un mode préféré d’implémentation de l’invention mais non limitatif, avec référence aux figures ci-dessous :
[0051] La figure 1 présente schématiquement une architecture d’un réseau superposé permettant de mettre en œuvre le procédé de la présente invention dans un mode de réalisation.
[0052] La figure 2 présente schématiquement une variante de réalisation de l’architecture de réseau superposé de la figure 1 .
[0053] La figure 3 présente schématiquement la structure d’un nœud d’un réseau superposé dans un mode de réalisation. [0054] La figure 4 illustre un enchaînement d’étapes réalisées par un nœud d’un réseau superposé pour émettre un paquet de données, selon un mode de réalisation du procédé de l’invention.
[0055] La figure 5 illustre un enchaînement d’étapes réalisées par un nœud d’un réseau superposé à réception d’un paquet de données, selon un mode de réalisation du procédé de l’invention.
[0056] La figure 6 illustre un séquencement d’opérations réalisées pour la distribution de clés de groupe aux nœuds d’un réseau superposé.
[0057] La figure 7 est une représentation temporelle d’une communication entre un nœud émetteur et un nœud récepteur basée sur le calcul d’un digest cumulatif pour vérifier la fiabilité du nœud émetteur.
Description détaillée de l’invention
[0058] Dans le cadre de la description d’un mode de réalisation, une enclave matérielle sécurisée au sens de l’invention est considérée être une enclave d’exécution de code, sécurisée au niveau du silicium. Bien que différents types d’enclave sécurisée puissent être adaptés pour mettre en œuvre l’invention, pour des raisons de simplification de la description, il est considéré une enclave matérielle sécurisée de type « TPM », i.e. ayant des caractéristiques standardisées selon les spécifications des plateformes sécurisées TPM définies par le consortium « Trusted Computing Group >>. Ce type d’enclave sécurisée représente l’approche la plus générale (car n’étant pas limitée aux seuls microprocesseurs Intel® par exemple comme l’enclave SGX).
[0059] La figure 1 présente schématiquement une architecture d’un réseau superposé 100 permettant de mettre en œuvre le procédé de la présente invention dans un mode de réalisation.
[0060] Les nœuds d’un réseau superposé sont opérés par divers opérateurs qui contribuent au réseau superposé. La figure 1 illustre trois opérateurs à titre d’exemple non limitatif : Opérateur A, Opérateur B, Opérateur C. Une pluralité de nœuds opérés par l’opérateur A sont nommés Nœud A1 (ou A1 ), Nœud A2 (ou A2), ..., Nœud Ai (ou Ai). Une pluralité de nœuds opérés par l’opérateur B sont nommés Nœud B1 (ou B1 ), Nœud B2 (ou B2), ..., Nœud Bj (ou Bj). Une pluralité de nœuds opérés par l’opérateur C sont nommés Nœud C1 (ou C1 ), Nœud C2 (ou C2), Nœud Ck (ou Ck).
[0061] Chaque opérateur est en charge d’une entité dite « Gestionnaire de clés de groupe », qui est configurée pour gérer (en termes de génération et de distribution) une clé secrète pour le groupe de nœuds dont l’opérateur est en charge.
[0062] Ainsi sur la figure 1 , il est illustré un gestionnaire de clés de groupe A configuré pour gérer une clé secrète pour le groupe de nœuds Ai opérés par l’opérateur A, i.e. permettant de générer une clé secrète (GKA) et la distribuer « GKA distribution >>.
[0063] De manière analogue, un gestionnaire de clés de groupe B est configuré pour gérer une clé secrète GKB pour le groupe de nœuds Bj opérés par l’opérateur B, et un gestionnaire de clés de groupe C est configuré pour gérer une clé secrète GKC pour le groupe de nœuds Ck opérés par l’opérateur C.
[0064] Selon le principe de l’invention, une clé secrète GKX générée par un gestionnaire de clés pour un groupe de nœuds opérés par un opérateur X, est distribuée à la pluralité des nœuds d’un réseau superposé qui sont configurés pour participer au procédé de vérification de fiabilité de l’invention.
[0065] Ainsi, tel qu’illustré sur la figure 1 , les clés secrètes de groupe GKA, GKB, GKC des opérateurs A, B, C, sont par exemple distribuées aux nœuds A1 , A2, B1 , B2, C1 et C2 qui sont configurés (illustré par un rectangle « TPM >>) pour mettre en œuvre le procédé de vérification de fiabilité de l’invention.
[0066] Ainsi, les nœuds participant au processus de vérification de fiabilité disposent chacun de toutes les clés secrètes des groupes opérés par les différents opérateurs.
[0067] Pour fournir son service, un réseau superposé met en œuvre des communications de données entre certaines paires de nœuds du réseau, voire entre toutes les paires de nœuds dans certains cas. Ces communications de données se font par paquets de données, par exemple par paquets (UDP) acronyme de « User Datagram Protocol >> en anglais.
[0068] Les nœuds de communication du réseau superposé sont configurés pour émettre « Env >> et recevoir « Rec >> des paquets de données, à destination de et en provenance de nœuds de la pluralité de groupes de nœuds du réseau superposé. il
[0069] En termes d’émission de paquets, seule la clé de groupe de l’opérateur du nœud émetteur est nécessaire. En termes de réception de paquets, comme un nœud peut recevoir des paquets de n’importe quel opérateur du réseau superposé, un nœud en mode réception doit disposer de toutes les clés de groupe afin d’effectuer la vérification de la fiabilité d’un nœud émetteur.
[0070] La figure 1 montre aussi des terminaux utilisateurs (U1 , U2, U3) permettant à des utilisateurs finaux d’émettre des requêtes de service vers des opérateurs du réseau superposé et recevoir des données. Dans un mode de réalisation, tout ou partie des terminaux utilisateurs sont configurés pour mettre en œuvre le processus de vérification de fiabilité de l’invention (illustré par un rectangle « TPM >>).
[0071] Ainsi, les composants d’un réseau superposé participant au procédé de vérification de fiabilité de l’invention disposent chacun d’une enclave matérielle sécurisée TPM. Les clés de groupe GKX (représentées à l’intérieur d’un TPM) ne sont connues et générées que dans les TPMs.
[0072] Avantageusement, une clé secrète de groupe GKX n’est pas connue des plateformes hôtes (« Application nœud ») dans les nœuds, ni dans celles des terminaux utilisateurs (« Application utilisateur »), i.e. la plateforme hôte d’un TPM n’a jamais accès à une clé GKX.
[0073] Toujours avantageusement, une clé secrète de groupe GKX n’est pas connue non plus des autres gestionnaires de clé de groupe d’un réseau superposé, ni des administrateurs des gestionnaires de clés de groupe.
[0074] La figure 2 présente schématiquement une variante de réalisation de l’architecture de réseau superposé de la figure 1 .
[0075] Cette variante permet à un gestionnaire de clés de groupe d’effectuer une attestation d’un nœud en préalable à la fourniture d’une clé secrète de groupe GKX à ce nœud.
[0076] Cette variante vise à remédier au problème sur l’architecture de la figure 1 , où rien ne force un gestionnaire de clé de groupe à effectuer une attestation d’un nœud avant de lui fournir une clé secrète. Pour contrer cette faille, il est proposé de mettre en œuvre des services de vérification pour effectuer régulièrement une attestation à distance du logiciel des gestionnaires de clés de groupe. [0077] Les services de vérification peuvent à leur tour faire appel à des services d’évaluation, lesquels peuvent aussi faire appels à des services de publication des sources (« Référentiel OSS » sur la figure 2).
[0078] Ainsi reprenant l’exemple de trois gestionnaires de clés de groupe, il est mis en oeuvre trois services de vérification (X, Y, Z), chacun pouvant effectuer des vérifications à distance de la non-compromission de chaque gestionnaires de clés de groupe des opérateurs A, B, C. Chaque service de vérification peut faire appel à un service d’évaluation (R, S, T) pour obtenir le statut d’un gestionnaire de clés de groupe.
[0079] La figure 3 présente schématiquement la structure d’un nœud d’un réseau superposé dans un mode de réalisation. Un nœud 302 d’un réseau superposé selon l’invention comprend un module récepteur 304, un module émetteur 306, un module applicatif 308, une enclave matérielle sécurisée 310, un module d’insertion 316, un module de comparaison 318 et un module de validation 320.
[0080] Le module récepteur 304 est configuré pour interfacer le nœud avec le réseau et recevoir des paquets de données d’autres nœuds du réseau et/ou de terminaux utilisateurs.
[0081] Le module émetteur 306 est configuré pour interfacer le nœud avec le réseau et émettre des paquets de données vers d’autres nœuds du réseau et/ou vers des terminaux utilisateurs.
[0082] Le module applicatif 308 est configuré pour mettre en œuvre le ou les services proposés par le réseau superposé.
[0083] Avantageusement, le nœud dispose d’une enclave matérielle sécurisée 310 qui comprend différents modules configurés pour permettre la mise en œuvre de l’invention. Ainsi, le nœud comprend au niveau de l’enclave matérielle sécurisée, un module de stockage 312 permettant de stocker des clés secrètes de groupe et un module de calcul 314 permettant de calculer des codes d’authentification.
[0084] Le nœud comprend de plus un module d’insertion 316 permettant d’insérer un code d’authentification dans un paquet de données à émettre, un module de comparaison 318 permettant d’effectuer une comparaison de codes d’authentification, et un module de validation 320 permettant de valider ou rejeter un paquet de données reçu.
[0085] Dans un mode de réalisation, le module d’insertion 316 peut être pris en charge par le module émetteur 306.
[0086] Dans un mode de réalisation, le module de comparaison (318) ainsi que le module de validation (320) peuvent être pris en charge par le module récepteur (304).
[0087] Le calcul de code d’authentification est ainsi effectué dans l’enclave sécurisée du nœud, sur sollicitation du nœud.
[0088] La figure 4 illustre un enchaînement d’étapes réalisées au niveau de l’enclave matérielle sécurisée d’un nœud d’un réseau superposé, pour émettre un paquet de données, selon un mode de réalisation du procédé de l’invention.
[0089] Le procédé 400 est initié lorsqu’un nœud d’un réseau superposé appartenant à un groupe de nœuds opérés par un opérateur X doit émettre un paquet de données dans le réseau. Le paquet de données peut être issu d’un paquet de données reçu et traité selon l’applicatif spécifique du nœud.
[0090] Dans une première étape 402, le procédé permet de calculer, par le module de calcul 314, un code d’authentification, à partir des données du paquet à émettre et de la clé secrète de groupe GKX de l’opérateur X stockée dans le module de stockage de clés 312.
[0091] Dans un mode de réalisation, le code d’authentification est calculé comme pour un code d’authentification de message dit (MAC) selon l’acronyme anglais de « Message Authentification Code », avec une fonction de hachage (ou « Digest >>) selon la formule suivante :
MAC = Digest(paquet, GKX), où GKX est la clé de groupe en cours de validité pour l’opérateur X et le terme « paquet >> correspondant au contenu binaire du paquet de données.
[0092] Dans une étape suivante 404, le procédé permet d’insérer, par le module d’insertion 316, le code d’authentification calculé dans le paquet sortant, puis dans une étape suivante 406, le procédé permet d’émettre dans le réseau, via le module émetteur 306, le paquet qui contient le code d’authentification.
[0093] Dans un mode de réalisation, le code d’authentification est inséré dans un champ disponible de l’entête du paquet de données.
[0094] Ainsi avantageusement, le code d’authentification calculé selon l’invention, présente les propriétés d’un MAC utilisé dans d’autres contextes, c’est-à-dire qu’il permet d’assurer l’intégrité des données du paquet où il est inséré. Par ailleurs, l’insertion du code d’authentification calculé dans l’enclave matérielle sécurisée d’un nœud, permet d’ajouter une garantie de légitimité du nœud émetteur, à l’instant de la création du paquet.
[0095] Un récepteur du paquet de données va pouvoir exécuter un calcul similaire de code d’authentification sur le paquet de données reçu, pour vérifier la légitimité du nœud émetteur.
[0096] La figure 5 illustre un enchaînement d’étapes réalisées dans l’enclave matérielle d’un nœud d’un réseau superposé à réception d’un paquet de données, selon un mode de réalisation du procédé de l’invention.
[0097] Le procédé 500 est initié lorsqu’un nœud d’un réseau superposé appartenant par exemple à un groupe de nœuds opérés par un opérateur X, reçoit dans une première étape 502, un paquet de données dans le réseau. Le paquet de données peut être issu d’un nœud du réseau superposé appartenant au même groupe de nœuds que le nœud récepteur et opéré par le même opérateur X ou être issu d’un nœud du réseau superposé appartenant à un groupe de nœuds opérés par un autre opérateur Z.
[0098] Dans une étape suivante 504, le procédé permet de calculer, par le module de calcul 314, un code d’authentification, à partir des données du paquet reçu et de la clé secrète de groupe de l’opérateur du nœud émetteur, stockée dans le module de stockage 312 du nœud récepteur, par exemple la clé GKX si le paquet de données provient d’un nœud opéré par l’opérateur X ou la clé GKZ si le paquet de données provient d’un nœud opéré par l’opérateur Z. [0099] Avantageusement, le module de stockage de clés 312 permet de stocker toutes les clés secrètes de groupe distribuées par les gestionnaires de clés des différents opérateurs.
[0100] Dans une étape suivante 506, le procédé permet de comparer le code d’authentification calculé par le nœud récepteur avec le code d’authentification inséré dans le paquet reçu, puis dans une étape suivante 508, le procédé permet de valider ou rejeter le paquet reçu selon que les codes d’authentification se correspondent ou non.
[0101] Si le paquet est validé, cela signifie que le nœud émetteur n’est pas compromis, et le nœud récepteur peut poursuivre le traitement du paquet reçu.
[0102] Si les codes d’authentification ne correspondent pas, cela signifie que le nœud émetteur est compromis, et le paquet reçu est ignoré.
[0103] Dans une option de réalisation, un rapport de situation peut être généré par le nœud récepteur avant d’ignorer un paquet reçu compromis, permettant ainsi de disposer dans le nœud d’une statistique concernant les nœuds fiables et les nœuds compromis.
[0104] Les clés secrètes de groupe sont distribuées aux nœuds d’un réseau superposé par les gestionnaires de clés de groupe, à l’initialisation des nœuds et lors du renouvellement des clés qui ont expirées.
[0105] La figure 6 illustre un séquencement d’opérations réalisées pour la distribution de clés de groupe aux nœuds d’un réseau superposé, lors de la mise en œuvre d’un nœud.
[0106] L’exemple présente pour des raisons de simplification, un séquencement de distribution de trois clés GKA, GKB, GKC vers un nœud, pour trois opérateurs A, B et C. Cependant, la mise en œuvre de l’invention peut être réalisée pour tout réseau superposé sans limitation du nombre d’opérateurs, et de gestionnaires de clés associés.
[0107] Lorsqu’un nœud est activé à l’initialisation, son enclave matérielle sécurisée ou TPM doit obtenir une copie de toutes les clés de groupe en cours de validité de tous les opérateurs. [0108] Le nœud, i.e. la machine correspondante, envoie à chaque gestionnaire de clés, une requête de clé de groupe, « Request GKA » pour le gestionnaire de clés de groupe A, « Request GKB » pour le gestionnaire de clés de groupe B, « Request GKC » pour le gestionnaire de clés de groupe C. La requête contient l’identifiant (id) du nœud et un nonce (noncel ) qui est une valeur aléatoire.
[0109] Il est possible qu’un ou tous les gestionnaires de clés de groupe n’aient pas une connaissance préalable du nœud pour lequel une requête leur est adressée.
[0110] Si le nœud n’est pas encore connu du gestionnaire de clés de groupe, ce dernier demande au nœud de lui fournir (Request AIK Cert) un certificat d’identité de clé ou (AIK) pour « Attestation Identity Key » en anglais.
[0111] Un tel certificat a été créé dans l’enclave matérielle du nœud à fins d’authentification. Il contient une clé publique signée par le fabriquant de l’enclave matérielle, et une clé privée associée (AIKpriv), interne à l’enclave matérielle et non exportable.
[0112] A réception du certificat (AIK Cert + Id), le gestionnaire de clés de groupe vérifie que la clé est bien signée par le fabriquant de l’enclave matérielle (par exemple le fabricant d’un module TPM). Cette vérification peut se faire via une infrastructure à clé publique ou (PKI) pour « Public Key Infrastructure » en anglais.
[0113] Puis le gestionnaire envoie au nœud une requête d’attestation logicielle distante, ainsi qu’un nonce (nonce2), en signant ce message composite avec sa clé privée (par exemple « Apriv » pour le gestionnaire de clés de groupe A).
[0114] Lorsque le nœud reçoit ce message il vérifie d’abord la signature. Il peut faire confiance à une PKI pour ce faire.
[0115] Ensuite, il sollicite son module sécurisé pour obtenir une mesure attestée de l’état de la plateforme hôte (Measurements). Cette mesure est typiquement constituée dans le cas d’un module TPM, d’une liste de valeurs de registres « PCR » contenu dans le TPM. La valeur de nonce2 est ajoutée à cette liste, et le TPM signe le message avec sa clé privée (AIKpriv).
[0116] A réception de ce message, le gestionnaire de clés de groupe vérifie la signature du message reçu, compte tenu du certificat AIK associé à ce nœud. [0117] Il vérifie ensuite la présence du nonce (nonce2) et vérifie que sa valeur est identique à celle qu’il a envoyée, puis il recueille la liste des valeurs associées aux registres PCR.
[0118] Pour évaluer l’état légitime ou potentiellement compromis de la plateforme hôte, le gestionnaire de clés de groupe peut faire appel à des services d’évaluation. Il s’agit de vérifier que le firmware n’est pas compromis, que l’image de l’OS n’est compromise, et qu’aucun des fichiers exécutables qui tournent sur la plateforme ne sont compromis.
[0119] Si le résultat de cette attestation distante est positif, alors le gestionnaire de clés de groupe peut envoyer sa clé secrète en cours de validité vers le nœud, par exemple la clé GKA pour le gestionnaire de clés de groupe A.
[0120] Il encrypte cette clé GKA avec la clé publique associée au certificat AIK du nœud, de telle sorte que seule l’enclave matérielle sécurisée du destinataire (et aucuns autre) puisse récupérer la clé décryptée.
[0121] Dans un mode de réalisation, le gestionnaire de clés de groupe fournit une période de validité pour la clé secrète. Le nœud doit noter cette période de validité et obtenir une nouvelle clé avant l’expiration de cette période de validité.
[0122] Le message contenant la clé secrète de groupe est finalement signé par le gestionnaire de clés de groupe avec sa clé privée.
[0123] Par exemple, le message envoyé par le gestionnaire de clés de groupe A est de type : [GKA encr/AIKpub + valid_period+nonce1] signed/Apriv.
[0124] Sur réception de ce message, le nœud vérifie la signature (signed/Apriv), vérifie le nonce (noncel ), et fournir à son module sécurisé la clé GKA encryptée pour la stocker de manière décryptée dans le module de stockage de clés.
[0125] Dans un mode de réalisation où l’enclave sécurise est un module TPM, la clé secrète, par exemple GKA, doit bénéficier d’un mécanisme de scellé (ou « sealing » en anglais) au niveau du TPM. Ce mécanisme permet au TPM de refuser à son hôte toute utilisation de cette clé GKA en dehors d’une vérification préalable de la valeur des registres PCR du TPM. La clé ne pourra être utilisée (par exemple pour le calcul d’un MAC) que si les registres TPM sont égaux à une configuration fixée. En l’occurrence le mécanisme de scellé est initié selon la valeur des registres PCR au moment de la réception de la clé GKA. Si, par exemple, la clé GKA est reçue et que le mécanisme de scellé est initié pour cette clé, et que par la suite, un nouvel exécutable est lancé sur la plateforme hôte, alors cet événement se traduira par la modification d’un registre PCR (sous Linux il faut un noyau dans lequel le module « Integrity Management architecture » est activé pour garantir ce comportement). Comme un registre est modifié, l’hôte ne peut plus faire appel au TPM pour utiliser la clé GKA.
[0126] Dans le mécanisme de distribution de clés, une entité, dite « Service de publication des sources », fournit des sources de référence qui peuvent être compilées au niveau du gestionnaire de clés et converties en digests. Cela permet aux gestionnaires de clés de déterminer quels sont les digests autorisés pour évaluer l’état d’une plateforme. Les sources sont signées par l’entité et le gestionnaire de clé doit vérifier la signature (en utilisant éventuellement une PKI).
[0127] Le calcul d’un code d’authentification entraîne une sollicitation du module sécurisé lors de chaque paquet émis et reçu. Ceci peut entraîner un phénomène de goulot d’étranglement au niveau du module sécurisé, en particulier si le nœud est amené à traiter des flux de données importants en termes de débits.
[0128] De plus, les performances des modules TPM sont en général assez limitées lorsqu’il s’agit d’exécuter rapidement des algorithmes cryptographiques.
[0129] Aussi, pour contourner ce risque, une variante de réalisation de la présente invention permet de ne pas insérer un code d’authentification dans chaque paquet de données émis, et de générer un digest cumulatif sur plusieurs périodes avant de calculer un code d’authentification à insérer dans un paquet de données à envoyer.
[0130] La figure 7 est une représentation temporelle d’une communication entre un nœud émetteur et un nœud récepteur basée sur le calcul d’un digest cumulatif pour vérifier la fiabilité du nœud émetteur.
[0131] L’exemple est illustré sur une période de validité d’une clé GKX, pour un nœud émetteur disposant d’une clé secrète GKX et un nœud pair récepteur disposant aussi de la clé secrète GKX.
[0132] Dans l’exemple de cette variante de réalisation, une information est envoyée du nœud émetteur vers le nœud récepteur par le protocole TCP (« Transmission Control Protocol » en anglais). L’information (flux TCP) est découpée en segments (paquets). Il est supposé que l’injection de segments dans un flux TCP se fait selon un protocole permettant de délimiter et d’identifier ces segments.
[0133] Le principe de cette variante est d’injecter deux types de paquets courts dans le flux : un premier type de paquets dits « CTRL1 » et un deuxième type de paquets dits « CTRL2 ».
[0134] Un paquet de type CTRL1 est destiné à délimiter des sous-périodes au niveau du nœud émetteur (il fait la frontière entre deux périodes), et un paquet CTRL2 est destiné à inclure un code d’authentification code (MAC) concernant la période qui vient de s’écouler.
[0135] Le code d’authentification est calculé de façon similaire au procédé décrit pour la figure 4, à la différence que ce n’est pas le contenu binaire d’un paquet à envoyer qui est utilisé pour le calcul, mais un digest cumulatif, selon la formule suivante :
MAC = Digest(digest_cumulatif_sur_dernière_période_écoulée, GKX), où GKX est la clé de groupe en cours de validité pour un opérateur X.
[0136] La génération d’un digest cumulatif suppose le découpage du flux TCP en segments de taille constante en octets (à l’exception du dernier segment) et réduite. Le calcul du digest cumulatif, est calculé « au fil de l’eau >> sur le flux, sans faire appel au module sécurisé.
[0137] En début de période le digest cumulatif est initialisé à 0, puis pour chaque nouveau segment envoyé, le digest cumulatif est mis à jour selon la formule suivante : digest_cumulatifn = Digest(digest_cumulatifn.i, contenu_segment_n) , où le digest cumulatif pour la dernière période écoulée ‘n’ est celui obtenu avec le contenu du dernier segment de cette période.
[0138] L’homme du métier connaît la technique de digest cumulatif qui présente l’avantage de ne pas avoir à mémoriser un volume de données important pour calculer un digest sur l’ensemble des segments pour une période. [0139] Une fois que le digest cumulatif sur la dernière période est calculé, il est possible de calculer un code d’authentification et de le transmettre au nœud récepteur, dans un paquet de type CTRL2.
[0140] La figure 7 ne fait pas apparaître le paquet CTRL2 car le nœud émetteur dispose d’une tolérance temporelle, notée « tcrl2max », pour le transmettre en début de période CTRL1 .
[0141] En tant qu’émetteur, le nœud est synchronisé avec son gestionnaire de clés GKX qui renouvelle cette clé avant toute nouvelle période, ce qui définit la « période GKX >> de validité avant un renouvellement. La figure 7 fait apparaître une opération de renouvellement de la clé GKX en fin de période, et cela pour l’émetteur ainsi que pour le récepteur. Cette opération peut être démarrée en avance par rapport à la nouvelle période de validité, sans excéder un délai noté « Trenew >>. En début d’une nouvelle période GKX, le nœud récepteur peut être encore autorisé à utiliser l’ancienne clé de groupe GKX, mais sans excéder un délai maximum noté « Rxtol >>.
[0142] Le nœud émetteur subdivise la période de validité GKX en sous-périodes de durée égale, incluant chacune une période réservée pour le calcul d’un code d’authentification. La période aussi appelée ici « période CTRL1 >> est réservée en insérant dans chaque sous-période un paquet de type CTRL1 , destinée à définir la période de calcul de code d’authentification.
[0143] Lorsque le nœud récepteur reçoit un paquet de type CTRL2, en début de période CTRL1 , il recalcule une valeur de code d’authentification en s’appuyant sur la clé de groupe de son propre module sécurisé. S’il y a divergence sur la valeur de code, le nœud récepteur termine la connexion avec le nœud émetteur, qui devient alors suspect de compromission.
[0144] Il est à noter que les mécanismes décrits n’entraînent aucun risque de mise en attente d’un nœud du fait de la sollicitation du module sécurisé et du temps de réponse à cette sollicitation.
[0145] Avantageusement, en début de période CTRL1 , un nœud émetteur peut continuer à traiter des segments émis en parallèle du fonctionnement du module sécurisé qui est sollicité pour calculer un code d’authentification. [0146] De même, lorsqu’un nœud récepteur reçoit un paquet CTRL2 qui contient un code d’authentification, il peut solliciter son module sécurisé pour calculer un code d’authentification afin de le comparer avec celui reçu dans le paquet CTRL2, sans pour autant arrêter de traiter le flux de données reçu.
[0147] La variante décrite ici ne résout pas complètement le risque de compromission soudaine d’un nœud (suite par exemple à l’exécution d’un fichier exécutable malveillant sur le nœud), qui va mener une attaque très rapide pour compromettre le service fourni par le réseau superposé. Pour cela il est important que la période CTRL1 soit faible, de façon à limiter au maximum ce risque. En effet, il faut attendre l’écoulement de la période CTRL1 en cours pour que le nœud récepteur reçoive un CTRL2, constate la divergence éventuelle de code d’authentification, et cesse toute interaction avec le nœud suspect.
[0148] Il est possible pour le nœud récepteur de déférer au niveau applicatif le traitement du flux reçu pendant une période CTRL1 , jusqu’à ce que toutes les données soient « validées » par la réception d’un CTRL2 associé. Cependant, cela peut entraîner une latence excessive au niveau de l’application et ce mode de fonctionnement ne peut pas être proposé de façon systématique. Par exemple, si la période CTRL1 est de 1 seconde, ce mode de fonctionnement entraîne une latence d’au moins 1 seconde.

Claims

REVENDICATIONS
1 . Dispositif de vérification de la fiabilité de noeuds de communication d’un réseau superposé, le réseau superposé comprenant une pluralité de groupes de noeuds de communication, chaque groupe de noeuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les noeuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de noeuds de la pluralité de groupes, le dispositif comprenant :
- des moyens de communication configurés pour qu’un nœud de groupe opéré par un opérateur émette une requête de clé de groupe secrète vers un gestionnaire de clés de groupe pour chaque opérateur, et pour recevoir une copie d’une clé de groupe secrète en cours de validité, après validation de l’état logiciel légitime dudit nœud par le gestionnaire de clés de groupe dudit opérateur ;
- une enclave matérielle sécurisée (310) comprenant :
- des moyens de stockage (312) pour stocker une copie de chaque clé de groupe secrète en cours de validité ;
- des moyens de calcul (314) configurés pour calculer un code d’authentification sur la base de données d’un paquet à émettre et de la copie d’une clé de groupe secrète en cours de validité de l’opérateur du nœud émetteur;
- des moyens d’insertion (316) configurés pour insérer dans un paquet de données à émettre un code d’authentification calculé dans l’enclave matérielle sécurisée ;
- des moyens de comparaison (318) configurés pour comparer un code d’authentification contenu dans un paquet de données reçu, avec un code d’authentification calculé dans l’enclave matérielle sécurisée sur la base des données du paquet reçu et d’une copie stockée de la clé de groupe secrète de l’opérateur dudit nœud émetteur ; et
- des moyens de validation (320) configurés pour valider ou rejeter un paquet de données reçu, selon le résultat de la comparaison des codes d’authentification.
2. Le dispositif selon la revendication 1 dans lequel les moyens de calcul (314) sont configurés pour calculer un code d’authentification avec une fonction de hachage cryptographique basée sur le contenu binaire d’un paquet de données et de la copie de la clé de groupe secrète de l’opérateur d’un nœud émetteur.
3. Le dispositif selon la revendication 1 ou 2 dans lequel la validation de l’état logiciel légitime d’un nœud consiste pour un gestionnaire de clés de groupe à envoyer au nœud une requête d’attestation logicielle distante, et pour ledit nœud à solliciter l’enclave matérielle sécurisée pour obtenir une mesure attestée de l’état de la plateforme hôte.
4. Le dispositif selon l’une quelconque des revendications 1 à 3 dans lequel le gestionnaire de clés de groupe envoie une période de validité pour la copie de la clé secrète en cours de validité.
5. Le dispositif selon l’une quelconque des revendications 1 à 4 dans lequel l’enclave matérielle sécurisée est un module matériel dont les caractéristiques sont standardisées selon les spécifications des plateformes sécurisées TPM définies par le consortium « Trusted Computing Group ».
6. Le dispositif selon la revendication 5 dans lequel l’enclave matérielle sécurisée comprend de plus des moyens configurés pour mettre en œuvre un mécanisme de scellé sur des registres de configuration de plateforme PCR, ledit mécanisme étant initié selon la valeur des registres PCR au moment de la réception d’une clé de groupe secrète.
7. Le dispositif selon l’une quelconque des revendications précédentes dans lequel l’enclave matérielle sécurisée comprend des moyens pour stocker une copie décryptée d’une clé de groupe secrète.
8. Le dispositif selon l’une quelconque des revendications précédentes comprenant de plus des moyens pour calculer un digest cumulatif sur plusieurs périodes d’émission de données et des moyens pour envoyer un code d’authentification calculé à partir du digest cumulatif.
9. Le dispositif selon la revendication précédente dans lequel un flux de données émises sur plusieurs périodes est constitué d’un ensemble de segments, et dans lequel un digest cumulatif est initialisé à une valeur constante en début de période et tel que pour tout nouveau segment émis, le digest cumulatif courant est généré à partir du digest cumulatif associé au segment précédent et du contenu du flux de données du segment courant.
10. Système de télécommunication basé sur un réseau superposé, le réseau superposé comprenant une pluralité de groupes de noeuds de communication, chaque groupe de noeuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les noeuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de noeuds de la pluralité de groupes, le système de télécommunication étant caractérisé en ce que tout ou partie des noeuds du réseau superposé comprend un dispositif selon l’une quelconque des revendications précédentes.
11 . Système de télécommunication basé sur un réseau superposé selon la revendication précédente, comprenant de plus des moyens de vérification configurés pour effectuer une attestation logicielle à distance des gestionnaires de clé de groupe secrète.
12. Procédé de vérification de fiabilité de noeuds de communication d’un réseau superposé, le réseau superposé comprenant une pluralité de groupes de noeuds de communication, chaque groupe de noeuds étant opéré par un opérateur différent, une clé de groupe secrète étant associée à chaque opérateur, les noeuds de communication étant configurés pour émettre et recevoir des paquets de données, à destination et en provenance de noeuds de la pluralité de groupes, le procédé étant mis en oeuvre sur un processeur, et comprenant :
- au niveau d’un nœud émetteur de données, des étapes consistant à :
- émette une requête de clé de groupe secrète vers un gestionnaire de clés de groupe pour chaque opérateur, et recevoir une copie d’une clé de groupe secrète en cours de validité, après validation de l’état logiciel légitime dudit nœud émetteur par le gestionnaire de clés de groupe dudit opérateur ;
- calculer dans une enclave matérielle sécurisée dudit nœud émetteur un code d’authentification sur la base de données d’un paquet à émettre et de la clé de groupe secrète de l’opérateur dudit nœud émetteur, ladite enclave matérielle sécurisée stockant une copie de chaque clé de groupe secrète associée à chaque opérateur ; et
- insérer dans un paquet de données à émettre, ledit code d’authentification ; - au niveau d’un nœud récepteur de données, des étapes consistant à :
- calculer dans une enclave matérielle sécurisée dudit nœud récepteur un code d’authentification sur la base des données d’un paquet reçu et de la clé de groupe secrète de l’opérateur du nœud émetteur du paquet de données, ladite enclave matérielle sécurisée stockant une copie de chaque clé de groupe secrète associée à chaque opérateur du réseau superposé ;
- comparer le code d’authentification calculé avec un code d’authentification contenu dans le paquet de données reçu ; et
- valider ou rejeter le paquet de données reçu, selon le résultat de la comparaison des codes d’authentification.
13. Procédé selon la revendication 12 dans lequel l’étape d’insérer un code d’authentification dans un paquet de données à émettre, est remplacée par des étapes consistant à calculer un digest cumulatif sur plusieurs périodes d’émission de données, et à insérer un code d’authentification calculé à partir du digest cumulatif, où un digest cumulatif est initialisé à une valeur constante en début de période, un flux de données émises sur plusieurs périodes est constitué d’un ensemble de segments, et tel que pour tout nouveau segment émis, le digest cumulatif courant est généré à partir du digest cumulatif associé au segment précédent et du contenu du flux de données du segment courant.
14. Un produit programme d’ordinateur, ledit programme d’ordinateur comprenant des instructions de code permettant d’effectuer les étapes du procédé selon la revendication 11 ou 12, lorsque ledit programme est exécuté sur un ordinateur.
EP24748375.3A 2023-07-25 2024-07-23 Méthode et dispositif de vérification de la fiabilité de noeuds de communication de données d'un réseau superposé Pending EP4751418A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2307980A FR3151677B1 (fr) 2023-07-25 2023-07-25 Méthode et dispositif de vérification de la fiabilité de nœuds de communication de données d’un réseau superposé
PCT/EP2024/070920 WO2025021824A1 (fr) 2023-07-25 2024-07-23 Méthode et dispositif de vérification de la fiabilité de nœuds de communication de données d'un réseau superposé

Publications (1)

Publication Number Publication Date
EP4751418A1 true EP4751418A1 (fr) 2026-06-03

Family

ID=89157999

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24748375.3A Pending EP4751418A1 (fr) 2023-07-25 2024-07-23 Méthode et dispositif de vérification de la fiabilité de noeuds de communication de données d'un réseau superposé

Country Status (3)

Country Link
EP (1) EP4751418A1 (fr)
FR (1) FR3151677B1 (fr)
WO (1) WO2025021824A1 (fr)

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101940983B1 (ko) * 2018-11-15 2019-01-22 주식회사 유니온플레이스 멀티캐스트 그룹 내의 디바이스
US11290437B2 (en) * 2018-12-27 2022-03-29 Beijing Voyager Technology Co., Ltd. Trusted platform protection in an autonomous vehicle
IL274674A (en) * 2020-05-14 2021-12-01 Zion Kopelovitz Ben System and method to support message authentication

Also Published As

Publication number Publication date
WO2025021824A1 (fr) 2025-01-30
FR3151677B1 (fr) 2026-01-23
FR3151677A1 (fr) 2025-01-31

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: 20260123

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