FR 3043870 A1 20170519 FR 1560916 A 20151113 1 PROCEDE DE SECURISATION ET D'AUTHENTIFICATION D'UNE TELECOMMUNICATION DOMAINE Le domaine de l'invention concerne la sécurisation de communications entre deux entités communicantes, telles qu'un client et un serveur ayant des interfaces réseaux. Plus particulièrement, l'invention se rapporte aux communications sécurisées ne nécessitant pas de gestion d'états ou de l'établissement d'une session de communication que l'on souhaite sécuriser. Enfin, le domaine de l'invention concerne les télécommunications comprenant une authentification permettant l'établissement de communications sécurisées ad hoc offrant une souplesse d'architecture en limitant l'usage d'un tiers d'authentification. ETAT DE L'ART Dans le domaine des services web, le style d'architecture logicielle de type REST, dont l'acronyme désigne « Representational State Transfer », s'est largement répandu en raison de sa simplicité de mise en oeuvre et d'intégration dans des systèmes distribués. Dans une application web reposant sur une architecture de type REST, un poste client fait appel à des ressources réparties sur un ou plusieurs postes serveur à l'aide de requêtes utilisant par exemple le protocole http, dont l'acronyme désigne « Hypertext Transfer Protocol », et faisant référence à une URI, dont la signification est « Uniform Resource Identifier », représentant l'adresse unique de la ressource sur le réseau. En réponse à cette requête, le serveur renvoie au poste client les ressources demandées généralement au format XML ou JSON. L'une des caractéristiques essentielles de l'architecture REST est de proscrire au niveau du serveur tout contexte de communication avec le poste client au-delà de la durée de réception de la requête. Ce mode de communication sans-état, également connu par l'appellation anglo-saxonne « stateless », garantit au poste serveur une capacité à monter en charge. En effet, ce dernier peut libérer immédiatement après la réception de la requête ses ressources nécessaires à la communication avec le poste client, les rendant ainsi disponibles pour une nouvelle communication et évitant la surcharge de ces ressources systèmes. 3043870 2 Dans le domaine de la sécurisation des télécommunications différentes techniques existent. Toutes reposent sur un mécanisme d'authentification permettant de sécuriser des échanges entre deux entités communicantes. 5 Parmi les solutions n'impliquant pas la mise en oeuvre d'une session entre les deux entités, deux méthodes d'authentification sont répandues. Parmi ces méthodes, toutes engagent l'échange d'au moins un secret entre le serveur et un client. Le secret peut prendre la forme d'un mot de passe ou d'une clef. Dans la suite de la description, nous désignerons par 10 secret l'un ou l'autre de ces cas. Une première méthode d'authentification repose sur l'échange d'une clef API, c'est-à-dire d'un secret partagé entre deux entités communicantes. Dans ce cas, généralement un secret tel qu'un mot de passe est défini coté serveur et est transmis par la requête à destination d'un client. 15 Ce mot de passe est alors échangé à chaque émission de requête entre les entités communicantes. Un problème de cette solution est qu'une interception de la requête permet à un tiers de récupérer le secret partagé et d'accéder par la suite au serveur de données. Un risque est que l'accès au serveur soit usurpé par un 20 tiers non autorisé qui peut alors partager des données sensibles. Une seconde méthode d'authentification repose sur l'établissement d'une signature de clef API. Un secret est alors partagé initialement entre deux entités communicantes, par exemple, par une phase d'enrôlement entre les 25 deux entités. Les secrets sont ensuite stockés du côté du client et du côté du serveur. Le secret est alors utilisé pour signer les messages qui sont ensuite émis. Un avantage est que le secret n'est pas partagé systématiquement lors de la transmission de chaque message entre deux entités communicantes. Cette solution limite les possibilités d'interception du secret. La signature 30 permet d'authentifier les messages une fois reçu avec le secret qui est stocké dans l'entité communicante, mais qui n'est pas transféré pendant les échanges. Un problème de cette solution est que les mots de passe / secrets doivent être stockés dans les entités. Or, généralement le stockage du secret 35 est effectué en clair, c'est-à-dire de manière non chiffrée. Un danger est qu'une 3043870 3 usurpation de la base de données du serveur par un tiers permette d'accéder aux secrets de tous les clients. Parmi les solutions impliquant la mise en oeuvre d'une session entre 5 les deux entités, deux méthodes d'authentification sont répandues. Une première méthode repose sur la technologie SAML désignant « Security Assertion Markup Language ». Cette méthode repose sur la définition d'un tiers d'authentification tel qu'un serveur d'authentification. Cette solution implique la mise en oeuvre d'un système de gestion de clefs PKI, 10 l'acronyme désignant « Public Key Infrastructure ». Cette méthode permet d'obtenir une bonne sécurité des échanges de données entre les entités communicantes. Cependant, elle est difficile à mettre en oeuvre simplement car un tiers d'authentification doit être paramétré. En outre, elle est couteuse et nécessite l'établissement d'une session entre les entités et/ou l'échanges 15 de certificats. Par ailleurs, le protocole XML est généralement employé dans cette méthode. Un inconvénient est que l'entête de sécurité de ce protocole est très verbeux et n'est pas adaptée à des communications à faible bande passante. Une seconde solution repose sur le protocole HTTPs qui repose 20 également sur un système de gestion de clefs PKI et sur l'échange de certificats. Cette solution offre également une bonne sécurité des échanges de données entre entités communicantes. En revanche, cette solution est couteuse et difficile à mettre en oeuvre. En outre, elle implique un mécanisme d'échange de clefs préalable avec un tiers d'authentification. Ces méthodes 25 peuvent se déployer sur des réseaux large bande mais sur des réseaux plus contraints, elles peuvent rencontrer quelques limitations lors de la mise en oeuvre des échanges. En outre, un problème d'un système de gestion de clef PKI est qu'il est difficile, voire impossible, du point de vue du serveur de suspendre un 30 équipement pendant une durée déterminée ou indéterminée. Le tiers d'authentification possédant des droits, il est difficile de disposer d'une autonomie de gestion des révocations ou des suspensions de droits du point de vue du serveur de communication. Le brevet US 8621598 B2 décrit un mécanisme s'appuyant sur une 35 architecture REST, en revanche la solution impose la définition d'un jeton de 3043870 4 session qui est transmis entre les entités communicantes. Dans cette solution, le jeton d'authentification est utilisé par le serveur pour échanger avec un serveur d'authentification autorisant ou non le transfert de données entre le client et le serveur. Cette solution implique la mise en oeuvre d'un serveur 5 d'authentification comprenant une base de données dans laquelle les clefs privées des équipements clients sont stockées. Il existe un besoin de définir une méthode de communication sécurisée pour l'échange de données entre deux entités communicantes qui 10 soit simple à mettre en oeuvre, qui ne s'appuie pas sur un serveur d'authentification tiers et qui n'implique pas la définition, la mise en oeuvre et la gestion d'une session entre les entités communicantes. Parmi les besoins de sécurisation de tels échanges de données, il existe un besoin de définir une méthode de communication qui soit robuste 15 aux attaques de type rejeu, de type HDM, désignant une attaque de l'« homme du milieu » ou encore une attaque de type « eavesdropping », désignant un type « écoute clandestine ». RESUME DE L'INVENTION 20 L'invention vise à pallier aux inconvénients précités. L'invention permet d'offrir un compromis entre un niveau de sécurité suffisant à mettre en oeuvre entre des entités communicantes et une simplicité de mise en oeuvre d'un certain niveau de sécurité permettant des échanges sans états entre lesdites entités. L'invention permet de s'affranchir d'échanges 25 de certificats ou de l'établissement d'une session. En outre, le procédé de l'invention permet de s'affranchir d'un tiers d'authentification, tel qu'un serveur d'authentification. Un objet de l'invention concerne un procédé de communication 30 entre deux entités communicantes, une première entité communicante générant un message de données comprenant des données utiles et un entête d'authentification, ledit procédé comportant : ^ une génération d'un identifiant de message à partir d'un paramètre donné et d'une date et une insertion de l'identifiant 35 dans un entête d'authentification ; 3043870 5 ^ une insertion d'une pluralité de données d'authentification comprenant au moins un identifiant utilisateur et un identifiant d'équipement dans l'entête d'authentification ; ^ une détermination et une insertion d'un profil de sécurité dans s l'entête d'authentification définissant les conditions : o de chiffrement des données utiles d'au moins l'émission du message par la première entité communicante ; o de génération d'une signature de données du message et du format de ladite signature générée ; 10 ^ une insertion des données utiles dans le message à transmettre. Un avantage de l'invention est de permettre de sécuriser une liaison de données entre deux entités communicantes sans avoir à mettre en oeuvre un tiers d'authentification, tel qu'un serveur d'authentification stockant des 15 données d'authentification des entités communicantes. Dans le procédé de l'invention, seules les entités communicantes échangeant des données mettent en oeuvre les mécanismes de sécurité de la liaison de données. En outre, le procédé de l'invention ne nécessite pas de gestion de session ou d'état entre les deux entités communicantes. Chaque message comporte les 20 éléments d'identification, d'authentification et de sécurité assurant une liaison fiable. Selon un mode de réalisation, l'ensemble de données à signer comprend une combinaison des données suivantes : 25 ^ l'identifiant de message ; ^ 'identifiant utilisateur ; ^ un mot de passe d'un compte utilisateur ; ^ l'identifiant de l'équipement ; ^ le profil de sécurité ; 30 ^ une information d'entêtes ou d'un champ de données de message représentative du protocole de transfert des données utiles ; ^ les données utiles. 3043870 6 Selon un mode de réalisation, la première entité communicante comprend une mémoire pour stocker une clef publique d'une seconde entité communicante, le profil de sécurité comprenant : ^ un premier paramètre indiquant la présence ou non d'un s chiffrement des données utiles effectué à partir de la clef publique de la seconde entité communicante et ; ^ un second paramètre indiquant la présence ou non d'une signature d'un ensemble de données à signer. 10 Selon un mode de réalisation, la première entité communicante comprend une mémoire pour stocker une clef publique d'une seconde entité communicante, le profil de sécurité comprenant : ^ un premier paramètre indiquant la présence ou non d'un chiffrement des données utiles effectué à partir d'une clef 15 symétrique et le cas échéant de la présence d'un chiffrement de la clef symétrique à partir de la clef publique de la seconde entité communicante et ; ^ un second paramètre indiquant la présence ou non d'une signature d'un ensemble de données à signer. 20 Selon un mode de réalisation, le profil de sécurité comprend : ^ Un troisième paramètre indiquant la présence ou non d'un chiffrement effectué à partir de la clef publique de la première entité communicante soit des données utiles soit d'une clef 25 symétrique et ; ^ Un quatrième paramètre indiquant la présence ou non d'une signature d'un ensemble de données à signer, d'au moins un message devant être émis par une seconde entité communicante en réponse à un message reçu de la première entité 30 communicante. Selon un mode de réalisation, la seconde entité communicante à réception d'un message de la première entité communicante décode l'entête d'authentification de manière à : 3043870 7 ^ contrôler l'identifiant de message pour déterminer si le message a été émis dans un laps de temps prédéfini ; ^ contrôler l'identifiant de l'utilisateur et l'identifiant de l'équipement en comparant la valeur de ces paramètres avec des données 5 stockées dans une mémoire de la seconde entité communicante pour déterminer si l'équipement ou l'utilisateur a été suspendu ou révoqué ; ^ contrôler le paramètre de chiffrement du profil de sécurité du message reçu pour déchiffrer le cas échéant les données utiles 10 avec la clef privée de la seconde entité communicante; ^ contrôler, le cas échéant, le paramètre de signature du profil de sécurité du message reçu pour vérifier le cas échéant la signature au moyen de la clef publique de la première entité communicante. 15 Selon un mode de réalisation, le serveur comprend des moyens d'accès à la mémoire stockant les données correspondantes aux identifiants clients et aux identifiants d'équipements de manière à révoquer ou suspendre un ou plusieurs équipement(s) ou client(s). 20 Un autre objet de l'invention concerne un procédé de génération d'une requête d'enrôlement par une première entité communicante à destination d'une seconde entité communicante. Le procédé de génération d'une requête d'enrôlement comprend : 25 ^ Une activation de la procédure d'enrôlement ; ^ Une génération d'une requête d'enrôlement comportant un identifiant d'un équipement, un identifiant de l'utilisateur, un mot de passe de l'utilisateur et une clef publique de la première entité communicante ; 30 ^ Un chiffrement de la requête avec une clef publique de la seconde entité communicante et une émission de la requête d'enrôlement au moyen d'une interface de communication à destination de la seconde entité communicante. 3043870 8 Selon un mode de réalisation, le procédé de génération d'une requête d'enrôlement par une première entité communicante comprend préalablement : ^ Une création d'un compte utilisateur comprenant un identifiant et s un mot de passe ; ^ L'enregistrement des données dudit compte utilisateur dans une mémoire de la seconde entité communicante ; ^ Une acquisition d'une clef publique de la seconde entité communicante pour lequel la procédure d'enrôlement est 10 engagée depuis la première entité communicante ; ^ Une génération d'un couple de clefs asymétriques de la première entité communicante. Selon un mode de réalisation, le procédé d'enrôlement comprend 15 les étapes suivantes réalisées par la seconde entité communicante : ^ Une réception d'une requête d'enrôle générée par un procédé de génération d'une requête d'enrôlement de l'invention ; ^ Un déchiffrement des données de la requête d'enrôlement au moyen d'une clef privée de la seconde entité communicante; 20 ^ Une comparaison entre l'identifiant utilisateur reçu et le mot de passe utilisateur reçu avec des données de comptes clients stockés dans une mémoire de la seconde entité communicante; ^ Un enregistrement de l'identifiant de l'équipement dans une mémoire de la seconde entité communicante ; 25 ^ Un enregistrement de la clef publique de la première entité communicante associée à l'identifiant de l'équipement dans une mémoire de la seconde entité communicante. Selon un mode de réalisation, la seconde entité communicante met 30 en oeuvre les étapes du procédé d'enrôlement suivantes : ^ un contrôle d'une date actuelle avec une date référence ; ^ une génération d'un message à destination de la première entité communicante comprenant un code spécifique indiquant qu'un couple de clefs asymétriques doit être renouvelé ; 3043870 9 ^ une réception d'une nouvelle requête d'enrôlement générée par la première entité communicante selon le procédé d'enrôlement de l'invention. s Selon un mode de réalisation le procédé de communication comprend préalablement l'exécution d'un procédé d'enrôlement de l'invention. Un autre objet de l'invention concerne une entité communicante comprenant au moins une mémoire, un calculateur et une interface de 10 communication pour l'exécution du procédé de communication de l'invention et/ou du procédé d'enrôlement. Un autre objet de l'invention concerne un programme d'ordinateur comportant un ensemble d'instructions pour la mise en oeuvre du procédé de 15 communication. Dans ce mode de réalisation, un support physique, tel qu'une mémoire, permet d'enregistrer les instructions et un calculateur permet de mettre en oeuvre les étapes du procédé. Dans ce dernier cas, le programme d'ordinateur est configuré pour exécuter le procédé de l'invention sur un ordinateur, une tablette, un Smartphone ou plus généralement un équipement 20 électronique intelligent comprenant une interface de communication. Selon un mode de réalisation, le programme d'ordinateur est configuré pour former une API, désignant « Application Programming Interface ». Cette dernière peut être mise en oeuvre dans un programme d'ordinateur au sein d'un procédé de gestion d'une interface de 25 communication d'un équipement. Selon un mode de réalisation, un programme d'ordinateur est également conçu pour comprendre des instructions et des moyens pour l'exécution du procédé d'enrôlement. Identiquement, ce programme d'ordinateur peut être conçu pour former une API. 30 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, qui illustrent : 3043870 10 ^ figure 1 : un schéma de principe des principaux éléments du système de l'invention mettant en oeuvre les procédés de l'invention ^ figures 2A, 2B : les principales étapes des procédés de l'invention 5 de génération d'une requête d'enrôlement et de réception de la requête d'enrôlement ; ^ figure 3 : les principales étapes du procédé de communication de l'invention. io DESCRIPTION L'invention concerne la sécurisation et l'authentification de communications entre deux entités communicantes. La description détaille un mode de réalisation dans lequel les deux entités concernent respectivement un client et un serveur. La présente invention vise un procédé d'enrôlement 15 entre au moins deux entités et un procédé de communication entre au moins ces deux entités. Client Un client selon l'invention comprend à minima un calculateur, une 20 mémoire et une interface de communication. Selon un mode de réalisation, le client est un ordinateur, une tablette, un smartphone ou encore un équipement industriel de type boitier intelligent ou tout équipement électronique dédié pour l'application visant à transférer des données de manière sécurisée. Le client comprend un système d'exploitation et un ensemble de fonctions permettant 25 d'offrir à un utilisateur un ensemble de services au sein d'un réseau. Le client est donc associé à un équipement. On parlera, dans la description qui suit, indifféremment d'un équipement ou d'un client, lorsque le client est une entité communicante ayant une configuration lui permettant de s'identifier au sein d'un réseau. Le client comprend donc un identifiant noté 30 EQ_ID. L'équipement client est donc indifféremment noté EQA, EQB ou encore CLIENT d'une manière générale. En conséquence, le client est généralement une entité qui est capable d'initier une communication par une procédure d'enrôlement qui a 3043870 11 pour objectif de sécuriser un transfert de données entre ledit client et un serveur. Serveur Un serveur selon l'invention comprend à minima une mémoire et un 5 calculateur ainsi qu'une interface de communication. Selon un mode de réalisation, le serveur est un ordinateur connecté à un réseau, tel que le réseau internet. Selon un mode de réalisation, le serveur est configuré pour recevoir des messages provenant de différents clients et stocker des données envoyées par différents clients. Selon un mode de réalisation, le serveur 10 stocke dans une base de données des données d'une pluralité d'utilisateurs dont des comptes clients et des associations entre chaque client et des équipements utilisateurs EQ. En outre, le serveur stocke des données cryptographiques. Le serveur est un équipement mettant à disposition une clef 15 publique KSpub pour un ou plusieurs client(s). Cette clef publique permet de chiffrer des messages émis par le client pour le serveur. Le serveur de données de l'invention est un serveur offrant des services à un client. Le serveur de l'invention n'est donc pas un serveur d'authentification réalisant exclusivement les fonctions d'authentification au 20 sens d'un tiers d'authentification couplé avec un autre serveur de données. Un des objectifs de l'invention est de permettre d'établir des communications sécurisées entre au moins un client et un serveur de données offrant des services impliquant une connexion sécurisée. 25 Compte client Dans la description qui suit un utilisateur est identifié par un Identifiant USER_ID. L'utilisateur est capable de définir un compte et de le référencer auprès du serveur, par exemple, au moyen d'une liaison distante permettant d'enregistrer les données de son compte. Le compte comprend au 30 minimum un identifiant USER_ID et un mot de passe USER_MDP qui est associé à l'identifiant USE R_ID. Le procédé d'échange de données entre deux entités communicantes comprend donc préalablement une étape d'enregistrement d'un utilisateur sur l'entité définissant le serveur de données. 35 3043870 12 Gestion de clefs asymétriques La méthode d'authentification de l'invention est basée sur une génération d'un couple de clefs cryptographiques asymétriques et l'échange de clefs publiques entre les entités communicantes. Une clef publique Kpub et 5 une clef privée Kpriv sont générées par un équipement, cette étape est notée K_ GEN à la figure 1. Cette fonction peut être réalisée par un composant cryptographique logiciel ou matériel de l'équipement. Seules les clefs publiques sont échangées entre les entités communicantes : - la clef privée de chaque client KApriv est stockée dans une 10 mémoire d'un équipement client ou dans un composant de sécurité dédié comme par exemple un TPM désignant « Trusted Platform Module », et ; - la clef privée d'un serveur de données KSpriv est stockée dans une mémoire du serveur. 15 Les clefs privées KApriv, KSpriv ne sont pas échangées entre les entités communicantes lors de l'exécution des procédés de l'invention. Sur la figure 1, coté client, les clefs sont gérées par un composant cryptographiques notées K_SUP_C. Ce composant permet de stocker la clef privée KApriv et la clef publique KApub du client ainsi que la clef publique du 20 serveur KSpub acquise lors d'une étape préalable. La figure 1 représente, en outre, un composant cryptographique coté serveur K_SUP_S qui permet de stocker le couple de clefs asymétriques du serveur : KSpriv, KSpub. Dans la présente invention, chaque équipement est associé à une 25 clef privée unique d'un équipement KApriv qui peut éventuellement être renouvelée. Une clef privée d'un équipement KApriv est associée à un équipement EQA comme par exemple un smartphone, une tablette, un PC ou un équipement industriel de type boitier intelligent tel qu'un compteur électrique par exemple. 30 Un utilisateur est associé à un ou plusieurs équipements EQA, EQB, etc. Procédé de génération d'une requête d'enrôlement L'enrôlement est une étape préliminaire à toute transmission de 35 données utiles entre deux entités communicantes établissant une 3043870 13 communication sécurisée selon le procédé de communication de l'invention. L'enrôlement permet d'échanger des données entre les entités communicantes qui vont permettre la sécurisation des échanges de données. Lorsqu'un client procède à un enrôlement auprès d'un serveur, il s initie cette procédure en générant une requête REQ_E. Un avantage est que cette requête ne comprend pas l'émission d'une clef privée de l'équipement. Le client comprend un composant noté ENROL_C permettant de mettre en oeuvre le mécanisme d'enrôlement du point de vue du serveur, notamment pour générer les requêtes d'enrôlement REQ_E. 10 Du point de vue du serveur, un composant noté EQ_MG contrôle la gestion des équipements et des utilisateurs et traite les requêtes d'enrôlement REQ_E, notamment en vérifiant la validité des données de la requête. Lorsqu'un équipement est enrôlé par un serveur, son identifiant est stocké dans une mémoire du serveur. Le serveur est alors capable d'associer un 15 client avec un ensemble d'équipements associés qui ont été enrôlés par l'utilisateur. Coté serveur, la fonction gérant les équipements et les utilisateurs est noté MG sur la figure 1 et la fonction traitant les requêtes d'enrôlement est notée ENROL_S. Une mémoire permet de stocker les clefs publiques des équipements ainsi que les mots de passe des comptes clients. Cette mémoire 20 est notée K_PUB sur la figure 1. Le procédé d'enrôlement de l'invention s'appuie sur la création d'un compte client par un utilisateur dont des données sont stockées dans une mémoire d'un serveur de données, le serveur de données SERV définissant l'une des entités communicantes de l'invention. 25 La figure 2A représente les principales étapes d'un procédé de génération d'une requête d'enrôlement REC_E engagé par le procédé de génération d'une requête d'enrôlement M1_ENROL_C réalisé par un équipement tel qu'un client. Avant de communiquer avec un serveur selon le procédé de 30 communication de l'invention, chaque client accomplit une phase d'enrôlement selon le procédé de génération d'une requête d'enrôlement de l'invention. Le procédé M1_ENROL_C comprend une étape activant ce procédé qui correspond également à l'étape éponyme de la méthode M1 ENROL_C. 3043870 14 Le procédé de génération d'une requête d'enrôlement M-I ENROL_C par le client comprend une étape correspondant à l'acquisition d'une clef publique d'un serveur SERV, notée ACQ_KSpub. Selon les modes de réalisation de l'invention, l'étape d'acquisition de la clef publique du serveur 5 KSpub peut être considérée comme faisant partie du procédé d'enrôlement ou elle peut être considérée comme une étape préalable dans laquelle la clef publique du serveur KSpub a été acquise par un utilisateur avant qu'il engage l'enrôlement. Dans ce dernier cas, l'acquisition de la clef publique du serveur KSpub n'est pas comprise dans le procédé d'enrôlement. 10 Cette étape peut être réalisée par une saisie manuelle si un utilisateur recopie une clef publique d'un serveur KSpub dans une interface d'un équipement client. En outre, la clef publique du serveur KSpub peut être reçue d'un équipement tiers ou encore directement du serveur SERV formant l'une des deux entités communicantes de l'invention. Dans ce dernier cas, la 15 clef publique du serveur KSpub peut être reçue, par exemple, après la création d'un compte utilisateur auprès du serveur SERV. Selon d'autres exemples de réalisation, l'acquisition de la clef publique du serveur KSpub peut être générée au moyen d'un fichier tel qu'une image, un code captcha, un code barre ou un code 2D, tel qu'un QR code. L'acquisition de la clef publique du 20 serveur KSpub par le client peut être réalisée, dans ce dernier cas, par une lecture du code ou de l'image comprenant ladite clef au moyen de l'équipement. L'équipement comprend dans ce dernier cas des moyens de capture d'une image tel qu'un capteur optique. Selon un mode de réalisation, lorsque l'acquisition de la clef 25 publique KSpub du serveur a déjà eu lieu, la clef publique du serveur est considérée comme déjà stockée dans une mémoire de l'équipement. L'étape d'acquisition de la clef publique du serveur KSpub du procédé peut donc correspondre à l'acquisition de cette clef depuis la mémoire de l'équipement quand elle a déjà été acquise du serveur. Lorsque l'équipement n'a pas la clef 30 publique du serveur, l'acquisition comprend l'opération visant à récupérer cette clef publique KSpub du serveur. Cette opération peut résulter d'une opération visant à établir un dialogue entre le client et le serveur. Selon un autre mode de réalisation, l'utilisateur récupère la clef publique du serveur sans procéder à un échange entre le client et le serveur, par exemple par une recopie 35 manuelle de la clef dans une interface du client. 3043870 15 Chaque équipement qui procède à un enrôlement avec un serveur a stocké une clef publique KSpub dudit serveur. La clef publique du serveur KSpub permet de chiffrer la requête d'enrôlement ainsi que les messages émis lors du procédé de communication de l'invention. 5 Selon un mode de réalisation de l'invention, le procédé de génération d'une requête d'enrôlement par le client comprend une étape de génération d'une clef publique d'un équipement EQA, notée KApub, et d'une clef privée d'un équipement notée KApriv. Les étapes de génération sont respectivement notées GEN_KApub et GEN_KApriv sur la figure 2A, elles sont 10 en outre généralement générées en même temps. Dans ce dernier cas un couple de clefs est généré conjointement. Lorsque l'étape de génération du couple de clefs asymétrique a été préalablement effectué, le procédé de génération d'une requête d'enrôlement vise à extraire la clef publique de l'équipement KApub d'une mémoire de l'équipement pour l'inclure dans la 15 requête. Dans ce dernier cas, selon un mode de réalisation, le procédé de génération d'une requête d'enrôlement comprend uniquement l'acquisition dans une mémoire de l'équipement de la clef publique du client et non sa génération à chaque enrôlement. 20 Le procédé de génération d'une requête d'enrôlement REQ_E par le client comprend donc la génération d'une requête d'enrôlement REQ_E à destination du serveur SERV. Cette étape est notée GEN_REQ sur la figure 2A. Cette étape est réalisée par un calculateur du client notée sur la figure 1 : « REQ ». Elle comprend la récupération d'un certain nombre de données 25 stockées dans une mémoire du client et la génération de la requête REQ_E comprenant ces données récupérées. Les étapes de récupération de certaines données sont également réalisées lors du procédé de communication de l'invention. Notamment, l'identifiant de l'équipement et l'identifiant utilisateur sont utilisés à chaque transmission de nouveaux 30 messages par application du procédé de communication de l'invention. Certaines étapes qui suivent sont donc communes au procédé d'enrôlement et au procédé de communication de l'invention. Selon un mode de réalisation, le calculateur récupère des données d'au moins une mémoire du client, par exemple stockée dans une base de 35 données dont un identifiant de l'équipement noté EQ_ID. En outre, le 3043870 16 calculateur récupère l'identifiant utilisateur USER_ID. L'identifiant utilisateur USER_ID peut être : - soit récupéré par le calculateur depuis une mémoire dans laquelle un utilisateur a préalablement stocké son identifiant ; s - soit récupéré depuis un contrôle de saisie d'une interface utilisateur dans laquelle l'utilisateur indique son identifiant sans qu'il soit préalablement stocké dans l'équipement. Le calculateur récupère également un mot de passe utilisateur to USER MDP. Le mot de passe utilisateur USER MDP peut être également soit récupéré d'une mémoire de l'équipement EQA dans laquelle il a été préalablement stocké par un utilisateur de l'équipement EQA, soit récupéré d'un contrôle de saisie d'une interface utilisateur. Cette étape est notamment exécutée pour le procédé d'enrôlement. 15 En outre, le calculateur récupère la clef publique de l'équipement KApub de l'équipement EQA qui est stockée dans une mémoire de l'équipement EQA après sa génération ou sa récupération depuis une interface. La clef publique du client est transmise lors du procédé d'enrôlement, mais ne l'est pas forcément lors du procédé de communication 20 de l'invention. C'est justement un avantage de l'invention de ne pas réémettre la clef publique de l'équipement à chaque émission de nouveaux messages. La requête d'enrôlement ainsi générée comprend donc les données suivantes : - l'identifiant utilisateur, USER_ID ; 25 - le mot de passe du client, USER_MDP ; - l'identifiant de l'équipement, EQ_ID ; - la clef publique du client, KApub. Le procédé de génération d'une requête d'enrôlement comprend 30 une étape de chiffrement de la requête, noté CRYP_REQ sur la figure 2A, par la clef publique du serveur KSpub. Cette clef publique a été préalablement acquise par le client et peut être utilisée pour chiffrer la requête d'enrôlement. En conséquence, le serveur sera en mesure de déchiffrer la requête ainsi chiffrée grâce à sa clef privée KSpriv. 3043870 17 Selon une alternative de réalisation, la clef publique du serveur KSpub est utilisée pour chiffrer une clef symétrique. Cette solution est plus performante en termes de calculs qu'un algorithme de chiffrement du message effectué à partir de clefs asymétriques. Cette solution permet de chiffrer un s message plus court avec une clef asymétrique qui comprend la clef symétrique. A la réception, la clef privée KSpriv du serveur permet de déchiffrer la clef symétrique et de décoder le message chiffré avec la clef symétrique ainsi déchiffrée. Cette alternative peut être mise en oeuvre lors du procédé d'enrôlement et/ou lors du procédé de communication de l'invention. 10 Le procédé d'enrôlement est effectué préalablement à l'émission de messages selon le procédé de communication de l'invention. L'enrôlement peut être effectuée une fois pour toute depuis l'équipement client ou depuis n'importe quelle équipement permettant d'établir une liaison avec le serveur de données. 15 Selon un autre exemple de réalisation, l'enrôlement peut être une étape préliminaire à l'émission d'un message qui succède directement l'étape de transmission sécurisée de messages. Réception de la requête par le serveur 20 L'invention concerne le traitement M2 _ ENROL _S d'une requête d'enrôlement REQ_E reçu par le serveur. Lorsque le serveur reçoit une nouvelle requête d'enrôlement REQ_E, il procède à sa réception REC_REQ au moyen d'une interface de communication, comme par exemple une carte réseau. Le serveur engage une étape de déchiffrement des données, notée 25 DECRYPT REQ, au moyen de sa clef privée KSpriv. Les données déchiffrées sont ensuite extraites et stockées dans une mémoire du serveur. Le serveur effectue un contrôle de l'identifiant utilisateur USER_ID et du mot de passe de l'utilisateur MDP_USER qui sont des données déjà enregistrées dans une mémoire du serveur lors de la 30 création du compte client sur le serveur SERV. Lorsque les données du compte utilisateur reçues correspondent aux données déjà enregistrées, le serveur enregistre les données de l'équipement dont son identifiant EQ_ID et la clef publique de l'équipement KApub dans une mémoire. 3043870 18 Le serveur SERV procède alors à une association ASSO_KApub entre les données des équipements et un compte utilisateur. Ainsi, un utilisateur peut être associé à différents équipements dont les clefs publiques sont connues du serveur. 5 Renouvellement de clef Selon un mode de réalisation, un mécanisme de renouvellement de clefs engage le renouvellement d'un couple de clefs asymétriques : une clef privée de l'équipement KApriv et une clef publique de l'équipement KApriv sont 10 renouvelées. La clef publique de l'équipement KApub peut être à nouveau transmise à destination du serveur. Pour cela, un procédé d'enrôlement peut être réitéré, par exemple sur demande du serveur ou après un certain temps écoulé. Selon un exemple de mise en oeuvre, le serveur peut émettre un 15 message d'erreur suite à la réception d'un message du client dont la clef publique n'est plus valide. Le message d'erreur peut comprendre un code de rejet indiquant qu'un procédé d'enrôlement doit être reconduit avec une nouvelle clef publique. Identiquement, lorsque c'est la clef publique du serveur qui est 20 modifiée, un message d'erreur peut indiquer au client qu'il est nécessaire qu'il récupère une nouvelle clef publique du serveur. Ce mécanisme peut être automatiquement engagé et de manière transparente vis-à-vis d'un utilisateur. L'équipement renouvelle alors une 25 nouvelle clef privée KApub qui est stockée localement et renouvelle une nouvelle clef publique KApub associée à cette clef privée. La clef publique de l'équipement est alors envoyée par une nouvelle requête d'enrôlement au serveur. 30 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 communicantes, ces messages sont notés MES_C et MES_S sur la figure 1. Le procédé de l'invention permet d'échanger des communications de manière 35 sécurisée par la définition de messages dont la sécurité est « autoportée », 3043870 19 c'est-à-dire que chaque message échangé comprend ses propres informations de sécurité permettant de traiter et de chiffrer le message envoyé. L'invention ne nécessite pas qu'un établissement d'une session entre les deux entités communicantes assure un canal sécurisé entre lesdites deux entités. 5 L'invention comprend donc deux mécanismes permettant de définir une méthode de communication sécurisée entre deux entités communicantes : ^ un mécanisme d'enrôlement et ; ^ un mécanisme de génération d'entête d'authentification des messages de données transmis entre les deux entités. 10 L'invention se rapporte à chacun de ces deux mécanismes. La description qui suit décrit un mode de réalisation dans lequel le client émet un message vers le serveur, ce message étant vérifié par le serveur. L'invention se rapporte également aux échanges inverses de 15 messages, dont notamment un message dont l'entête est généré par le serveur et dont la vérification est effectuée à réception par un client. Selon un mode de réalisation, le procédé de communications sécurisé de l'invention est symétrique entre un client et un serveur. Le procédé de communication s'applique donc réciproquement d'une transmission d'un client vers un serveur 20 ou d'un serveur vers un client. On note sur la figure 1, les composants permettant de traiter les fonctions en émission et en réception des procédés de l'invention : SEC_SW_C pour le client et SEC_SW_S coté serveur. 25 Entête d'authentification d'un message Consécutivement à l'étape d'enrôlement, l'invention met en oeuvre un procédé de communication permettant de transmettre des messages sécurisés par la génération d'un entête d'authentification, noté TOKEN. Le 30 procédé de communication pourrait, dans une autre variante de réalisation, être réalisé indépendamment de l'exécution préalable d'un procédé d'enrôlement. C'est par exemple le cas lorsque les données échangées dans le procédé d'enrôlement seraient définies par un utilisateur dans chaque équipement, comme par exemple l'échange des clefs publiques et des 35 identifiants d'équipement et d'utilisateur. 3043870 20 L'entête d'authentification TOKEN est généré par un composant du client noté sur la figure 1 : TOK_GEN_C. Coté serveur, le composant noté TOK_ CHK _S vérifie l'entête d'authentification reçu du client. Inversement, lorsqu'un message est émis par le serveur à destination d'un client, un s composant noté TOK_GEN_S, coté serveur, permet de générer l'entête d'authentification du message et un composant noté TOK_CHK_C, coté client, permet de vérifier l'entête d'authentification d'un message émis par le serveur à destination du client. L'entête d'authentification TOKEN des messages transmis io comprend différents champs de données dont l'identifiant de l'équipement EQ_ID, l'identifiant de l'utilisateur USER_ID, l'identification du message, MES_ID, un profil de sécurité PRO_SEC et une signature le cas échéant. L'entête d'authentification TOKEN peut être, par exemple, intégré aux entêtes du protocole transport utilisé selon les communications 15 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, le contenu de l'entête d'authentification générée par la présente invention est associé à 20 l'entête « Authorization : » du protocole HTTP/1 .1 selon la RFC [2616]. Identifiant de message, MES_ID Selon un mode de réalisation, le calculateur récupère un identifiant de message MES_ID qui est généré par un compteur de messages qui génère 25 des identifiants de messages. La figure 1 représente les composants permettant de générer et traiter des identifiants de messages, ils sont également notés MES_ID. Selon un mode de réalisation, le compteur de message calcule le MES_ID à partir d'un aléa, c'est-à-dire d'un paramètre aléatoire et d'une date. 30 L'aléa permet de définir un identifiant unique du message. Lorsque l'identifiant du message MES_ID est calculé notamment à partir d'une date définie par une horloge locale de l'équipement, l'identifiant MES_ID comprend une information relative à la date de génération du message qui pourra être décodée en réception par le serveur. 3043870 21 Selon une alternative de réalisation, le MES_ID peut être généré avec un paramètre non aléatoire et une date. L'identifiant de message MES_IS peut être par exemple calculé à la volée, c'est-à-dire en temps réel par un calculateur de l'entité s communicante. L'identifiant du message ainsi calculé est attribué à un message. Profil de sécurité Le profil de sécurité PRO_SEC permet de définir un algorithme qui 10 sera utilisé pour signer ou chiffrer le contenu à transmettre et pour indiquer et définir si la réponse émise par le serveur doit également être chiffrée et selon quel algorithme. Les différentes entités communicantes, telles qu'un serveur et une pluralité de clients peuvent comprendre une configuration de profils de sécurité 15 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é. Selon un mode de réalisation de l'invention, quatre profils de sécurité sont prédéfinis. Un premier profil correspond à l'activation d'un paramètre de 20 sécurité P-I incorporé dans l'entête d'authentification TOKEN du message à transmettre par le client au serveur. Ce paramètre indique la présence d'un chiffrement des données utiles transmises. Ainsi, le serveur recevant ce paramètre est capable de mettre en oeuvre un déchiffrement des données transmises lorsque ces dernières sont chiffrées. 25 Un second profil correspond à l'activation d'un paramètre de sécurité P2 incorporé dans l'entête d'authentification du message à transmettre par le client. Le paramètre P2 permet d'indiquer que l'entête d'authentification est signé. La signature est dans ce cas effectuée par le client grâce à la clef privée du client KApriv. Selon un mode de réalisation, la 30 signature est incorporée dans l'entête d'authentification. Un troisième profil correspond à l'activation d'un paramètre de sécurité P3 incorporé dans l'entête d'authentification TOKEN du message à transmettre par le client au serveur. Ce paramètre indique que les données 3043870 22 utiles du ou des message(s) retour(s) émis par le serveur vers le client doivent être chiffrées. Un quatrième profil correspond à l'activation d'un paramètre de 5 sécurité P4 incorporé dans l'entête d'authentification TOKEN du message à transmettre par le client. Le paramètre P4 indique au serveur qu'il doit signer les entêtes d'authentification des messages qu'il émettra en retour du message émis par le client. Ainsi, si les paramètres P3 et P4 sont activés par le client dans les 10 messages émis vers le serveur, le serveur chiffrera les données utiles et signera l'entête d'authentification TOKEN des messages émis à son tour vers le client en réponse au(x) message(s) reçu(s) de ce dernier. Le serveur peut donc indiquer à son tour la valeur des paramètres P1, P2, P3 et P4 pour informer le client de son mode de chiffrement des 15 données ainsi que la présence d'une signature. Cette configuration a l'avantage de permettre d'établir des communications dont la sécurité est entièrement autoportée entre deux entités communicantes. Lorsque le procédé est implémenté symétriquement dans le client 20 et le serveur, l'entête d'authentification de la réponse du serveur comprend donc également un profil de sécurité comprenant un paramétrage P1, P2, P3, P4. Dans ce cas, la signature est générée à partir de la clef privée du serveur KSpriv et le chiffrement des données utiles est effectuée avec la clef publique du client KApub. 25 Les différents profils de sécurité permettent d'adapter le niveau de sécurité des échanges de données entre les entités communicantes selon le contexte d'échanges de données ou du type de données à échanger. Selon un mode particulier de réalisation de l'invention, les profils de 30 sécurité PRO_SEC utilisent un cinquième paramètre de sécurité P5 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 d'authentification TOKEN du message ; 35 ^ des données utiles et ; 3043870 23 ^ de données du protocole transport tels que les entêtes du protocole transport, ou d'autres champs de données tels que le champ du type REQUEST_LINE du protocole http. Selon un autre mode de réalisation, les paramètres de sécurité P2 5 et P4 indiquent directement le format de signature appliqué. Le format d'une signature est défini par au moins l'une quelconque de ces données ou une combinaison de ces données : ^ L'algorithme de la fonction de hachage ; ^ L'algorithme de chiffrement ; to ^ Le type de clef ; ^ 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 et optionnellement des données relatives aux champs de données du protocole transport utilisé. 15 Lorsqu'une entité reçoit un profil de sécurité qu'elle ne connait 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é. Selon un autre mode de réalisation, l'étape d'enrôlement peut comprendre la transmission de la définition d'un profil de 20 sécurité soit dans l'entête d'authentification TOKEN de données, soit dans la charge utile des données transmises. A réception, une entité peut alors enregistrer la définition du nouveau profil de sécurité et l'utiliser pour déployer une stratégie de chiffrement des messages émis et de déchiffrement des messages reçus. 25 En outre, le profil de chiffrement comprend la désignation 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. 30 Le profil de sécurité comprend donc une indication sur la présence d'une signature et sur la présence d'un chiffrement des données et le cas échéant, le profil de sécurité comprend la désignation des algorithmes utilisés pour générer la signature ou chiffrer les données. 35 Signature 3043870 24 L'entête d'authentification TOKEN comprend également une signature des données transmises dans l'entête et/ou dans le corps de message. Une signature est créée au moyen d'un algorithme de génération d'une signature. La signature est réalisée au moyen d'une clef privée de l'entité 5 communicante signant. Si le client signe l'entête d'authentification d'un message émis, la signature est réalisée à partir de la clef KApriv, c'est à dire la clef privée de l'équipement. Selon un exemple de réalisation un algorithme basé sur une méthode RSA SHA256 peut être mise en oeuvre par l'invention pour générer la signature. Nous rappelons que l'acronyme SHA désigne dans 10 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. Selon un autre exemple de réalisation, l'algorithme ECDSA 15 désignant « Elliptic Curve Digital Signature Algorithm » peut ê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 être automatiquement déterminé en fonction de l'équipement du client ou de son 20 système d'exploitation. Un avantage est d'utiliser les ressources déjà existantes sur un équipement. Selon un mode de réalisation, lorsqu'un champ de l'entête d'authentification TOKEN comprend la signature générée, un autre champ peut être renseigné dans l'entête pour désigner l'algorithme permettant de 25 générer la signature et/ou l'algorithme de chiffrement des données utiles. A la réception, le serveur de données pourra décoder la signature grâce au choix du bon algorithme pour décoder la signature. La signature est générée à partir de données relatives notamment au client et à l'équipement. 30 Selon un exemple de réalisation, la signature est générée à partir des données : MES_ID, EQ_ID, USER_ID, PRO_SEC et du contenu du message. Selon un autre mode de réalisation, la signature est générée à partir des données utiles du message. Cela permet de générer une signature des 35 données d'authentification MES_ID, EQ_ID, USER_ID, du profil de sécurité 3043 870 25 PRO _SEC, et du contenu du message DATA. Les données lorsqu'elles sont signées peuvent correspondre aux données utiles chiffrées ou aux données utiles non chiffrées. 5 Selon un mode de réalisation, la signature peut prendre en compte des données d'un message du protocole de transport qui achemine les messages échangés telles que des données d'entête de protocole, de l'adresse du message du protocole ou encore d'un autre champ propre au protocole comme par exemple la ligne de requête du protocole http. 10 Le terme « entête de protocole » est utilisé pour le différencier de l'entête d'authentification de l'invention. 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 15 exemple la forme suivante : - Entête : POST http://control_center_url/rest/conso HTTP/1.0 Accept : application/json User-Agent : Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) 20 Authorization:JohnDo:Android22434:1430896533037_97:OneWaySignature_ RSA-SHA256_none: w9Bgirb8 - Corps de message (body) : {"P 1"=2345,"HCHC"=29384632,"HCH P"=2936241490} 25 Selon un mode de réalisation, une ou plusieurs données relatives aux données du protocole transport peuvent être utilisées. Une partie d'un champ d'un entête du protocole peut également être utilisée. Selon un exemple, le champ Method du protocole http précisant le type de requête dont notamment les valeurs {GET, PUT, POST}, présent dans la ligne de requête 30 d'une requête http a un intérêt pour a un intérêt pour signer l'entête d'authentification TOKEN. Cette prise en compte permet notamment d'éviter les attaques de type « rejeu » par un tiers en réalisant une autre action que la requête initiale. Selon un exemple de réalisation, une entête de message d'un 35 protocole applicatif de transport est définie par un couple {clé :valeur}. Par 3043870 26 exemple pour le protocole HTTP, l'entête [Expires: "Sat, 07 Nov 2015 00:59:59 GMT"] représente une 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 5 http://control_center_uri/rest/conso HTTP/1.1], et peuvent être utilisés pour générer la signature. Ce mode de réalisation est particulièrement avantageux pour assurer l'intégrité des échanges de données. Selon ce même exemple, lorsque les données sont signées avec le 10 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 type de requête différent ou/et avec une date d'expiration différente soit engagée par un tiers puisque dans ce cas la signature ne sera pas reconnue 15 par le serveur. La génération d'une signature comprend l'exécution d'une fonction de hachage des données à signer. Ainsi, si un tiers, non autorisé, récupère un message signé, il n'est pas possible de reconstituer les données qui ont été 20 signées à partir de la signature. La prise en compte de l'identifiant de message MES_ID, qui change à chaque message, dans la signature permet grâce à la fonction de hachage de générer un contenu de la signature totalement différent d'un message à l'autre. La génération d'une signature peut comprendre également une 25 fonction de padding, c'est-à-dire une fonction de remplissage des données. La signature est enfin générée à partir de la clef privée du client KApriv. Les entités communicantes de l'invention comprennent des 30 moyens pour générer un couple de clefs asymétriques KApriv, KApub, la clef privée KApriv permettant de générer une signature d'une entête d'authentification d'un message émis par une entité communicante par l'exécution d'une fonction de hachage et d'une fonction de fonction de remplissage des données. 35 3043870 27 Chiffrement des données Lorsque l'option du chiffrement des données d'un message émis par le client est activée, le profil de chiffrement défini quel algorithme est utilisé pour chiffrer les données. Le profil de chiffrement est indiqué dans l'entête 5 d'authentification TOKEN du message et permet d'indiquer la désignation de l'algorithme de chiffrement. Cette désignation peut être codée dans le même champ que la désignation de l'algorithme de la génération d'une signature. Les données du message qui sont transmises au serveur, sont chiffrées avec l'algorithme déterminé par le client. Les données peuvent ensuite être to déchiffrées, coté serveur, grâce à l'indication de l'algorithme utilisé. L'algorithme de chiffrement des données peut être automatiquement déterminé en fonction de l'équipement du client ou de son système d'exploitation. Un avantage est d'utiliser les ressources déjà existantes sur un équipement. 15 Un exemple d'algorithme selon l'invention peut être AES désignant « 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. 20 Selon un mode de réalisation, les données utiles sont chiffrées à partir la clef publique du serveur KSpub, c'est-à-dire avec la clef publique d'une seconde entité communicante KSpub dans le cas général où le serveur est une seconde entité communicante. Selon un autre mode de réalisation, les données sont chiffrées 25 grâce à une clef symétrique et la clef symétrique est elle-même chiffrée par une clef asymétrique, telle que la clef publique du serveur KSpub. Ce mode de réalisation présente l'avantage d'optimiser les opérations de chiffrement sur des volumes de données plus petits, notamment relatifs à la taille d'une clef symétrique au lieu d'une taille de champ relative à un contenu de données. 30 Les profils de sécurité peuvent alors se transposer à ce cas de figure dans lequel il est précisé si un message comporte un entête signé et un contenu chiffré dans un sens et dans le sens retour. Un « contenu chiffré » signifie alors dans ce cas qu'il l'a été avec une clef symétrique et que la clef symétrique a été chiffrée avec une clef asymétrique. 35 3043870 28 Avantages de la transmission de champs dans l'entête Le champ MES_ID permet de définir une sécurité contre les attaques par rejeu de messages tiers. Le champ EQ_ID permet de définir une sécurité lorsqu'un 5 équipement a été suspendu ou révoqué par le serveur SERV. Le champ USER_ID permet de définir une sécurité lorsqu'un compte utilisateur a été suspendu ou révoqué par le serveur SERV. Selon un mode de réalisation de l'invention, lorsqu'une procédure de suspension ou de révocation d'un utilisateur a été engagée par le serveur, 10 l'ensemble des équipements associé à cet utilisateur est également suspendu ou révoqué. La figure 3 représente les principales étapes du procédé de communication de l'invention du point de vue d'une entité communicante qui 15 génère un message MES. L'étape de génération du TOKEN est notée GEN TOKEN. Elle comprend les sous-étapes de génération d'un identifiant de message GEN MES ID et d'insertion INSERT MES ID de cet identifiant dans l'entête d'authentification TOKEN. 20 La génération du TOKEN comprend, en outre, l'insertion d'un identifiant d'équipement INSERT_ED_ID et l'insertion d'un identifiant d'utilisateur INSERT USER_ID. Ces étapes permettent de générer un entête d'authentification selon le procédé de communication de l'invention. 25 Lorsque le TOKEN est signé SIGN_TOKEN, il peut l'être à partir de la clef privée du client KApriv. Lorsqu'un chiffrement est effectué CRYP_DATA, il peut l'être à partir de la clef publique KSpub du serveur. Le message comportant l'entête d'authentification et les données 30 utiles peut alors être généré GEN_MES selon le protocole utilisé pour émettre des données entre le client et le serveur, comme par exemple un protocole HTTP. Selon une variante de réalisation, comme cela est représenté en 35 pointillé sur la figure 3, une clef symétrique Ksym peut être utilisée pour chiffrer 3043870 29 les données utiles lors de l'exécution de l'étape CRYP_DATA. Dans ce mode de réalisation, la clef symétrique peut être elle-même chiffrée à partir de la clef publique du serveur KSpub et être insérée par exemple dans l'entête d'authentification TOKEN lors de l'étape INSERT_Ksym. 5 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 données avec une pluralité de clients. Il comprend à cet effet un composant io permettant de gérer les équipements, il est noté EQ_MG sur la figure 1. Ce composant permet de stocker les données de chiffrement des équipements clients dans une mémoire notée K_PUB qui stocke les clefs publiques des équipements KApub. Ce composant comprend une fonction MG qui est configurée pour stocker les comptes clients et une fonction ENROL_S qui 15 permet de recevoir et de traiter une requête d'enrôlement d'un équipement. Le traitement d'une requête comprend des opérations de déchiffrement des données et des opérations de vérifications visant à vérifier que l'équipement, l'utilisateur ou le message reçus ne sont pas suspendus ou révoqués ou que les comptes clients existent déjà bien. 20 La fonction MG permet, en outre, de révoquer ou de suspendre des équipements ou des utilisateurs. Cette action peut être automatiquement engagée à la demande d'un client ou à la demande d'un administrateur du serveur. 25 Serveur - réception d'un message, déchiffrement Le message émis par l'équipement est reçu par le serveur via une interface de communication. Un composant du serveur réalise une étape de vérification du message reçu. Le serveur comprend un jeu de clefs asymétrique comprenant une 30 clef publique KSpub et une clef privée KSpriv. Le message reçu par le serveur a été chiffré avec la clef publique du serveur KSpub par le client. Cette clef publique du serveur KSpub a été préalablement acquise par un utilisateur, par exemple, au moyen de l'équipement EQA. 35 Serveur - vérification de l'identifiant de message 3043870 30 La vérification du message comprend le contrôle de l'identifiant du message : MES_ID. Le contrôle des données MES_ID comprend la vérification de la date de génération du message avec une heure locale du serveur. La date de génération du message peut être calculée à partir de s l'identifiant de message MES_ID par un calculateur et un algorithme de décodage approprié. Lorsqu'un écart entre la date décodée dans le MES_ID et la date locale du serveur dépasse un seuil prédéfini, le serveur peut engager un refus du message reçu. Lorsque l'écart de date est inférieur à un seuil de date prédéfini, le serveur peut traiter le message en réception. 10 Selon un mode de réalisation, dans le cas d'un écart de date trop important, le serveur renvoie une erreur spécifique contenant la date courante du serveur. Cette variante permet que le client puisse se resynchroniser et réémettre un nouveau TOKEN valide. La vérification du MES_ID par le serveur permet de limiter les 15 attaques réseau par rejeu de message sur une période plus longue que la période de temps pendant laquelle un message est validé suite à l'analyse de la valeur des données du MES_ID. Une seconde vérification effectuée par le serveur consiste à vérifier si le message a déjà été reçu par ce dernier. Si le message a déjà été reçu, 20 c'est-à-dire que le MES_ID du message reçu est identique à un MES_ID d'un message précédemment reçu alors le message n'est pas traité par le serveur. Serveur - vérification de l'authentification, de la clef publique client KApub 25 Lorsque le MES_ID d'un message reçu par le serveur n'est pas rejeté, alors le serveur procède à une étape de vérification de l'authentification du message. Selon les modes de réalisation, le serveur peut vérifier alternativement les données d'authentification avant l'identifiant MES ID. _ On rappelle que l'utilisateur a préalablement défini un compte 30 utilisateur comprenant un identifiant utilisateur et un mot de passe associé. Le serveur SERV a stocké les données de ce compte utilisateur dans une mémoire. Le serveur exécute une recherche de la clef publique de l'équipement KApub dans sa base de données. La clef publique de 3043870 31 l'équipement KApub a été associée au client dont la référence USER_ID est connue puisqu'elle a été stockée suite à l'enregistrement du compte client. La clef publique de l'équipement KApub qui est contenu dans message transmis est alors comparée à la clef publique de l'équipement 5 stocké dans la mémoire du serveur. Lorsqu'il y a correspondance des clefs publiques de l'équipement entre d'une part celle transmise dans le message et d'autre part celle stockée dans le serveur, une validation peut être effectuée du message reçu. Selon un 10 mode de réalisation, la clef publique de l'équipement stockée dans le serveur peut être utilisée pour vérifier que la signature est correctement authentifiée, alors le message peut être traité par le serveur. Si la clef publique du client KApub a été révoquée ou suspendue ou encore si elle n'est pas connue par le serveur, alors le message n'est pas 15 traité par le serveur. Selon un mode de réalisation, lorsque la signature est invalide, le message est rejeté par le serveur. Un avantage de cette solution est que le serveur ne stocke que des informations publiques des clients, c'est-à-dire les clefs publiques des clients KApub. Les clefs privées des clients ne sont pas stockées par le serveur. En 20 conséquence, un tiers accédant à la base de données du serveur ne peut récupérer les clefs privées des clients sans l'autorisation des clients. Vérification de la signature Lorsque les messages transmis sont signés, la clef publique de l'équipement KApub connue par le serveur SERV peut également être utilisée 25 pour vérifier la signature comprise dans le message qui a été réalisée à partir de la clef privée du client KApriv. La signature peut être vérifiée puisque le serveur a reçu les données d'authentification : USER_ID, EQ_ID, l'identifiant de message MES_ID, le profil de sécurité PRO_SEC qui comprend le format de la signature le cas échéant, et le contenu du message DATA. Ces données 30 peuvent être utilisées pour vérifier que le message a correctement été signé. Déchiffrement du message après vérifications Lorsque l'identifiant de message MES_ID et que l'authentification du message ont été vérifiés par le serveur SERV, ce dernier traite le champ 35 indiquant le profil de sécurité qui a été choisi par le client. Lorsque ce profil 3043870 32 indique que le compte du message est chiffré, alors le serveur engage le déchiffrement des données utiles du message grâce à la clef publique de l'équipement KApub. Les données sont déchiffrées et stockées dans une mémoire ou émises vers une application traitant les données. 5 Traitement du message après vérifications Les données utiles, une fois décodées par le serveur, sont transmises à un composant APP traitant fonctionnellement le message reçu. Ce composant permet d'interpréter et de gérer le message au niveau d'une 10 couche applicative. Réciproquement, coté client, le composant APP permet de traiter le contenu des messages provenant du serveur lorsque ces derniers ont été validés et déchiffrés par le composant SEC_SW_C. Avantages 15 La méthode de l'invention permet d'établir une communication de manière sécurisée sous forme de questions/réponses entre un client et un serveur sans avoir à gérer les états d'une communication, c'est-à-dire des sessions entre les entités communicantes. Ainsi, l'invention permet de s'affranchir d'un protocole préliminaire entre deux entités d'un réseau ou d'une 20 liaison visant à préparer les conditions d'une communication sécurisée. Les moyens d'une communication sécurisée échangeant des données sous forme de questions / réponses peuvent être implémentés en respectant les principes d'une architecture de type REST. L'invention permet donc de s'affranchir d'échanges de données 25 telles que des certificats ou des PKI tout en permettant une sécurisation des échanges. L'invention s'affranchit donc d'une mise en oeuvre d'une infrastructure PKI impliquant la gestion de certificat d'authentification. Un autre avantage de l'invention est d'induire qu'un faible coût de déploiement étant donné que la communication sécurisée peut être établie entre deux entités se 30 découvrant pour la première fois. La solution de l'invention permet de suspendre ou de révoquer un équipement par le serveur. Identiquement, le serveur peut révoquer ou suspendre un compte utilisateur. 3043870 33 Un autre avantage de l'invention est que le piratage de la base de données du serveur ne permettra pas à un tiers d'obtenir des clefs privées des équipements puisqu'il ne stocke que des informations publiques. Un autre avantage de l'invention est de permettre de durcir s l'association entre un équipement et un utilisateur. En effet, le procédé de l'invention permet d'associer dans les échanges, entre les entités communicantes, l'identifiant utilisateur USER_ID et l'identifiant d'un équipement EQ_ID. L'équipement possède un identifiant et un jeu de clefs asymétriques et l'utilisateur possède un compte utilisateur comprenant au 10 moins un mot de passe et un identifiant, en conséquence le piratage d'un couple de données ne permet pas d'accéder au serveur sans l'autre couple de données. REVENDICATIONS1. Procédé de communication entre deux entités communicantes, une première entité communicante générant un message de données comprenant des données utiles et un entête d'authentification (TOKEN), ledit procédé comportant : ^ une génération d'un identifiant de message (MES_ID) à partir d'un paramètre donné et d'une date et une insertion de to l'identifiant dans un entête d'authentification (TOKEN) ; ^ une insertion d'une pluralité de données d'authentification comprenant au moins un identifiant utilisateur (USER_ID) et un identifiant d'équipement (EQ_ID) dans l'entête d'authentification (TOKEN) ; 15 ^ une détermination et une insertion d'un profil de sécurité (PRO_SEC) dans l'entête d'authentification (TOKEN) définissant les conditions : o de chiffrement des données utiles d'au moins l'émission du message par la première entité communicante ; 20 o de génération d'une signature de données du message et du format de ladite signature générée ; ^ une insertion des données utiles dans le message à transmettre. 2. Procédé de communication selon la revendication 1, l'ensemble de 25 données à signer comprend une combinaison des données suivantes : ^ L'identifiant de message (MES_ID) ; ^ L'identifiant utilisateur (USER_EQ) ; ^ Un mot de passe d'un compte utilisateur (MDP_ID) ; ^ L'identifiant de l'équipement (EQ_ID) ; 30 ^ Le profil de sécurité (PRO_SEC) ; ^ Une information d'entêtes ou d'un champ de données de message représentative du protocole de transfert des données utiles ^ Les données utiles (DATA). 35 3043870 35 3. Procédé de communication selon la revendication 1, la première entité communicante (CLIENT) comprenant une mémoire pour stocker une clef publique (KSpub) d'une seconde entité communicante (SERVEUR), caractérisé en ce que le profil de sécurité (PRO_SEC) 5 comprend : ^ un premier paramètre (P1) indiquant la présence ou non d'un chiffrement des données utiles (DATA) effectué à partir de la clef publique (KSpub) de la seconde entité communicante (SERVEUR) et ; ^ un second paramètre (P2) indiquant la présence ou non d'une signature d'un ensemble de données à signer. 4. Procédé de communication selon la revendication 1, la première entité communicante (CLIENT) comprenant une mémoire pour stocker une clef publique (KSpub) d'une seconde entité communicante (SERVEUR), caractérisé en ce que le profil de sécurité (PRO_SEC) comprend : ^ un premier paramètre (P1) indiquant la présence ou non d'un chiffrement des données utiles (DATA) effectué à partir d'une clef symétrique et le cas échéant de la présence d'un chiffrement de la clef symétrique à partir de la clef publique (KSpub) de la seconde entité communicante (SERVEUR) et ; ^ un second paramètre (P2) indiquant la présence ou non d'une signature d'un ensemble de données à signer. 5. Procédé de communication selon l'une quelconque des revendications 3 à 4, caractérisé en ce que le profil de sécurité (PRO_SEC) comprend : ^ Un troisième paramètre (P3) indiquant la présence ou non d'un chiffrement effectué à partir de la clef publique (KApub) de la première entité communicante (CLIENT) soit des données utiles soit d'une clef symétrique et ; ^ Un quatrième paramètre (P4) indiquant la présence ou non d'une signature d'un ensemble de données à signer, 3043870 36 d'au moins un message devant être émis par une seconde entité communicante (SERVEUR) en réponse à un message reçu de la première entité communicante (CLIENT). s 6. Procédé de communication selon l'une quelconque des revendications 1 à 5, caractérisé en ce que la seconde entité communicante (SERV) à réception d'un message de la première entité communicante (CLIENT) décode l'entête d'authentification (TOKEN) de manière à : - contrôler l'identifiant de message (MES_ID) pour déterminer si io le message a été émis dans un laps de temps prédéfini ; - contrôler l'identifiant de l'utilisateur (USER_ID) et l'identifiant de l'équipement (EQ_ID) en comparant la valeur de ces paramètres avec des données stockées dans une mémoire de la seconde entité communicante (SERV) pour déterminer si l'équipement ou 15 l'utilisateur a été suspendu ou révoqué ; - contrôler le paramètre de chiffrement (P1, P3) du profil de sécurité (PRO_SEC) du message reçu pour déchiffrer le cas échéant les données utiles avec la clef privée de la seconde entité communicante (SERV) ; 20 - contrôler, le cas échéant, le paramètre de signature (P2, P4) du profil de sécurité (PRO_SEC) du message reçu pour vérifier le cas échéant la signature au moyen de la clef publique (KApub) de la première entité communicante (CLIENT). 25 7. Procédé de communication selon la revendication 6, caractérisé en ce que le serveur comprend des moyens d'accès à la mémoire stockant les données correspondantes aux identifiants clients (USER_ID) et aux identifiants d'équipements (EQ_ID) de manière à révoquer ou suspendre un ou plusieurs équipement(s) ou client(s). 30 8. Procédé de génération d'une requête d'enrôlement (REQ_E) par une première entité communicante (CLIENT) à destination d'une seconde entité communicante (SERV), caractérisé en ce qu'il comprend : - Une activation de la procédure d'enrôlement (M1_ENROL_C); 3043870 37 ^ Une génération d'une requête d'enrôlement (REQ_E) comportant un identifiant d'un équipement (EQ_ID), un identifiant de l'utilisateur (USER ID), un mot de passe de l'utilisateur (USER_MDP) et une clef publique (KApub) de la 5 première entité communicante (CLIENT) ; ^ Un chiffrement de la requête avec une clef publique (KSpub) de la seconde entité communicante (SERV) et une émission de la requête d'enrôlement (REQ_E) au moyen d'une interface de communication à destination de la seconde entité communicante to (SERV). 9. Procédé de génération d'une requête d'enrôlement (REQ_E) par une première entité communicante (CLIENT) selon la revendication 8, caractérisé en ce qu'il comprend préalablement : 15 ^ Une création d'un compte utilisateur comprenant un identifiant (USER_ID) et un mot de passe (USER_MDP) ; ^ L'enregistrement des données dudit compte utilisateur dans une mémoire de la seconde entité communicante (SERV) ; ^ Une acquisition (ACQ_KSpub) d'une clef publique (KSpub) de la 20 seconde entité communicante (SERV) pour lequel la procédure d'enrôlement est engagée depuis la première entité communicante (CLIENT) ; ^ Une génération d'un couple de clefs asymétriques (KApub, KApriv) de la première entité communicante (CLIENT). 25 10. Procédé d'enrôlement (ENROL), caractérisé en ce que la seconde entité communicante (SERV) comprend : ^ Une réception d'une requête d'enrôle générée par un procédé de génération d'une requête d'enrôlement (REQ_E) selon l'une 30 des revendications 8 à 9 ; ^ Un déchiffrement des données de la requête d'enrôlement (REQ_E) au moyen d'une clef privée (KSpriv) de la seconde entité communicante (SERV) ; ^ Une comparaison entre l'identifiant utilisateur (USER_ID) reçu et le mot de passe utilisateur (USER_MDP) reçu avec des données 3043870 38 de comptes clients stockés dans une mémoire de la seconde entité communicante (SERV) ; ^ Un enregistrement de l'identifiant de l'équipement (EQ_ID) dans une mémoire de la seconde entité communicante (SERV) ; 5 ^ Un enregistrement de la clef publique (KApub) de la première entité communicante (CLIENT) associée à l'identifiant de l'équipement (EQ_ID) dans une mémoire de la seconde entité communicante (SERV). to 11. Procédé d'enrôlement (ENROL) selon la revendication 10, caractérisé en ce que la seconde entité communicante (SERV) comprend : ^ un contrôle d'une date actuelle avec une date référence ; ^ une génération d'un message à destination de la première entité communicante (CLIENT) comprenant un code spécifique 15 indiquant qu'un couple de clefs asymétriques doit être renouvelé ; ^ une réception d'une nouvelle requête d'enrôlement générée par la première entité communicante selon le procédé de l'une des revendications 8 à 9. 20 12. Procédé de communication selon l'une des revendications 1 à 7, caractérisé en ce qu'elle comprend préalablement l'exécution d'un procédé d'enrôlement (ENROL) selon l'une des revendications 8 à 11. 25 13. Entité communicante caractérisée en ce qu'elle comprend au moins une mémoire, un calculateur et une interface de communication pour l'exécution du procédé de communication selon l'une quelconque des revendications 1 à 7 et/ou du procédé d'enrôlement selon l'une quelconque des revendications 8 à 11. 30 14. 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 à 7. 35