FR3093882A1 - Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. - Google Patents

Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. Download PDF

Info

Publication number
FR3093882A1
FR3093882A1 FR1902427A FR1902427A FR3093882A1 FR 3093882 A1 FR3093882 A1 FR 3093882A1 FR 1902427 A FR1902427 A FR 1902427A FR 1902427 A FR1902427 A FR 1902427A FR 3093882 A1 FR3093882 A1 FR 3093882A1
Authority
FR
France
Prior art keywords
network
communicating object
parameters
communicating
access
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
FR1902427A
Other languages
English (en)
Other versions
FR3093882B1 (fr
Inventor
Jean-Luc Grimault
Tanguy GODQUIN
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.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Priority to FR1902427A priority Critical patent/FR3093882B1/fr
Publication of FR3093882A1 publication Critical patent/FR3093882A1/fr
Application granted granted Critical
Publication of FR3093882B1 publication Critical patent/FR3093882B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0876—Aspects of the degree of configuration automation
    • H04L41/0883—Semiautomatic configuration, e.g. proposals from system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/37—Managing security policies for mobile devices or for controlling mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/77—Graphical identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/14—WLL [Wireless Local Loop]; RLL [Radio Local Loop]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Automation & Control Theory (AREA)
  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. L'invention concerne un procédé de configuration d’un objet communicant (O) apte à être connecté à un réseau de communication (RC), ledit réseau de communication comprenant au moins un équipement d’accès (EA) audit réseau, ledit objet comprenant une première interface (Int1) de connexion locale à un terminal d’utilisateur (TU) et une deuxième interface (Int2) de connexion audit équipement d’accès. Ledit procédé est mis en œuvre par ledit terminal d’utilisateur (TU) et comprend les étapes suivantes :- Configuration de paramètres réseau (FO) associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication (RC);- Enregistrement de l’objet communicant auprès d’un serveur constructeur distant (SC), comprenant la transmission audit serveur constructeur (SC) d’un identifiant (IDO) de l’objet communicant et des paramètres réseau configurés et la réception, en provenance du serveur constructeur (SC), d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis;- Transmission du micrologiciel reçu à l’objet communicant via la première interface ; et- Enregistrement de l’identifiant (IDO) de l’objet communicant et de ses paramètres réseau (FO) auprès du réseau de communication. fig. 3

Description

Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.
Domaine de l'invention
Le domaine de l'invention est celui des réseaux de communication, notamment, mais non exclusivement, des réseaux de communication locaux résidentiels ou d’entreprise, comprenant un équipement ou passerelle d’accès et une pluralité d’objets communicants, tels que des ordinateurs, tablettes, téléphones intelligents (en anglais « smartphones »), mais également des caméras de type webcams, des stations météo, des capteurs, des thermostats, des actionneurs etc.
Plus précisément, l'invention concerne la mise en service d’un nouvel objet communicant en vue de sa connexion à un tel réseau de communication. Elle s’applique aussi à la mise à jour d’un objet communicant déjà en service dans le réseau.
Art antérieur et ses inconvénients
Aujourd'hui, dans le monde de l'Internet des Objets ou IoT (pour « Internet of Things », en anglais), de nombreux objets communicants ne disposent pas d'un élément de sécurité matériel pour sécuriser avec un grand niveau de confiance le stockage et l'usage d'une clé cryptographique.
En l'absence d'élément de sécurité matériel, l’objet communicant met généralement en œuvre une clé secrète cryptographique au moyen de ses propres ressources matérielles telles qu’un processeur ou une mémoire. Cette mise en œuvre peut être associée ou non à des solutions logicielles de sécurisation connues de l’homme de métier, parmi lesquelles on peut citer :
- Les techniques d’offuscation du code informatique du micrologiciel (pour « firmware », en anglais) de l’objet communicant, c’est-à-dire du programme informatique intégré à l’objet communicant pour lui permettre de fonctionner ;
- Les techniques de dissimulation de la clé cryptographique dans le code informatique du micrologiciel, pour parer une attaque de type « boîte blanche », selon laquelle un attaquant accède à toutes les données stockées dans l’objet communicant, comme par exemple celles décrites par S. Chow et al dans le document intitulé «A white-box DES implementation for DRM applications”,dans les proceedings de la conférence ACM Workshop on Digital Rights Management, publiés par Springer, pp. 1–15., en 2002.
Or, il s’avère que ces solutions logicielles utilisées seules, si elles apportent un niveau de sécurité acceptable pour certains cas d’usage peu sensibles, comme par exemple l’utilisation de l’objet communicant au sein d’un réseau de communication local résidentiel, sont nettement insuffisantes pour des cas d’usage plus sensibles, comme par exemple un réseau local professionnel ou encore lorsque les objets doivent se connecter à des réseaux de communications étendus, comme un réseau cellulaire, plus exigeant en termes de sécurité. En tout état de cause, elles ne permettent pas d’atteindre le niveau de protection apporté par un élément de sécurité matériel, notamment contre les usurpations d'identité des objets, les atteintes à la sécurité notamment de type perte de confidentialité des communications et perte d'intégrité des données échangées.
Par exemple, une carte SIM (pour «Subscriber Identity Module », en anglais) ou une carte de type de type e-SIM (pour « embedded-SIM », en anglais), utilisée pour stocker des informations spécifiques à un utilisateur d’un réseau de communications mobiles, repose sur des composants disposant d'une certification d'un niveau souvent au moins égal à EAL4, niveau qu'aucune solution logicielle ne peut atteindre aujourd'hui.
Cependant, il subsiste aujourd’hui des freins à l’intégration d’éléments de sécurité matériels dans les objets communicants pour l’IoT, parmi lesquels on peut citer :
- leur coût de fabrication élevé au regard du faible prix de vente de certains objets communicants, comme les capteurs par exemple ;
- la dépendance qu’ils imposent aux constructeurs d'objets communicants vis-à-vis de sous-traitants spécialistes des éléments de sécurité matériels,
- Lorsque l’objet est destiné à un réseau cellulaire, une certaine complexité induite par l'architecture des systèmes e-SIM, nécessitant l’installation à distance des informations de connexion (ou "profils") dans la carte e-SIM de l’objet communicant via des serveurs sécurisés gérés par l’opérateur du réseau cellulaire.
Au vu de ces freins, on peut s'attendre à ce que perdure la situation actuelle; c’est-à-dire qu’avec le développement de l’IoT, de nombreux objets communicants soient déployés dans les réseaux de communications avec un niveau de sécurité insuffisant au regard du cas d’usage.
Par ailleurs, la question de la sécurité des objets communicants dans l’IoT ne se limite pas à leur mise en service et à leur première connexion au réseau de communication. En effet, en cas d’attaques causées par l'installation de virus ou chevaux-de-Troie, des correctifs doivent être apportés au micrologiciel d’un objet communicant déjà en service, sous forme d’une mise à jour de ce micrologiciel.
Au plan réglementaire, des dispositions commencent à être édictées pour obliger les constructeurs d'objets à proposer des mises à jour des micrologiciels des objets communicants déjà commercialisés, telle que par exemple la loi «IoT Cybersecurity Improvement Act of 2017» aux Etats-Unis ou le devoir de diligence instauré par la Commission Européenne, mais la mise en application pratique de ces dispositions reste problématique.
Il existe donc un besoin d'une technique de mise en service d’un objet communicant dans un réseau de communication local ou étendu qui ne présente pas ces différents inconvénients de l’art antérieur. Il existe notamment un besoin d’une telle technique qui permette de garantir un niveau de sécurité suffisant des communications de l’objet communicant au vu du cas d’usage ciblé, pour un coût raisonnable. Il existe aussi un besoin d’une telle technique qui prenne en compte la diversité des objets communicants et des cas d’usage, tout en préservant un écosystème technique simple pour l’usage de ces objets communicants. Il existe enfin un besoin d’une telle technique qui permette aussi bien de mettre en service un nouvel objet communicant que de mettre à jour un objet communicant déjà en service dans le réseau de communication.
L'invention répond à ce besoin en proposant un procédé de configuration d’un objet communicant (O) apte à être connecté à un réseau de communication, ledit réseau de communication comprenant au moins un équipement d’accès audit réseau, ledit objet comprenant une première interface de connexion locale à un terminal d’utilisateur et une deuxième interface de connexion audit équipement d’accès,
Ledit procédé est mis en œuvre par ledit terminal d’utilisateur et comprend les étapes suivantes :
- Configuration de paramètres réseau associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication ;
- Enregistrement de l’objet communicant auprès d’un serveur constructeur distant, comprenant la transmission au serveur constructeur d’un identifiant de l’objet communicant et des paramètres réseau configurés et la réception, en provenance du serveur constructeur , d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis;
- Transmission du micrologiciel reçu à l’objet communicant via la première interface ; et
- Enregistrement de l’identifiant de l’objet communicant et de ses paramètres réseau auprès du réseau de communication.
Ainsi, l’invention repose sur une approche tout à fait nouvelle et inventive de la mise en service d’un objet communicant dans un réseau de communication, tel que par exemple un réseau Wifi résidentiel ou d’entreprise ou encore un réseau cellulaire, ce réseau pouvant être géré ou non par un opérateur en télécommunications.
En effet, selon l’invention, c’est l’utilisateur d’un terminal connecté qui interagit d’une part avec le constructeur de l’objet et d’autre part avec le réseau de communication pour configurer les fonctionnalités réseau qu’il souhaite attribuer à l’objet communicant.
Au cours d’une première phase de configuration, l’utilisateur du terminal définit les paramètres réseau qu’il souhaite attribuer à l’objet communicant dans le réseau de communication puis les enregistre auprès du constructeur. En réponse, il reçoit du constructeur un micrologiciel personnalisé et programmé en fonction des paramètres réseau qu’il lui a communiqués. Il transmet le micrologiciel reçu à l’objet communicant. Une fois le micrologiciel installé par l’objet communicant, la configuration de l’objet communicant par le terminal est terminée.
Au cours d’une deuxième phase d’enregistrement de l'objet dans le réseau, l’utilisateur se connecte au réseau de communication local ou étendu pour enregistrer l’identifiant de l’objet communicant et ses paramètres réseau.
A l’issue de ces deux phases, l’objet communicant est configuré et peut se connecter au réseau.
Avec l’invention, le micrologiciel installé dans l’objet communicant est donc spécifiquement programmé pour s’adapter aux besoins spécifiques de l’objet communicant et limiter ses fonctionnalités à ces besoins, tels que définis par l’utilisateur.
En outre, le fait que ce soit l’utilisateur du terminal, dûment enregistré dans le réseau de communication, qui pilote la configuration de l’objet communicant à la fois auprès du constructeur et du réseau de communication, garantit une cohérence globale et une sécurité accrue.
Enfin, du fait que l’enregistrement de l’objet communicant dans le réseau est réalisé depuis le terminal de l’utilisateur, l’invention ne requiert pas l’intervention de l'opérateur du réseau de communication pendant la phase de configuration de l’objet. En particulier, l’opérateur n’a pas à s’interfacer avec l’objet pour lui installer une clé d’accès au réseau. La solution proposée par l’invention permet donc de conserver un écosystème simple.
Selon un premier aspect, le micrologiciel comprend une commande d’activation de la deuxième interface et de désactivation de la première interface.
De la sorte, seule la première interface, non connectée à Internet, est active durant la phase initiale de configuration de l’objet, ce qui contribue à renforcer la sécurisation de cette phase. Suite à l’installation du micrologiciel, elle est désactivée au profit de la deuxième interface, qui permet à l’objet, dans une phase de fonctionnement normal, de se connecter au réseau de communication.
Selon un autre aspect, la configuration comprend la saisie de champs d’information d’un formulaire de configuration des paramètres réseau de l’objet communicant, le formulaire rempli étant transmis à l’équipement serveur constructeur distant.
Le paramétrage de l’objet communicant est avantageusement réalisé par l’intermédiaire d’une application logicielle disponible sur le terminal utilisateur. Cette application logicielle est programmée pour afficher un formulaire de configuration, que l’utilisateur peut remplir de façon très simple et ergonomique via l’interface de l’application.
Selon encore un autre aspect, le procédé comprend une étape d’obtention de l’identifiant et d’une clé cryptographique de l'objet par lecture d’un QR code comprenant au moins l’identifiant et la clé cryptographique et le micrologiciel est transmis à l’objet via un canal de communication chiffré par ladite clé.
Un avantage est que la récupération de ces informations fournies par le constructeur de l’objet communicant est purement locale, ce qui permet de renforcer ensuite la sécurité de l’installation du micrologiciel dans l’objet et sa connexion ultérieure au réseau de communication (RC), en évitant notamment la récupération indue de ces informations par un attaquant. Un avantage de la clé cryptographique est de sécuriser les échanges entre le terminal utilisateur et l’objet communicant, en particulier la transmission du micrologiciel par le terminal utilisateur à l’objet communicant.
Selon un autre aspect, le QR code comprend en outre le formulaire de configuration des paramètres réseau.
Un avantage est de sécuriser par la même opération la récupération du formulaire de configuration.
Selon encore un autre aspect, le QR code comprend en outre une adresse d’une page internet comprenant le formulaire de configuration des paramètres réseau.
Un avantage est que la quantité d’information à intégrer dans le QR code est ainsi réduite.
Selon un autre aspect, les paramètres réseau comprennent en outre :
- des adresses de correspondants que l’objet est autorisé à atteindre; et
- des droits d’accès auxdits correspondants.
De tels paramètres spécifient des fonctionnalités réseau attribuées à l'objet, par exemple des adresses de correspondants avec lesquelles l'objet est autorisé de communiquer.
Ces informations supplémentaires sont d’une part programmées dans le micrologiciel par le constructeur et enregistrées dans le réseau de communication. Un avantage est qu’elles vont permettre d’une part à des équipements du réseau, tels que l’équipement d’accès par exemple, de définir et de limiter les fonctionnalités de l’objet communicant dans le réseau de communication et d’autre part de réduire les risques d’attaques du fait que l’objet communicant est limité dans ses communications.
Selon encore un autre aspect, le procédé comprend en outre une étape d’analyse préalable d’un voisinage de l’objet communicant et une détermination d’un niveau de sécurité nécessaire au fonctionnement de l’objet communicant en fonction d’un résultat de l’analyse, les paramètres réseau étant configurés en fonction du niveau de sécurité déterminé.
L’analyse peut être réalisée en mode local par exemple en lançant une commande de type « ARP scan » pour obtenir les adresses d’objets voisins. En variante, l’équipement terminal peut interroger une base de données locale ou distante comprenant des informations sur des périphériques présents dans le voisinage de l’objet communicant. Un avantage est de pouvoir limiter d’autant plus les fonctionnalités de l’objet communicant que le niveau de sécurité déterminé est élevé.
Selon un aspect de l’invention, le procédé de mise en service de l’objet est déclenché lors d’une première connexion de l’objet communicant au deuxième réseau de communication ou suite à une réinitialisation de l’objet communicant.
Un avantage de l’invention est qu’elle permet aussi une mise à jour sécurisée du micrologiciel d’un objet communicant déjà en service dans le réseau de communication suivant les mêmes modalités que la première mise en service et ainsi l’application des correctifs de sécurité les plus récents à l’objet communicant. Elle répond donc à un besoin de mise à jour qui devient de plus patent dans le monde de l'IoT.
L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de configuration d’un objet communicant dans un réseau de communication tel que décrit précédemment, lorsqu’il est exécuté par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé de mise en service d’un objet communicant selon l’invention tel que décrit ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de mise en service précité.
L'invention concerne également un terminal utilisateur adapté à configurer un objet communicant apte à être connecté à un réseau de communication, caractérisé en ce qu’il comprend les modules suivants :
- Configuration de paramètres réseau associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication;
- Enregistrement de l’objet communicant auprès d’un serveur constructeur distant, comprenant la transmission d’un identifiant de l’objet communicant et des paramètres d’accès configurés et la réception, en provenance de l’équipement serveur constructeur, d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis;
- Transmission du micrologiciel reçu à l’objet communicant via une première interface de connexion locale dudit objet; et
- Enregistrement de l’identifiant de l’objet communicant et de ses paramètres réseau auprès du réseau de communication.
Plus généralement, un tel terminal utilisateur est apte à mettre en œuvre un procédé de configuration d’un objet communicant tel que décrit précédemment.
Le terminal utilisateur et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de configuration selon la présente invention.
Corrélativement, l’invention concerne aussi un procédé de connexion d’un objet communicant à un réseau de communication, comprenant au moins un équipement d’accès audit réseau et un serveur réseau.
Un tel procédé comprend les étapes suivantes:
- Réception par le serveur réseau, en provenance d’un terminal utilisateur, d’une demande d’enregistrement de l’objet communicant, ladite demande comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au deuxième réseau de communication ;
- Transmission des paramètres réseau associés à l’objet communicant par le serveur réseau à l’équipement d’accès pour enregistrement ; et
- Lors d’une première demande de connexion au réseau de communication par l’objet communicant, établissement d’une connexion sécurisée avec l’objet communication à partir des paramètres réseau enregistrés.
Avec l’invention, l’objet communicant est enregistré dans le réseau de communication par l’utilisateur du terminal, qui se connecte lui-même au réseau à l’aide de son propre identifiant et fournit au réseau via cette connexion, les paramètres réseau qu’il a définis lui-même pour l’objet. Ces paramètres réseaux comprennent les informations nécessaires pour l’établissement par l’équipement d’accès d’une première connexion sécurisée avec l’objet communicant. Par exemple, l’équipement d’accès négocie une clé réseau avec l’objet à l’aide de ces informations. Ainsi, l’intervention de cet opérateur pendant la phase de configuration de l’objet n’est pas requise. En particulier, l’opérateur n’a pas à s’interfacer avec l’objet pour lui installer une clé d’accès au réseau. La solution proposée par l’invention permet donc de conserver un écosystème simple.
Selon un aspect de l’invention, lesdits paramètres réseaux comprennent en outre des adresses de correspondants autorisés et des droits d’accès à ces correspondants et, sur, réception d’un flux de données en provenance ou à destination de l’objet communicant, le procédé comprend une vérification d’une conformité du flux aux paramètres réseau enregistrés pour l’objet communicant.
Un avantage est que ces paramètres réseau limitent les fonctionnalités de l’objet communicant dans le réseau, lequel peut les utiliser pour vérifier la conformité des communications impliquant l’objet communicant, notamment au niveau de l’équipement d’accès.
Lorsque le réseau de communication est géré par un opérateur, le procédé comprend une vérification d’une conformité des paramètres réseau à un contrat de l’utilisateur du terminal.
L’invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé de connexion d’un objet communicant à un réseau de communication tel que décrit précédemment, lorsqu’il est exécuté par un processeur.
L’invention vise également un support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur comprenant des instructions de code de programme pour l’exécution des étapes du procédé de connexion selon l’invention tel que décrit ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur.
D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de connexion précité.
L’invention concerne aussi un équipement d’accès à un réseau de communication adapté à la connexion d’un objet communicant et comprenant:
- un module de réception d’une demande d’enregistrement de l’objet communicant en provenance d’un terminal utilisateur, ladite demande comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au deuxième réseau de communication,
- un module d’enregistrement des paramètres réseau associés à l’objet communicant ;
- un module d’établissement d’une connexion sécurisée avec l’objet communicant à partir des paramètres réseau enregistrés, apte à être mis en œuvre lors d’une première demande de connexion au deuxième réseau de communication par l’objet communicant.
Plus généralement, un tel équipement d’accès est apte à mettre en œuvre un procédé de connexion d’un objet communicant tel que décrit précédemment.
Selon un aspect complémentaire, un tel équipement d’accès est intégré dans une passerelle d’un réseau de communication résidentiel ou d’entreprise ou dans une station de base d’un réseau de communication cellulaire.
Corrélativement, une telle passerelle résidentielle ou d’entreprise comprend l’équipement d’accès qui vient d’être décrit selon l’invention et un serveur réseau apte à recevoir une demande d’enregistrement de l’objet communicant en provenance d’un terminal utilisateur, ladite demande d’enregistrement comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au réseau de communication, le serveur réseau étant apte à transmettre les paramètres réseau reçus à l’équipement d’accès pour enregistrement.
L’équipement d’accès, la passerelle et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de connexion d’un objet communicant selon la présente invention.
Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
Cette figure présente une vue schématique d’un réseau de communication et de différents objets communicants de ce réseau, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un objet communicant avant sa mise en service dans le réseau de communication;
Cette figure présente sous forme de logigramme les différentes étapes du procédé de configuration d’un objet communicant et du procédé de connexion de cet objet selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un terminal utilisateur mettant en œuvre l’obtention d’information d’identification de l’objet communicant selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un terminal d’utilisateur connecté au réseau de communication et mettant en œuvre une analyse d’un voisinage de l’objet communicant, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un terminal utilisateur connecté à un serveur distant du constructeur de l’objet communicant via le réseau de communication et lui transmettant les paramètres de configuration de l’objet, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un terminal utilisateur connecté à l’objet communicant et lui transmettant le micrologiciel personnalisé en fonction des paramètres de configuration, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un terminal utilisateur connecté à un serveur du réseau de communication et lui transmettant les informations d’identification de l’objet et ses paramètres de configuration pour enregistrement, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’un serveur réseau connecté à une passerelle réseau du réseau de communication et lui transmettant les informations d’identification de l’objet et ses paramètres de configuration pour enregistrement, selon un mode de réalisation de l’invention;
Cette figure présente une vue schématique d’une passerelle réseau du réseau de communication mettant en œuvre une vérification de conformité des flux de données échangés par l’objet communicant avec un correspondant dans une phase de fonctionnement, selon un mode de réalisation de l’invention;
Cette figure propose un schéma synoptique d’un terminal utilisateur mettant en œuvre le procédé de configuration de la [fig. 3] ; et
Cette figure propose un schéma synoptique d’une passerelle réseau mettant en œuvre le procédé de connexion de la [fig. 3].
Description détaillée de modes de réalisation de l'invention
L’invention concerne la mise en service sécurisée d’un objet communicant d’un utilisateur dans un réseau de communication. Le principe de l’invention est de piloter cette mise en service depuis un terminal de cet utilisateur. Ce terminal obtient de l’utilisateur des paramètres de configuration des fonctionnalités que ce dernier souhaite activer sur l’objet communicant, comprenant notamment des fonctionnalités réseau. Il enregistre ensuite l’objet auprès d’un serveur du constructeur, lui transmet les paramètres de configuration de l’objet et obtient en retour un micrologiciel personnalisé en fonction de ces paramètres de configuration. Enfin, le terminal utilisateur enregistre lui-même l’objet communicant dans le réseau de communication en lui transmettant les paramètres de configuration des fonctionnalités réseau.
Le réseau de communication peut être un réseau local de type résidentiel ou professionnel, permettant d’accéder à un réseau étendu, tel que par exemple Internet, ou bien un réseau d’accès à un réseau mobile, comme par exemple un réseau cellulaire géré par un opérateur en télécommunications.
L'invention vise d’abord à sécuriser les communications des objets communicants de l’IoT ne disposant pas d'élément de sécurité matériel, donc en incapacité d’assurer une protection suffisante de leurs clés cryptographiques.
Il convient toutefois de noter qu’elle est aussi applicable à des objets communicants disposant d'élément de sécurité matériel, dont elle vient renforcer la sécurité.
L’invention s’applique ainsi à tout objet apte à être connecté à un réseau de communication fixe par voie filaire (câble Ethernet, port USB (pour l’anglais « Universal Serial Bus »), etc.) ou sans fil (Wi-Fi®, Bluetooth®, ZigBee, Z-Wave®, etc.).
La notion d’objet communicant englobe également les applications logicielles associées à certains objets connectés non IP (« Internet Protocol »), fonctionnant sur des technologies sans fil tels que BLE (pour « Bluetooth® Low Energy »), Z-wave®, Thread®, etc.
En effet, l’utilisation de tels objets communicants requiert le plus souvent l’installation d’une application de gestion sur une passerelle d’accès au réseau de communication. Une telle application s’appuie sur une machine virtuelle, ou un conteneur, à qui le serveur de configuration de paramètres d’accès (serveur DHCP) fournit une adresse IP. De tels objets communicants qui ne sont pas naturellement compatibles avec le protocole IP nécessitent la mise en œuvre d’une passerelle IoT vers IP et/ou du protocole « 6LowPan ».
Ainsi, dans la suite, on désigne par objet communicant, aussi bien les objets physiques connectés au réseau que les applications logicielles « virtualisées » associées à certains de ces objets.
L’invention s’applique également à tout objet destiné à être connecté à un réseau mobile cellulaire pour lequel :
- il serait complexe d'installer un profil opérateur dans un élément de sécurité ; ou
- plus généralement, il serait complexe que l'opérateur installe lui-même une clé dans l'objet, durant une phase préalable à son fonctionnement normal.
On comprend que l’invention s’applique préférentiellement à un objet communicant disposant de ressources matérielles et logicielles limitées, donc d’un nombre réduit de fonctionnalités et dont la fabrication est soumise à des contraintes strictes en termes de coût. Il s’agit par exemple de capteurs, d’actionneurs ou de tout autre objet de l’IoT, tel qu’un thermostat, une station météo, une webcam, etc. Un tel objet n’est pas nécessairement équipé d’un écran, d’une dalle tactile ou d’un clavier.
Dans la suite, on désigne par terminal utilisateur, un équipement terminal comprenant au moins des moyens d’interaction avec un utilisateur, tels qu’un écran et un clavier ou une dalle tactile, une première interface de connexion locale, par voie filaire ou sans fil (Bluetooth ou NFC (pour « Near Field Communication », en anglais)) à un objet communicant, une deuxième interface de connexion au réseau de communication auquel l’objet communicant est destiné à se connecter, par voie filaire ou sans fil. Avantageusement, il peut aussi disposer d’une troisième interface de connexion à un réseau d’accès à un réseau étendu, tel qu’un réseau cellulaire par exemple.
Un terminal utilisateur dispose de ressources matérielles et logicielles plus importantes qu’un objet communicant visé par l’invention et intègre généralement un élément de sécurité matériel. Il s’agit par exemple d’un téléphone intelligent (pour « smartphone », en anglais), d’une tablette, d’un ordinateur portable, etc. Le terminal utilisateur considéré dans la suite de la description est déjà dûment enregistré au réseau de communication.
On s’attache plus en détail dans la suite de ce document à décrire la mise en œuvre d’un mode de réalisation de l’invention dans le cadre d’un réseau de communication local par exemple résidentiel, chez un utilisateur particulier. L’invention s’applique bien sûr également à tout autre type de réseau de communication local ou LAN (pour « Local Area Network », en anglais), tel qu’un réseau de communication professionnel ou encore au réseau cellulaire, ou boucle locale, d’accès à un réseau de communication mobile.
Dans le réseau de communication RC, représenté schématiquement sur lafig. 1, un équipement d’accès EA, 30 intégré à une passerelle résidentielle PR référencée 50 permet de relier le réseau de communication RC à un réseau étendu RE tel que le réseau Internet. Dans un réseau d’entreprise cet équipement d’accès serait intégré à une passerelle d’entreprise et dans un réseau de communication géré par un opérateur tel qu’un réseau cellulaire, dans une station de base.
Dans l’exemple de lafig. 1, plusieurs équipements sont présents sur le réseau RC, parmi lesquels on distingue :
- des terminaux d’utilisateurs, tels que des téléphones intelligents (ou « smartphones », en anglais) TU, référencé 20 ou l’ordinateur portable TU1;
- des objets communicants tels que la station météo O, référencée 10 ou la webcam O1. Cette liste n’est bien sûr pas exhaustive, et de nombreux autres terminaux utilisateurs et/ou objets communicants peuvent être présents sur le réseau local RC.
Dans la suite de la description, l’objet O est un nouvel objet communicant qui n’a pas encore été mis en service et on décrit la configuration de cet objet O et sa connexion au réseau RC selon un mode de réalisation particulier de l’invention.
Selon ce mode de réalisation de l’invention, l’objet communicant O à configurer possède plusieurs caractéristiques qui sont listées ci-dessous et illustrées par lafig. 2:
- L’objet O est associé à un identifiant unique, par exemple de type UUID (pour « Universally Unique identifier », en anglais), que l’on désignera par IDO;
- L’objet O est associé à une clé cryptographique symétrique KO;
- L’objet comprend au moins deux interfaces réseau :
- Une première interface Int1de connexion locale et sans fil à un terminal utilisateur, tel que par exemple le téléphone intelligent TU, 20 dans un réseau de communication local RC1. Avantageusement, elle est dédiée à l’installation du micrologiciel dans l’objet O. Pour des raisons de sécurité, elle fonctionne en mode local, typiquement non connecté à Internet et utilise par exemple une technologie de type Bluetooth ou NFC ;
- Une deuxième interface Int2de connexion au réseau de communication RC via la passerelle résidentielle PR. Avantageusement, elle est utilisée ensuite par l'objet durant son fonctionnement normal, c’est-à-dire une fois que le micrologiciel a été installé; Il s’agit par exemple d’une interface sans fil de type Wifi ou Zigbee ou radio cellulaire.
Optionnellement, seule l'une des interfaces est activée à un instant donné. En particulier, Int2n'est pas activée pendant l'installation du micrologiciel (seule Int1l'est). A l'acquisition de l'objet ou après son reset, seule l'interface Int1est activée.
Pour les raisons précédemment évoquées, il est important de configurer l’objet O de façon à ce qu’il rende les services pour lesquels il est prévu et d’assurer sa première connexion au réseau de communication, tout en garantissant la sécurité du réseau de communication RC.
Pour ce faire, un mode de réalisation de l’invention repose sur le logigramme de lafig. 3.
Selon ce mode de réalisation, un procédé de configuration de l’objet communicant O est mis en œuvre par un terminal utilisateur, par exemple le téléphone TU, 20. On notera toutefois que l'utilisateur peut utiliser n'importe quel type d'équipement, terminal utilisateur ou objet communicant.
Au cours d’une étape 201, l’identifiant IDOet la clé cryptographique KOassociés à l’objet communicant O sont obtenus. A cet égard plusieurs modes d’obtention de ces informations sont envisagés :
- Elles sont fournies avec l’objet O lors de l’acte d’achat; ou
- elles sont accessibles sur requête auprès du constructeur ; ou encore
- l’identifiant IDOest fourni avec l’objet et la clé KOest obtenue par requête auprès du constructeur .
Avantageusement, comme illustré par lafig. 4, un QR code a été fourni à l’utilisateur lors de l’achat de l’objet, comportant :
- l’identifiant de l'objet IDO,et
- la clé cryptographique de l’objet KO.
Par exemple, ce QR code est imprimé sur une feuille de papier ou bien il est affiché sur un écran de l’objet communicant O, le cas échéant. L'utilisateur du terminal TU, 20 le scanne à l’aide d’une application logicielle installée sur ce terminal. L'avantage de ce mode de récupération est qu'il est purement local et très peu soumis à un espionnage potentiel, pourvu que l'utilisateur prenne garde à ne pas divulguer le QR code.
Le QR code est lu par l’application qui récupère ainsi les informations IDOet KO. La clé cryptographique KO, comme on le verra, sera utilisée ensuite pour sécuriser une communication entre le terminal utilisateur TU et l'objet O via sa première interface Int0.
Au cours d’une étape 203, l’objet communicant est configuré en positionnant les valeurs de plusieurs paramètres Fo.
Avantageusement, ce paramétrage est réalisé à partir d’un formulaire de configuration de l’objet qui doit être préalablement obtenu par le terminal utilisateur TU, 20.
Ce formulaire peut être obtenu par l’intermédiaire d’une application installée sur le terminal utilisateur TU, 20, qui peut être la même que celle utilisée dans l’étape 201.
Selon une première option, l'application interroge un serveur SC du constructeur de l'objet, en lui envoyant une requête REQ-FC. Ce serveur est généralement distant et accessible via le réseau étendu RE, comme illustré par la Figure1. La requête REQ-FC comprend au moins l'identité de l'objet IDO, valeur contenant la marque et le type d'objet. De la sorte, le serveur du constructeur SC peut alors déterminer, selon le type d'objet, un formulaire de configuration de l'objet FCO, adapté à ce type d'objet et à ses fonctionnalités et l’envoyer à l’application requérante.
Il est important de noter que le terminal utilisateur TU peut aussi bien accéder à ce serveur constructeur SC via le réseau de communication RC ou via un autre réseau d’accès RA au réseau étendu RE, par exemple un réseau radio cellulaire, comme illustré par lafig. 1. Si au contraire, le réseau de communication RC était un réseau cellulaire, alors le terminal utilisateur pourrait choisir de communiquer avec le serveur constructeur SC via un réseau résidentiel ou d’entreprise RA.
Par exemple, si l'objet est un capteur météo, le serveur du constructeur peut retourner un formulaire de configuration FCOcomprenant les champs à compléter suivants :
- "protocole HTTPS, sur port TCP 443" < champ pré rempli, car l'objet fonctionne toujours avec ce protocole et port>.
- adresse ou url (pour « Uniform Resource Locator », en anglais) du serveur météo: <champ à remplir par l'utilisateur>,
- droits de connexion au serveur météo (exemple login/mot de passe) <champ à remplir par l'utilisateur >,
- des paramètres d'accès au réseau. Leur usage sera décrit par la suite.
Selon une deuxième option, le formulaire de configuration FCOest contenu dans le QR code, en plus de IDOet KO.
Selon une troisième option (non représentée), le QR code contient, en plus de IDOet KOune adresse ou url d’une page internet du serveur du constructeur de l'objet, permettant de récupérer le formulaire de configuration correspondant à l’objet O.
Une fois le formulaire de configuration obtenu, l’application propose à l’utilisateur de compléter ou modifier certains paramètres du formulaire de configuration. Par exemple, il est affiché sur l’écran du terminal utilisateur, afin que l’utilisateur puisse saisir les valeurs qu’il souhaite pour ces paramètres en remplissant les champs correspondants.
Ces paramètres correspondent d'une manière générale à la liste des fonctionnalités FOque l'objet pourra exécuter. L'utilisateur pourra par exemple entrer :
- les adresses des correspondants AC que son objet pourra atteindre (exemple : url ou adresse IP, port de communication associé) ;
- les droits d'accès DA aux services liés à ces correspondants comprenant par exemple :
- des mots de passe pour accéder aux correspondants en question, ou
- des mots de passe temporaires servant à générer des nouveaux mots de passe pour se connecter aux correspondants en question (visant ainsi un masquage de ces mots de passe définitifs vis à vis du constructeur), et/ou
- des clés cryptographiques pour la même fonction, permettant une sécurité accrue grâce au chiffrement des données échangées,
- soit des données permettant à l'objet de négocier en pair à pair avec ses correspondants des clés cryptographiques pour la même fonction ;
- les paramètres d’accès réseau PA comprenant les informations permettant à l'objet de se connecter au réseau de communication RC. Il s’agit de données secrètes, qui comprennent par exemple :
- dans le cas d'un réseau d'accès Wifi, le mot de passe WPA2 de connexion au point d'accès Wifi, ou bien
- une clé de chiffrement des données échangées entre l'objet O et la passerelle réseau PR, ou bien
- une chaine d'octets permettant de négocier ensuite, entre l'objet et la passerelle réseau, une clé de chiffrement; ce mode pourrait être utilisé en particulier pour connecter l'objet directement à un réseau cellulaire,
- une identification des fréquences radios du réseau sur lequel l'objet s'accrochera ou plus généralement une identification du réseau RC.
Bien sûr, les paramètres listés ci-dessus ne constituent qu'un exemple. L’ensemble des paramètres configurés par l’utilisateur est variable selon le type d’objet communicant à configurer.
En outre, il est possible de laisser l’option à l'utilisateur de désactiver des fonctionnalités qu'il ne souhaite pas que son objet mette en œuvre.
Dans le cas d’un capteur météo, voici les champs du formulaire de configuration que l'utilisateur pourra être invité à remplir :
- les adresses des correspondants AC = l'url du serveur météo,
- les droits d'accès correspondants DA = login/mot de passe du serveur météo,
- les paramètres d'accès réseau = par exemple : nom-opérateur + chaine d'octets permettant de négocier ensuite entre l'objet et la passerelle réseau une clé de chiffrement.
Le formulaire de configuration FCOcomplété est enregistré par l’application du terminal utilisateur TU dans une mémoire du terminal d’utilisateur TU, 20.
On décrit maintenant une étape optionnelle 202 d’analyse d’un environnement de l’objet communicant O, préalable à la détermination de ses paramètres de configuration.
On désigne par environnement de l’objet :
- les équipements, objets communicants et terminaux utilisateurs, situés dans son voisinage et à sa portée, avec lesquels il pourrait être amené à communiquer ;
- un niveau de sensibilité de cet environnement.
L’analyse de l’environnement de l’objet vise à déterminer un niveau de sécurité nécessaire au bon fonctionnement de l'objet et d'adapter, en fonction de cette analyse, le paramétrage de l’objet et par conséquent le micrologiciel MLOde l'objet.
Par exemple, si l'objet est destiné à être installé dans un environnement sensible:
- les clés cryptographiques insérées dans le micrologiciel pourront être placées au sein d'un code offusqué,
- certaines fonctionnalités optionnelles, connues pour augmenter les risques d'attaques sur l'objet, pourront être désélectionnées lors de la génération du micrologiciel de l'objet.
Cette étape optionnelle peut être réalisée par une analyse en mode local. Ainsi, sur un réseau mettant en œuvre les protocoles IP, tel que par exemple selon la technologie Wifi, l'application du terminal utilisateur TU, 20 peut, par exemple, lancer une commande "ARP scan" (pour « Address Resolution Protocol », en anglais) pour déterminer les voisins potentiels de l'objet dans le réseau de communication RC, comme illustré par lafig. 5.
De façon alternative, cette étape comprend l’interrogation d’une base de données, locale ou distante, comprenant des informations sur des équipements présents dans le voisinage de l’objet O. Par exemple, cette base de données est comprise dans la passerelle résidentielle PR.
Avantageusement, cette étape d’analyse 202 précède l'étape d’interrogation du serveur du constructeur SC distant en vue d’obtenir le formulaire de configuration FC et la requête comprend une indication relative au niveau de sécurité requis. De la sorte, le serveur du constructeur SC adapte les champs du formulaire de configuration à ce niveau de sécurité. Par exemple, si l'objet est destiné à être installé dans un milieu sensible :
- on ne proposera de rentrer qu'une seul url,
- ou bien des fonctionnalités optionnelles, augmentant les risques d'attaques sur l'objet, ne seront pas proposées dans le formulaire.
Dans la suite de la description, nous désignerons par :
-FO: la liste des paramètres de configuration des fonctionnalités, valorisés par l'utilisateur dans le formulaire de configuration FCO,
- SO: l'ensemble des paramètres concernant l'objet, stocké dans l'application du terminal utilisateur TU, 20. Ainsi, SOcontient donc :
- l’identifiant de l’objet communicant IDO,
- la clé cryptographique symétrique KO,

- les paramètres FOde configuration des fonctionnalités de l’objet communicant,
- et éventuellement d’autres paramètres obtenus par l'application au cours des étapes 201 à 203 précédemment décrites, tels que par exemple, pour un capteur de température, des modalités de détection de la température (fréquence de mesures, …).
Une fois le paramétrage finalisé par l'utilisateur, ce dernier procède en 204 à l’enregistrement de l’objet communicant O auprès du serveur du constructeur SC, grâce à l'application de son terminal utilisateur TU, 20. Cette étape est illustrée par lafig. 6.
La connexion de l'application du terminal utilisateur TU au serveur SC du constructeur est classique, typiquement sur l’établissement d’une session HTTPS et la fourniture d’un login/mot de passe. Au cours de cette étape illustrée par lafig. 6, le terminal utilisateur transmet au serveur du constructeur SC un message de demande d’enregistrement comprenant l’identifiant de l’objet communicant O et ses paramètres FO.
Sur réception de ce message, le serveur SC enregistre les informations reçues et génère une version du micrologiciel MLOadaptée à l'objet communicant O, à partir des paramètres de configurationF O des fonctionnalités souhaitées par l’utilisateur.
Ainsi, dans le cas d’un capteur météo :
- le micrologiciel est adapté pour ne transmettre des informations que vers le serveur météo indiqué par l'utilisateur (url) dans le paramètre,
- le micrologiciel comprend les droits d'accès aux correspondants DA, tels que les login/mot de passe nécessaires à la connexion de l’objet communicant au serveur météo,
- le micrologiciel inclut les paramètres d'accès au réseau PA nécessaires à la connexion de l’objet communicant à l’équipement d’accès EA, 30 du réseau de communication RC, tels que le nom de l’opérateur + la chaine d'octets permettant de négocier ensuite une clé de chiffrement entre l'objet communicant O et l’équipement d’accès EA.
Préférentiellement, ce micrologiciel personnalisé MLOcomprend des instructions de désactivation de la première interface de communicationInt 1 de l'objet et des instructions d’activation de la deuxième interface de communicationInt 2 . De la sorte, la première interface, locale, ne sera plus utilisable une fois la phase de configuration terminée, au profit de la deuxième.
Si les paramètres DA contiennent des clés cryptographiques, un mécanisme d'offuscation de code ou un mécanisme de cryptographie de type boîte blanche (pour "whitebox", en anglais) qui consiste en une protection de la clé par méthode logicielle, peut être avantageusement appliqué pour protéger ces clés. Ce mécanisme pourra aussi être appliqué le cas échéant à d’éventuelles clés présentes dans les paramètres d’accès au réseau.
Lorsque le serveur du constructeur SC a terminé la génération et la personnalisation du micrologiciel de l'objet communicant O ou, de façon alternative, celles d'un script de configuration dans le cas où le micrologiciel serait trop volumineux pour être transmis, il en informe le terminal utilisateur afin que ce dernier puisse le télécharger. En variante, il lui transmet directement.
Ainsi, le micrologiciel personnalisé MLOde l’objet communicant est reçu par le terminal utilisateur TU, 20 en 205.
Au cours d’une étape 206, illustrée par lafig. 7, le terminal utilisateur TU, 20 se connecte à l’objet communicant O via sa première interface Int1, en mode local, laquelle, dans un mode de réalisation préférentiel est l’unique interface de communication de l’objet communicant O qui soit active à ce stade. On comprend que le fait que cette interface soit locale et ne permette pas d’accéder à un réseau étendu, comme Internet par exemple, contribue à sécuriser la phase de configuration de l’objet O.
Cette première interface Int1 est donc dédiée à l’installation du micrologiciel. Le terminal utilisateur TU établit un canal de communication chiffré Ckavec l’objet O en utilisant la clé cryptographique symétrique KO. Il s’agit par exemple d’une liaison de type Bluetooth.
Optionnellement, une fois le canal de communication Ckétabli, un échange de clés de type Diffie-Hellman est effectué afin de créer un deuxième canal de communication sécurisé CdHentre l'objet et le terminal utilisateur TU, 20. Ce deuxième canal est avantageusement utilisé pour transmettre le micrologiciel personnalisé à l'objet communicant O, car il permet de réduire les possibilités qu'un attaquant ayant usurpé la clé KOmais n'ayant pas assisté à l'échange de clés Diffie-Hellman puisse altérer le contenu du micrologiciel ou en capter le contenu.
A réception du micrologiciel MLO, l'objet l’installe en 101. Avantageusement la première interface de communication Int1est alors désactivée au profit de la deuxième interface Int2qui, une fois activée, rend l’objet apte à communiquer avec le réseau de communication RC.
Au cours d’une étape 207 illustrée par lafig. 8, le terminal utilisateur TU, 20 enregistre l’objet communicant O dans le réseau de communication RC, en particulier auprès d’un serveur SR de ce réseau connecté à l’équipement d’accès EA sur lafig. 1. Pour ce faire, il émet à destination de ce serveur SR un message de demande d’enregistrement comprenant au moins l’identité IDU-réseaude l’utilisateur dans le réseau RC, l’identifiant IDOde l’objet communicant et une partie appelée FO-réseaudes paramètres FOde configuration des fonctionnalités de cet objet. Il peut aussi fournir un mot de passe associé à l’identifiant IDU-réseaude l’utilisateur. Les paramètres FO-réseaudéterminent les fonctionnalités que le réseau RC doit connaître pour gérer les communications impliquant l’objet communicant O.
Dans le cas d’un capteur météo, les paramètres FO-réseaucomprennent les données suivantes :
- les adresses des correspondants AC = l'url du serveur météo,
- les paramètres d'accès au réseau PA = nom-opérateur + chaine d'octets permettant de négocier ensuite une clé de chiffrement entre l'objet et la passerelle réseau.
Avantageusement, l'utilisateur se connecte au serveur SR à l’aide de la même application logicielle que celle déjà utilisée durant les étapes précédentes. Cette application dispose donc déjà des paramètres FO.Les paramètres spécifiques FO-réseausont alors extraits de FOavant d’être transmis au serveur SR.
De façon alternative, l'utilisateur se connecte au serveur SR par un autre moyen que l'application logicielle utilisée lors des étapes précédentes. Par exemple, il a recours à un autre terminal utilisateur, comme l’ordinateur portable TU.
Dans tous les cas, les paramètres FO-réseauconfigurés aux étapes précédentes doivent être présentés au serveur SR selon une sémantique et une syntaxe compréhensible du réseau RC.
A réception de ces informations en 301, le serveur réseau SR enregistre l’objet communicant O, d’abord en stockant en 302 les informations reçues dans une mémoire, puis en les transmettant en 303 à l’équipement d’accès EA.
On distingue deux cas :
- Si le serveur SR est géré par l'utilisateur, le serveur SR et la l’équipement d’accès EA peuvent être intégrés à un seul et même équipement ou passerelle PR, comme illustré par lafig. 1. C’est le cas par exemple d’une passerelle Wifi d’un réseau local résidentiel, d’une passerelle d’un réseau local d’entreprise d’une usine ou d’une ville intelligente. ;
- Si le serveur SR est administré par un opérateur de réseau et si l’équipement d’accès EA est une passerelle d'accès à un réseau de communication mobile de type station de base, alors l'opérateur doit s'assurer que les fonctionnalités configurées par les paramètres FO-réseausont conformes aux dispositions du contrat signé par l'utilisateur avec cet opérateur. Le serveur SR effectue cette vérification auprès d’un Système d'Information de l'opérateur en lui transmettant un message de requête de vérification (non représenté sur lafig. 3) comprenant au moins l’identifiant de l’utilisateur IDU-réseauet les paramètres FO-réseauet en analysant la réponse reçue.
Par exemple, dans le cas du capteur météo, le système d'information SI vérifie que le contrat de l'utilisateur d'identité IDU-réseau prévoit bien qu'un de ses objets communicants puisse échanger des données avec un serveur dont l'url (ou l’adresse IP) est comprise dans les adresses de correspondants AC des paramètres FO-réseau .
On notera que dans ce deuxième cas, l’étape 207 d'enregistrement de l'objet sur le réseau est réalisée par le terminal utilisateur TU avant les 204 à 206, de sorte à n’installer le micrologiciel personnalisé MLOsur l’objet communicant O qu’une fois la vérification de conformité effectuée auprès du réseau RC.
Une fois l'enregistrement de l'objet effectué sur le serveur SR, ce dernier transmet donc en 303 à l’équipement d’accès EA les fonctionnalités FO-réseauà utiliser lors des communications prochaines de l'objet O dans le réseau RC à travers la passerelle PR. Comme illustré par lafig. 9, le serveur SR envoie un message à l’équipement d’accès EA comprenant au moins l’identifiant de l’utilisateur IDU-réseau, l’identifiant de l’objet IDOet les paramètres FO-réseau .
L’équipement d’accès EA reçoit ces informations en 401 et les enregistre dans une mémoire MEA. Elle est maintenant prête à établir une première connexion avec l’objet communicant O.
L’équipement d’accès EA peut donc être intégré à différents types de passerelles PR parmi lesquelles on cite de façon non exhaustive :
- Une passerelle de connexion à internet d'un réseau local (type "box" Wifi),
- Une passerelle de connexion à internet d'un réseau cellulaire,
- Une passerelle décentralisée d'un réseau cellulaire,
- Un nœud particulier d'un réseau maillé
- etc
En outre, l’équipement d’accès peut être implémenté sous la forme d'un élément matériel, tel qu’un équipement physique d’accès au réseau, mais aussi sous la forme d’une fonction réseau virtualisée, de type VNF (pour « Virtual Network Function », en anglais).
A ce stade, l’objet communicant O est maintenant configuré et on décrit en relation avec lafig. 3et lafig. 10ses échanges avec l’équipement d’accès EA dans une phase dite de fonctionnement.
Pour se connecter une première fois au réseau RC, l’objet communicant O émet un message de requête de connexion REQ-CONN1 par l’intermédiaire de sa deuxième interface Int2. Une liaison s’établit entre l’objet et l’équipement d’accès EA.
La sécurisation de cette liaison est basée sur les paramètres d'accès au réseau PA contenus dans les paramètres de configuration FO-réseauenregistrés par l’équipement d’accès EA pour l’objet O.
Cette sécurisation peut être implémentée selon diverses méthodes connues de l’homme de métier.
En tout état de cause, l’objet communicant O utilise les paramètres d'accès au réseau PA pour se connecter directement à l’équipement d’accès EA et de façon sécurisée, par exemple lorsque l’équipement d’accès EA est un équipement d’accès Wifi, intégré à une passerelle résidentielle ou professionnelle et si les paramètres PA contiennent le mot de passe WPA2 de connexion à ce point d'accès Wifi.
Avantageusement, lors de la première communication impliquant l’objet O via EA, une clé KO/EAcommune entre O et EA est négociée en pair à pair entre l'objet O et l’équipement d’accès EAau cours d’échanges 403, sur la base de données contenues dans les paramètres d’accès au réseau PA (typiquement une chaine d'octets) et d'un aléa transmis par l’équipement d’accès EA. Divers modes de réalisation sont possibles pour établir cette clé KO/EA, comme par exemple l'usage des principes Diffie-Hellman déjà cités. Ce mode de fonctionnement sécurisé est adapté à un réseau de communication cellulaire.
On comprend que du fait que l’équipement d’accès EA a précédemment reçu et stocké les paramètres réseaux configurés par le terminal utilisateur TU pour l’objet O, il est en mesure de négocier une clé réseau avec l’objet, sans qu’aucune intervention de l’opérateur du réseau cellulaire ne soit requise sur l’objet dans la phase de configuration.
Avantageusement, des mécanismes cryptographiques dits de "Proxy Re-Encryption" peuvent être utilisés pour apporter encore plus de sécurité; ceci en permettant :
- à l’objet communicant O de chiffrer les données qu’il transmet à l’équipement d’accès EA avec une clé K1,
- l’équipement d’accès EA de chiffrer des données en transit émises par l’objet à destination d’un correspondant par une autre clé K2dérivée de données contenues dans les paramètres PA ;
- à un correspondant de l’objet O de déchiffrer les données qu’il reçoit de lui avec une clé K3, les trois clés K1, K2et K3étant différentes.
Avantageusement, l’équipement d’accès EA selon l’invention est placé en coupure des flux de données FD émis et reçus par l’objet O et il est configuré pour vérifier en 404 que ces flux FD sont bien conformes aux fonctionnalités définies par les paramètresF O-réseau qu’il a enregistrés.
Quand des flux de données FD d’une communication COM impliquant l’objetOtraversent l’équipement d’accès EA, il consulte les paramètres FO-réseau pour déterminer si les contraintes stipulées par ces paramètres sont respectées. Dans le cas contraire, il prend des mesures de protection du réseau à l’encontre de l’objet O. Ces mesures peuvent consister en un rejet des paquets de données issus du flux, par l’émission d’un message d’avertissement à destination d'un terminal utilisateur, d’une coupure complète des communications impliquant l'objet.
Dans le cas du capteur météo, l’équipement d’accès EA vérifie si les adresses des correspondants et les modalités de communication comme les ports TCP sont autorisées, c’est-à-dire si ces adresses sont présentes dans le paramètre AC spécifiant les adresses des correspondants autorisés.
En outre, les flux de données transitant entre l’objet O et l’équipement d’accès EA sont protégés par un mécanisme de sécurité basé sur les paramètres d'accès réseau. Ceci permet de garantir la confidentialité au sein du réseau entre O et PR, dans l’éventualité de la présence d’un attaquant qui intercepterait les communications à ce niveau.
Dans le cas du capteur météo, les flux de données échangés sont chiffrés par la clé KO/EA. Ils sont déchiffrés par PR avec KO/PRavant d'être transmis vers les correspondants. De même, les flux issus des correspondants transitant par PR et à destination de O sont chiffrés par l’équipement d’accès EA avec la clé KO/EAavant d'être transmis vers l’objet O.
Bien sûr, comme évoqué précédemment, d’autres moyens de protection peuvent être mis en œuvre, comme par exemple la simple mise en œuvre d'un mode de passe contenu dans FO-réseau sans qu'une clé KO/EAsoit ensuite dérivée entre O et EA.
Dans le cas du capteur météo, la vérification effectuée par l’équipement d’accès EA garantit ainsi que :
- seul l'objet O d'identité IDOet associé aux paramètres d'accès réseau, comprenant notamment la chaine d'octets qui a permis d'établir la clé KO/EAentre l'objet O et l’équipement d’accès EA pourra se connecter à l’équipement d’accès EA; et
- cet objet O ne pourra échanger des données via l’équipement d’accès EA qu'avec les correspondants dont l’adresse est spécifiée dans le paramètre AC de FO-réseau(en l'occurrence l'url du serveur météo).
On considère maintenant plus particulièrement le cas où l’équipement d’accès EA est un équipement d’accès à un réseau cellulaire géré par un opérateur.
Du fait de l'obligation qui incombe à l’opérateur de tracer les correspondants des équipements connectés à son réseau, ce dernier doit s'assurer que le trafic impliquant l'objet communicant O est bien à destination ou en provenance d’un correspondant listé dans le paramètre AC de FO-réseau.
Pour ce faire, plusieurs solutions sont envisagées parmi lesquelles on peut citer à titre d’exemple:
- un mécanisme basé sur des certificats à clés publiques, de type HTTPS classique ou avec chiffrement des données entre l’équipement d’accès EA et le correspondant,
- un mécanisme dit de preuve de transit ou POT (pour "proof of transit", en anglais, décrit dans le document de travail intitulé « Proof of Transit », publié par l’IETF en octobre 2018 et disponible à l’adresse suivante https://tools.ietf.org/pdf/draft-ietf-sfc-proof-of-transit-01.pdf), basé sur un marquage des paquets d’un flux de données, qui permettent de vérifier leur passage par certains nœuds du réseau.
Dans un mode de réalisation, on applique un tel mécanisme à un flux de données émis par l’objet communicant O :
- les paquets issus de O et à destination du correspondant sont marqués d'un champ POT par l’équipement d’accès EA grâce à un secret partagé entre EA et le correspondant; le correspondant vérifie ce marquage sur chaque paquet reçu,
- de même, les paquets issus du correspondant et à destination de O sont marqués par un champ POT par le correspondant, grâce au secret partagé entre EA et le correspondant.
Dans un autre mode de réalisation, si le correspondant et un routeur proche du correspondant appartenant au réseau RC,ont déjà mis en place entre eux une liaison sécurisée, le marquage POT des paquets issus du correspondant peut être réalisé par ce routeur pourvu qu’il partage un secret avec PR. PR vérifiera que le paquet vient bien du routeur en question et en déduira, transitivement, que le paquet vient bien du correspondant, puisqu'il existe une liaison sécurisée entre le routeur et le correspondant.
De même, pour les paquets issus de l'objet O à destination du correspondant, c'est ce routeur proche qui vérifiera le bon marquage des paquets par PR avant de les retransmettre au correspondant.
En outre, pour plus de sécurité, les flux entre O et son correspondant peuvent être chiffrés ou/et signés par une clé cryptographique commune, dite clé de service, entre O et ce correspondant (le serveur météo dans notre exemple). Cette clé de service peut par exemple être négociée en début de session entre O et le correspondant (via EA comme tout autre flux) sur la base du contenu du paramètre DA (droits d'accès correspondants) spécifique à ce correspondant.
L’invention qui vient d’être décrite s’applique non seulement à la mise en service d’un nouvel objet communicant mais aussi à la mise à jour d’un objet communicant déjà en service.
Le procédé de configuration d’un objet communicant s’applique de façon similaire à la mise à jour d’un tel objet selon les mêmes étapes. L’utilisateur détermine les paramètres de configuration de l’objet et les transmet au serveur du constructeur en vue d’obtenir un micrologiciel personnalisé et mis à jour. Une fois reçu, il l’installe de façon sécurisée sur l’objet, en remplacement de l’ancien.
De la sorte, l’objet communicant est mieux protégé vis à vis des récentes attaques de sécurité. Cette mise à jour peut aussi donner l’occasion à l’utilisateur de modifier les fonctionnalités de l’objet.
Pour effectuer une telle mise à jour, l’utilisateur déclenche une procédure de remise-à-zéro. qui place l'objet dans un état où l'interface Int2devient inactive et où l'interface Int1redevient active. L'objet se retrouve ainsi dans le même état qu'avant l'installation du micrologiciel .
Comme évoqué précédemment, l’invention qui vient d’être décrite s’applique aussi à un objet communicant doté d’un élément de sécurité matériel. Elle contribue dans ce cas à apporter un niveau de sécurité supplémentaire grâce à la mise en œuvre des paramètres d’accès réseau configurés pour cet objet tel que décrit plus haut, ceci tout en procurant tous les autres avantages de l’invention déjà listés, à savoir :
- la possibilité pour l’utilisateur de configurer les fonctionnalités de l’objet ;
- la négociation d’une clé réseau sans l’intervention préalable de l’opérateur du réseau sur l’objet ;
- la vérification en temps réel des flux de données échangés par l’objet dans le réseau et leur conformité aux fonctionnalités configurées.
Ainsi l’invention qui vient d’être décrite dans ses différents modes de réalisation permet de sécuriser davantage la mise en service puis le fonctionnement d’un objet communicant dans un réseau de communication.
On présente maintenant, en relation avec lafig. 11, la structure matérielle d’un terminal utilisateur TU, 20 selon un mode de réalisation de l’invention, dans lequel ce terminal, intègre un module de configuration de paramètres réseau associés à l’objet communicant, un module d’enregistrement de l’objet communicant auprès d’un serveur constructeur distant, un module de transmission du micrologiciel reçu à l’objet communicant et un module d’enregistrement de l’objet communicant et de ses paramètres réseau auprès du réseau de communication.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel équipement terminal TU, 20 comprend une mémoire vive 23 (par exemple une mémoire RAM), une unité de traitement 22 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg1, représentatif du module de configuration de paramètres réseau associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication, du module d’enregistrement de l’objet communicant auprès d’un serveur constructeur, comprenant la transmission au serveur constructeur distant d’un identifiant de l’objet communicant et des paramètres d’accès configurés et la réception, en provenance du serveur constructeur, d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis, d’un module de transmission du micrologiciel reçu à l’objet communicant ; et d’un module d’enregistrement de l’identifiant de l’objet communicant et de ses paramètres réseau auprès du réseau de communication, stocké dans une mémoire morte 21 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 23 avant d'être exécutées par le processeur de l'unité de traitement 22. La mémoire vive 23 contient notamment les valeurs de l’identifiant de l’objet, de sa clé de chiffrement et de ses paramètres de configuration saisis par l’utilisateur pour l’objet communicant O. Le processeur de l’unité de traitement 22 pilote la configuration de paramètres réseau associés à l’objet communicant, l’enregistrement de l’objet communicant auprès d’un serveur constructeur comprenant la transmission d’un identifiant de l’objet communicant et des paramètres d’accès configurés et la réception, en provenance de l’équipement serveur constructeur, d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis, la transmission du micrologiciel reçu à l’objet communicant, et l’enregistrement de l’identifiant de l’objet communicant et de ses paramètres réseau auprès du réseau de communication, conformément au logigramme de lafig. 3.
Lafig. 11illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le terminal utilisateur TU 20, afin qu’il effectue les étapes du procédé de configuration d’un objet communicant tel que détaillé ci-dessus, en relation avec lafig. 3. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le terminal utilisateur TU, 20 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec un terminal utilisateur, mais peuvent plus généralement être mis en œuvre dans n’importe quel équipement terminal pourvu qu’il soit connectable localement à l’objet communicant et au réseau de communication.
On présente enfin, en relation avec lafig. 11, la structure matérielle d’un équipement d’accès selon un mode de réalisation de l’invention, dans lequel cet équipement intègre un module de réception d’une demande d’enregistrement de l’objet communicant en provenance du terminal utilisateur via un serveur réseau, un module d’enregistrement des paramètres réseau associés à l’objet communicant par l’équipement et un module de négociation d’une clé réseau à partir des paramètres réseau enregistrés, apte à être mis en œuvre lors d’une première demande de connexion au deuxième réseau de communication par l’objet communicant.
Le terme « module » peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions.
Plus généralement, un tel équipement d’accès comprend une mémoire vive 33 (par exemple une mémoire RAM), une unité de traitement 32 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur Pg2, représentatif du module de réception d’une demande d’enregistrement de l’objet communicant en provenance du terminal utilisateur, du module d’enregistrement des paramètres réseau associés à l’objet communicant par l’équipement et du module de négociation d’une clé réseau à partir des paramètres réseau enregistrés, stocké dans une mémoire morte 31 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 33 avant d'être exécutées par le processeur de l'unité de traitement 32. La mémoire vive 33 contient notamment les valeurs de l’identifiant de l’objet et de ses paramètres de configuration transmis par le terminal utilisateur. Le processeur de l’unité de traitement 32 pilote la réception d’une demande d’enregistrement de l’objet communicant en provenance du terminal utilisateur, l’enregistrement des paramètres réseau associés à l’objet communicant par l’équipement d’accès et l’établissement d’une connexion sécurisée avec l’objet communicant à partir des paramètres réseau enregistrés, par exemple en négociant une clé réseau, conformément au logigramme de lafig. 3.
En mode de fonctionnement normal, c’est-à-dire une fois l’objet communicant configuré, le processeur de l’unité de traitement 32 pilote aussi la vérification d’une conformité d’un flux de données échangé dans le réseau par l’objet communicant avec un correspondant aux paramètres réseau enregistrés pour cet objet.
Lafig. 11illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser l’équipement d’accès, afin qu’il effectue les étapes du procédé de connexion d’un objet communicant détaillé ci-dessus, en relation avec la fig. 3. En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d’instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où l’équipement d’accès est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d’instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation décrits ci-avant peuvent être mis en œuvre dans tous les équipements d’accès à un réseau de communication et situés en coupure entre l’objet communicant et le réseau de communication. Comme précédemment décrit, un tel équipement d’accès peut être intégré dans une passerelle résidentielle ou d’entreprise ou dans une station de base d’un réseau de communication cellulaire ou plus généralement dans tout type de passerelle réseau.

Claims (15)

  1. Procédé de configuration d’un objet communicant (O) apte à être connecté à un réseau de communication (RC), ledit réseau de communication comprenant au moins un équipement d’accès (EA) audit réseau, ledit objet comprenant une première interface (Int1) de connexion locale à un terminal d’utilisateur (TU) et une deuxième interface (Int2) de connexion audit équipement d’accès,
    caractérisé en ce queledit procédé est mis en œuvre par ledit terminal d’utilisateur (TU) et en ce qu’il comprend les étapes suivantes :
    - Configuration de paramètres réseau (FO) associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication (RC);
    - Enregistrement de l’objet communicant auprès d’un serveur constructeur distant (SC), comprenant la transmission au serveur constructeur d’un identifiant (IDO) de l’objet communicant et des paramètres réseau configurés et la réception, en provenance du serveur constructeur (SC), d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis;
    - Transmission du micrologiciel reçu à l’objet communicant via la première interface ;
    - Enregistrement de l’identifiant (IDO) de l’objet communicant et de ses paramètres réseau (FO) auprès du réseau de communication.
  2. Procédé de configuration d’un objet communicant selon la revendication 1,caractérisé en ce queledit micrologiciel comprend une commande d’activation de la deuxième interface et de désactivation de la première interface.
  3. Procédé de configuration d’un objet communicant selon l'une quelconque des revendications 1 à 2,caractérisé en ce quela configuration comprend la saisie de champs d’information d’un formulaire de configuration des paramètres réseau de l’objet communicant, le formulaire rempli étant transmis au serveur constructeur (SC).
  4. Procédé de configuration d’un objet communicant selon l'une quelconque des revendications 1 à 3,caractérisé en ce qu’ilcomprend une étape d’obtention de l’identifiant et d’une clé cryptographique par lecture d’un QR code comprenant au moins l’identifiant et la clé cryptographique et en ce que le micrologiciel est transmis à l’objet via un canal de communication chiffré par ladite clé.
  5. Procédé de configuration d’un objet communicant selon les revendications 3 et 4,caractérisé en ce quele QR code comprend en outre le formulaire de configuration des paramètres réseau.
  6. Procédé de configuration d’un objet communicant selon les revendications 4 et 5,caractérisé en ce quele QR code comprend en outre une adresse d’une page internet comprenant le formulaire de configuration des paramètres réseau.
  7. Procédé de configuration d’un objet communicant selon l'une quelconque des revendications 1 à 6,caractérisé en ce queles paramètres réseau comprennent en outre :
    - des adresses de correspondants que l’objet est autorisé à atteindre; et
    - des droits d’accès auxdits correspondants.
  8. Procédé de configuration d’un objet communicant selon l'une quelconque des revendications 1 à 7,caractérisé en ce quele procédé comprend en outre une étape d’analyse préalable d’un voisinage de l’objet communicant et une détermination d’un niveau de sécurité nécessaire au fonctionnement de l’objet communicant en fonction d’un résultat de l’analyse, les paramètres réseau étant configurés en fonction du niveau de sécurité déterminé.
  9. Procédé de configuration d’un objet communicant selon l’une quelconque des revendications 1 à 8,caractérisé en ce qu’il est déclenché lors d’une première connexion de l’objet communicant au réseau de communication ou suite à une réinitialisation de l’objet communicant.
  10. Terminal utilisateur (TU) adapté à configurer un objet communicant apte à être connecté à un réseau de communication (RC), caractérisé en ce qu’il comprend les modules suivants :
    - Configuration de paramètres réseau (FO) associés à l’objet communicant, lesdits paramètres réseau comprenant au moins des paramètres d’accès audit réseau de communication (RC);
    - Enregistrement de l’objet communicant auprès d’un serveur constructeur (SC) distant, comprenant la transmission d’un identifiant (IDO) de l’objet communicant et des paramètres d’accès configurés et la réception, en provenance de l’équipement serveur constructeur (SC), d’un micrologiciel adapté à l’objet communicant en fonction des paramètres réseau transmis;
    - Transmission du micrologiciel reçu à l’objet communicant via une première interface de connexion locale dudit objet; et
    - Enregistrement de l’identifiant de l’objet communicant et de ses paramètres réseau auprès du réseau de communication (RC).
  11. Procédé de connexion d’un objet communicant (O) à un réseau de communication, comprenant au moins un équipement d’accès (EA) audit réseau et un serveur réseau (SR),caractérisé en ce qu’il comprend :
    - Réception par le serveur réseau (SR), en provenance d’un terminal utilisateur, d’une demande d’enregistrement de l’objet communicant, ladite demande comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au deuxième réseau de communication ;
    - Transmission des paramètres réseau associés à l’objet communicant par le serveur réseau (SR) à l’équipement d’accès (EA) pour enregistrement ;
    - Lors d’une première demande de connexion au réseau de communication par l’objet communicant, établissement par l’équipement d’accès (EA) d’une connexion sécurisée avec l’objet communicant à partir des paramètres réseau enregistrés.
  12. Procédé de connexion d’un objet communicant à un réseau de communication, selon la revendication 11,caractérisé en ce que, lesdits paramètres réseaux comprenant en outre des adresses de correspondants autorisés et des droits d’accès à ces correspondants, sur réception d’un flux de données en provenance ou à destination de l’objet communicant, le procédé comprend une vérification d’une conformité du flux aux paramètres réseau enregistrés pour l’objet communicant.
  13. Equipement d’accès (EA) à un réseau de communication (RC) adapté à la connexion d’un objet communicant,caractérisé en ce qu’il comprend :
    - un module de réception d’une demande d’enregistrement de l’objet communicant en provenance d’un terminal utilisateur, ladite demande comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au réseau de communication,
    - un module d’enregistrement des paramètres réseau associés à l’objet communicant par l’équipement d’accès (EA) ;
    - un module d’établissement d’une connexion sécurisée avec l’objet communicant à partir des paramètres réseau enregistrés, apte à être mis en œuvre lors d’une première demande de connexion au deuxième réseau de communication par l’objet communicant.
  14. Passerelle résidentielle ou d’entreprise (PR) caractérisée en ce qu’elle comprend un équipement d’accès (EA) selon la revendication 13 et un serveur réseau (SR) apte à recevoir une demande d’enregistrement de l’objet communicant en provenance d’un terminal utilisateur, ladite demande d’enregistrement comprenant au moins des paramètres réseau associés audit objet communicant, lesdits paramètres comprenant au moins des paramètres d’accès au deuxième réseau de communication, le serveur réseau (SR) étant apte à transmettre les paramètres réseau reçus à l’équipement d’accès (EA) pour enregistrement.
  15. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l'une quelconque des revendications 1 à 9 et 11 à 12, lorsqu’il est exécuté par un processeur.
FR1902427A 2019-03-11 2019-03-11 Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants. Active FR3093882B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR1902427A FR3093882B1 (fr) 2019-03-11 2019-03-11 Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1902427 2019-03-11
FR1902427A FR3093882B1 (fr) 2019-03-11 2019-03-11 Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.

Publications (2)

Publication Number Publication Date
FR3093882A1 true FR3093882A1 (fr) 2020-09-18
FR3093882B1 FR3093882B1 (fr) 2022-04-08

Family

ID=67262630

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1902427A Active FR3093882B1 (fr) 2019-03-11 2019-03-11 Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.

Country Status (1)

Country Link
FR (1) FR3093882B1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140068719A1 (en) * 2012-09-04 2014-03-06 Nokia Corporation Method, apparatus, and computer program product for sharing wireless network configurations
US20140173059A1 (en) * 2012-12-13 2014-06-19 Google Inc. Device Commissioning
US20150248394A1 (en) * 2013-06-28 2015-09-03 Quickmii Corporation Automatically uploading user profile information
US9913143B1 (en) * 2016-11-28 2018-03-06 Amazon Technologies, Inc. Auto-provisioning device
US20180375665A1 (en) * 2017-06-21 2018-12-27 Microsoft Technology Licensing, Llc Device provisioning
US10169587B1 (en) * 2018-04-27 2019-01-01 John A. Nix Hosted device provisioning protocol with servers and a networked initiator

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140068719A1 (en) * 2012-09-04 2014-03-06 Nokia Corporation Method, apparatus, and computer program product for sharing wireless network configurations
US20140173059A1 (en) * 2012-12-13 2014-06-19 Google Inc. Device Commissioning
US20150248394A1 (en) * 2013-06-28 2015-09-03 Quickmii Corporation Automatically uploading user profile information
US9913143B1 (en) * 2016-11-28 2018-03-06 Amazon Technologies, Inc. Auto-provisioning device
US20180375665A1 (en) * 2017-06-21 2018-12-27 Microsoft Technology Licensing, Llc Device provisioning
US10169587B1 (en) * 2018-04-27 2019-01-01 John A. Nix Hosted device provisioning protocol with servers and a networked initiator

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
S. CHOW ET AL.: "conférence ACM Workshop on Digital Rights Management", 2002, SPRINGER, article "A white-box DES implementation for DRM applications", pages: 1 - 15

Also Published As

Publication number Publication date
FR3093882B1 (fr) 2022-04-08

Similar Documents

Publication Publication Date Title
EP1683388B1 (fr) Methode de gestion de la sécurité d&#39;applications avec un module de sécurité
EP1903746B1 (fr) Procédé de sécurisation de sessions entre un terminal radio et un équipement dans un réseau
EP2871876B1 (fr) Technique de configuration d&#39;accès sécurisé d&#39;un terminal invité à un réseau hôte
FR2877521A1 (fr) Dispositif, procede, programme et support de distribution d&#39;informations, d&#39;initialisation, dispositif, procede, programme et support de transfert d&#39;initialisation d&#39;authentification et programme de reception ...
EP2912594A1 (fr) Procede de fourniture d&#39;un service securise
FR3013541A1 (fr) Procede et dispositif pour la connexion a un service distant
EP2600587B1 (fr) Procédé d&#39;authentification d&#39;un terminal à un réseau de télécommunications
WO2018065707A1 (fr) Procédé et dispositif de détection d&#39;intrusions sur un réseau utilisant un algorithme de chiffrement homomorphe
US11831775B1 (en) Using secure tokens for stateless software defined networking
WO2019186006A1 (fr) Procédé de connexion sans fil d&#39;un objet communicant à un réseau de communication local, programme d&#39;ordinateur et équipement d&#39;accès correspondant
FR3103990A1 (fr) Procédés et applications de contrôle d’accès distribué à un réseau de télécommunications
EP3829101B1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
FR3093882A1 (fr) Procédé de configuration d’un objet communicant dans un réseau de communication, terminal utilisateur, procédé de connexion d’un objet communicant au réseau, équipement d’accès et programmes d’ordinateur correspondants.
EP1737191B1 (fr) Procédé de création d&#39;un terminal éclaté entre un terminal de base et des équipements connectés en serie
EP3149902B1 (fr) Technique d&#39;obtention d&#39;une politique de routage de requêtes émises par un module logiciel s&#39;exécutant sur un dispositif client
FR2813151A1 (fr) Communication securisee dans un equipement d&#39;automatisme
EP2290901A1 (fr) Dispositif électronique nomade configuré pour établir une communication sans fil sécurisé
FR2913841A1 (fr) Procede d&#39;acces a distance a un reseau,produit programme d&#39;ordinateur,moyen de stockage et dispositifs correspondants
FR3116978A1 (fr) Contrôle d’accès à un réseau de communication local, et passerelle d’accès mettant en œuvre un tel contrôle
FR3060163B1 (fr) Gestion d&#39;un reseau de communication local par classification d&#39;objets communicants en categories de confiance.
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
FR3052004B1 (fr) Procede d&#39;echange de donnees entre un objet connecte et un serveur central.
EP4068679A1 (fr) Authentification d&#39;un dispositif par un traitement cryptographique
FR3137238A1 (fr) Procédé de suspension d’un jeton de certification permettant d’authentifier l’établissement d’une connexion entre deux équipements de communication, dispositifs et programmes d’ordinateur correspondants
WO2022096824A1 (fr) Procede de delegation d&#39;acces a une chaine de blocs

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200918

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