FR3066666A1 - Procede de securisation d'une communication sans gestion d'etats - Google Patents

Procede de securisation d'une communication sans gestion d'etats Download PDF

Info

Publication number
FR3066666A1
FR3066666A1 FR1754413A FR1754413A FR3066666A1 FR 3066666 A1 FR3066666 A1 FR 3066666A1 FR 1754413 A FR1754413 A FR 1754413A FR 1754413 A FR1754413 A FR 1754413A FR 3066666 A1 FR3066666 A1 FR 3066666A1
Authority
FR
France
Prior art keywords
entity
message
data
communication method
generation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1754413A
Other languages
English (en)
Other versions
FR3066666B1 (fr
Inventor
Paul-Emmanuel BRUN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Airbus Cybersecurity SAS
Original Assignee
Cassidian Cybersecurity SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cassidian Cybersecurity SAS filed Critical Cassidian Cybersecurity SAS
Priority to FR1754413A priority Critical patent/FR3066666B1/fr
Priority to EP18723562.7A priority patent/EP3625928A1/fr
Priority to CN201880042967.2A priority patent/CN111164933A/zh
Priority to US16/614,535 priority patent/US11303453B2/en
Priority to PCT/EP2018/062974 priority patent/WO2018211026A1/fr
Publication of FR3066666A1 publication Critical patent/FR3066666A1/fr
Application granted granted Critical
Publication of FR3066666B1 publication Critical patent/FR3066666B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16YINFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y10/00Economic sectors
    • G16Y10/75Information technology; Communication
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16YINFORMATION AND COMMUNICATION TECHNOLOGY SPECIALLY ADAPTED FOR THE INTERNET OF THINGS [IoT]
    • G16Y30/00IoT infrastructure
    • G16Y30/10Security thereof
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0822Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using key encryption key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085Secret sharing or secret splitting, e.g. threshold schemes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03Protecting confidentiality, e.g. by encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041Key generation or derivation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • H04W12/069Authentication using certificates or pre-shared keys
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • H04W12/106Packet or message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30Security of mobile devices; Security of mobile applications
    • H04W12/35Protecting application or service provisioning, e.g. securing SIM application provisioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/72Signcrypting, i.e. digital signing and encrypting simultaneously
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/045Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply hybrid encryption, i.e. combination of symmetric and asymmetric encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60Context-dependent security
    • H04W12/69Identity-dependent
    • H04W12/71Hardware identity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W4/00Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Abstract

Procédé de communication entre au moins deux entités communicantes (C1, S1), une première entité communicante (C1) générant au moins un message de données comprenant des données utiles (Datai) et un entête d'authentification (Token1), ledit procédé étant caractérisé en ce qu'il comporte : ▪ 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) dans l'entête d'authentification (Token1) définissant les conditions : ○ de chiffrement des données utiles (Data1) du message ; ○ de génération d'une signature (Sign1) par un algorithme (Signing_Module1) appliqué au moins aux données utiles (Data1) du message ; ▪ une inclusion de ladite signature (Sign1) dans le message généré ; ▪ une insertion d'un identifiant mémorisé (C1 _Id) de la première entité communicante (C1) dans l'entête d'authentification (Token1) ; ▪ une insertion du profil de sécurité (PRO_SEC) dans les données utiles ou dans l'entête d'authentification.

Description

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.
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 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é.
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 é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 même destinés à fournir des informations en temps réel. II 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, 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. 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 un équipement de commande ou un serveur et d'autre part un ou plusieurs objets connectés, le procédé sécurisant par ailleurs le fonctionnement en luimême des entités distantes.
RESUME DE L’INVENTION
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 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é;
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;
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 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 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 :
Un identifiant d'un calculateur de la première entité;
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é
J
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, 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é.
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 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é.
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 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.
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.
Selon une particularité, les données utiles comprennent des données collectées par au moins un capteur de la première entité communicante.
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.
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 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 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é ;
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:
Une génération d'une nouvelle clef secrète symétrique à partir d'un module de génération de clef symétrique ;
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 à 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 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 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 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.
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.
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é.
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 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 œuvre du procédé de communication de l’invention.
Avantageusement encore le procédé sécurisé de communication apporte une solution qui :
permet de choisir des dispositifs peu coûteux notamment du fait de leur capacités réduites en termes de charge de calculs pour l’objet connecté ;
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é ;
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.
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 :
figure 1 : un schéma général d’une architecture réseau comportant un serveur et une pluralité de clients mettant en œuvre un procédé selon l’invention ;
figures 2: un exemple d’architecture d’un serveur et d’un client mettant en œuvre un procédé de l’invention ;
figures 3A à 3B: des fonctions mises en œuvre dans un procédé selon l’invention ;
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.
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 respectivement un client et un serveur. Le client C1 est par exemple un objet connecté et le serveur S1 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 C1, l'entité communicante C1 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 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 S1 qui reçoit les données utiles. La seconde entité 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 S1 peut notamment transmettre des commandes à la première entité communicante Ci afin de commander une 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.
Dans la suite de la description un message mes1 visant à transmettre des données utiles Datai comporte deux parties : une entête d'authentification Tokenl et un champ utile comportant des données utiles Datai. Le message de données utiles peut comprendre, outre des données 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.
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 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 boîtier 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.
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 C1 comprend par exemple un 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 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é C1 comprend donc un identifiant noté C1_ld. Un tel équipement client est indifféremment noté C1, C2, Ci, ie[1 ;NJ.
Entité Centrale
L’entité centrale qui correspond à la seconde entité est par exemple l’entité Serveur. Un serveur S1 comprend par exemple à minima une mémoire et un calculateur ainsi qu'une interface de communication. La seconde entité S1 est par exemple un ordinateur ou une station de travail connectée à un 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 entités.
La première entité S1 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é S1 stocke par exemple dans une base de données BDS1 des données relatives à d'une pluralité de première entités tels que des objets connectés.
La première entité S1 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é S1 comporte par exemple en mémoire des clefs cryptographiques reçus d'une première entité communicante telle que C1, à savoir au moins une clef privé symétrique KSec et une clef publique asymétrique KPub2.
La première entité S1 comporte par exemple en mémoire une clef privée asymétrique Kprivl et une clé publique asymétrique Kpubl. Ces clefs peuvent être générées par exemple par un module de génération de clef privé asymétrique ASymKGenl.
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 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.
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.
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 des données relatives à une pluralité de premières entités communicantes. Les différentes premières entités C1 à 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 une fonction de lecture d’un identifiant (IdCol) d'un calculateur (Co1) 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 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 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 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 Internet, un réseau local câblé, un réseau mobile ou un réseau local radio tel que WiFi.
Gestion de clefs symétriques
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 C1 etS1.
La clé secrète symétrique est générée, dans la première entité C1, 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é C1 et la seconde entité S1 afin que ces deux entités disposent toutes deux d'un secret partagé.
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 Signl et pour chiffrer les données utiles Datai. Les ressources nécessaires au cryptage par clé secrète partagée sont 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 Signl 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 périodiquement par la première entité C1 et transmises périodiquement à la seconde entitéSI.
Une même clé secrète symétrique partagée est ainsi stockée dans une mémoire respectivement de la première entité C1 et de la seconde entité S1.
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é C1 ou par la seconde entité centrale S1. L’utilisation des clés publiques et privées 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 privée asymétrique KPriv2 ou KPrivI est par exemple stockée dans une 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é S1 comprend notamment un générateur de clé asymétrique ASymKGenl et mémorise une clé privée asymétrique générée KPrivI.
La première entité C1 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 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.
Paramètre de contexte
Selon le procédé de l'invention un paramètre de contexte ContextPI est transmis par la première entité C1 à la seconde entité S1.
Le paramètre de contexte ContextPI est généré par un module de génération du paramètre de contexte référencé ContexPGen sur la figure 2.
Le paramètre de contexte ContextPI comprend au moins une donnée représentative de la configuration matérielle de la première entité C1.
Le paramètre de contexte ContextPI comprend, par exemple, une ou plusieurs des données parmi les suivantes :
Un identifiant IdCol d'un calculateur Co1 de la première entité C1 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é C1 ;
Une date de mise à jour DM_Co1 d'un micrologiciel CtrIProg de la première entité C1 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é.
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 l’espace supplémentaire occupé.
Un avantage de l'utilisation d'un paramètre de contexte ContextPI 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 message de données utiles.
Un avantage de l'utilisation d'un paramètre de contexte ContextPI 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 entité.
Ce paramètre de contexte ContextPI 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 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 ContextPI à partir de la clef publique asymétrique KPubl de la seconde entité pour être déchiffrée à réception par la seconde entité S1 en utilisant sa clef privée asymétrique KPrivI.
Procédé de génération d’une requête d’enrôlement
Le procédé de l'invention peut comprendre des étapes 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 C1 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 à la clé secrète partagée.
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é C1 procède à un enrôlement auprès de la seconde entité
S1, en générant une requête notée MesEnrl. Cette requête comprend par exemple l’identifiant C1_ld et le paramètre de contexte ContextPI 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 une clef asymétrique.
Les identifiants de chaque première entité tel que C1 en association avec leur paramètre de contexte sont par exemple enregistrés dans une base de données de la seconde entité S1.
La seconde entité S1 est alors capable d'associer une première entité C1 avec son paramètre de contexte ContextPI.
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 MesEnr de l'une ou l'autre des entités C1, S1.
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 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.
Selon un mode de réalisation de l'invention, le procédé de génération d'une requête d'enrôlement MesEnrl par le client C1 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. 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 peut viser à extraire la clef publique du client C1 d'une mémoire dudit client Clpour l'inclure dans la requête.
La requête d'enrôlement peut ainsi comprendre les données suivantes:
- le paramètre de contexte, ContextPI ;
- l'identifiant du client, C1 Jd ;
- la clef publique asymétrique du client, KPub2.
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.
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.
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 ContextPI et de l'identifiant du client C1_ld 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 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 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 communicantes, ces messages sont notés Mes1 et comprennent les données 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 Tokenl.
Le procédé de l'invention permet d'échanger des communications 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 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 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.
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 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 chaque équipement C1, S1, comme par exemple l'échange des clefs publiques et des identifiants d'équipement.
L'entête d'authentification Tokenl est généré par un composant du client C1. Côté serveur, un composant vérifie l'entête d'authentification reçu du client C1.
L'entête d'authentification Tokenl des messages Mes1 transmis comprend différents champs de données dont l'identifiant du client C1_ld.
Le Tokenl peut comprendre une identification Mesjd du message Mes1, et éventuellement un profil de sécurité PRO_SEC qui permet de définir 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 Sign 1.
L'entête d'authentification Tokenl peut être, par exemple, intégré aux entêtes du protocole transport utilisé selon les communications 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é à 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 coding_Module1 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.
Identifiant de message, Mesjd
Le calculateur peut récupérer un identifiant de message Mesjd 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 MesJDI permettant de générer et traiter des identifiants de messages Mesjd.
Le compteur de message génère par exemple le Mesjd à partir d'un aléa, c'est-à-dire d'un paramètre aléatoire RamdomPI et d'une date d’expiration Stampl. L'aléa RamdomPI permet de définir un identifiant unique
Mesjd du message. L'état aléatoire RamdomPI peut être par exemple généré à partir d'un module de génération d'un aléa noté Ramdom_Module1.
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 Clock_Module1 locale de l'équipement C1, l'identifiant Mesjd comprend une information relative à la date d’expiration Stampl du message Mes1 qui pourra être vérifiée à la réception par le serveur S1.
Selon une alternative de réalisation, le Mesjd peut être généré avec un paramètre non aléatoire et une date d’expiration Stampl. L'identifiant de message MesJDI peut être, par exemple, calculé à la volée, c'est-à-dire en temps réel par un calculateur de l'entité communicante C1. L'identifiant du message Mes ID1 ainsi calculé est attribué à un message Mes1.
Profil de sécurité
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 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 et définir si la réponse au message Mes1 émise par le serveur S1 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 C1.
Les différentes entités communicantes C1, S1, telles qu'un serveur S1 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 d'un paramètre de sécurité P1 incorporé dans l'entête d'authentification
Tokenl du message Mes1 à transmettre par le client C1 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 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 Tokenl du message Mes1 à transmettre par le client C1. Le paramètre P2 permet d'indiquer que l'entête d'authentification Tokenl est signé. La signature Signl est dans ce cas effectuée par le client C1 grâce à la clef privée du client KPrivI. La signature Signl est notamment incorporée dans l'entête d'authentification Tokenl.
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 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.
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 d'authentification Tokenl 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 combinaison de ces données :
L'algorithme d'une fonction de hachage ;
L'algorithme de chiffrement ;
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.
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 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 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 Signl et sur la présence d'un chiffrement des 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
Selon un mode de réalisation, l'entête d'authentification Tokenl comprend également une signature des données transmises dans l'entête tokenl. Une signature Signl est créée au moyen d'un algorithme de génération d'une signature Signing_Module1.
La signature Signl est par exemple réalisée au moyen d'une clef publique KPub2 acquise par l'entité communicante signant C1 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.
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.
La signature Signl peut par exemple être générée à partir des données: Mes_ID1, C1 Jd, PRO_SEC et du contenu du message Datai.
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 Signl. Nous rappelons que l'acronyme SHA désigne dans la terminologie anglosaxonne : « 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.
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 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 Tokenl comprend la signature Signl générée et un autre champ peut être renseigné dans l'entête Tokenl pour désigner l'algorithme permettant de générer la signature Signl. Un autre champ désigne également l'algorithme de chiffrement des données utiles Datai.
A la réception, le serveur S1 de données pourra décoder la signature Signl grâce au choix du bon algorithme tel qu’indiqué pour décoder la signature Signl.
Le terme « entête de protocole >> est utilisé pour le différencier de l'entête d'authentification Tokenl 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 exemple la fomle suivante :
• Entête:
POST http://control_center_urllrest/conso HTTP/1.0
Accept : application/jsonUser-Agent: Mozil/a/4.0 (compatible; MSIE 5.0; Windows 95) Authori:zation:JohnDo:Android22434:143089653303797:0neWa Signature_ 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 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, P0$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 Tokenl. 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.
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 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 http:/lcontrol_center_uri/rest/conso HTTP/1.1], et peuvent être utilisés pour générer la signature Sign 1.
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 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 Signl ne sera pas reconnue par le serveur S1.
On préfère toutefois une mise en œuvre du procédé de communication sécurisé de façon indépendante du protocole de communication.
La génération d'une signature Signl 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 pour ce tiers de reconstituer les données qui ont été signées à partir de la signature Signl.
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 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.
La génération d'une signature Signl 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.
Chiffrement des données
Lorsque l'option du chiffrement des données d'un message émis par le client C1 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 d'authentification Tokenl 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 S1, sont chiffrées avec l'algorithme déterminé par le client C1. Les 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 automatiquement déterminé, parmi une liste d’algorithmes disponibles, en fonction de l'équipement du client C1 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 « 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 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 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.
Lorsque le client C1 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 C1 a été décidé, alors un mécanisme impliquant la transmission du profile de sécurité peut également être mis en place.
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 C1_ld permet de définir une sécurité lorsqu'un équipement a été suspendu ou révoqué par le serveur S1.
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.
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 Tokenl et des données utiles Datai.
Une première étape, notée GEN(ContextPI), consiste par exemple en la génération du paramètre de contexte ContextPI. 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é PortCI du client C1. Le port Portl fait transiter les données émises par C1 sur le réseau Net1 notamment à destination du serveur S1 via le port PortS 1.
Selon d’autres exemples de réalisation, d'autres configurations matérielles peuvent être générées dans le paramètre de contexte ContextPI. Par exemple, il peut s'agir d'une date de mise à jour d'un « Firmware >> CtrIProg, c'est-à-dire d'un logiciel d'exploitation matériel d'un ou plusieurs composants de l’équipement. App_C1 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 ContextPI 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 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 ContextPI.
Le paramètre de contexte ContextPI 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 de sécurité PRO_SEC généré est intégré dans l'entête d'authentification tokenl.
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 de l'identifiant du client C1_ld, notée INS(C1_ld) dans le message Mes1. L'identifiant C1 Jd 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.
Le message Mes1 comportant l'entête d'authentification Tokenl et les données utiles Datai 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 C1 et le serveur S1.
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 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 Cijd et les paramètres de contexte ContextPI.
En outre, le serveur S1 peut comprendre une mémoire pour stocker 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 C1, ainsi que les clefs symétriques KSec sécrètes partagées.
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 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 l’équipement.
Serveur - réception d’un message, déchiffrement
Le message Mes1 émis par l'équipement client C1 est reçu par le Serveur S1 via une interface de communication. Un composant du serveur S1 réalise par exemple une étape de vérification du message reçu Mes1 et notamment sa date d’expiration.
Le serveur S1 comprend notamment un jeu de clefs asymétriques comprenant une clef publique KPubl et une clef privée KPrivI pour les besoins de déchiffrement, en fonction des paramètres du profile de sécurité.
Le message Mes1, reçu par le serveur S1, 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 paramétrer un client ou le serveur.
Une vérification de l'entête d'authentification Tokenl peut être réalisée grâce à un module de vérification notée Token_ChK1.
Serveur - vérification de l’identifiant de message
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 S1 peut engager un refus du message reçu Mes1.
Dans le cas d'un écart de date trop important, le serveur S1 peut renvoyer une erreur spécifique contenant la date courante du serveur. Cette variante permet que le client C1 puisse se resynchroniser et réémettre à un nouveau des messages avec des entêtes d’authentification Tokenl valides.
La vérification du MESJD1 par le serveur S1 permet de limiter les attaques réseau par rejeu de message Mes1.
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 MESJD1 du message reçu Mes1 est identique à un MESJD d'un message précédemment reçu alors le message Mes1 n'est pas traité par le serveur S1.
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 Signl est invalide, le message Mes1 est par exemple rejeté par le serveur S1.
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.
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 S1 afin d’être utilisée pour vérifier la signature Signl.
Les messages peuvent aussi être signés à l’aide d’une clef asymétrique publique KPubl fournie par le serveur KPrivI qui utilise alors sa clé asymétrique privée pour vérifier la signature Signl.
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.
Le profil de sécurité PRO_SEC comprend notamment le format de la signature Signl dont les données signées et la désignation de l’algorithme utilisé.
Déchiffrement du message après vérifications
Lorsque l'identifiant de message MESJD1 et que l'authentification du message Mes1 ont été vérifiés par le serveur S1, ce dernier réalise par exemple le déchiffrement des données comme indiqué dans le profil de sécurité PRO_SEC.
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.
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 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 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, 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_C1 permet par exemple de gérer un ou plusieurs capteurs ou un ou plusieurs actionneurs.
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 C1 et un serveur S1 sans avoir à gérer les états d'une communication, c'est-à-dire sans avoir à gérer des sessions entre les entités 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 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 îo 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 C1 défectueux détecté par le serveur S1.

Claims (19)

  1. REVENDICATIONS
    1. Procédé de communication entre au moins deux entités communicantes (C1, S1), 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 (Tokenl), ledit procédé étant caractérisée en ce qu'il comporte, pour la génération dudit message (Mes1 ):
    une génération d'un paramètre de contexte (ContextPI) comportant au moins une donnée représentative de la configuration matérielle (ctrIProg) 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 (Tokenl) et définissant les conditions:
    de chiffrement des données utiles (Datai) du message ;
    de génération d'une signature (Signl) par un algorithme de signature (Signing ModuIel) appliqué au moins aux données utiles (Data 1 ) ;
    une génération de ladite signature (Signl ) intégrée dans l’entête d’authentification ;
    une insertion d'un identifiant mémorisé (C1_ld) de la première entité communicante (C1) dans l'entête d'authentification (Tokenl);
    une insertion du paramètre de contexte (ContextPI) dans le champ utile (Datai) ou dans l'entête d'authentification (Tokenl);
    une agrégation du champ utile (Datai ) et de l'entête (Tokenl ).
  2. 2. Procédé de communication selon la revendication 1, caractérisé en ce que le message (Mes1 ) émis à la seconde entité communicante (S1 ) 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 (C1.S1).
  3. 3. Procédé de communication selon l'une quelconque des revendications 1 à 2, caractérisé en ce le paramètre de contexte (ContextPI) comprend en outre une ou plusieurs des données parmi les suivantes :
    Un identifiant (IdCol ) d’un calculateur (Co1 ) 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_Co1) d'un micrologiciel de la première entité (C1) ;
    Une donnée représentative de l’espace mémoire occupé par le micrologiciel.
  4. 4. Procédé de communication selon l'une quelconque des revendications 1 à 3, caractérisé en ce que le paramètre de contexte (ContextPI) 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 (ContextPI) étant déchiffré grâce à une première clef privé asymétrique (KPrivI) enregistrée dans une mémoire de la seconde entité (S1).
  5. 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 (ContextPI), 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 (ContextPI) et l'identifiant (C1_ld) 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 (Mes1) reçu lorsque l'état de vérification est validé.
  6. 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 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 (ContextPI) 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. 7. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que le paramètre de contexte (ContextPI) est inclus dans l'entête d'authentification (Tokenl), la signature (Signl) étant appliquée également au paramètre de contexte (ContextPI ).
  8. 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).
  9. 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 (MesSyml) préalable à la génération dudit message (Mes1) de transmission de données utiles (Datai), ladite clef secrète partagée symétrique (KSec) étant utilisée pour générer la signature (Signl) et pour chiffrer des données utiles.
  10. 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 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 mémoire ;
    Une transmission par la première entité (C1) vers la seconde entité (S1) d'une requête d'enregistrement (MesEnrl) comportant l'identifiant de la première entité (C1_ld), le paramètre de contexte (ContextPI ) 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 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).
  11. 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) ;
    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).
  12. 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) à 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. 13. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que les données utiles comprennent le paramètre de contexte (ContextPI), le paramètre de contexte (ContextPI) étant généré et émis régulièrement.
  14. 14. Procédé de communication selon l'une quelconque des revendications 1 à 13, caractérisé en ce que la génération dudit message (Mes1) comprend:
    Une génération d'un identifiant de message (Mes_ID1) calculé à partir :
    o d'un paramètre généré aléatoirement (RamdomPI) et fourni par un module aléatoire (Ramdom ModuIel) et ;
    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 (Mes_ld1) dans l'entête d'authentification (Tokenl) dudit message (Mes1).
  15. 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 (Signl) par l’algorithme de signature (Signing_Module1) qui est appliqué aux données utiles (batal) du message (Mes1), au paramètre de contexte (Contextl) et à l'identifiant de message (Mes_ID1 ).
  16. 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 (Signl) comprennent :
    le profil de sécurité (PRO_SEC);
    l’identifiant de la première entité (C1_ld).
  17. 17. 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 à 16.
  18. 18. Entité communicante selon la revendication 17 caractérisée en ce qu'elle comprend au moins un capteur de données.
  19. 19. Programme d'ordinateur comportant un ensemble d'instructions pour la mise en œuvre du procédé de communication de l'une quelconque des revendications 1 à 18.
FR1754413A 2017-05-18 2017-05-18 Procede de securisation d'une communication sans gestion d'etats Active FR3066666B1 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR1754413A FR3066666B1 (fr) 2017-05-18 2017-05-18 Procede de securisation d'une communication sans gestion d'etats
EP18723562.7A EP3625928A1 (fr) 2017-05-18 2018-05-17 Procede de securisation d'une communication sans gestion d'etats
CN201880042967.2A CN111164933A (zh) 2017-05-18 2018-05-17 一种在不进行状态管理下确保通信安全的方法
US16/614,535 US11303453B2 (en) 2017-05-18 2018-05-17 Method for securing communication without management of states
PCT/EP2018/062974 WO2018211026A1 (fr) 2017-05-18 2018-05-17 Procede de securisation d'une communication sans gestion d'etats

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1754413A FR3066666B1 (fr) 2017-05-18 2017-05-18 Procede de securisation d'une communication sans gestion d'etats
FR1754413 2017-05-18

Publications (2)

Publication Number Publication Date
FR3066666A1 true FR3066666A1 (fr) 2018-11-23
FR3066666B1 FR3066666B1 (fr) 2020-07-03

Family

ID=60202076

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1754413A Active FR3066666B1 (fr) 2017-05-18 2017-05-18 Procede de securisation d'une communication sans gestion d'etats

Country Status (5)

Country Link
US (1) US11303453B2 (fr)
EP (1) EP3625928A1 (fr)
CN (1) CN111164933A (fr)
FR (1) FR3066666B1 (fr)
WO (1) WO2018211026A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT201800011129A1 (it) * 2018-12-14 2020-06-14 Toi Srl Sistema, dispositivo e metodo per trasferire in maniera sicura informazioni da un apparecchio a una blockchain
US11539517B2 (en) * 2019-09-09 2022-12-27 Cisco Technology, Inc. Private association of customer information across subscribers
US11811743B2 (en) * 2020-10-26 2023-11-07 Micron Technology, Inc. Online service store for endpoints
WO2023090918A1 (fr) * 2021-11-17 2023-05-25 Samsung Electronics Co., Ltd. Procédé et système d'annonce sécurisée liée dans un système à bande ultralarge (uwb)
CN114499969B (zh) * 2021-12-27 2023-06-23 天翼云科技有限公司 一种通信报文的处理方法、装置、电子设备及存储介质
US20240056651A1 (en) * 2022-08-09 2024-02-15 Dish Network, L.L.C. Digital rights management using a gateway/set top box without a smart card

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7530096B2 (en) * 2003-11-12 2009-05-05 Nokia Siemens Networks Oy Intermediate node aware IP datagram generation
CN101626294A (zh) * 2008-07-07 2010-01-13 华为技术有限公司 基于身份的认证方法、保密通信方法、设备和系统
ATE547855T1 (de) * 2008-10-01 2012-03-15 Sap Ag Kontextfreie und kontextsensitive digitale xml- signaturen für soap botschaften
US8843764B2 (en) * 2011-07-15 2014-09-23 Cavium, Inc. Secure software and hardware association technique
US9124564B2 (en) * 2013-08-22 2015-09-01 Cisco Technology, Inc. Context awareness during first negotiation of secure key exchange
KR101521808B1 (ko) * 2014-02-20 2015-05-20 한국전자통신연구원 클라우드 환경에서의 상황인지형 보안 통제 장치, 방법, 및 시스템
US9641488B2 (en) * 2014-02-28 2017-05-02 Dropbox, Inc. Advanced security protocol for broadcasting and synchronizing shared folders over local area network
US9799142B2 (en) * 2014-08-15 2017-10-24 Daqri, Llc Spatial data collection
US9942201B1 (en) * 2015-12-16 2018-04-10 vIPtela Inc. Context specific keys
KR101795457B1 (ko) * 2016-09-27 2017-11-10 시큐리티플랫폼 주식회사 보안 기능이 강화된 디바이스의 초기화 방법 및 디바이스의 펌웨어 업데이트 방법
US10826876B1 (en) * 2016-12-22 2020-11-03 Amazon Technologies, Inc. Obscuring network traffic characteristics

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LAVINA JAIN ET AL: "CS259 Project Report Security Analysis of Remote Attestation", 19 March 2008 (2008-03-19), XP055094023, Retrieved from the Internet <URL:http://seclab.stanford.edu/pcl/cs259/projects/cs259_final_lavina_jayesh/CS259_report_lavina_jayesh.pdf> [retrieved on 20131217] *
THOMAS KOTHMAYR ET AL: "A DTLS based end-to-end security architecture for the Internet of Things with two-way authentication", LOCAL COMPUTER NETWORKS WORKSHOPS (LCN WORKSHOPS), 2012 IEEE 37TH CONFERENCE ON, IEEE, 22 October 2012 (2012-10-22), pages 956 - 963, XP032321793, ISBN: 978-1-4673-2130-3, DOI: 10.1109/LCNW.2012.6424088 *

Also Published As

Publication number Publication date
US11303453B2 (en) 2022-04-12
CN111164933A (zh) 2020-05-15
FR3066666B1 (fr) 2020-07-03
WO2018211026A1 (fr) 2018-11-22
US20210144130A1 (en) 2021-05-13
EP3625928A1 (fr) 2020-03-25

Similar Documents

Publication Publication Date Title
FR3066666A1 (fr) Procede de securisation d&#39;une communication sans gestion d&#39;etats
EP2820795B1 (fr) Procede de verification d&#39;identite d&#39;un utilisateur d&#39;un terminal communiquant et systeme associe
EP3238474B1 (fr) Procédé de sécurisation de transactions sans contact
EP3174241B1 (fr) Méthode d&#39;établissement d&#39;une communication sécurisée de bout en bout entre le terminal d&#39;un utilisateur et un objet connecté
EP3375133B1 (fr) Procede de securisation et d&#39;authentification d&#39;une telecommunication
WO2017055716A1 (fr) Procede et dispositif d&#39;authentification ameliores
FR2997525A1 (fr) Procede de fourniture d’un service securise
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l&#39;intégrité de données mémorisées dans une telle entité électronique sécurisée
WO2016079429A1 (fr) Procede de controle d&#39;acces a un systeme de production d&#39;un systeme informatique non connecte a un systeme d&#39;information dudit systeme informatique
EP3840324B1 (fr) Liaison série asynchrone sécurisée
WO2019228853A1 (fr) Methode d&#39;etablissement de cles pour le controle d&#39;acces a un service ou une ressource
EP3758322A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
FR3103987A1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
WO2012156365A1 (fr) Procede de securisation d&#39;une platforme d&#39;authentification, dispositifs materiels et logiciels correspondants
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
EP3725025B1 (fr) Procede de communication securise
FR3038414A1 (fr) Procede et systeme de controle d&#39;acces a un service via un media mobile.
EP2911365A1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d&#39;un utilisateur et un point d&#39;acceptation
EP3360293A1 (fr) Moyens de gestion d&#39;accès à des données
FR3041841A1 (fr) Procede et dispositif pour acceder a une ressource a l’aide d’un jeton chiffre
EP2836952A1 (fr) Procede de generation et de verification d&#39;identite portant l&#39;unicite d&#39;un couple porteur-objet
FR2900776A1 (fr) Procede de securisation de donnees

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20181123

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7