Brevet FR3066666A1 — publié le 20181123

PROCEDE DE SECURISATION D'UNE COMMUNICATION SANS GESTION D'ETATS DOMAINE Le domaine de l'invention concerne la sécurisation de communications entre deux entités communicantes, telles qu'une ou plusieurs entités gérant des capteurs ou pilotant des actionneurs et une entité centrale gérant des ressources matérielles à distance et communiquant via des interfaces réseaux. L'invention se rapporte notamment aux communications sécurisées ne nécessitant pas de gestion d'états. Le domaine de l'invention concerne également la sécurisation dans la génération des données de contrôle ou dans le pilotage d'actionneurs ainsi que la sécurisation des données en tant que telles notamment par l'établissement de communications sécurisées ad hoc offrant une souplesse d'architecture et adaptable à l'Internet des objets en prenant en compte les ressources de calcul limitées. ETAT DE L'ART L'Internet des objets et les environnements fortement digitalisés s'accompagnent de la mise en place de flux d'information à des fins par exemple de gestion, de sauvegarde ou d'interactivité. On connaît ainsi des processus de sécurisation des communications tels que les réseaux privés virtuels désignés également par VPN (Virtual Private Network en anglais). On connaît également la mise en place de programme de sécurité tels que les antivirus permettant de se prémunir contre différents types d'attaques. Cependant ces moyens de défense sont généralement mis en oeuvre sur des terminaux disposant de ressources très importantes tels que des smartphones, des tablettes ou des ordinateurs. Actuellement, il existe aussi des solutions permettant de sécuriser des communications entre équipements par exemple au moyen de clefs asymétriques publiques et clefs privés asymétriques ou avec des tiers d'authentification, mais ces solutions impliquent des ressources de calcul importantes à assurer par l'objet connecté en matière de fonctions cryptographiques. 3066666 2 Lorsque l'objet connecté est passif, c'est-à-dire qu'il ne gère pas de commande provenant d'un équipement de commande connecté, qui pourrait être le serveur, alors il transmet des données utiles collectées par le capteur 5 vers le serveur. Lorsque l'objet connecté est actif, il peut être commandé par un équipement de commande connecté, qui pourrait être le serveur, l'équipement de commande est donc susceptible de transmettre des instructions à un objet connecté. 10 Dans le domaine des objets connectés, il existe ainsi un besoin de sécuriser les communications entre les objets connectés transmettant des données et une entité centrale de gestion à distance. En effet dans un environnement du type Internet des objets 15 également désigné par loT (Internet of Things en anglais) les objets connectés disposent de ressources limitées pour encrypter les données mais sont également vulnérables à des attaques cybernétiques ou à des attaques physiques. Certains objets connectés disposent par exemple d'un système électronique embarqué ayant une faible capacité de traitement et sont tout de 20 même destinés à fournir des informations en temps réel. Il existe également des processus de sécurisation développés pour l'IoT, tel que Zigbee, assurant une communication entre les dispositifs capteurs et la passerelle d'accès au réseau. La sécurité de bout en bout n'est alors pas assurée. Ce type de sécurité peut être d'autant plus limitée que le réseau de capteur est étendu, 25 du fait de l'utilisation de plusieurs réseaux successifs. En effet des centaines voire des milliers de capteurs peuvent être utilisés pour superviser des installations. Les communications radio sont généralement préférées pour des raisons de coût. Enfin une sécurité accrue peut être nécessaire pour certains équipements ou installations comme par exemple dans le domaine militaire. 30 Les capteurs et actionneurs assurent ainsi l'interface avec le monde réel dans une large gamme de systèmes. La présente invention vise à pallier aux inconvénients de l'art antérieur en fournissant procédé sécurisant les transmissions entre d'une part 35 un équipement de commande ou un serveur et d'autre part un ou plusieurs 3066666 3 objets connectés, le procédé sécurisant par ailleurs le fonctionnement en lui-même des entités distantes. RESUME DE L'INVENTION 5 L'invention vise à pallier aux inconvénients précités. Selon un aspect, l'invention concerne un procédé de communication entre au moins deux entités communicantes, une première entité communicante générant au moins un message de données utiles, émis vers une seconde entité communicante, comprenant un champ utile to comportant des données utiles et un entête d'authentification, ledit procédé étant caractérisée en ce qu'il comporte, pour la génération dudit message : ^ une génération d'un paramètre de contexte comportant au moins une donnée représentative de la configuration matérielle de la première entité; 15 ^ une génération d'un profil de sécurité intégré dans l'entête d'authentification et définissant les conditions: ^ de chiffrement des données utiles du message ; ^ de génération d'une signature par un algorithme de signature appliqué au moins aux données utiles; 20 ^ une génération de ladite signature intégrée dans l'entête d'authentification ; ^ une insertion d'un identifiant mémorisé de la première entité communicante dans l'entête d'authentification ; ^ une insertion du paramètre de contexte dans le champ utile ou 25 dans l'entête d'authentification ; ^ une agrégation du champ utile et de l'entête. Selon une particularité, le message émis à la seconde entité communicante est transmis dans une couche applicative d'un réseau de 30 données auquel sont connectées la première et la seconde entité communicante. Selon une particularité, le paramètre de contexte comprend en outre une ou plusieurs des données parmi les suivantes : 35 ^ Un identifiant d'un calculateur de la première entité; 3066666 4 ^ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité ; ^ Une date de mise à jour d'un micrologiciel de la première entité 5 ^ Une donnée représentative de l'espace mémoire occupé par le micrologiciel. Selon une particularité, le paramètre de contexte est chiffré par une première clef publique asymétrique avant d'être intégré dans le message émis, 10 ladite première clef publique asymétrique étant enregistrée dans une mémoire de la première entité, le paramètre de contexte étant déchiffré grâce à une première clef privé asymétrique enregistrée dans une mémoire de la seconde entité. 15 Selon une particularité, la seconde entité comprend une base de données mémorisant une pluralité de paramètre de contexte, chacun étant associé à une parmi plusieurs premières entités, la réception par la seconde entité dudit message émis par la première entité comportant : ^ Une vérification que le paramètre de contexte et l'identifiant de 20 la première entité reçus par la seconde entité sont présents dans la base de données ; ^ Un traitement dudit message reçu lorsque l'état de vérification est validé. 25 Selon une particularité, la réception par la seconde entité dudit message émis par la première entité comporte en outre : ^ Une analyse par un gestionnaire d'application de la seconde entité afin de déterminer si une mise à jour d'un micrologiciel ou une installation d'une nouvelle première entité communicante a 30 eu lieu ; ^ Une mise à jour de la base de données de la seconde entité prenant en compte le paramètre de contexte et l'identifiant de la première entité reçus lorsque l'analyse indique qu'une mise à jour ou qu'une nouvelle installation a eu lieu. 35 3066666 5 Selon une particularité, le paramètre de contexte est inclus dans l'entête d'authentification, la signature étant appliquée également au paramètre de contexte. 5 Selon une particularité, les données utiles comprennent des données collectées par au moins un capteur de la première entité communicante. 10 Selon une particularité, le procédé de communication comprend une étape transmission d'une information comprenant une clef secrète partagée symétrique préalable à la génération dudit message de transmission de données utiles, ladite clef secrète partagée symétrique étant utilisée pour générer la signature et pour chiffrer des données utiles. 15 Selon une particularité, le procédé de communication comprend préalablement à l'étape de transmission de la clef secrète partagée symétrique; ^ Une génération d'une seconde clef publique asymétrique et d'une 20 seconde clef privée asymétrique par un module de génération de clefs asymétriques de la première entité, les dites clefs générées étant enregistrées dans une mémoire ; ^ Une transmission par la première entité vers la seconde entité d'une requête d'enregistrement comportant l'identifiant de la première 25 entité, le paramètre de contexte et ladite seconde clef publique asymétrique; ^ Une transmission par la seconde entité vers la première entité d'un acquittement indiquant l'enregistrement de la première entité dans la base de données de la seconde entité ; 30 ^ Un chiffrement à partir de la seconde clef privée asymétrique de la clef secrète symétrique. Selon une particularité, le procédé de communication comprend un renouvellement périodique de la clef secrète partagée symétrique comportant: 35 ^ Une génération d'une nouvelle clef secrète symétrique à partir d'un module de génération de clef symétrique ; 3066666 6 ^ Un chiffrement, par la seconde clef privée asymétrique, de la clef secrète symétrique mémorisée dans une mémoire de la première entité ; ^ Une transmission de la nouvelle clef secrète partagée symétrique à 5 la seconde entité. Selon une particularité, le procédé de communication comprend un renouvellement périodique de la clef secrète privée comportant : ^ Une génération d'une nouvelle clef secrète symétrique à partir d'un to module de génération de clef symétrique; ^ Une transmission de la nouvelle clef secrète partagée symétrique. Selon une particularité, les données utiles comprennent le paramètre de contexte, le paramètre de contexte étant généré et émis 15 régulièrement. Selon une particularité, la génération dudit message comprend: ^ Une génération d'un identifiant de message calculé à partir : o d'un paramètre généré aléatoirement et fourni par un module 20 aléatoire et ; o d'une date limite de validité générée par un module d'horloge; ^ Une insertion de l'identifiant de message dans l'entête d'authentification dudit message. 25 Selon une particularité, le profil de sécurité définit les conditions de génération d'une signature par l'algorithme de signature qui est appliqué aux données utiles du message, au paramètre de contexte et à l'identifiant de message. 30 Selon une particularité, les données signées par l'algorithme de signature comprennent : ^ le profil de sécurité ; ^ l'identifiant de la première entité. 3066666 7 Selon un aspect l'invention concerne une entité communicante comprenant au moins une mémoire, un calculateur et une interface de communication pour l'exécution du procédé de communication de l'invention. Selon un mode de réalisation, l'entité communicante comprend au 5 moins un capteur de données. Selon un aspect, l'invention concerne un programme d'ordinateur comportant un ensemble d'instructions pour la mise en oeuvre du procédé de communication de l'invention. 10 Avantageusement encore le procédé sécurisé de communication apporte une solution qui : ^ permet de choisir des dispositifs peu couteux notamment du fait de leur capacités réduites en termes de charge de calculs pour l'objet connecté ; 15 ^ permet de sécuriser les transmissions des données utiles pouvant être critiques vers un serveur gestionnaire de données; ^ permet possiblement de sécuriser les transmissions des données de commandes transmises d'un équipement de commande vers un objet connecté ; 20 ^ permet de vérifier l'intégrité d'un ou plusieurs composants et d'une ou plusieurs configurations matérielles de l'objet connecté ; ^ permet une sécurisation des communications de bout en bout sur une grande variété de réseaux. 25 BREVE DESCRIPTION DES FIGURES D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description détaillée qui suit, en référence aux figures annexées, données à titre d'exemple, qui illustrent : 30 ^ figure 1 : un schéma général d'une architecture réseau comportant un serveur et une pluralité de clients mettant en oeuvre un procédé selon l'invention ; ^ figures 2: un exemple d'architecture d'un serveur et d'un client mettant en oeuvre un procédé de l'invention ; 35 ^ figures 3A à 3B: des fonctions mises en oeuvre dans un procédé selon l'invention ; 3066666 8 ^ figure 4 : des étapes d'un procédé de l'invention ; ^ figure 5: des étapes de chiffrement et de déchiffrement du paramètre de contexte selon un exemple de réalisation. 5 DESCRIPTION Définitions L'invention concerne la sécurisation et l'authentification de communications entre deux entités communicantes. La description porte notamment sur deux entités constituant 10 respectivement un client et un serveur. Le client Cl est par exemple un objet connecté et le serveur Si est du type serveur de données recevant, pour les exploiter, les données utiles Datai collectées par un capteur de l'objet connecté. On nomme dans la présente description une première entité communicante 15 C1, l'entité communicante Cl qui transmet des données utiles par exemple collectées par un ou plusieurs capteurs. Les capteurs mesurent par exemple des grandeurs physiques comme des températures, des pressions, des vibrations, des forces et des accélérations. La première entité peut comprendre un ou plusieurs actionneurs. La première entité peut également 20 comprendre un ensemble de capteurs et d'actionneurs, les capteurs fournissant par exemple des informations sur l'état ou la position des actionneurs. On nomme la seconde entité communicante S1, l'entité communicante Si qui reçoit les données utiles. La seconde entité 25 communicante sera par exemple une entité centrale. La seconde entité communicante pourra être reliée à plusieurs premières entités comprenant des capteurs ou des actionneurs. La seconde entité communicantes Si peut notamment transmettre des commandes à la première entité communicante Ci afin de commander une 30 fonction, configurer un composant ou un logiciel, mettre à jour un logiciel, ou encore définir de nouveaux paramètres de configuration par défaut. Dans la présente description, le client correspond par exemple à la première entité communicante, le serveur correspondant à la seconde entité communicante. 35 3066666 9 Dans la suite de la description un message mess visant à transmettre des données utiles Datai comporte deux parties : une entête d'authentification Tokeni et un champ utile comportant des données utiles Datai . Le message de données utiles peut comprendre, outre des données 5 utiles Datai , des données relatives au protocole ou des identifiants ou encore des signatures. On entendra plus généralement pour la simplicité de lecture le champ utile comme les données utiles Datai que l'on pourra nommer également Datai . 10 Entité déportée L'entité déportée qui correspond à la première entité est par exemple l'entité Client. L'entité déportée comprend par exemple un calculateur, une mémoire et une interface de communication comprenant 15 notamment plusieurs ports d'entrée et de sortie. L'entité déportée peut être constituée par un ordinateur, une tablette, un smartphone ou encore un équipement industriel de type boitier intelligent comprenant des capteurs ou des actionneurs ou tout équipement électronique dédié à une application visant à transférer des données de manière sécurisée. 20 La première entité est par exemple un objet connecté comportant un capteur et générant des données représentatives des mesures effectuée par le capteur, transmises à un serveur constituant la seconde entité communicante. La première entité communicante Cl comprend par exemple un 25 système d'exploitation ou un micrologiciel, également désigné en anglais par Firmware. La première entité réalise ainsi un ensemble de fonctions pour la gestion de ses capteurs et actionneurs mais également pour réaliser la sécurisation des données à transférer. La première entité est donc associée à un équipement dont la 30 configuration lui permet notamment de s'identifier au sein d'un réseau de communication ou à tout le moins auprès de la seconde entité communicante. La première entité Cl comprend donc un identifiant noté Cl_ld. Un tel équipement client est indifféremment noté C1, C2, Ci, ie[l ;N]. 35 Entité Centrale 3066666 10 L'entité centrale qui correspond à la seconde entité est par exemple l'entité Serveur. Un serveur 51 comprend par exemple à minima une mémoire et un calculateur ainsi qu'une interface de communication. La seconde entité 51 est par exemple un ordinateur ou une station de travail connectée à un s réseau, tel que le réseau internet, ou un smartphone ou une tablette connecté à un réseau mobile. La seconde entité est par exemple configurée pour recevoir des messages provenant de différentes premières entités et stocker les données reçues de ces premières entités. La seconde entité est par exemple configurée pour envoyer des commandes vers différentes premières 10 entités. La première entité 51 peut décoder ou déchiffrer les données reçues au moyen d'un module de décodage Decoding_Module1. La première entité 51 stocke par exemple dans une base de données BDS1 des données relatives à d'une pluralité de première entités tels 15 que des objets connectés. La première entité 51 peut aussi stocker des données cryptographiques qu'elle génère ou qu'elle reçoit de chaque première entité. La première entité 51 comporte par exemple en mémoire des clefs cryptographiques reçus d'une première entité communicante telle que Cl, à 20 savoir au moins une clef privé symétrique KSec et une clef publique asymétrique KPub2. La première entité 51 comporte par exemple en mémoire une clef privée asymétrique Kprivl et une clé publique asymétrique Kpub1. Ces clefs peuvent être générées par exemple par un module de génération de clef privé 25 asymétrique ASymKGen1. La seconde entité se présentant sous la forme d'un serveur gestionnaire de données fournit par exemple des services de gestion d'un ensemble de capteurs et d'actionneurs via des premières entités. La seconde entité peut également fournir des services aux premières entités tels que 30 l'enregistrement de chaque première entité auprès de la première entité. On désigne de manière générale la seconde entité comme étant l'entité serveur et la ou les premières entités comme des entités clients mais les fonctions de client et de serveur peuvent s'inverser selon les étapes du procédé selon l'invention. 3066666 11 On note que la seconde entité serveur S1 ne correspond pas notamment à un serveur d'authentification réalisant exclusivement les fonctions d'authentification au sens d'un tiers d'authentification couplé avec un autre serveur de données. 5 Avantageusement, la présente invention permet notamment d'établir des communications sécurisées entre au moins un client et un serveur de données offrant une sécurisation des données échangées. Comme représenté à la figure 1 la seconde entité communicante S1 comprend une base de données DBS1 permettant notamment d'enregistrer 10 des données relatives à une pluralité de premières entités communicantes. Les différentes premières entités Cl à C4 communiquent, à la seconde entité S1, des données utiles Datai collectées par un ou plusieurs capteurs de chacune des premières entités ou générées par des fonctions internes à chaque première entité. Un module d'une première entité réalise par exemple 15 une fonction de lecture d'un identifiant (IdCol ) d'un calculateur (Col) ) de la première entité (C1). Un module d'une première entité réalise par exemple une fonction de test des ports d'entrée et de sortie pour générer une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité (C1) et notamment le nombre de ports utilisés. Un module d'une 20 première entité réalise par exemple une fonction de lecture d'une date de mise à jour d'un micrologiciel de la première entité. Un module d'une première entité réalise par exemple une fonction de calcul de l'espace mémoire occupé par le micrologiciel. Le procédé de l'invention permet avantageusement de sécuriser les 25 données utiles Datai à transmettre entre deux entités communicantes par exemple par un plusieurs cryptages ou contrôles. La configuration matérielle de l'entité émettant le message de données utiles peut notamment être vérifiée. Avantageusement les messages sont transmis dans une couche 30 applicative du ou des réseaux de données successifs, ce qui permet de sécuriser la transmission de données de bout en bout. Un réseau de données utilisé est par exemple le réseau Intemet, un réseau local câblé, un réseau mobile ou un réseau local radio tel que WiFi. 35 Gestion de clefs symétriques 3066666 12 Le procédé de l'invention met, par exemple, en oeuvre un échange de clef secrète symétrique partagée entre les deux entités communicantes Cl et S1. La clé secrète symétrique est générée, dans la première entité C1, 5 par un composant cryptographique SymKGen. Ce composant SymKGen permet de générer au moins une clef secrète symétrique partagée KSec. La clef symétrique KSec est par exemple transmise dans une information échangée au préalable entre la première entité Cl et la seconde entité S1 afin que ces deux entités disposent toutes deux d'un secret partagé. 10 La figure 3B représente une transmission d'information comprenant la clef symétrique secrète. La clef secrète partagée symétrique KSec peut être utilisée pour générer une signature Sign1 et pour chiffrer les données utiles Datai . Les ressources nécessaires au cryptage par clé secrète partagée sont 15 avantageusement moindres que pour une clé privée asymétrique. La seconde entité S1 recevant le message de données utiles est ainsi en mesure de vérifier l'authenticité de a signature SIgn1 et de déchiffrer les données utiles chiffrées avec cette clef secrète symétrique partagée. Les clefs secrètes symétriques KSec peuvent être renouvelées 20 périodiquement par la première entité Cl et transmises périodiquement à la seconde entitéS1. Une même clé secrète symétrique partagée est ainsi stockée dans une mémoire respectivement de la première entité Cl et de la seconde entité S1. 25 Gestion de clefs asymétriques Le procédé de l'invention peut comporter une génération d'un couple de clefs cryptographiques asymétriques par la première entité Cl ou par la seconde entité centrale S1. L'utilisation des clés publiques et privées 30 asymétriques est de préférence restreinte par rapport à l'utilisation des clés secrète symétriques partagées comme décrit auparavant, de façon à optimiser les ressources matérielles nécessaires pour les traitements de données. La fonction de génération de clé asymétrique peut être réalisée par un composant cryptographique logiciel ou matériel de l'équipement. La clef 35 privée asymétrique KPriv2 ou KPrivl est par exemple stockée dans une 3066666 13 mémoire ou dans un composant de sécurité dédié comme par exemple un TPM désignant « Trusted Platform Module ». La première entité peut lire et mémoriser la clé publique KPubl générée par la seconde entité pour crypter des données. La seconde entité 5 S1 comprend notamment un générateur de clé asymétrique ASymKGen1 et mémorise une clé privée asymétrique générée KPrivl . La première entité Cl peut également générer un couple de clé asymétrique privée KPriv2 et clé asymétrique publique KPub2 destinée à la seconde entité communicante, en utilisant un générateur de clé asymétrique io ASymKGen2. La clé asymétrique publique KPub2 sera alors transmise à la seconde entité et stockée en mémoire. La seconde entité peut alors chiffrer des données destinées à la première entité et déchiffrée à partir de sa clé privée asymétrique KPriv2 mémorisée. 15 Paramètre de contexte Selon le procédé de l'invention un paramètre de contexte ContextP1 est transmis par la première entité Cl à la seconde entité Si. Le paramètre de contexte ContextP1 est généré par un module de génération du paramètre de contexte référencé ContexPGen sur la figure 2. 20 Le paramètre de contexte ContextP1 comprend au moins une donnée représentative de la configuration matérielle de la première entité C1. Le paramètre de contexte ContextP1 comprend, par exemple, une ou plusieurs des données parmi les suivantes : 25 ^ Un identifiant IdCol d'un calculateur Col de la première entité Cl ou d'un autre composant matériel tel qu'une mémoire ROM, RAM ou FLASH ou autre carte mémoire; ^ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité Cl ; 30 ^ Une date de mise à jour DM_Col d'un micrologiciel CtrlProg de la première entité Cl ou une donnée de mise à jour d'un autre sous- programme mémorisé ; ^ Une donnée représentative de l'espace mémoire occupé par le micrologiciel ou par un autre sous- programme mémorisé. 35 3066666 14 Lorsqu'un programme est installé sur une mémoire stable de la première entité, c'est-à-dire, par exemple, un espace mémoire modifié uniquement en cas de mise à jour du Firmware, il est possible de détecter un sous-programme pirate rajouté en mémoire à des fins malveillantes, du fait de 5 l'espace supplémentaire occupé. Un avantage de l'utilisation d'un paramètre de contexte ContextPl relatif à un identifiant matériel d'un composant est de détecter une éventuelle falsification de matériel par la seconde entité en comparant un identifiant matériel mémorisé initialement avec un identifiant matériel inclus dans un 10 message de données utiles. Un avantage de l'utilisation d'un paramètre de contexte ContextPl comportant une donnée représentative des ports d'entrée/ sortie utilisés ou non utilisés est de détecter une fonction hors de service du client ou débranchée ou non-connectée ou une connexion frauduleuse à la première 15 entité. Ce paramètre de contexte ContextPl est avantageusement envoyé à la seconde entité communicante à des fins de contrôle par la seconde entité communicante. Le paramètre de contexte est par exemple crypté avant l'envoi à la 20 seconde entité. Une clé publique KPubl fournie par la seconde entité est par exemple utilisée à cette fin. La figure 5 représente le chiffrage du paramètre de contexte ContextPl à partir de la clef publique asymétrique KPubl de la seconde entité 25 pour être déchiffrée à réception par la seconde entité S1 en utilisant sa clef privée asymétrique KPrivl . Procédé de génération d'une requête d'enrôlement Le procédé de l'invention peut comprendre des étapes 30 d'enrôlement. L'enrôlement est réalisé de façon préalable aux transmissions des données utiles Datai entre deux entités communicantes Cl et S1 L'enrôlement permet d'enregistrer une première entité et des données relatives à cette première entité préalablement à la transmission de données utiles. Ces données relatives à la première entité correspondent par exemple 35 à la clé secrète partagée. 3066666 15 La clé secrète partagée peut être renouvelée régulièrement, par sécurité. Comme représenté à la figure 3A, la première entité Cl procède à un enrôlement auprès de la seconde entité 5 S1, en générant une requête notée MesEnr1 . Cette requête comprend par exemple l'identifiant Cl_ld et le paramètre de contexte ContextP1 crypté à l'aide de la clé publique KPub2. Cette solution est performante notamment en termes de calculs puisqu'elle permet de chiffrer un message court, qui comprend la clef symétrique, avec 10 une clef asymétrique. Les identifiants de chaque première entité tel que Cl en association avec leur paramètre de contexte sont par exemple enregistrés dans une base de données de la seconde entité 51. La seconde entité 51 est alors capable d'associer une première 15 entité Cl avec son paramètre de contexte ContextPl. De manière non limitative, l'enrôlement peut être initié par la première ou par la deuxième entité. Les échanges de clefs publiques sont par exemple automatiquement effectués à réception d'un premier message 20 MesEnr de l'une ou l'autre des entités C1, 51. Les partages de clés peuvent aussi être réalisés par un programme de supervision accédant à la seconde entité et aux premières entités. Selon d'autres exemples de réalisation, l'acquisition d'une clef publique du serveur KPubl peut être générée en utilisant un fichier tel qu'une image, un 25 code captcha, un code barre ou un code 20, tel qu'un QR code. L'acquisition de la clef publique du serveur KPubl par le client peut être réalisée, dans ce dernier cas, par une lecture du code ou de l'image comprenant ladite clef par des moyens de capture d'une image tel qu'un capteur optique. 30 Selon un mode de réalisation de l'invention, le procédé de génération d'une requête d'enrôlement MesEnr1 par le client Cl comprend une étape de génération d'une clef publique d'un client C1, notée KPub2, et d'une clef privée d'un équipement notée KPriv2. Dans ce dernier cas un couple de clefs est généré conjointement. 35 Lorsque l'étape de génération du couple de clefs asymétrique a été 3066666 16 préalablement effectué, le procédé de génération d'une requête d'enrôlement peut viser à extraire la clef publique du client Cl d'une mémoire dudit client Cl pour l'inclure dans la requête. La requête d'enrôlement peut ainsi comprendre les données 5 suivantes: - le paramètre de contexte, ContextPl; - l'identifiant du client, Cl_Id ; - la clef publique asymétrique du client, KPub2. 10 Un mécanisme de renouvellement de clefs asymétriques par la première entité ou par la seconde entité peut également être envisagé. La nouvelle clef publique du client KPpub2 peut par exemple être transmise à destination du serveur S1 grâce à un nouvel enrôlement. Des étapes d'enrôlement sont alors réitérées. 15 Réception de la requête par le serveur Lorsque la seconde entité S1 reçoit un message de données utiles, la seconde entité S1 engage par exemple une étape de déchiffrement des données au moyen de la clef secrète partagée. 20 Les données déchiffrées sont ensuite extraites et stockées dans une mémoire de la seconde entité S1. La seconde entité S1 peut alors effectuer un contrôle du paramètre de contexte ContextPl et de l'identifiant du client Cl_Id comparés aux données stockées dans sa base de données BDS1. Si la comparaison est valide, le message est authentifié et son traitement est 25 poursuivi. Dans le cas contraire où les données comparées ne correspondent pas, la seconde entité peut, par exemple, stopper le traitement et envoyer un message d'alerte. La seconde entité peut également enclencher une vérification relative aux mises à jour des premières entités ou aux connexions 30 de nouvelles entités. Transmission des données utiles Le procédé de communication de l'invention permet d'émettre et de recevoir des données sous forme de messages entre deux entités 35 communicantes, ces messages sont notés Mes1 et comprennent les données 3066666 17 utiles Datai . La figure 3C représente l'étape de transmission d'un message Mes1 comportant des données utiles Datai et un entête d'authentification Token 1 . Le procédé de l'invention permet d'échanger des communications 5 de manière sécurisée par la définition de messages dont la sécurité est « autoportée », c'est-à-dire que chaque message Mes1 échangé comprend ses propres informations de sécurité permettant de traiter et de déchiffrer le message envoyé. L'invention ne nécessite pas notamment l'établissement d'une 10 session entre les deux entités communicantes assurant un canal sécurisé entre ces deux entités. L'invention comprend donc un mécanisme de génération d'entête d'authentification des messages de données transmis entre les deux entités. La description qui suit décrit un mode de réalisation dans lequel le 15 client C1, représentant une première entité communicante, émet un message Mes1 vers le serveur S1, représentant la seconde entité communicante, ce message étant vérifié par le serveur S1. Les rôles de client et de serveur peuvent toutefois s'inverser entre les première et seconde entités communicantes. 20 Entête d'authentification d'un message Mes1 Consécutivement à l'étape d'enrôlement lorsqu'elle a lieu, l'invention met en oeuvre un procédé de communication permettant de transmettre des messages de données utiles sécurisées Mes1 notamment 25 grâce à l'entête d'authentification, noté Tokenl. Le procédé de communication peut également être réalisé sans l'enrôlement préalable. C'est par exemple le cas lorsque les données échangées dans le procédé d'enrôlement seraient définies par un programme superviseur dans 30 chaque équipement C1, S1, comme par exemple l'échange des clefs publiques et des identifiants d'équipement. L'entête d'authentification Token1 est généré par un composant du client C1. Côté serveur, un composant vérifie l'entête d'authentification reçu 35 du client C1. 3066666 18 L'entête d'authentification Tokenl des messages Mes1 transmis comprend différents champs de données dont l'identifiant du client C1_Id. Le Token1 peut comprendre une identification Mes_Id du message Mes1, et éventuellement un profil de sécurité PRO_SEC qui permet de définir 5 les conditions de chiffrement ou de déchiffrement. Le profil de sécurité est généré par un module de génération du profile de sécurité Pro_SecGen. Le Tokenl peut comprendre une signature Sign1. L'entête d'authentification Tokenl peut être, par exemple, intégré aux entêtes du protocole transport utilisé selon les communications 10 effectuées, comme un entête du protocole http par exemple. Selon un mode de réalisation, l'entête d'authentification est ajouté à la liste des entêtes du protocole applicatif de transport utilisé par l'application. Dans l'exemple du protocole HTTP, selon un mode de réalisation, 15 le contenu de l'entête d'authentification générée par la présente invention est associé à l'entête «Authorization: »du protocole HTTP/1.1 selon la RFC [2616]. Le message Mes1 est généré par le module Mess_Gen en agrégeant l'entête Tokenl au champ utile Datai. Un module de codage 20 coding_Modulel permet de chiffrer les données du message. Le module de codage chiffre alors les données du message Mes1 en fonction des données à chiffrer ou non, comme indiqué dans le profil de sécurité, et des clefs mémorisées et nécessaires pour effectuer ces opérations. 25 Identifiant de message, Mes_Id Le calculateur peut récupérer un identifiant de message Mes_Id qui est généré par un compteur de messages qui génère des identifiants de messages. La figure 2 représente un composant Mes_ID1 permettant de générer et traiter des identifiants de messages Mes_Id. 30 Le compteur de message génère par exemple le Mes_Id à partir d'un aléa, c'est-à-dire d'un paramètre aléatoire RamdomPl et d'une date d'expiration Stamp1 . L'aléa Ramdam P1 permet de définir un identifiant unique Mes_Id du message. L'état aléatoire RamdomPl peut être par exemple généré à partir d'un module de génération d'un aléa noté 35 Ramdom_Modulel. 3066666 19 Ce dernier peut être exécuté par le calculateur. Lorsque l'identifiant du message Mes_ID1 est calculé notamment à partir d'une date d'expiration Stampl définie par un module d'horloge 5 Clock_Modulel locale de l'équipement Cl, l'identifiant Mes_Id comprend une information relative à la date d'expiration Stampl du message Mes1 qui pourra être vérifiée à la réception par le serveur Si. Selon une alternative de réalisation, le Mes_Id peut être généré avec un paramètre non aléatoire et une date d'expiration Stampl . L'identifiant 10 de message Mes_ID1 peut être, par exemple, calculé à la volée, c'est-à-dire en temps réel par un calculateur de l'entité communicante Cl. L'identifiant du message Mes Dl ainsi calculé est attribué à un message Mes1. Profil de sécurité 15 Selon un mode de réalisation, le profil de sécurité PRO_SEC permet de définir un algorithme qui sera utilisé pour signer ou chiffrer le contenu à transmettre. Le profil de sécurité PRO_SEC peut être généré à partir d'un module Pro_SecGen, noté à la figure 2. Le module Pro_SecGen permet de préconfigurer le profil de sécurité PRO_SEC de manière à répondre aux 20 exigences d'une application donnée, d'un contexte donné ou d'une consigne émise par un utilisateur. Le profil de sécurité inclus dans le message de données utiles fournit alors des informations pour le mode de décodage. Le profil de sécurité PRO_SEC peut aussi être utilisé pour indiquer 25 et définir si la réponse au message Mes1 émise par le serveur 51 doit également être chiffrée et selon quel algorithme. Ce mode de réalisation est notamment avantageux lorsque le serveur transmet des commandes au client Cl. Les différentes entités communicantes Cl, 51, telles qu'un serveur 30 51 et une pluralité de clients Ci peuvent comprendre une configuration de profils de sécurité prédéfinis. Chaque profil prédéfini peut être activé pour définir une manière d'émettre et recevoir des données avec une autre entité. Différents profils de sécurité peuvent ainsi être prédéfinis. Un premier profil de sécurité correspond par exemple à l'activation 35 d'un paramètre de sécurité P1 incorporé dans l'entête d'authentification 3066666 20 Token1 du message Mes1 à transmettre par le client Cl au serveur S1. Ce paramètre P1 Indique la présence d'un chiffrement des données utiles Datai transmises. Ainsi, le serveur S1 recevant ce paramètre P1 est capable de mettre en oeuvre un déchiffrement des données transmises lorsque ces s dernières sont chiffrées. Un second profil correspond par exemple à l'activation d'un paramètre de sécurité P2 incorporé dans l'entête d'authentification Token1 du message Mes1 à transmettre par le client C1. Le paramètre P2 permet d'indiquer que l'entête d'authentification Token1 est signé. La signature Sign1 io est dans ce cas effectuée par le client Cl grâce à la clef privée du client KPrivl . La signature Sign1 est notamment incorporée dans l'entête d'authentification Token1 . Cette configuration a l'avantage de permettre d'établir des communications dont la sécurité est entièrement autoportée entre deux entités 15 communicantes C1, S1. Les différents profils de sécurité permettent par exemple d'adapter le niveau de sécurité des échanges de données entre les entités communicantes C1, S1 selon le contexte d'échanges de données ou du type de données à échanger. 20 Les profils de sécurité PRO_SEC peuvent également utiliser un autre paramètre de sécurité représentatif du format de la signature utilisée pour l'entête d'authentification. Ce paramètre permet de définir l'utilisation ou non dans la signature de : ^ un ou plusieurs champs de données de l'entête 25 d'authentification Token1 du message; ^ des données utiles. Un paramètre de sécurité De l'entête peut également être représentatif du format de signature appliqué défini par au moins l'une quelconque de ces données ou une 30 combinaison de ces données : ^ L'algorithme d'une fonction de hachage ; ^ L'algorithme de chiffrement ; ^ Le type de clef ; 3066666 21 ^ L'indication des données à signer telle que par exemple les champs de données de l'entête d'authentification ainsi que les données utiles. s Lorsqu'une entité reçoit un profil de sécurité PRO_SEC qu'elle ne connaît pas, c'est-à-dire qui n'est pas prédéfini dans une mémoire de l'entité, alors un profil par défaut peut être utilisé. L'enrôlement peut notamment comprendre la transmission de la définition d'un profil de sécurité PRO_SEC. A réception, une entité peut alors to enregistrer la définition du nouveau profil de sécurité et l'utiliser pour déployer une stratégie de chiffrement des messages émis ou de déchiffrement des messages reçus. En outre, le profil de sécurité PRO_SEC comprend la désignation 15 d'un algorithme de génération de signature comme par exemple RSA-SHA256 et le cas échéant la désignation d'un algorithme de chiffrement des données, comme par exemple AES. Le profil de sécurité PRO_SEC comprend donc une indication sur la présence d'une signature Sign1 et sur la présence d'un chiffrement des 20 données et le cas échéant, le profil de sécurité PRO_SEC comprend la désignation des algorithmes utilisés pour générer la signature ou chiffrer les données. Signature 25 Selon un mode de réalisation, l'entête d'authentification Token1 comprend également une signature des données transmises dans l'entête token1 . Une signature Sign1 est créée au moyen d'un algorithme de génération d'une signature Signing_Modulel . La signature Sign1 est par exemple réalisée au moyen d'une clef 30 publique KPub2 acquise par l'entité communicante signant Cl ou au moyen de la clé secrète partagée KSec. La signature est appliquée à un ensemble d'éléments du message dont les données utiles du message. Le paramètre de contexte peut notamment être intégré aux données utiles. 3066666 22 Le paramètre de contexte peut aussi être transmis dans l'entête d'authentification et être pris en compte dans les données signées. Les données utiles, lorsqu'elles sont signées, peuvent correspondre aux données utiles chiffrées ou aux données utiles non chiffrées. s La signature Sign1 peut par exemple être générée à partir des données: Mes_ID1, C1_Id, PRO_SEC et du contenu du message Data1. Un algorithme basé sur une méthode RSA SHA256 peut par exemple être mise en oeuvre par l'invention pour générer la signature Sign1. 10 Nous rappelons que l'acronyme SHA désigne dans la terminologie anglo-saxonne : « Secure Hash Algorithm » et correspond à une fonction de hachage cryptographique. Le RSA est un algorithme de cryptographie asymétrique utilisant un couple de clefs asymétriques. Les deux algorithmes peuvent être associés dans un unique algorithme de chiffrement. 15 Un algorithme ECDSA désignant « Elliptic Curve Digital Signature Algorithm » peut également être utilisé selon la méthode de l'invention. Il s'agit d'un algorithme de signature numérique à clef publique. L'algorithme de génération d'une signature peut également être automatiquement déterminé, parmi plusieurs algorithmes, en fonction de 20 l'équipement du client ou de son système d'exploitation et par exemple en fonction du paramètre de contexte. Un avantage est d'utiliser les ressources déjà existantes sur un équipement et de prendre en compte la configuration matérielle de l'équipement. Un champ de l'entête d'authentification Token1 comprend la 25 signature Sign1 générée et un autre champ peut être renseigné dans l'entête Token1 pour désigner l'algorithme permettant de générer la signature Sign1. Un autre champ désigne également l'algorithme de chiffrement des données utiles Data1. A la réception, le serveur S1 de données pourra décoder la 30 signature Sign1 grâce au choix du bon algorithme tel qu'indiqué pour décoder la signature Sign1. Le terme « entête de protocole » est utilisé pour le différencier de l'entête d'authentification Token1 de l'invention. 3066666 23 A titre d'exemple, les différents champs du protocole http de l'exemple suivant peuvent être utilisés selon un mode de réalisation de l'invention pour signer l'entête d'authentification. La requête http ayant par exemple la fom1e suivante : 5 - Entête: POST http://control_center_urIlrest/conso HTTP/1.0 Accept : application/jsonUser-Agent: Mozil/a/4.0 (compatible; MSIE 5.0; Windows 95) Authori:zation:JohnDo:Android22434:143089653303797:OneWa Signature_ io RSA-SHA256_none: w9Bgirb8 - Corps de message (body) : {"P l"-=2345,"HCHC"-=29384632,"HCHP"=2936241490} Une ou plusieurs données relatives aux données du protocole 15 transport peuvent être utilisées. Une partie d'un champ d'un entête du protocole peut également être utilisée. Par exemple, le champ Method du protocole http précisant le type de requête dont notamment les valeurs {GET, PUT, PO$1}, présent dans la ligne de requête d'une requête http a un intérêt pour a un intérêt pour signer l'entête d'authentification Token1. Cette prise en 20 compte permet notamment d'éviter les attaques de type « rejeu » par un tiers en réalisant une autre action que la requête initiale. Un entête de message d'un protocole applicatif de transport est par exemple défini par un couple {clé :valeur}. Par exemple pour le protocole HTTP, l'entête [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"] représente une 25 date d'expiration de la requête. Selon ce même protocole, le type de requête et l'adresse de la ressource à interroger sont contenus dans la ligne d requête du message, par exemple [POST httpilcontrol_center_uri/rest/conso HTTP/1.1], et peuvent être utilisés pour générer la signature Sign1. Ce mode de réalisation est particulièrement avantageux pour 30 assurer l'intégrité des échanges de données. Selon ce même exemple, lorsque les données sont signées avec le couple [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"], et avec le type de la requête HTTP, qui est dans ce cas une requête de type « POST », il n'est pas possible qu'une attaque par rejeu en réutilisant les mêmes données avec un 35 type de requête différent ou/et avec une date d'expiration différente soit 3066666 24 engagée par un tiers puisque dans ce cas la signature Sign1 ne sera pas reconnue par le serveur Si. On préfère toutefois une mise en oeuvre du procédé de communication sécurisé de façon indépendante du protocole de s communication. La génération d'une signature Sign1 comprend par exemple l'exécution d'une fonction de hachage des données utiles non cryptées à signer. Les données utiles sont par exemple cryptées avant leur transmission. Ainsi, si un tiers, non autorisé, récupère un message signé, il n'est pas possible 10 pour ce tiers de reconstituer les données qui ont été signées à partir de la signature Sign1. La signature peut également être appliquée aux données utiles cryptées. La signature permet aussi de vérifier que les données transmises 15 signées ne sont pas altérées. La prise en compte dans les données signées de l'identifiant de message Mes_ID1, qui change à chaque message Mes1, permet grâce à la fonction de hachage de générer un contenu de la signature totalement différent d'un message à l'autre. 20 La génération d'une signature Sign1 peut également s'appliquer sur des données auxquelles une fonction de padding est appliquée, c'est-à-dire une fonction de remplissage des données. 25 Chiffrement des données Lorsque l'option du chiffrement des données d'un message émis par le client Cl est activée, le profil de sécurité PRO_SEC définit quel algorithme est utilisé pour chiffrer les données. Le profil de sécurité PRO_SEC est indiqué dans l'entête 30 d'authentification Token1 du message Mes1 et permet d'indiquer la désignation de l'algorithme de chiffrement. Le profil de sécurité PRO_SEC peut également faire partie des données signées Les données utiles du message Mes1 qui sont transmises au serveur Si, sont chiffrées avec l'algorithme déterminé par le client C1. Les 3066666 25 données peuvent ensuite être déchiffrées, coté serveur, grâce à l'indication de l'algorithme utilisé. L'algorithme de chiffrement des données peut être 5 automatiquement déterminé, parmi une liste d'algorithmes disponibles, en fonction de l'équipement du client Cl ou de son système d'exploitation ou du paramètre de contexte. Un avantage est d'utiliser les ressources déjà existantes sur un équipement et en fonction de sa configuration. Un exemple d'algorithme selon l'invention peut être AES désignant 10 « Advanced Encryption Standard » dans la terminologie anglo-saxonne. Il s'agit d'un standard de chiffrement avancé également connu sous le nom de « Rijndael ». D'autres algorithmes tels que Script ou Vscript peuvent être alternativement utilisés selon le procédé de l'invention. Les données utiles 15 Datai sont chiffrées grâce à une clef secrète symétrique partagée KSec. Les opérations de chiffrement sont avantageusement optimisées grâce au cryptage par clé symétrique. L'utilisation du cryptage par clés asymétriques comprenant une clé publique et une clé privée peut également être envisagée mais implique des 20 opérations sur des tailles de clés plus importantes et donc plus complexe et consommatrice de ressources pour le traitement des données. Les profils de sécurité PRO_SEC indiquent avantageusement quel type de signature ou de cryptage. Il est par exemple précisé si un message comporte un entête signé et un contenu chiffré dans un sens. 25 Lorsque le client Cl est un objet connecté pilotable à distance à partir d'un serveur S1 et qu'un chiffrement des données émises du serveur S1 vers le client Cl a été décidé, alors un mécanisme impliquant la transmission du profile de sécurité peut également être mis en place. 30 Avantages de la transmission de champs dans l'entête Le champ Mes_ID1 permet de définir une sécurité contre les attaques par rejeu de messages tiers. Le champ Cl_ld permet de définir une sécurité lorsqu'un 35 équipement a été suspendu ou révoqué par le serveur Si. 3066666 26 La figure 4 représente des étapes du procédé de communication de l'invention du point de vue d'une entité communicante qui génère un message Mes1 . s Le procédé selon l'invention permet notamment de générer un message Mes1 et la succession d'étapes sont notées GEN(Mes1 ). Ce procédé comprend une génération d'un entête d'authentification Tokeni et des données utiles Datai . Une première étape, notée GEN(ContextP1), consiste par exemple 10 en la génération du paramètre de contexte ContextP1 . Il comprend au moins une donnée représentative de la configuration matérielle de l'équipement. Il peut s'agir par exemple d'une variable d'état d'un port d'entrée/sortie tel que le port noté PortC1 du client C1. Le port Port1 fait transiter les données émises par Cl sur le réseau Net1 notamment à destination du serveur S1 via le port 15 PortS1. Selon d'autres exemples de réalisation, d'autres configurations matérielles peuvent être générées dans le paramètre de contexte ContextP1 . Par exemple, il peut s'agir d'une date de mise à jour d'un « Firmware » CtrlProg, c'est-à-dire d'un logiciel d'exploitation matériel d'un ou plusieurs 20 composants de l'équipement. App_Cl représente une application dédiée aux interactions avec l'environnement par la gestion de capteurs ou d'actionneurs. Le paramètre de contexte peut par exemple être représentatif du nombre de capteurs ou d'actionneurs en service. Selon d'autres modes de réalisation, le paramètre de contexte 25 ContextP1 peut être complexe et comprendre plusieurs valeurs représentatives d'un ensemble de différentes configurations matérielles de différents composants du client C1, tel qu'un capteur, un port, une mémoire, un microprocesseur ou une antenne. Le nombre de port d'entrée et de sortie connectés peut également être pris en compte. Une donnée représentative 30 des ports d'entrée et de sortie utilisés et non utilisés peut également être intégrée au paramètre de contexte. Des identifiants de composants peuvent également être intégrés dans le paramètre de contexte ContextPl. 3066666 27 Le paramètre de contexte ContextPl est par exemple automatiquement généré en fonction des variables qui le composent. Le procédé comprend par exemple une étape suivante de génération du profil de sécurité PRO_SEC notée GEN(PRO_SEC). Le profil s de sécurité PRO_SEC généré est intégré dans l'entête d'authentification token1. Le procédé comporte par exemple ensuite une étape d'insertion de la signature Signl, notée JNS(Sign1), dans le message Mes1 . Le procédé comporte par exemple une étape suivante d'insertion to de l'identifiant du client C1_ld, notée INS(C1_ld) dans le message Mes1 . L'identifiant Cl_ld est préférentiellement inclus dans l'entête d'authentification. Le procédé comprend par exemple une étape suivante INS(PRO_SEC) d'insertion du profil de sécurité PRO_SEC qui définit les conditions de chiffrement et de la génération d'une signature Signl. 15 Le message Mes1 comportant l'entête d'authentification Tokenl et les données utiles Datal peut alors être généré GEN(Mes1) par l'agrégation de l'entête et des données utiles. Ce message de données utiles peut ainsi être émis, selon un protocole de communication Utilisé, pour émettre des données entre le client 20 Cl et le serveur Sl. Serveur, Gestion des enrôlements Le serveur de données qui correspond à une des entités communicantes de l'invention est destiné à gérer des transmissions de 25 données avec une pluralité de clients Ci. Il comprend à cet effet un composant permettant de gérer les équipements, telle qu'une mémoire dans laquelle la base de donnée BDS1 enregistre les données de chaque client Ci tel que les identifiant Ci_Id et les paramètres de contexte ContextPl. En outre, le serveur S1 peut comprendre une mémoire pour stocker 30 les données relatives aux chiffrements en association avec chaque équipement client dans une mémoire notée DBS2 qui stocke des clefs publiques asymétrique KPub2 des équipements Cl, ainsi que les clefs symétriques KSec sécrètes partagées. 3066666 28 Le serveur exécute par exemple une première fonction de stockage des comptes clients et une seconde fonction de réception et de traitement de requêtes d'enrôlement émises par des équipements clients Ci. Le traitement d'une requête comprend par exemple des opérations 5 de déchiffrement des données et des opérations de vérifications que l'équipement client Ci n'est pas suspendu ou révoqué ou que le message reçu est valide visant à vérifier, ou qu'une anomalie matérielle ne soit survenue dans l'équipement client Ci. Le paramètre de contexte peut par exemple être analysé pour une analyse de conformité de la configuration matérielle de 10 l'équipement. Serveur - réception d'un message, déchiffrement Le message Mes1 émis par l'équipement client Cl est reçu par le Serveur 51 via une interface de communication. Un composant du serveur 51 15 réalise par exemple une étape de vérification du message reçu Mes1 et notamment sa date d'expiration. Le serveur 51 comprend notamment un jeu de clefs asymétriques comprenant une clef publique KPubl et une clef privée KPrivl pour les besoins de déchiffrement, en fonction des paramètres du profile de sécurité. 20 Le message Mes1, reçu par le serveur 51, a par exemple été chiffré, par le client C1, avec la clef publique asymétrique du serveur KPubl. Cette clef publique asymétrique du serveur KPubl a été préalablement acquise par l'équipement, par exemple, lors de son installation ou lors d'un enrôlement. Un programme de supervision peut également être utilisé pour 25 paramétrer un client ou le serveur. Une vérification de l'entête d'authentification Token1 peut être réalisée grâce à un module de vérification notée Token_ChK1. Serveur - vérification de l'identifiant de message 30 La vérification du message comprend notamment le contrôle de l'identifiant du message Mes_ID1, et en particulier sa date d'expiration. Lorsque la date d'expiration est périmée, le serveur 51 peut engager un refus du message reçu Mes1. Dans le cas d'un écart de date trop important, le serveur 51 peut 35 renvoyer une erreur spécifique contenant la date courante du serveur. Cette 3066666 29 variante permet que le client Cl puisse se resynchroniser et réémettre à un nouveau des messages avec des entêtes d'authentification Token1 valides. La vérification du MES _ID1 par le serveur S1 permet de limiter les attaques réseau par rejeu de message Mes1. s Une seconde vérification effectuée par le serveur S1 peut consister notamment à vérifier si le message Mes1 a déjà été reçu par ce dernier. Si le message a déjà été reçu, c'est-à-dire que le MES_ID1 du message reçu Mes1 est identique à un MES_ID d'un message précédemment reçu alors le message Mes1 n'est pas traité par le serveur 51. 10 L'identifiant de message peut également être signé, par exemple, à l'aide d'une clé secrète symétrique partagée mémorisée par le serveur. La validité de l'identifiant de message est alors également confirmée lors de la vérification de la signature dans l'entête d'authentification. Lorsque la signature Sign1 est invalide, le message Mes1 est par 15 exemple rejeté par le serveur 51. Lorsque la signature est réalisée à partir d'une clé asymétrique privée, le serveur réalise par exemple une lecture de la clé asymétrique publique en mémoire du serveur ou directement auprès de l'équipement. 20 Vérification de la signature Lorsque les messages transmis sont signés avec une clef symétrique secrète partagée KSec, la clef symétrique secrète partagée KSec est stockée en mémoire par le serveur 51 afin d'être utilisée pour vérifier la signature Sign1. 25 Les messages peuvent aussi être signés à l'aide d'une clef asymétrique publique KPubl fournie par le serveur KPrivl qui utilise alors sa clé asymétrique privée pour vérifier la signature Sign1. De préférence une clef symétrique secrète partagée sera utilisée pour des équipements ne disposant pas d'une puissance de calcul importante. 30 Le profil de sécurité PRO_SEC comprend notamment le format de la signature Sign1 dont les données signées et la désignation de l'algorithme utilisé. Déchiffrement du message après vérifications 3066666 30 Lorsque l'identifiant de message MES_ID1 et que l'authentification du message Mes1 ont été vérifiés par le serveur Si, ce dernier réalise par exemple le déchiffrement des données comme indiqué dans le profil de sécurité PRO SEC. 5 Le profil de sécurité PRO_SEC indique par exemple que les données utiles sont chiffrées avec la clef symétrique secrète partagée et permet au serveur S1 d'engager le déchiffrement des données utiles datai du message Mes1 grâce à la clef symétrique partagée KSec stockée en mémoire par le serveur. io Le profil de sécurité peut également indique que les données utiles sont chiffrées avec la clef asymétrique publique fournie par le serveur. Dans ce cas le serveur réalise un décryptage à l'aide de sa clé asymétrique privée. De préférence, le cryptage à l'aide d'une clé secrète symétrique partagée est préféré pour les équipements disposant de peu de puissance de 15 calcul. Les données utiles déchiffrées sont ensuite traitées par le serveur central de gestion de données. On peut aussi envisager la transmission non chiffrée des données utiles. Dans ce cas, le non chiffrement des données utiles est indiqué dans le 20 profil de sécurité. Traitement du message après vérifications Les données utiles Datai , une fois décodées par le serveur S1, 25 sont traitées par le module APP_S1 . L'utilisation spécifique des données récupérées par le serveur central de gestion des données n'est pas décrite dans la présente description. Réciproquement, coté client, le composant APP _Cl permet par exemple de gérer un ou plusieurs capteurs ou un ou plusieurs actionneurs. 30 Avantages La méthode de l'invention permet notamment d'établir une communication de manière sécurisée sous forme de requête et acquittements entre un client Cl et un serveur S1 sans avoir à gérer les états d'une 35 communication, c'est-à-dire sans avoir à gérer des sessions entre les entités 3066666 31 communicantes. Ainsi, l'invention permet de s'affranchir d'un protocole préliminaire complexe, tel que VPN, entre deux entités communicantes d'un réseau. Les moyens d'une communication sécurisée selon l'invention s peuvent notamment être implémentés en respectant les principes d'une architecture de type REST. L'invention permet également de s'affranchir d'échanges de certificats d'authentification Un autre avantage de l'invention est également d'induire qu'un faible coût de déploiement étant donné que la communication 10 sécurisée peut être établie rapidement entre deux entités communicantes dès leur installation sur le ou les réseaux de communication. La solution de l'invention permet également de suspendre ou de révoquer un équipement Cl défectueux détecté par le serveur S1. REVENDICATIONS1. Procédé de communication entre au moins deux entités communicantes (C1, Si ), une première entité communicante (C1) générant au moins un message (Mes1) de données utiles, émis vers une seconde entité communicante (S1), comprenant un champ utile comportant des données utiles (Datai) et un entête d'authentification (Tokeni), ledit procédé étant caractérisée en ce qu'il comporte, pour la génération dudit message (Mes1): 10 ^ une génération d'un paramètre de contexte (ContextP1) comportant au moins une donnée représentative de la configuration matérielle (ctrlProg) de la première entité (C1) ; ^ une génération d'un profil de sécurité (PRO_SEC) intégré dans l'entête d'authentification (Tokeni) et définissant les conditions: 15 ^ de chiffrement des données utiles (Datai) ) du message ; ^ de génération d'une signature (Signi ) par un algorithme de signature (Signing_Module1) appliqué au moins aux données utiles (Data 1) ; ^ une génération de ladite signature (Signi ) intégrée dans l'entête 20 d'authentification ; ^ une insertion d'un identifiant mémorisé (C1_ld) de la première entité communicante (C1) dans l'entête d'authentification (Tokeni); ^ une insertion du paramètre de contexte (ContextPl) dans le 25 champ utile (Datai) ou dans l'entête d'authentification (Tokeni); ^ une agrégation du champ utile (Datai) ) et de l'entête (Tokeni). 2. Procédé de communication selon la revendication 1, caractérisé en ce que le message (Mes1) émis à la seconde entité communicante (S1) 30 est transmis dans une couche applicative d'un réseau de données auquel sont connectées la première et la seconde entité communicante (Cl, S1). 3. Procédé de communication selon l'une quelconque des revendications 35 1 à 2, caractérisé en ce le paramètre de contexte (ContextP1) comprend en outre une ou plusieurs des données parmi les suivantes : 3066666 2 ^ Un identifiant (IdCol ) d'un calculateur (Col) ) de la première entité (C1 ); ^ Une donnée représentative des ports d'entrée/sortie utilisés et non utilisés de la première entité (C1) ; ^ Une date de mise à jour (DM_Col) d'un micrologiciel de la première entité (C1) ; ^ Une donnée représentative de l'espace mémoire occupé par le micrologiciel. 4. Procédé de communication selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le paramètre de contexte (ContextP1) est chiffré par une première clef publique asymétrique (KPubl) avant d'être intégré dans le message émis, ladite première clef publique asymétrique (KPubl) ) étant enregistrée dans une mémoire de la première entité (C1), le paramètre de contexte (ContextP1) étant déchiffré grâce à une première clef privé asymétrique (KPriv1) enregistrée dans une mémoire de la seconde entité (S1). 5. Procédé de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que la seconde entité (S1) comprend une base de données (DBS1) mémorisant une pluralité de paramètre de contexte (ContextP1), chacun étant associé à une parmi plusieurs premières entités (Ci), la réception par la seconde entité (S1) dudit message émis par la première entité (C1) comportant : ^ Une vérification que le paramètre de contexte (ContextPl) et l'identifiant (C1 Id) de la première entité (C1) reçus par la seconde entité (S1) sont présents dans la base de données (DBS1); ^ Un traitement dudit message (Mesl) reçu lorsque l'état de vérification est validé. 6. Procédé de communication selon la revendication 5, caractérisé en ce que la réception par la seconde entité (S1) dudit message émis par la première entité (C1) comporte en outre : ^ Une analyse par un gestionnaire d'application (App_S1) de la seconde entité (S1) afin de déterminer si une mise à jour d'un 3066666 3 micrologiciel ou une installation d'une nouvelle première entité communicante a eu lieu ; ^ Une mise à jour de la base de données (DBS1) de la seconde entité (S1) prenant en compte le paramètre de contexte 5 (ContextP1) et l'identifiant de la première entité reçus lorsque l'analyse indique qu'une mise à jour ou qu'une nouvelle installation a eu lieu. 7. Procédé de communication selon l'une quelconque des revendications 10 1 à 6, caractérisé en ce que le paramètre de contexte (ContextPl) est inclus dans l'entête d'authentification (Token1), la signature (Sign1) étant appliquée également au paramètre de contexte (ContextP1). 15 8. Procédé de communication selon la revendication 7, caractérisé en ce que les données utiles (Datai) comprennent des données collectées par au moins un capteur (REF) de la première entité communicante (C1). 20 9. Procédé de communication selon l'une quelconque des revendications 7 à 8, caractérisé en ce qu'il comprend une étape transmission d'une information comprenant une clef secrète partagée symétrique (MesSym1) préalable à la génération dudit message (Mes1) de transmission de données utiles (Datai ), ladite clef secrète partagée 25 symétrique (KSec) étant utilisée pour générer la signature (Sign1) et pour chiffrer des données utiles. 10. Procédé de communication selon la revendication 9, caractérisé en ce qu'il comprend préalablement à l'étape de transmission de la clef 30 secrète partagée symétrique (Ksec); ^ Une génération d'une seconde clef publique asymétrique (KPub2) et d'une seconde clef privée asymétrique (Kpriv2) par un module de génération de clefs asymétriques (AsymKGen2) de la première entité (C1), les dites clefs générées étant enregistrées dans une 35 mémoire ; ^ Une transmission par la première entité (C1) vers la seconde entité (S1) d'une requête d'enregistrement (MesEnr1) comportant 3066666 4 l'identifiant de la première entité (C1_Id), le paramètre de contexte (ContextPl) et ladite seconde clef publique asymétrique (KPub2) ; ^ Une transmission par la seconde entité (S1) vers la première entité (C1) d'un acquittement indiquant l'enregistrement de la première 5 entité (C1) dans la base de données (BDS1) de la seconde entité (S1 ); ^ Un chiffrement à partir de la seconde clef privée asymétrique (Kpriv2) de la clef secrète symétrique (Ksec). 10 11. Procédé de communication selon la revendication 10, caractérisé en ce qu'il comprend un renouvellement périodique de la clef secrète partagée symétrique (KSec) comportant: ^ Une génération d'une nouvelle clef secrète symétrique (KSecNew) à partir d'un module de génération de clef symétrique (SynKGen) ; 15 ^ Un chiffrement, par la seconde clef privée asymétrique (KPriv2), de la clef secrète symétrique (KSec) mémorisée dans une mémoire de la première entité (C1) ^ Une transmission de la nouvelle clef secrète partagée symétrique (KSec) à la seconde entité (S1). 20 12. Procédé de communication selon la revendication 10, caractérisé en ce qu'il comprend un renouvellement périodique de la clef secrète privée (Ksec) comportant : ^ Une génération d'une nouvelle clef secrète symétrique (KSecNew) 25 à partir d'un module de génération de clef symétrique (SynKGen) ; ^ Une transmission de la nouvelle clef secrète partagée symétrique (KSecNew). 13. Procédé de communication selon l'une quelconque des revendications 30 1 à 6, caractérisé en ce que les données utiles comprennent le paramètre de contexte (ContextPl ), le paramètre de contexte (ContextPl) étant généré et émis régulièrement. 14. Procédé de communication selon l'une quelconque des revendications 35 1 à 13, caractérisé en ce que la génération dudit message (Mes1) comprend: 3066666 5 ^ Une génération d'un identifiant de message (Mes_ID1) calculé à partir o d'un paramètre généré aléatoirement (RamdomPl) et fourni par un module aléatoire (Ramdom_Modulel) et ; 5 o d'une date limite de validité générée par un module d'horloge (Clock_Module1); ^ Une insertion de l'identifiant de message (Mesid1) dans l'entête d'authentification (Token1) dudit message (Mes1). 10 15. Procédé de communication selon l'une des revendications 1 à 14, caractérisé en ce que le profil de sécurité (PRO SEC) définit les conditions de génération d'une signature (Sign1) par l'algorithme de signature (Signing_Modulel) qui est appliqué aux données utiles (batal) du message (Mes1), au paramètre de contexte (Context1) et à 15 l'identifiant de message (Mes_ID1). 16. Procédé de communication selon l'une quelconque des revendications 1 à 15, caractérisé en ce les données signées par l'algorithme de signature (Sign1) comprennent : 20 ^ le profil de sécurité (PRO_SEC); ^ l'identifiant de la première entité (C1_Id). 17. Entité communicante caractérisée en ce qu'elle comprend au moins une mémoire, un calculateur et une interface de communication pour 25 l'exécution du procédé de communication selon l'une quelconque des revendications 1 à 16. 18. Entité communicante selon la revendication 17 caractérisée en ce qu'elle comprend au moins un capteur de données. 30 19. Programme d'ordinateur comportant un ensemble d'instructions pour la mise en oeuvre du procédé de communication de l'une quelconque des revendications 1 à 18.