FR3142313A1 - Procédé de distribution de clefs de session dans un réseau de télécommunication, procédés associés de traitement dans un client et un serveur, module client et serveur associés - Google Patents

Abstract

Procédé de distribution de clefs de session dans un réseau (1) de télécommunication comportant N serveurs (1_1, 1_2), des clients (2_1, 2_2) de type « publishers » ou « subscribers » échangeant, en utilisant des clefs de session (3), des informations chiffrées, selon lequel : chaque serveur (1_1, 1_2), quand il a le rôle de serveur maître, seul autorisé à distribuer des clefs de session, envoie aux clients (2_1, 2_2), selon une périodicité minimale prédéfinie, un message prédéfini ; chaque client (2_1, 2_2) lorsqu’il détecte que ledit message prédéfini n’a pas été reçu conformément à ladite périodicité, envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans une liste ordonnée des serveurs ; chaque serveur (1_1, 1_2) dès qu’il reçoit une telle requête, déclenche une opération d’élection d’un nouveau serveur maître auprès des serveurs ; le serveur maître élu par ladite opération d’élection déclenche, dès son élection, auprès des clients (2_1, 2_2), un remplacement des clefs de session valides. Figure pour l’abrégé : Fig. 1

Description

Procédé de distribution de clefs de session dans un réseau de télécommunication, procédés associés de traitement dans un client et un serveur, module client et serveurs associés.

L’invention se situe dans le domaine de la distribution des clefs dans un réseau de télécommunication comportant des serveurs de distribution de clefs et des modules clients utilisant ces clefs pour communiquer entre eux.

Elle est particulièrement utile dans les systèmes embarqués et/ou temps-réel critiques.

On désigne par « clefs de session » l’ensemble des données cryptographiques permettant d’assurer la confidentialité et/ou l’intégrité des communications entre plusieurs clients, quel que soit le type de chiffrement utilisé. Ces clefs sont valables pendant une durée prédéfinie, et donc soumises à renouvellement périodiques. Elles comportent par exemple des clefs symétriques ou asymétriques, utilisées pour chiffrer ou signer des données.

L’augmentation notable des performances des communications sans fil ainsi que le développement de protocoles standards rend possible l’utilisation massive d’objets connectés en contexte industriel (IIoT) ou grand public (IoT).

Malgré les avantages qu’ils apportent en termes de flexibilité et de connectivité, l’utilisation de ces systèmes composés majoritairement d’objets connectés de type IoT/IIoT, sont un facteur d’exposition à des risques nouveaux qui peuvent impacter fortement la cyber-sécurité et, par suite, la sûreté de fonctionnement. En effet, la dernière décade a été également marquée par l’avènement d’attaques de plus en plus complexes sur les systèmes industriels (Stuxnet en 2010, Black Energy en 2017…), ayant causé des dégâts considérables à leurs victimes.

Parmi les nombreux protocoles de communication pour l'IoT et l'IIoT, les protocoles des couches transport et supérieures dans le modèle OSI semblent particulièrement aptes à porter la sécurité, notamment les protocoles DDS, MQTT, CoaP et OPC UA. Ceux-ci supportent, pour la communication opérationnelle, des paradigmes producteur-consommateurs : le modèle publish/subscribe (PubSub) est une alternative au modèle "Client/Serveur" traditionnel. Le modèle "PubSub" dissocie le client (appelé publisher) qui envoie un message particulier, auquel les clients abonnés (appelés subscribers) ont accès. Un troisième acteur, appelé le broker, connu à la fois par le publisher et le subscriber, filtre tous les messages entrants provenant des publishers et les distribue en conséquence aux subscribers (ou les notifie de la disponibilité de nouvelles données accessibles depuis le broker) en fonction du type de message, du sujet ou du contenu et de critères indiqués par les subscribers. En conséquence, le publisher ne connaît pas la liste des subscribers appelés à recevoir les données que le publisher envoie au broker. Il est important de noter que l’authentification et la distribution des clefs peuvent relever d’autres paradigmes, par exemple client/ serveur.

MQTT et CoaP sont des protocoles de communication très légers n'incorporant nativement aucune sécurité. Dans le cas de MQTT, une version sécurisée nommée MQTT-S (ou MQTT-SN), sous la forme d'un chiffrement avec TLS avec déchiffrement/chiffrement des messages au niveau du broker. Cette solution n'est pas satisfaisante sur un réseau public, car le broker peut être compromis, exposant toutes les communications à des attaques de type Man In The Middle (MITM).

DDS propose une architecture distribuée (DDS Security version 1.1, OMG) permettant aux différents acteurs communicants d'échanger des clefs de chiffrement entre eux. Les fonctions de serveurs de clefs (KeyFactory) peuvent être implémentées dans tout acteur. La solution proposée par DDS est lourde en termes d'échanges générés à chaque connexion et donc peu compatible avec les contraintes de beaucoup de systèmes embarqués et/ou temps-réel critiques. De plus, aucune solution spécifique n’est proposée pour assurer la résilience de serveur de clefs.

OPC UA PUBSUB (OPC Unified Architecture Specificiations part 14, version 1.04, OPC Foundation) est une variante du protocole OPC UA. Elle propose entre autre une solution de chiffrement bout-à-bout où la distribution des clefs est centralisée, mais reste compatible avec OPC UA. Les clefs de chiffrement sont distribuées à tous les acteurs par un service spécifique, le service de clef de chiffrement (SKS). Cette solution est efficace en terme de communication réseau, et résistante aux attaques MITM, mais pose problème du point de vue de la sûreté de fonctionnement, en introduisant un point de vulnérabilité unique : le SKS.

Les mécanismes permettant d’assurer la redondance des SKS ne sont pas décrits explicitement dans la partie de la spécification décrivant OPC UA PUBSUB. Cependant, en PUBSUB, la distribution des clefs est faite en OPC UA Client-Serveur, où le SKS est implémenté dans un serveur OPC UA, tandis que le publisher ou subscriber est implémenté dans un client OPC UA - et la spécification OPC UA décrit une solution pour la redondance des serveurs (OPC Unified Architecture Specifications, part 4, version 1.04, section 6.6.2, OPC Foundation).

OPC UA définit deux modes de fonctionnement pour les mécanismes de redondance des serveurs génériques : transparent et non-transparent. Le mode transparent implémente un proxy situé entre les clients et les serveurs, qui se charge de rediriger les demandes des clients selon la disponibilité des serveurs. Le mode non-transparent donne au client la responsabilité de choisir un serveur au sein de l'ensemble de serveurs redondés.

Dans le mode non-transparent, il y a quatre catégories de basculement, correspondant à divers degrés de synchronisation des SKS :

-Froid :seul le serveur actif est fonctionnel, les autres sont éteints. Aucune information n'est donc synchronisée entre les serveurs, et le client doit maintenir en local les informations relatives aux serveurs inactifs (non-synchronisé) ;

-Tiède :tous les serveurs sont démarrés, et sont en écoute des différents clients, mais seul le serveur actif peut émettre vers un client. Les serveurs partagent donc les informations reçues des clients (synchronisés) ;

-Chaud: tous les clients sont connectés à tous les serveurs, et reçoivent les informations de ces derniers en parallèle. Le client est chargé de gérer les flux redondés ;

-Chaud et dupliqué :les clients ne sont connectés qu'à un serveur, qui maintient sur les autres serveurs une copie des sessions que les clients ouvrent avec lui. En cas de basculement, les clients n'ont pas à créer de nouveau contexte de session (fortement synchronisés).

Analyse de l’application de la redondance OPC UA à la distribution de clef dans PUBSUB :

Déterminisme de la génération des clefs

La spécificité des SKS est de détenir une clef (ou un jeu de clefs) dont la consultation illégitime remet en question la sécurité du système. De plus, ils ont un comportement asymétrique par nature, à cause de la source d'entropie nécessaire à la génération de clef. Deux SKS ayant les mêmes entrées auront des comportements différents (i.e. généreront des clefs différentes). C'est pourquoi il ne doit pas être possible d'avoir deux clients abonnés à des SKS différents - sans quoi ils ne pourront communiquer entre eux. Ce mode de fonctionnement exclut les basculements tièdes, qui sont basés sur le déterminisme des comportements des serveurs.

Synchronisation et vulnérabilité

Les solutions répliquant les données (typiquement tiède et au-delà) permettraient de remonter un serveur possédant la clef de chiffrement courante, ce qui introduirait une vulnérabilité (un SKS remonté devrait immédiatement procéder à une nouvelle génération de clef, car la clef du SKS défaillant doit être considérée comme potentiellement compromise). Par ailleurs ces solutions impliquent de multiplier le nombre de connexions dans le système par le nombre de SKS existants, ce qui est très lourd en terme d'impact sur les performances. Cette solution n'est donc pas souhaitable.

Le mode de basculement froid n'implique pas de communication supplémentaire, mais se repose sur une connexion directe avec le serveur pour détecter la défaillance de ce dernier. Cette hypothèse tombe dans le cas d'OPC UA PUBSUB, à cause de la présence du broker et de la nature déconnectée du protocole (cas général des paradigmes producteurs-consommateurs). Par ailleurs, la question du choix SKS n'est traitée dans la norme que dans l'optique de l'équilibrage de charge, et peut mener dans le cas de réseaux instables à ce que des clients choisissent des SKS différents, ce qui remettrait en question la disponibilité du système.

Détail des vulnérabilités de l’échange de clef : les trois risques résiduels présents lors de l’utilisation des techniques présentées dans l’état de l’art sont explicités ci-dessous dans le contexte de OPC UA PUBSUB pour l’exemple.

Risque 1 : Compromission du client

En cas d’utilisation d’un jeu de clefs de taille K supérieure à 1 (c’est-à-dire le jeu de clefs comprend au moins K clefs associées à des périodes de validité qui se succèdent, les K clefs étant donc prévues pour se succéder au fil du temps) et propre à un groupe de clients (l’objet électronique de type publisher ou subscriber est en effet un client vis-à-vis du serveur SKS, qui lui délivre des clefs secrètes), la sécurité face à une attaque statistique contre les clefs session utilisées pour chiffrer/déchiffrer les données publiées par le publisher est conservée (puisque les clefs changent), mais la sécurité face à la compromission d’un client du groupe est diminuée d’un facteur égal à la taille du jeu de clefs : en effet, si le jeu de clefs est obtenu par un attaquant, alors le groupe tout entier est compromis pour une durée d’autant plus grande. C’est une conséquence du fait de diminuer la fréquence de la distribution des clefs sécurisées.

Une telle situation est représentée en . Tout d’abord le serveur SKS distribue le jeu de clefs de session au Publisher et au Subscriber, de taille K. Dans une première phase φ1, la première clef secrète est utilisée pour le chiffrement par le Publisher des messages M1, qu’il envoie ensuite au Broker, lequel les fait suivre aux Subscribers qui déchiffrent les messages M1 avec la première clef secrète. Au cours de cette phase φ1, l’attaquant obtient de façon malveillante le jeu de clefs de session, par exemple en lisant la mémoire physique du Publisher. Après la date, T1, d’expiration de la première clef secrète, commence une deuxième phase φ2 (jusqu’à la date, T2, d’expiration de la deuxième clef secrète), où la deuxième clef secrète est utilisée pour le chiffrement par le Publisher des messages M2, qu’il envoie ensuite au Broker, lequel les fait suivre aux Subscribers qui déchiffrent les messages M2 avec la deuxième clef secrète ; l’attaquant lui aussi publie des messages chiffrés par la deuxième clef secrète qui parviennent aux subscribers via le broker, et cette intrusion peut durer tant que le jeu de clefs secrètes reste valide, i.e jusqu’à l’expiration de la validité de la Kième clef.

Risque 2 : Disponibilité au renouvellement

Les dates précises des demandes de renouvellement des clefs par les clients dépendent de leur source de temps. Si l’un d’entre eux est en retard par rapport au SKS, il pourra recevoir des messages chiffrés avec une clef secrète qu’il ne possède pas encore, et perdra donc ces messages. Selon le contexte d’emploi de l’IIoT, cela peut être un problème important, car les objets connectés peuvent être situés dans des réseaux ne disposant pas d’accès à des sources de temps fiables.

Risque 3 : Défaillance du SKS

La plateforme hébergeant le SKS peut être victime d’une panne, induite par une attaque ou accidentelle. Dans les deux cas, le réseau IIoT continuera de fonctionner jusqu’à expiration des clefs du jeu de clefs en cours d’usage, puis s’arrêtera faute de nouveau jeu. Comme la défaillance du SKS peut très bien être le résultat d’une compromission du SKS, et les clefs conservées dans le SKS être à présent connues de l’attaquant, cette continuité d’activité est en une vulnérabilité secondaire (on revient alors au risque 1).

Il existe donc un besoin d’améliorer la résilience et la cyber-sécurité dans les communications des systèmes répartis dans un contexte de système embarqué.

A cet effet, suivant un premier aspect, la présente invention décrit un procédé de distribution de clefs de session dans un réseau de télécommunication comportant un ensemble de N serveurs de distribution de clefs de session, N étant strictement supérieur à 1, des clients comportant des clients de type « publishers » et des clients de type « subscribers », et un module de communication intermédiaire de type « broker », lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;

selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite via le module de communication intermédiaire broker lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;

ledit procédé étant caractérisé en ce que :

un seul quelconque des serveurs, à tout instant considéré, a le rôle de serveur maître des serveurs, et seul le serveur maître est autorisé à distribuer des clefs de session aux clients ;

chaque serveur et chaque client stockent une même liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, chaque serveur stockant une liste des clients auxquels des clefs de session en cours de validité ont été distribuées par le serveur maître actuel et les serveurs maîtres précédents ;

chaque serveur, quand il a le rôle de serveur maître, envoie aux clients, selon au moins une périodicité minimale prédéfinie, un message périodique d’un premier type prédéfini (heartbeat) ;

chaque client surveille qu’il reçoit selon ladite périodicité prédéfinie, les messages du premier type en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, le client envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans la liste ordonnée des serveurs ;

chaque serveur de l’ensemble des serveurs, dès qu’il reçoit une requête de recherche d’un nouveau serveur maître, déclenche une opération d’élection d’un nouveau serveur maître auprès des serveurs de l’ensemble de serveurs ;

le serveur maître élu par ladite opération d’élection déclenche, dès son élection, auprès des clients de sa liste de clients, un remplacement des clefs de session valides indiquées dans la liste des clients et qui leur ont été attribuées.

L’invention assure une résilience sécurisée de la distribution des clefs de session et accroît la sécurité des communications.

Dans des modes de réalisation, un tel procédé comprendra en outre l’une au moins des caractéristiques suivantes :

• à l’expiration d’un délai prédéfini après qu’un client a envoyé une requête de recherche d’un nouveau serveur sans que le client ait reçu un message en provenance d’un serveur élu maître serveur, ledit client envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+2 dans la liste ordonnée de serveurs ;
• l’opération d’élection déclenchée par ledit serveur dès réception d’une requête de recherche d’un nouveau serveur maître comprend les étapes consistant à :

• envoyer à tous autres serveurs de la liste ordonnée des serveurs un message d’un deuxième type prédéfini, indiquant qu’un serveur maître est à élire, et identifiant le serveur envoyant ledit message ;
• après une temporisation déterminée :

- si ledit serveur a reçu pendant ladite temporisation un ou des messages du deuxième type en provenance de serveur(s) et que, d’après la liste ordonnée, sa priorité est inférieure à la priorité des serveurs ayant envoyé lesdits messages du deuxième type, il n’est pas le serveur maître élu par ladite opération d’élection ;

- si ledit serveur n’a reçu pendant ladite temporisation aucun message du deuxième type en provenance de serveur(s) ou s’il en a reçu et que, d’après la liste ordonnée, sa priorité est supérieure à la priorité des serveurs ayant envoyé lesdits messages du deuxième type, il est le serveur maître élu par ladite opération d’élection ;

• les nouvelles clefs destinées à remplacer les clefs de session sont générées par le serveur maître au moment de son élection à partir d’une nouvelle graine de génération qu’il génère aléatoirement ;
• la liste ordonnée est une boucle ordonnée, où après le serveur de rang N, on revient sur le serveur de rang 1 ;
• lors d’une demande de clef de session par un client, ledit client envoie une requête de clef au serveur de rang i dans la liste, en commençant par i = 1, et en l’absence de réponse revendiquant le statut de serveur maître de la part dudit serveur, incrémente la valeur de i, i = i+1, et itère ledit envoi de requête ;
• un mécanisme de synchronisation entre les serveurs comprend la synchronisation de la liste des serveurs indiquant le serveur maître actuel, aucune synchronisation des clefs distribuées par les serveurs et/ou de la source d’entropie des serveurs ne devant avoir lieu.

Suivant un autre aspect, l’invention décrit un procédé de traitement, mis en œuvre dans un client, pour l’obtention de clefs de session, dans un réseau de télécommunication comportant un ensemble de N serveurs de distribution de clefs de session, N étant strictement supérieur à 1, des clients comportant des clients de type « publishers » et des clients de type « subscribers », et un module de communication intermédiaire de type « broker », lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;

selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite via le module de communication intermédiaire broker lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;

ledit procédé étant caractérisé en ce que, le client ayant stocké une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, un seul quelconque des serveurs, à tout instant considéré, ayant le rôle de serveur maître des serveurs, et seul le serveur maître étant autorisé à distribuer des clefs de session aux clients :

le client surveille qu’il reçoit selon une périodicité minimale prédéfinie, des messages périodiques d’un premier type prédéfini (heartbeat) en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et

lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, le client envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maîtreactuel de rang n dans la liste ordonnée des serveurs ;

le client reçoit, depuis un nouveau maître serveur, de nouvelles clefs de session pour remplacement des précédentes clefs de session.

Suivant un autre aspect, l’invention décrit un client dans un réseau de télécommunication comportant un ensemble de N serveurs de distribution de clefs de session, N étant strictement supérieur à 1, des clients comportant des clients de type « publishers » et des clients de type « subscribers », chaque client subscriber étant associé à un client publisher, et un module de communication intermédiaire de type « broker », lesdits serveurs, clients et broker étant adaptés pour être interconnectés par des liaisons de télécommunication ;

un client publisher étant adapté pour délivrer au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher étant adapté pour ensuite obtenir, via le module de communication intermédiaire broker, lesdites informations consultables et déchiffrer, et/ou vérifier, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;

ledit client étant un dispositif électronique caractérisé en ce que, le client ayant stocké une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, un seul quelconque des serveurs, à tout instant considéré, ayant le rôle de serveur maître des serveurs, et seul le serveur maître étant autorisé à distribuer des clefs de session aux clients :

le client est adapté pour surveiller qu’il reçoit selon une périodicité minimale prédéfinie, des messages périodiques d’un premier type prédéfini (heartbeat) en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et

le client est adapté pour, lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, envoyer une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans la liste ordonnée des serveurs et pour recevoir, depuis un nouveau maître serveur, de nouvelles clefs de session pour remplacement de clefs de session valides précédemment attribuées au client.

Suivant un autre aspect, l’invention décrit un serveur de distribution de clefs de session dans un réseau de télécommunication comportant un ensemble de N serveurs de distribution de clefs de session, N étant strictement supérieur à 1, des clients comportant des clients de type « publishers » et des clients de type « subscribers », et un module de communication intermédiaire de type « broker », lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;

selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite, via le module de communication intermédiaire broker, lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;

ledit serveur étant caractérisé en ce qu’il est adapté pour respecter la règle suivante : un seul quelconque des serveurs, à tout instant considéré, a le rôle de serveur maître des serveurs, et seul le serveur maître est autorisé à distribuer des clefs de session aux clients ;

le serveur stockant une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, et le serveur stockant une liste des clients auxquels des clefs de session en cours de validité ont été distribuées par le serveur maître actuel et les serveurs maîtres précédents ;

le serveur est adapté pour, quand il a le rôle de serveur maître, envoyer aux clients, selon au moins une périodicité minimale prédéfinie, un message périodique d’un premier type prédéfini (heartbeat) ;

le serveur est adapté pour, quand il reçoit une requête de recherche d’un nouveau serveur maître depuis un client, déclenche une opération d’élection d’un nouveau serveur maître auprès des serveurs de l’ensemble de serveurs ;

le serveur est adapté, s’il est élu le serveur maître par ladite opération d’élection déclencher, dès son élection, auprès des clients de sa liste de clients, un remplacement des clefs de session valides indiquées dans la liste des clients et qui leur ont été attribuées.

L’invention sera mieux comprise et d’autres caractéristiques, détails et avantages apparaîtront mieux à la lecture de la description qui suit, donnée à titre non limitatif, et grâce aux figures annexées, données à titre d’exemple.

La représente un système de communication de type producteurs d’information-consommateurs d’information dans un mode de réalisation de l’invention ;

La représente les étapes de détection d’une panne de serveur SKS ;

La représente les étapes d’une élection de serveur maître des serveurs SKS ;

La est un schéma de l’architecture d’un système mettant en œuvre l’invention dans le domaine ferroviaire ;

La illustre une situation de compromission d’un client dans l’art antérieur.

Des références identiques peuvent être utilisées dans des figures différentes lorsqu’elles désignent des éléments identiques ou comparables.

La représente un système de communication de communicationrésiliente répartie et sécurisée pour l’échange de clefs de session dans un mode de réalisation de l’invention.

Dans le mode de réalisation considéré en référence à la , le système de communication 1 comprend un nombre P de dispositifs électroniques clients 2_1, 2_2, …, 2_P, par exemple des ordinateurs ou des smartphones (P nombre quelconque, supérieur ou égal à 2), un nombre N de serveurs de clefs secrètes (N supérieur ou égal à 2 et dans le cas représenté, N = 3) 1_1, 1_2, … 1_N, nommés ici serveurs SKS, et un dispositif broker 3, typiquement un ordinateur.

Des liaisons de télécommunication 4, comprenant par exemple des liaisons sans fil, interconnectent entre eux les serveurs SKS, les clients et le broker, qui sont adaptés pour communiquer via lesdites liaisons 4. Parmi les clients figurent des clients publishers et des clients subscribers et la transmission de messages depuis un publisher vers un ou des subscribers se fait via le broker 3.

Un publisher et les subscribers ayant accès aux messages du publisher constituent un groupe ; des clefs de session, propres au groupe (notamment le broker n’obtient pas ces clefs), leur sont distribuées pour le chiffrement par le publisher des messages qu’il envoie au broker et le déchiffrement par les subscribers des messages délivrés par le broker issu du publisher. La clef de chiffrement est par exemple une clef symétrique, ou alors une paire de clefs asymétriques. Le chiffrement est conforme à la norme AES 256 par exemple.

L’architecture est précisée en pour le serveur 1_1, et chaque serveur présente la même architecture que celle du serveur 1_1.

Similairement, l’architecture est précisée en pour le client 2_1, et chaque client présente la même architecture que celle du client 2_1.

Le mode de réalisation décrit ici est relatif à un système qui intègre l’invention sur la base du protocole OPC UA PUBSUB, mais l’invention peut bien sûr être implémentée en utilisant un autre protocole de communication utilisant le paradigme de communication par groupe (e.g. MQTT).

La fonction de distribution de clefs de session est redondée par la présence de N serveurs de clefs.

Les serveurs de clefs sont par exemple des serveurs informatiques adressables, via les liaisons de communication 4, depuis tous les points du réseau, et leur adresse réseau est connue de tous les clients présents et futurs.

Chaque serveur de clefs 1_1, 1_2, …1_N comprend, outre un calculateur et des moyens de télécommunication via les liaisons 4 :

• un module électronique 13 de génération de clefs, par exemple de type OPC UA PUBSUB côté SKS permettant de (1) générer de nouvelles clefs de session à l’expiration de la durée de vie des précédentes ou à l’issue de l’élection d’un nouveau serveur maître et (2) de transmettre ces clefs aux clients concernés ;

ainsi que les quatre modules additionnels mis en œuvre dans un mode de réalisation de l’invention :

• un module électronique 14 d’élection, adapté pour mettre en œuvre les étapes des élections de serveur maître (cf. ci-dessous) ;
• un module électronique 15 de signalisation de présence adapté pour envoyer des messages permettant la détection de panne de SKS par les clients de (cf. ci-dessous) ;
• un module électronique 16 de renouvellement des clefs, adapté pour mettre en œuvre la distribution des clefs à l’initiative du SKS lors de l’élection en tant que serveur maître du serveur de clefs (cf. ci-dessous) et en outre à l’expiration de la période de validité des clefs qui ont été générées par le serveur de clefs ;
• un module électronique 17 d’authentification sécurisée adapté pour mettre en œuvre la sécurisation de l’authentification utilisée dans la distribution de clefs (cf. ci-dessous) ;

Chaque serveur de clefs 1_1, 1_2, …1_N comprend une mémoire stockant :

• la liste 11 des serveurs 1_1, 1_2, …1_N ainsi qu’un curseur sur le SKS maître actuel ; dans la liste 11, les serveurs sont ordonnés selon un ordre de priorité affecté à chacun des serveurs ; ici par exemple la plus grande priorité est affectée au serveur 1_1 et la plus faible priorité au serveur 1_N. L’ordre de priorité est par exemple arbitraire ou fonction de la capacité des serveurs ou de leur position géographique. On notera que l’objectif de la redondance est de permettre d’assurer la résilience, et non la performance – l’invention ne s’applique donc pas à la redondance appliquée pour l’équilibrage de charge ;
• la liste 12 identifiant les clients, listant pour chaque client du système 1, notamment son adresse réseau, comme par exemple une adresse IP et un port en TCP/IP ;
• la date d’expiration des clefs que ledit serveur a distribué en association avec l’identifiant des clients destinataires de ces clefs.

Chaque client 2_1, …, 2_P, qu’il soit de type publisher ou subscriber, comprend, outre un calculateur et des moyens de télécommunication via les liaisons 4 :

• un module électronique 22 de publication/abonnement et de gestion des clefs de session reçue d’un SKS (par exemple de type OPC UA PUBSUB côté client, dans un mode de réalisation),
• un module électronique 23 de détection de dysfonctionnement du SKS maître ;
• un module électronique 24 d’authentification sécurisée adapté pour mettre en œuvre la sécurisation de l’authentification utilisée dans la distribution de clefs (cf. ci-dessous).

Chaque client comprend une mémoire stockant la liste 21 des serveurs de clefs 1_1, …, 1_N ordonnés selon l’ordre de priorité affecté à chacun des serveurs, ainsi que leur adresse réseau en vue d’effectuer le routage physique des trames, comme par exemple une adresse IP et un port en TCP/IP.

Chaque serveur de clefs synchronise avec les autres serveurs de clefs et avec tous les clients la liste ordonnée des SKS, ainsi que le curseur sur le SKS maître actuel. Chaque serveur de clefs synchronise avec les autres serveurs de clefs la liste 12 des clients.

La synchronisation entre serveurs de clefs est effectuée de façonlaxe: i.e. elle est volontairement limitée à deux éléments : la liste ordonnée des SKS (contenant également un pointeur vers le SKS maître) et la liste des clients. La synchronisation de la liste des SKS est une propriété convergente de l’élection du serveur maître (cf. ci-après). Cette synchronisation est dite laxe car elle exclue un certain nombre de données dont la réplication serait une source de vulnérabilités. En particulier, aucune synchronisation des clefs (ni de leur date d’expiration) distribuées par les serveurs aux clients n’est effectuée entre les serveurs de clefs, pas plus que de la source d’entropie (mécanisme et graine).

Dans un mode de réalisation, les modules électroniques dans les clients, respectivement les serveurs sont réalisés sous forme de modules logiciels comprenant des instructions logicielles qui lorsqu’elles sont exécutées sur un calculateur du client, respectivement du serveur, mettent en œuvre les étapes décrites ci-dessous et incombant au client, respectivement au serveur.

Chaque serveur de clefs 1_1, 1_2, …1_N est adapté pour fonctionner en serveur maître ou en serveur esclave selon qu’il est le dernier élu serveur maître ou non.

Si et seulement si un serveur de clef est le serveur maître, alors son module électronique 15 de signalisation de présence envoie à chaque client, à l’adresse réseau indiquée dans la liste clients 12, un message d’un premier type, nommé ici message «heartbeat», à intervalles réguliers, selon une période prédéfinie ou un profil cyclique défini et connu des clients. L’objectif de ce message est de signifier le fait que le SKS émetteur est opérationnel.

Le module de détection de dysfonctionnement 23 dans chaque client 2_1, …, 2_P, surveille qu’il reçoit, selon ladite périodicité prédéfinie, les messagesheartbeaten provenance du serveur maître actuel tel indiqué par le curseur dans la liste ordonné des serveurs 21; et lorsqu’il détecte que le messageheartbeatn’a pas été reçu conformément à ladite périodicité prédéfinie (ou dans des modes de réalisation, que le nombre de messages non reçus selon cette périodicité est supérieur à un seuil fixé, supérieur ou égal à 2), le module de détection 23 du client détecte un dysfonctionnement et envoie une requête de recherche (message de typeMaster Request)d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel (de rang n dans la liste) dans la liste ordonnée des serveurs.

Le message de typeheartbeatest, dans le cas considéré, par exemple paramétré parrenewal, qui définit le nombre de messages manqués déclenchant un changement de serveur de clef, etperiod, qui définit la périodicité de l’envoi duheartbeat. Cette valeur de périodicité est typiquement la durée maximale pendant laquelle des pertes de messages sont acceptables du point de vue opérationnel, divisée parrenewal.

La illustre le déroulé de ces précédentes étapes mises en œuvre dans une situation de détection de de panne du serveur SKS maitre par un client (ici publisher).

Chaque module 14 d’élection de chaque serveur de clef, à l’exclusion du serveur maître précédent, dès réception par ledit serveur de clefs d’un message de typeMaster Requestenvoyé par un client 2_i, i = 1 à P, envoie à tous les autres serveurs de la liste 11 des serveurs un message requérant une élection, nommé ici messageMaster Claim,avec l’identifiant du serveur. Il attend un temps prédéfini (délai nommétimeoutégal au minimum deux fois la latence du message en prenant comme référence l’envoi de son propre Master Claim). Il peut recevoir pendant cette période un ou des messagesMaster Claimvenant d’autres serveurs de clef. A la fin de l’attente :

• si la priorité du serveur de clef auquel appartient le module d’élection 14 est inférieure à celles d’autresMaster Claimreçus, il se considère comme serveur esclave, et ne répond pas au client ;
• dans le cas contraire, c’est-à-dire s’il n’a reçu aucun messageMaster Claim,le serveur devient le serveur de clef maître courant, il génère alors de nouvelles clefs de session et le module 16 de renouvellement des clefs du serveur de clef répond au client l’ayant sollicité par le message Master Request par unSetSecurityKey(avec un renouvellement de clef immédiat quelle que soit la date d’expiration de sa clef) et plus globalement à chaque client de sa liste de clients.

Il met en outre à jour le curseur dans sa liste des serveurs 11 et par synchronisation, la liste des serveurs dans les autres serveurs et dans les clients est mise à jour également.

SetSecurityKeyest un ensemble d’échanges protocolaires initié par un SKS et à destination d’un client, et a pour fonction d’envoyer de nouvelles clefs de session au client. Ces échanges incluent l’authentification réciproque des interlocuteurs, la création d’un canal sécurisé entre ceux-ci et la transmission des clefs de session dans ce canal. Une solution d’implémentation possible et efficace serait d’utiliser la fonction homonyme définie dans OPC UA PUBSUB.

La illustre une élection de serveur SKS maître dans le système 1, après un dysfonctionnement détecté par exemple comme illustré en , avec N=3.Dans le scénario illustré, un client Publisher 2_i (i ∈ 1,…, Q, Q<P) a détecté une défaillance du serveur alors maître (ici le serveur 1_1) ; il envoie comme décrit précédemment un message Master Request au serveur esclave 1_2. Le serveur esclave 1_2 émet un messageMaster Claimà destination de chacun des serveurs 1_1 et 1_3. Ici seul le serveur esclave 1_2 a reçu unMaster Requestd’un client. Il est donc le seul à émettre uneMaster Claim. Il procède donc à l’envoi d’unSetSecurityKeyaprès expiration dutimeoutà destination du client 2_i.

Dans un mode de réalisation, si le client n’a pas eu de retour (messageSetSecurityKey)après l’expiration d’un délai prédéfini (typiquement égale àtimeoutfois deux) suite à l’envoi de son messageMaster Request,le client envoie alors un messageMaster Requestau serveur suivant dans sa liste, et ainsi de suite. Une fois le Nième serveur, le serveur 1_N, de la liste des serveurs atteint, le client reboucle sur le premier serveur 1_1, en incrémentant la durée entre chaque cycle, jusqu’à obtenir une réponse. Un mécanisme extérieur au serveur maître exclu permet de s’assurer de sa non-compromission avant de le réintroduire dans la liste des serveurs SKS éligibles à la position de serveur maître.

La redondance est dite cyclique car, après épuisement de la liste des serveurs de clef (par défaillance de la totalité d’entre eux) sans réception d’un message indiquant la prise en compte de sa requête, le client va repartir sur le premier serveur, et ainsi de suite, jusqu’à ce qu’un des serveurs de clefs réponde finalement.

La redondance est dite adaptable car un nombre arbitraire N de serveurs peut être provisionné, en fonction des besoins du système en termes de disponibilité.

Le risque 3 mentionné plus haut est évité, puisque le serveur de clefs est redondé sans limites théoriques. Les clefs de session éventuellement compromises ne le seront que pendant une durée maximale égale àperiodfoisrenewal(plus le temps d’élection du serveur maître, très généralement extrêmement court).

On notera que la transmission des clefs de session est effectuée selon le standard OPC UA PUBSUB, dans le mode de réalisation considéré et donc selon les étapes suivantes :

1. Envoi par le client 2_i (i ∈ 1,…, P) de ses certificats (contenant en particulier leur clef publique de chiffrement) au serveur SKS maître 1_n (n ∈ 1,…, N);
2. Vérification du certificat par le serveur SKS maître (signature par une autorité légitime et date d’expiration) ;
3. Réponse du serveur SKS par l’envoi d’un message non prévisible chiffré avec la clef publique du client (challenge);
4. Déchiffrement par le client du challenge en utilisant sa propre clef privée ;
5. Réponse du client au challenge par un message contenant le même texte, chiffré avec la clef publique du SKS ;
6. Déchiffrement par le SKS du message reçu du client (réponse au challenge) ;
7. Calcul par le client d’une clef secrète temporaire SK1 utilisant la clef publique du SKS et sa clef privée ;
8. Calcul par le SKS d’une clef secrète temporaire SK2 utilisant la clef publique du client et sa clef privée (par construction SK1 = SK2);
9. Envoi par le SKS de la clef de session (ou clef de groupe) chiffrée avec SK2 par le SKS ;
10. Déchiffrement par le client de la clef de session avec SK1.

Dans un mode de réalisation de l’invention, la conservation des clefs privées est effectuée, pour chaque interlocuteur (Client et SKS), dans des « Secure Elements » (SE) présents dans leurs hôtes respectifs, par exemple suivant le standard TPM2 (https://trustedcomputinggroup.org/resource/tpm-library-specification/), ou le Embedded Secure Element de Gemalto (https://www.thalesgroup.com/en/markets/digital-identity-and-security/mobile/secure-elements/embedded-secure-element).

Dans ce mode de réalisation, l’échange des clefs de session est sécurisé en ajoutant les étapes suivantes :

En phase de provisionnement :

• La clef privée de chaque client est conservée dans un « Secure Element » (SE) ;
• Le certificat du client est généré (signature cryptographique) par le SE sans que la clef privée soit extraite de celui-ci ;
• La clef privée de chaque SKS est conservée dans le SE présent dans son hôte ;
• Le certificat du SKS est également généré en utilisant le SE.

En phase opérationnelle (distribution de clef) :

• Le déchiffrement du challenge SKS (phase 4) est effectué dans le SE du Client ;
• Le déchiffrement de la réponse au challenge par le Client (phase 6) est effectué dans le SE du SKS ;
• Le calcul de la clef secrète temporaire SK1 (étape 7) est effectué par le SE du client ;
• Le calcul de la clef secrète temporaire SK2 (étape 8) est effectué par le SE du SKS ;

Comme les clefs privées ne quittent jamais le SKS (ou le client), et grâce aux propriétés de non-lisibilité du SE, un accès physique à la machine ne permet pas simplement de les obtenir, et il n’est donc pas possible à un attaquant ne disposant pas de moyens très conséquents de compromettre l’intégrité ou la confidentialité du système en insérant un nœud illégitime.

A l’issue de ces étapes de transmission de clef entre un publisher et un SKS implémentant ces principes, le publisher a reçu une clef de session chiffrée, ainsi que la clef temporaire (SK1) qui permet de déchiffrer cette clef secrète. A aucun moment la clef de session n’a été transmise en clair, et une clef privée légitime (signée par une autorité de certification connue du SKS) est nécessaire pour calculer une clef temporaire. Un attaquant n’a aucun moyen simple d’obtenir une clef privée légitime, puisque celles-ci sont protégées par des SE.

Lors d’une demande de clef initiale, un client essaye tous les serveurs de clef (dans l’ordre de priorité décroissant de la liste, du rang 1 au rang N) jusqu’à en trouver un qui réponde. Il établit alors une connexion sécurisée et reçoit les clefs de session. A la différence de ce qui se passe dans la version actuelle du protocole OPC UA PUBSUB, le serveur de clef associe au nouveau client ses identifiants réseau (au format dépendant du protocole utilisé, e.g. adresse IP et port d’écoute en IP). Cette association peut être implémentée dans un tableau indexé par l’identifiant du client.

En cas de clef expirée, le renouvellement de clef dans un mode de réalisation de l’invention est imposé par le serveur de clef maître et non par les clients individuellement. A l’expiration de la clef, le serveur de clef maître et pas les serveurs esclaves, exploite saClient Listpour diffuser un messageSetSecurityKeyaffectant les nouvelles clefs dans tous les clients connus. Un décalage entre les assignations de clefs aux clients est toujours possible à cause des aléas du routage, mais celui-ci sera beaucoup moins grand que celui lié à une source de temps défaillante. Le risque 2 est donc mitigé. Dans cette opération de renouvellement, le SKS fournit également son propre identifiant aux clients.

On notera que les clefs de session distribuées par les serveurs de clefs selon l’invention peuvent comporter d’autres clefs que celles de chiffrement ou de déchiffrement (différentes dans le cas de chiffrement asymétriques), par exemple clefs de signature utilisées, ou date d’expiration de ces clefs.

Cette solution traite ou mitige les risques évoqués dans la distribution de clef OPC UA PUBSUB et plus généralement dans les paradigmes de communication par groupe ; elle propose des mécanismes pour assurer la résilience sécurisée de la distribution et de l’usage des clefs de session par synchronisation laxe dans les paradigmes de communication de type producteurs-consommateurs tout en apportant les bénéfices suivants :

• disponibilité des communications : la défaillance d’un serveur hébergeant le service de clef sécurisé (SKS) n’a qu’un impact minimal et limité dans le temps sur la capacité à communiquer de façon sécurisée (chiffrée et signée).
• intégrité de la clef secrète : une clef secrète potentiellement compromise fait l’objet d’une utilisation minimale par les producteurs et consommateurs du groupe associé à cette clef.
• sécurité des communications : les communications sont mieux protégées contre les attaques en confidentialité ou en intégrité grâce à la garantie supplémentaire concernant l’intégrité de la clef secrète.
• faible impact sur les performances : l’impact sur les performances est minimal en termes de débit réseau (entre les serveurs de clefs, ou entre les serveurs de clefs et les clients), temps de calcul (dans les serveurs de clef ou dans les clients), latence (pour la réception d’une clef valide par un client) et empreinte mémoire (sur les serveurs de clef).

Il est étudié ci-après comment l’invention permet d’adresser les trois risques indiqués relativement à l’art antérieur.

Résolution du Risque 1 : Compromission du client

En cas de compromission d’un client, les clefs compromises ne sont que les dernières clefs distribuées par le serveur de clef. La solution, dans le mode de réalisation où il n’est envoyé que des clefs uniques (taille du jeu = 1) et non des listes de clefs, permet de réduire la durée de compromission des échanges.

Pour ce qui relève de la compromission de la distribution des clefs, le fait qu’une réception de clef implique un échange sécurisé par un SE empêche strictement la réplication (ou clonage) du certificat du client. De plus, l’accès à l’élément physique étant protégé, elle rend plus difficile le fait de d’obtenir une nouvelle clef valide du service de clef.

Résolution du Risque 2 : Disponibilité au renouvellement

Du fait de la redondance des serveurs de clefs, la résilience du serveur de clef permet d’assurer la disponibilité du service de distribution des clefs même en cas de défaillance (accidentelle ou malveillante) d’un serveur de clef.

L’invention permet de déployer les serveurs de clefs sur des architectures hétérogènes (différentes bibliothèques logicielles, systèmes d’exploitation et/ou architectures matérielles). De cette façon, une protection est apportée contre des vulnérabilités non encore découvertes (0-day) qui seraient présentes dans ces éléments, du moins si elles sont utilisées en vue d’obtenir un déni de service (DoS).

Résolution du Risque 3 : Compromission d’un serveur de clef

Le mécanisme de synchronisation laxe proposé permet d’assurer que, en cas de compromission détectable d’un serveur (c’est-à-dire impliquant une interruption du service), les clefs présentes sur le serveur compromis sont très rapidement invalidées, et une nouvelle graine de génération est générée aléatoirement par un autre serveur de clef, avant d’être utilisée pour générer une nouvelle clef (et les clefs suivantes générées par ce serveur) qui sera ensuite diffusée aux clients. L’exposition des données est limitée dans le temps et calculable. On suppose l’existence de moyens de génération aléatoire possédant une entropie satisfaisante sur chaque SKS.

A titre d’illustration, il est maintenant présenté la mise en œuvre de l’invention dans le cas d’une application type big data pour la maintenance prédictive dans le domaine ferroviaire. Cette application exploite des données remontées de capteurs pour obtenir un état en temps réel souple de l’état d’équipements de voies ferroviaires (rails, caténaires, etc.). L’opérateur ferroviaire souhaite sécuriser les communications sur le réseau public, y compris entre la passerelle sécurisée et le réseau APN (Access Public Network) fourni par un opérateur télécom.

Un protocole de communication sécurisée producteur-consommateur mettant en œuvre l’invention, comme représenté schématiquement en , est implémenté dans ce système, pour apporter la sécurité tout en maintenant la disponibilité des informations. Dans le mode de réalisation considéré, il est créé une extension du protocole OPC UA PUBSUB pour implémenter l’invention.

Le mode de réalisation de l’invention décrit ci-dessus dans le cas particulier dans le cas d’un système implémentant la norme OPC UA PUBSUB comprend l’utilisation des échanges protocolaires suivants :

GetSecurityKey :non modifié par rapport à la norme OPC-UA PUBSUB.

SetSecurityKey :modifié par rapport à la norme OPC-UA PUBSUB. Ajout de l’identifiant du serveur SKS maître aux informations envoyées au client.

HeartBeat: nouveau. Informe un client de la disponibilité du SKS maitre. Paramètres : renewal, period.

Master Claim :nouveau. Informe un SKS de la candidature d’un autre SKS à l’élection du maître. Paramètres : identifiant, priorité.

Master Request :nouveau. Informe un SKS d’une demande de nouveau serveur maître par un client. Paramètres : identifiant.

Une autre variante serait de l’implémenter au travers d’une nouvelle couche de protocole de communication sécurisée qui serait située au-dessus du protocole OPC UA PUBSUB. Cette variante est une solution qui limite l’effort de développement, et permet à la fois de pouvoir profiter du protocole OPC UA et d’être indépendant de OPC UA de manière à ce que notre invention puisse être utilisée au-dessus de n’importe quel autre protocole de communication de producteur-consommateur.

Dans le cas considéré, trois serveurs de clefs tels que décrits plus haut sont instanciés, avec renouvellement clef effectué quotidiennement à 4 heures du matin. 500 instances de capteurs connectés (producteurs) ont été déployées, relevant la tension physique des caténaires. Deux consommateurs ont été déployés : un pour le centre de visualisation et d’analyse, et un pour le centre de commandement. D’autres producteurs et consommateurs pourrons être ajoutés durant le cycle de vie du système (par exemple pour une supervision par les autorités civiles), conformément à la nature dynamique des architectures couvertes par l’invention.

Les paramétrages sont par exemple les suivants :Heartbeat: 1 minute ;Renewal: 3 messagesHeartbeatmanquants ;Timeout: 30 secondes.

Par ailleurs la latence d’une communication client-SKS est estimée (après mesures opérationnelles) de l’ordre de 1 seconde, et la disponibilité d’un serveur est estimée à 99 %.

Le SKS n’envoie pas de jeu de clefs, mais uniquement des clefs individuelles. Le risque 1 est ainsi mitigé. Le coût de cette mesure est celui d’une connexion sécurisée (en termes de débit réseau), avec une périodicité étant égale à la durée de vie de la clef (date d’expiration moins date de création). Cette mesure n’est faisable que si la bande passante pendant la durée de vie cryptographique de la clef symétrique est supérieure au coût de cette connexion. Ceci est valable dans la grande majorité des cas, et en particulier dans le cas d’étude proposé.

Ainsi, par la mise en œuvre de l’invention, le seul cas de non-disponibilité durable du SKS est la défaillance collective de la totalité des serveurs de clefs (soit un taux de disponibilité du service de 99,9999%). Pour un client, le pire temps d’attente pour recevoir une clef suite à une demande sera égal à 32 secondes (timeout de l’élection du SKS plus deux fois la latence d’une communication SKS-client). Le temps maximal d’utilisation d’une clef potentiellement invalide (i.e. clef provenant d’un serveur de clef défaillant) sera de 3 minutes.

En résumé, l’invention comprend les éléments suivants (ou au moins certains des éléments selon les modes de réalisation) :

• résilience du service de distribution des clefs par utilisation de mécanismes permettant la mise en œuvre d’une redondance cyclique configurable du serveur de clef ;
• synchronisation laxe entre les serveurs de clef (on entend par « laxe » - correspondant au sens du terme anglais « loose » -, le fait que certaines informations ne sont pas synchronisés entre serveurs de clefs comme décrit plus haut) ;
• détection de panne dans les serveurs de clef par les clients ;
• élection d’un serveur de clef maître ;
• transmission sécurisée des clefs, renforcée par l’utilisation d’un SE ;
• implémentation par exemple en créant une extension sécurisée du protocole OPC UA PUBSUB ou de autre protocole de communication de producteur-consommateur.

Cette invention est particulièrement utile dans les domaines industriels critiques basés sur un ensemble de calculateurs ou éléments de calcul distribuées voir géo-distribuées supportant l’environnement client-serveur et possédant un système de communication par échange de messages de type producteur-consommateur avec présence d’un agent médiateur entre émetteurs et récepteurs (« broker ») exigeant un haut niveau de Cyber-sécurité. Elle permet d’augmenter la confidentialité, l’intégrité et la disponibilité des communications entre les différents composants du système industriel capteurs, calculateurs et actionneurs, de bout en bout (de l’application émettrice à l’application réceptrice) tout en ayant un faible impact sur les performances.

Les domaines industriels susceptibles de déployer notre invention pour sécuriser leurs systèmes de communication comportent notamment tout domaine relevant de l’Industrie 4.0, et tout domaine de type : IIoT (Industrial Internet of Things), ville intelligente, spatial, aéronautique, automobile, naval, ferroviaire (infrastructure, train, tramway), militaire (champ de bataille connecté).

Claims (10)

1. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication comportant un ensemble de N serveurs (1_1, 1_2) de distribution de clefs de session, N étant strictement supérieur à 1, des clients (2_1, 2_2) comportant des clients de type « publishers » et des clients de type « subscribers », et un module (3) de communication intermédiaire de type « broker » lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;
   selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite via le module de communication intermédiaire broker lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;
   ledit procédé étant caractérisé en ce que :
   un seul quelconque des serveurs (1_1, 1_2), à tout instant considéré, a le rôle de serveur maître des serveurs, et seul le serveur maître est autorisé à distribuer des clefs de session aux clients (2_1, 2_2) ;
   chaque serveur (1_1, 1_2) et chaque client (2_1, 2_2) stockent une même liste ordonnée en vue de l’élection d’un nouveau serveur maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, et chaque serveur stocke une liste des clients auxquels des clefs de session en cours de validité ont été distribuées par le serveur maître actuel et les serveurs maîtres précédents ;
   chaque serveur (1_1, 1_2), quand il a le rôle de serveur maître, envoie aux clients (2_1, 2_2), selon au moins une périodicité minimale prédéfinie, un message périodique d’un premier type prédéfini (heartbeat) ;
   chaque client (2_1, 2_2) surveille qu’il reçoit selon ladite périodicité prédéfinie, les messages du premier type en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, le client (2_1, 2_2) envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans la liste ordonnée des serveurs ;
   chaque serveur (1_1, 1_2) de l’ensemble des serveurs, dès qu’il reçoit une requête de recherche d’un nouveau maître serveur, déclenche une opération d’élection d’un nouveau serveur maître auprès des serveurs de l’ensemble de serveurs ;
   le serveur maître élu par ladite opération d’élection déclenche, dès son élection, auprès des clients (2_1, 2_2) de sa liste de clients, un remplacement des clefs de session valides indiquées dans la liste des clients et qui leur ont été attribuées.
2. Procédé de distribution de clefs session dans un réseau de télécommunication (1) selon la revendication 1, selon lequel à l’expiration d’un délai prédéfini après qu’un client (2_1, 2_2) a envoyé une requête de recherche d’un nouveau serveur sans que le client ait reçu un message en provenance d’un serveur élu maître serveur, ledit client (2_1, 2_2) envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+2 dans la liste ordonnée de serveurs.
3. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication selon l’une des revendications précédentes, selon lequel l’opération d’élection déclenchée par ledit serveur (1_1, 1_2) dès réception d’une requête de recherche d’un nouveau serveur maître comprend les étapes consistant à :
   - envoyer à tous les autres serveurs de la liste ordonnée des serveurs un message d’un deuxième type prédéfini, indiquant qu’un serveur maître est à élire, et identifiant le serveur envoyant ledit message ;
   - après une temporisation déterminée :
   - si ledit serveur (1_1, 1_2) a reçu pendant ladite temporisation un ou des messages du deuxième type en provenance de serveur(s) et que, d’après la liste ordonnée, sa priorité est inférieure à la priorité des serveurs ayant envoyé lesdits messages du deuxième type, il n’est pas le serveur maître élu par ladite opération d’élection ;
   - si ledit serveur (1_1, 1_2) n’a reçu pendant ladite temporisation aucun message du deuxième type en provenance de serveur(s) ou s’il en a reçu et que, d’après la liste ordonnée, sa priorité est supérieure à la priorité des serveurs ayant envoyé lesdits messages du deuxième type, il est le serveur maître élu par ladite opération d’élection.
4. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication selon l’une des revendications précédentes, selon lequel les nouvelles clefs destinées à remplacer les clefs de session sont générées par le serveur maître au moment de son élection à partir d’une nouvelle graine de génération qu’il génère aléatoirement.
5. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication selon l’une des revendications précédentes, selon lequel la liste ordonnée est une boucle ordonnée, où après le serveur de rang N, on revient sur le serveur de rang 1.
6. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication selon l’une des revendications précédentes, selon lequel lors d’une demande de clef de session par un client (2_1, 2_2), ledit client envoie une requête de clef au serveur (1_1, 1_2) de rang i dans la liste, en commençant par i = 1, et en l’absence de réponse revendiquant le statut de serveur maître de la part dudit serveur, incrémente la valeur de i, i = i+1, et itère ledit envoi de requête.
7. Procédé de distribution de clefs de session dans un réseau (1) de télécommunication selon l’une des revendications précédentes, selon lequel un mécanisme de synchronisation entre les serveurs (1_1, 1_2) comprend la synchronisation de la liste des serveurs indiquant le serveur maître actuel, aucune synchronisation des clefs distribuées par les serveurs et/ou de la source d’entropie des serveurs ne devant avoir lieu.
8. Procédé de traitement, mis en œuvre dans un client (2_1, 2_2), pour l’obtention de clefs de session, dans un réseau (1) de télécommunication comportant un ensemble de N serveurs (1_1, 1_2) de distribution de clefs de session, N étant strictement supérieur à 1, des clients (2_1, 2_2) comportant des clients de type « publishers » et des clients de type « subscribers », et un module de communication intermédiaire (3) de type « broker » lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;
   selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite, via le module de communication intermédiaire broker (3), lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur (1_1, 1_2) est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;
   ledit procédé étant caractérisé en ce que, le client (2_1, 2_2) ayant stocké une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs (1_1, 1_2), ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, un seul quelconque des serveurs, à tout instant considéré, ayant le rôle de serveur maître des serveurs, et seul le serveur maître étant autorisé à distribuer des clefs de session aux clients :
   le client (2_1, 2_2) surveille qu’il reçoit selon une périodicité minimale prédéfinie, des messages périodiques d’un premier type prédéfini (heartbeat) en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et
   lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, le client envoie une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans la liste ordonnée des serveurs ;
   le client (2_1, 2_2) reçoit, depuis un nouveau maître serveur, de nouvelles clefs de session pour remplacement des précédentes clefs de session.
9. Client (2_1, 2_2) dans un réseau (1) de télécommunication comportant un ensemble de N serveurs (1_1, 1_2) de distribution de clefs de session, N étant strictement supérieur à 1, des clients (2_1, 2_2) comportant des clients de type « publishers » et des clients de type « subscribers », chaque client subscriber étant associé à un client publisher, et un module de communication intermédiaire de type « broker » lesdits serveurs, clients et broker étant adaptés pour être interconnectés par des liaisons de télécommunication ;
   un client publisher étant adapté pour délivrer au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, un client subscriber associé au client publisher étant adapté pour obtenir ensuite, via le module de communication intermédiaire broker, lesdites informations consultables et déchiffrer, et/ou vérifier, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur (1_1, 1_2) est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;
   ledit client (2_1, 2_2) étant un dispositif électronique caractérisé en ce que, le client ayant stocké une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, un seul quelconque des serveurs, à tout instant considéré, ayant le rôle de serveur maître des serveurs, et seul le serveur maître étant autorisé à distribuer des clefs de session aux clients :
   le client (2_1, 2_2) est adapté pour surveiller qu’il reçoit selon une périodicité minimale prédéfinie, des messages périodiques d’un premier type prédéfini (heartbeat) en provenance du serveur maître actuel indiqué dans la liste ordonné des serveurs ; et
   le client (2_1, 2_2) est adapté pour, lorsqu’il détecte qu’un message du premier type n’a pas été reçu conformément à ladite périodicité minimale, envoyer une requête de recherche d’un nouveau serveur maître au serveur de rang n+1 qui suit le serveur maître actuel de rang n dans la liste ordonnée des serveurs et pour recevoir, depuis un nouveau maître serveur, de nouvelles clefs de session pour remplacement de clefs de session valides précédemment attribuées au client.
10. Serveur de distribution de clefs de session (1_1, 1_2) dans un réseau (1) de télécommunication comportant un ensemble de N serveurs de distribution de clefs de session, N étant strictement supérieur à 1, des clients (2_1, 2_2) comportant des clients de type « publishers » et des clients de type « subscribers », et un module de communication intermédiaire de type « broker » (3), lesdits serveurs, clients et broker étant interconnectés par des liaisons de télécommunication ;
    selon lequel un client publisher délivre au module broker des informations chiffrées en fonction d’au moins une clef secrète de chiffrement stockée dans le client publisher, au moins un client subscriber associé au client publisher obtient ensuite via le module de communication intermédiaire broker lesdites informations consultables et déchiffre, et/ou vérifie, lesdites informations en fonction d’une clef de déchiffrement associée à ladite clef de chiffrement ; et chaque serveur est adapté pour générer et distribuer des clefs de session aux clients, comprenant les clefs de chiffrement, déchiffrement et /ou signature ;
    ledit serveur (1_1, 1_2) étant caractérisé en ce que :
    le serveur (1_1, 1_2) est adapté pour respecter la règle suivante : un seul quelconque des serveurs, à tout instant considéré, a le rôle de serveur maître des serveurs, et seul le serveur maître est autorisé à distribuer des clefs de session aux clients ; le serveur stockant une liste ordonnée en vue de l’élection d’un nouveau maître, du rang 1 associé à la priorité maximale au rang N associé à la priorité minimale, des serveurs de l’ensemble de serveurs, ladite liste ordonnée des serveurs indiquant en outre quel est le serveur maître actuel, et le serveur stockant une liste des clients auxquels des clefs de session en cours de validité ont été distribuées par le serveur maître actuel et les serveurs maîtres précédents ;
    le serveur (1_1, 1_2) est adapté pour, quand il a le rôle de serveur maître, envoyer aux clients (2_1, 2_2), selon au moins une périodicité minimale prédéfinie, un message périodique d’un premier type prédéfini (heartbeat) ;
    le serveur (1_1, 1_2) est adapté pour, quand il reçoit une requête de recherche d’un nouveau serveur maître depuis un client (2_1, 2_2), déclenche une opération d’élection d’un nouveau serveur maître auprès des serveurs de l’ensemble de serveurs ;
    le serveur (1_1, 1_2) est adapté, s’il est élu le serveur maître par ladite opération d’élection déclencher, dès son élection, auprès des clients (2_1, 2_2) de sa liste de clients, un remplacement des clefs de session valides indiquées dans la liste des clients et qui leur ont été attribuées.