FR3060163B1 - Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance. - Google Patents

Abstract

La gestion d'un réseau de communication local comprenant une pluralité d'objets communicants (11-17; 21) aptes à être connectés au réseau, et un serveur (10; 20) de configuration de paramètres d'accès des objets communicants au réseau, met en œuvre une authentification des objets communicants et une classification des objets communicants dans une catégorie de confiance en fonction d'un résultat de l'authentification.

Description

Gestion d'un réseau de communication local par classification d'objets communicants en catégories de confiance. 1. Domaine de l'invention

Le domaine de l'invention est celui des réseaux de communication locaux, notamment, mais non exclusivement, des réseaux de communication domestiques, comprenant une 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, etc.

Plus précisément, l'invention concerne la gestion d'une politique de sécurité au sein d'un tel réseau de communication local. 2. Art antérieur et ses inconvénients

Actuellement, lorsqu'un objet communicant est connecté dans un réseau de communication, et souhaite échanger des données sur ce réseau, il lui est nécessaire d'obtenir certains paramètres de configuration, et notamment une adresse IP (pour l'anglais « Internet Protocol »). Le protocole de configuration automatique le plus couramment utilisé pour ce faire est le protocole DHCP (pour l'anglais « Dynamic Host Configuration Protocol », protocole de configuration dynamique des hôtes).

Classiquement, l'objet communicant diffuse sur le réseau un datagramme DHCP DISCOVER. A réception, un serveur DHCP, présent par exemple dans la passerelle d'accès au réseau, envoie en réponse à l'objet communicant une offre DHCP OFFER, s'il est en mesure de proposer une adresse sur le réseau auquel appartient l'objet communicant. Une telle offre DHCP comporte l'adresse IP du serveur, ainsi que l'adresse IP et le masque de sous-réseau qu'il propose à l'objet communicant. S'il retient cette offre, l'objet communicant diffuse sur le réseau un datagramme de requête DHCP (DHCP REQUEST), qui comporte l'adresse IP du serveur et celle qui vient de lui être proposée. Elle a pour effet, notamment, de demander au serveur DHCP l'assignation de cette adresse, et l'envoi éventuel des valeurs de certains paramètres.

Le serveur DHCP élabore un datagramme d'accusé de réception (DHCP ACK pour acknowledgement) qui assigne à l'objet communicant l'adresse IP et son masque de sous-réseau, la durée du bail de cette adresse, et éventuellement d'autres paramètres, parmi lesquels l'adresse IP de la passerelle par défaut, et les adresses IP des serveurs DNS.

Le serveur DHCP, qui est le plus souvent intégré dans la passerelle d'accès au réseau local (la passerelle résidentielle dans le cas d'un réseau domestique), alloue ainsi des paramètres de configuration, de même nature et de même portée, à tous les objets communicants du réseau qui en font la demande, leur permettant, d'une part, d'accéder aux ressources et données du réseau local, et d'autre part, d'accéder au réseau mondial Internet.

Si ceci posait peu de problèmes à la genèse des réseaux locaux, lorsque seuls un ou deux ordinateurs personnels de type PC étaient présents sur le réseau, la multiplication du nombre d'objets communicants, de tous types, et de toutes provenances, pose à cette approche des problèmes de sécurité.

En effet, le risque est accru que l'un de ces objets communicants présente une ou plusieurs failles de sécurité, susceptibles de permettre à un individu malveillant de pénétrer sur le réseau local, par exemple par installation sur l'objet communicant d'un logiciel malveillant (en anglais « malware »), en vue d'y opérer des activités malveillantes, telles que du vol de données, ou une attaque de déni de service par exemple.

Il existe donc un besoin d'une technique de gestion des réseaux de communication locaux qui ne présente pas ces inconvénients de l'art antérieur, et permettre d'accroître leur sécurité vis-à-vis d'objets communicants susceptibles de présenter une faille de sécurité. 3. Exposé de l'invention L'invention répond à ce besoin en proposant un procédé de gestion d'un réseau de communication local comprenant une pluralité d'objets communicants aptes à être connectés au réseau et un serveur de configuration de paramètres d'accès des objets communicants au réseau. Un tel procédé de gestion met en oeuvre une authentification des objets communicants et une classification des objets communicants dans une catégorie de confiance en fonction d'un résultat de l'authentification.

Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion de la sécurité des réseaux de communication locaux, et notamment des réseaux domestiques, auxquels accèdent de multiples objets communicants de fiabilités diverses.

En effet, l'invention propose d'authentifier ces objets communicants, puis de les classer, en fonction du résultat de cette authentification, dans une catégorie de confiance adaptée. Le résultat de ce classement peut être mémorisé au sein du réseau de communication, par exemple dans une passerelle d'accès au réseau, afin d'être aisément accessible aux équipements du réseau local. Ainsi, par mise en place d'un simple mécanisme d'authentification, il est possible de vérifier si l'objet communicant qui souhaite accéder au réseau est fiable, et ainsi d'accroître la sécurité du réseau. Une telle authentification peut reposer sur tout mécanisme d'authentification connu, par exemple une certification avec clé publique et clé privée, une signature numérique, un jeton d'authentification, une cryptographie asymétrique, etc.

Selon un mode de réalisation, la catégorie de confiance appartient à un ensemble d'au moins deux catégories de confiance, comprenant : une catégorie d'objets communicants de confiance ; une catégorie d'objets communicants non fiables.

Ainsi, si l'authentification est un succès en ce qu'elle permet de vérifier que l'objet communicant fait partir d'une liste d'objets communicants équipés d'une version de logiciel embarqué fiables, alors l'objet communicant est classé dans la catégorie des objets communicants de confiance. A l'inverse, si l'authentification échoue, par exemple parce que l'objet communicant ne dispose pas de données d'authentification propres aux objets communicants de confiance, ce dernier est classé dans une catégorie d'objets communicants non fiables.

Selon un mode de réalisation, l'ensemble d'au moins deux catégories de confiance comprend également au moins une catégorie d'objets communicants insuffisamment fiables.

Une telle catégorie peut être assimilée à une catégorie d'objets communicants « en quarantaine », qui nécessitent par exemple de subir une mise à jour de leur logiciel embarqué (en anglais « firmware ») pour y corriger une faille de sécurité récemment détectée ou une opération de maintenance (par exemple une mise à jour des paramètres d'identification, tels qu'un mot de passe).

Ainsi, un objet communicant de la catégorie des objets communicants de confiance peut être classé dans la catégorie des objets communicants insuffisamment fiables lorsqu'on détecte que cette mise à jour du firmware ou cette opération de maintenance est nécessaire. Dès que la mise à jour ou l'opération de maintenance est effectuée, l'objet communicant peut réintégrer la catégorie des objets communicants de confiance, à l'issue d'une nouvelle authentification réussie.

Selon un mode de réalisation, préalablement à ladite authentification, un desdits objets communicants est par défaut classé dans ladite catégorie d'objets communicants non fiables.

Ainsi, par sécurité, un objet communicant qui rejoint le réseau de communication local sans utiliser le mécanisme de configuration automatique de l'invention est classé par défaut dans la catégorie des objets communicants non fiables. Il peut ensuite se déclarer de confiance, en procédant à une authentification selon un mode de réalisation de l'invention, et ainsi rejoindre la catégorie des objets communicants de confiance.

Selon un mode de réalisation, un tel procédé comprend une adaptation d'une offre d'accès audit réseau par lesdits objets communicants, en fonction de ladite catégorie de confiance dans laquelle ils sont classés.

Il est ainsi possible d'allouer des droits d'accès différents aux objets communicants, en fonction de la catégorie de confiance à laquelle ils appartiennent. Notamment, il est possible de mettre en place plusieurs sous-réseaux, présentant des politiques de sécurité différentes, au sein du réseau de communication local.

Par exemple, les équipements appartenant à la catégorie des objets communicants non fiables peuvent avoir des droits d'accès restreints par rapport aux objets communicants de confiance, et être cloisonnés dans un sous-réseau, sans possibilité d'accéder au reste du réseau de communication local : on réduit ainsi leur pouvoir de nuisance, et on évite leur accès à des données sensibles ou protégées (pas de possibilité pour l'objet potentiellement malveillant de « sniffer » le réseau local).

De même, un équipement appartenant à la catégorie des objets communicants insuffisamment fiables peut par exemple se voir refuser tout droit d'accès au réseau de communication local tant qu'il n'a pas procédé à la mise à jour requise de son logiciel embarqué. En variante, si cette mise à jour doit viser à corriger une faille de sécurité détectée sur l'un de ses ports de communication, il est aussi possible de bloquer ce port jusqu'à ce que la mise à jour ait été effectuée.

Selon un mode de réalisation, un tel procédé met en oeuvre un protocole de configuration dynamique de type DHCP (« Dynamic Host Configuration Protocol », en français, protocole de configuration dynamique des hôtes) et, lors de ladite authentification, il comprend : une étape d'envoi à un des objets communicants à authentifier d'une offre DHCP comprenant un challenge d'authentification à résoudre ; une étape de vérification d'une résolution du challenge d'authentification par l'objet communicant.

Un tel challenge d'authentification est par exemple transmis, avec le DHCP Offer, dans un champ d'option du protocole DHCP : il peut consister à demander à l'objet communicant de signer une chaîne unique aléatoire au moyen d'une clé privée de certification qu'il détient, et de renvoyer cette chaîne signée vers le serveur DHCP. Ce dernier peut alors procéder à la vérification de cette signature, à partir d'une clé publique de certification de l'objet communicant, dont il a connaissance.

Cette mise en oeuvre est simple et fiable, en ce qu'elle repose sur le protocole DHCP couramment utilisé, et exploite avantageusement un champ option de ce protocole déjà existant. L'invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé 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 gestion d'un réseau de communication local 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 contrôle d'affichage précité. L'invention concerne également un serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, et une passerelle d'accès à un réseau de communication présentant en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document.

Notamment, un tel serveur de configuration comprend un processeur apte à mettre en oeuvre le procédé décrit précédemment, et la passerelle d'accès, par exemple une passerelle résidentielle de type Livebox®, intègre un serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, par exemple un serveur DHCP.

Le serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, la passerelle d'accès 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 gestion d'un réseau de communication local selon la présente invention. 4. 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 : la figure 1 présente une vue schématique d'un réseau local de communication et des différents objets communicants qui y sont connectés, selon un mode de réalisation de l'invention; la figure 2 présente sous forme de logigramme les différentes étapes du procédé de gestion selon un mode de réalisation de l'invention; la figure 3 propose un schéma synoptique d'un serveur DHCP ou d'une passerelle d'accès mettant en oeuvre le procédé de la figure 2. 5. Description détaillée de modes de réalisation de l'invention

Le principe général de l'invention repose sur la classification, en différentes catégories de confiance, des objets communicants susceptibles d'être connectés dans un réseau de communication local, en fonction du résultat d'une phase d'authentification au sein de ce réseau.

On s'attache plus en détail dans la suite de ce document à décrire la mise en oeuvre d'un mode de réalisation de l'invention dans le cadre d'un réseau domestique, chez un utilisateur particulier. L'invention s'applique bien sûr également à tout autre type de réseau de communication local (LAN, pour « Local Area Network »), auquel une pluralité d'équipements de communication sont connectés.

Dans un tel réseau domestique, représenté schématiquement sur la figure 1, une passerelle résidentielle HGW référencée 10 permet de relier un réseau de communication local et un réseau étendu tel que le réseau Internet (non représenté). Une telle passerelle résidentielle HGW 10 intègre un serveur DHCP : elle effectue le routage des paquets de données sur le réseau, et peut également jouer le rôle de pare-feu, de proxy, ...

Le serveur DHCP peut bien sûr également être dissocié de la passerelle résidentielle HGW 10, dans un autre mode de réalisation.

Dans l'exemple de la figure 1, de nombreux équipements sont présents sur le réseau local, à savoir : un téléphone intelligent (ou « smartphone ») 11 ; un ordinateur portable 12 ; un ordinateur de type PC 13 ; une tablette 14 ; une station météo 15 ; une webcam 16; un thermostat 17.

Cette liste n'est bien sûr pas exhaustive, et de nombreux autres objets communicants peuvent être présents sur le réseau local de l'utilisateur. Ces objets communicants peuvent être reliés au réseau par voie filaire (câble Ethernet, port USB (pour l'anglais « Universal Serial Bus »)...) ou sans fil (Wi-Fi®, Bluetooth, zigbee). Ils comprennent tous types d'objets physiques, aptes à communiquer numériquement sur le réseau local, en vue d'un échange de données, et qui sont compatibles avec le réseau DHCP. Ils comprennent é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 local. 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 oeuvre d'une passerelle loT 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.

De tels objets communicants peuvent être désignés par l'acronyme loT, pour l'anglais « Internet of Things », en français « Internet des objets ».

Parmi les objets communicants de la figure 1, on peut imaginer que le téléphone intelligent 11 et la tablette 14 aient été fournis à l'utilisateur par un Fournisseur d'Accès Internet (FAI), qui a également fourni à l'utilisateur l'équipement de terminaison de réseau que constitue la passerelle résidentielle HGW 10. De ce fait, le fournisseur d'accès connaît ces équipements 11, 14, et peut en garantir la fiabilité. A l'inverse, d'autres objets communicants comme la webcam 16 ou la station météo 15 peuvent provenir d'autres sources et d'autres provenances : le fournisseur d'accès ne dispose a priori d'aucun contrôle sur l'existence de potentielles failles de sécurité sur ces objets communicants, ni sur la possibilité de procéder à une mise à jour des logiciels qu'ils embarquent (« firmware »), en cas de détection d'une éventuelle faille de sécurité.

Il est donc important de pouvoir classer ces différents objets communicants référencés 11 à 17 dans des catégories de confiance appropriées, afin notamment d'adapter les droits alloués à ces différents objets par le serveur DHCP embarqué dans la passerelle résidentielle HGW 10, et ce, afin d'améliorer la sécurité du réseau local vis-à-vis d'éventuelles attaques malveillantes.

Pour ce faire, un mode de réalisation de l'invention repose sur le logigramme de la figure 2.

Un objet communicant loT 21 (par exemple l'ordinateur portable 12 de la figure 1), présent sur le réseau domestique, est dépourvu d'adresse IP, mais souhaite accéder aux ressources du réseau, ou au réseau Internet. Il envoie alors en mode de diffusion (« broadcast ») un datagramme DHCP DISCOVER 25 qui s'adresse aux serveurs DHCP présents sur le réseau local. Ce datagramme comporte notamment l'adresse physique (MAC pour Media Access Control) de l'IoT 21.

Dans l'exemple du réseau de la figure 1, un unique serveur DHCP référencé 20 est présent sur le réseau local, par exemple intégré dans la passerelle résidentielle HGW 10. S'il est en mesure de proposer une adresse sur le réseau local, ce dernier envoie alors une offre DHCP (DHCP OFFER 26) à l'attention de l'objet communicant loT 21, identifié par son adresse physique. Cette offre comporte l'adresse IP du serveur 20, ainsi que l'adresse IP et le masque de sous-réseau qu'il propose à l'IoT 21.

Selon un mode de réalisation de l'invention, cette offre DHCP 26 comporte également un challenge Chall., par exemple sous la forme d'une chaîne unique aléatoire, que l'objet communicant 21 va devoir signer au moyen d'une clé privée de certification KPR 233, s'il dispose d'une telle clé. Un tel challenge Chall. est par exemple inséré par le serveur SERV. DHCP 20 dans un champ d'option du protocole DHCP. A réception, si l'objet communicant loT 21 dispose d'une clé privée de certification KPR 233, il diffuse sur le réseau un datagramme de requête DHCP (DHCP REQUEST 27), auquel il a ajouté un drapeau (en anglais « flag ») d'acceptation du challenge Chall. Acc.

Ce datagramme comporte l'adresse IP du serveur 20 et celle qui vient d'être proposée à l'objet communicant loT 21. Elle a pour effet de demander au serveur 20, l'assignation de cette adresse et l'envoi éventuel des valeurs de certains paramètres. L'objet communicant loT 21 envoie ensuite au serveur 20 la résolution du challenge qui lui a été adressé RES (Chall., KPR) 28. Cette résolution correspond à la chaîne aléatoire Chall. signée par l'IoT 21 au moyen de la clé privée KPR 233. A réception, le serveur SERV. DHCP 20 vérifie cette signature au moyen de la clé publique KPU 232, associée à l'objet communicant loT 21, et à la version du logiciel qu'il embarque. Cette clé publique KPU 232 est par exemple mémorisée dans la passerelle résidentielle HGW 10, en association avec un identifiant de l'objet communicant loT 21, et un identifiant d'une version de firmware.

Cette clé publique KPU 232, ainsi que l'ensemble des clés publiques des objets communicants du réseau, est envoyée (flèche référencée 24) au serveur DHCP 20 par un serveur magasin de clés publiques de certifications MAG(KPU) 22.

La synchronisation des données stockées dans le serveur magasin MAG(KPU) 22 et dans la passerelle résidentielle HGW 10, ou dans le serveur DHCP 20, s'effectue à intervalles de temps réguliers, par exemple la nuit, par envoi 24 des mises à jour des clés publiques de certification KPU 23l

Les clés publiques de certification KPU 23i peuvent être directement fournies au serveur magasin MAG(KPU) 22 par les fabricants d'objets communicants.

Après vérification par le serveur DHCP 20 que la résolution du challenge RES (Chall., KPR) 28 est exacte, ce dernier élabore un datagramme d'accusé de réception 29 (DHCP ACK pour acknowledgement) qui assigne au client 21 l'adresse IP et son masque de sous-réseau, la durée du bail de cette adresse, et éventuellement d'autres paramètres, tels que l'adresse IP de la passerelle 10, et les adresses IP des serveurs DNS (pour « Domain Name Server »).

En l'espèce, l'adresse IP indiquée dans le datagramme 29 DHCP ACK (IPtrust), correspond à une adresse IP du sous-réseau des objets communicants de confiance, qui offre à ces derniers des droits et un accès étendus aux ressources du réseau local.

Ainsi, l'objet communicant loT 21 va pouvoir bénéficier d'un routage spécifique aux objets communicants de confiance, ou « trustés », à partir : d'une adresse IP « trustée », par exemple 192.168.2.22 ; d'un masque de réseau « trusté », par exemple 255.255.0.0 ; de l'adresse IP d'un routeur spécifique, par exemple 192.168.2.1 ; de l'adresse IP d'un serveur DNS spécifique, par exemple 192.168.2.1.

Un identifiant de l'objet communicant loT 21, qui vient donc d'être authentifié comme faisant partie de la catégorie des objets communicants de confiance, peut être mémorisé dans la passerelle HGW 10, dans une zone dédiée à cette catégorie de confiance, ou en association avec une donnée représentative de cette catégorie de confiance.

Si, en revanche, l'objet communicant loT 21 (par exemple la webcam 16) ne dispose pas d'une clé privée de certification KPR 233, il peut choisir, à réception du datagramme DHCP OFFER 26, d'accepter ou non le challenge Chall. S'il n'accepte pas le challenge Chall., il renvoie au serveur DHCP 20 un datagramme DHCP REQUEST 27, dans lequel il n'a pas positionné de flag (« drapeau ») d'acceptation du challenge. A réception, le serveur DHCP 20 en déduit donc directement qu'il ne s'agit pas d'un objet communicant à classer dans la catégorie des objets communicants de confiance, dans la mesure où il ne dispose pas de la clé privée de certification KPR 233 lui permettant de s'authentifier avec succès. Il classe alors cet objet communicant loT 21 dans la catégorie des objets communicants non fiables, et mémorise un identifiant de cet objet communicant loT 21 en conséquence, en association avec cette catégorie non fiable.

Il renvoie un datagramme DHCP ACK 29, dans lequel l'adresse IP allouée à l'objet communicant loT 21 correspond à un sous-réseau dans lequel sont cloisonnés les objets communicants non fiables, qui disposent d'accès restreints aux ressources du réseau local. Par exemple, l'objet communicant loT 21 peut accéder au réseau Internet, mais ne peut pas accéder au reste du réseau local, afin notamment de l'empêcher de « sniffer » ce réseau. On limite ainsi la possibilité que cet objet communicant non fiable loT 21 soit utilisé pour des attaques malveillantes contre le réseau. De même, les paramètres du routeur ou l'adresse du serveur DNS renvoyé dans ce datagramme DHCP ACK 29 peuvent être adaptés à cette catégorie d'objets communicants non fiables.

Lorsque l'objet communicant loT 21 (par exemple le thermostat 17) ne dispose pas d'une clé privée de certification KPR 233, mais qu'il choisit, à réception du datagramme DHCP OFFER 26, d'accepter le challenge Chall. il renvoie au serveur DHCP 20 un datagramme DHCP REQUEST ΊΊ, dans lequel il a positionné le flag (« drapeau ») d'acceptation du challenge.

Cependant, ne disposant pas de clé privée de certification KPR 233, il n'est pas en mesure de fournir au serveur DHCP 20 une résolution de challenge RES (Chall., KPR) 28 exacte ou correcte.

Le serveur DHCP en déduit donc que cet objet communicant loT 21 doit être classé dans la catégorie des objets communicants non fiables, et mémorise un identifiant de cet objet communicant loT 21 en conséquence, en association avec cette catégorie non fiable.

Il renvoie un datagramme DHCP ACK 29, dans lequel l'adresse IP allouée à l'objet communicant loT 21 correspond au sous-réseau dans lequel sont cloisonnés les objets communicants non fiables, qui disposent de droits restreints. De même, les paramètres du routeur ou l'adresse du serveur DNS renvoyé dans ce datagramme DHCP ACK 29 peuvent être adaptés à cette catégorie d'objets communicants non fiables. Par exemple, comme précédemment, l'objet communicant loT 21 peut accéder au réseau Internet, mais ne peut pas accéder au reste du réseau local, afin notamment de l'empêcher de «sniffer» ce réseau. On limite ainsi la possibilité que cet objet communicant non fiable loT 21 soit utilisé pour des attaques malveillantes contre le réseau.

Il est également possible que l'objet communicant loT 21 dispose d'une clé privée de certification KPR 233, mais que cette dernière corresponde à un certificat révoqué par le fournisseur d'accès, suite à la détection d'une faille de sécurité sur cet objet 21.

Une telle faille de sécurité peut nécessiter une mise à jour du logiciel embarqué sur l'objet communicant loT 21; elle peut également nécessiter une simple maintenance de cet objet (par exemple, un changement des identifiant et mot de passe, qui auraient été laissés par l'utilisateur dans leur paramétrage par défaut, sans être personnalisés).

Dans ce cas, à détection de cette faille, le serveur magasin MAG (KPU) 22 envoie (24) au serveur DHCP 20 une clé publique mise à jour 23i, 232 pour l'objet communicant loT 21.

Ainsi, lorsque l'objet communicant loT 21 cherche à obtenir une adresse IP, il diffuse un datagramme DHCP DISCOVER 25, puis une requête DHCP REQUEST 27, dans laquelle il accepte le challenge Chall. proposé par le serveur DHCP 20.

Il tente ensuite de résoudre le challenge, au moyen de sa clé privée de certification KPR 233, et renvoie le résultat RES (Chall., KPR) 28 au serveur DHCP 20. Cependant, la vérification de cette résolution échoue, car la clé privée de certification KPR 233 utilisée pour la signature correspond par exemple à une version du firmware obsolète, qui nécessite d'être mise à jour.

Le serveur DHCP 20 en déduit donc que l'objet communicant loT 21 doit être classé dans une catégorie de mise en quarantaine, qui correspond à celle des objets communicants non suffisamment fiables, car ils nécessitent une mise à jour logicielle, ou une opération de maintenance. Il mémorise un identifiant de l'objet communicant loT 21, en association avec la catégorie de mise en quarantaine.

On peut bien sûr envisager qu'il existe plusieurs catégories de mise en quarantaine, en fonction de la gravité de la faille de sécurité détectée sur l'objet communicant, ou en fonction de la nature de l'action à effectuer (mise à jour, maintenance) pour réparer cette faille. L'objet communicant loT 21 pouvait avoir été précédemment mémorisé dans la passerelle HGW 10 dans la catégorie des objets communicants de confiance, mais être ainsi basculé dans la catégorie des objets communicants non suffisamment fiables, ou en attente de mise à jour.

Dans ce cas, plusieurs options peuvent être envisagées par le serveur DHCP 20.

Il peut par exemple décider d'empêcher toute utilisation de l'objet communicant loT 21, tant que la mise à jour de son logiciel embarqué n'a pas été effectuée. Dans ce cas, il renvoie à l'objet communicant loT 21 un datagramme DHCP ACK 29, dans lequel l'adresse IP qui lui est allouée ne lui permet d'accéder qu'au seul serveur de mise à jour logicielle.

Si la faille de sécurité détectée est associée à un port de communication spécifique de l'objet communicant 21, par exemple le port 153, le serveur DHCP 20 peut choisir de bloquer uniquement ce port de communication 153, mais d'autoriser l'accès aux ressources du réseau par les autres ports de communication de l'objet communicant 21. Dès que la mise à jour est faite, et que l'objet communicant loT 21 a en conséquence récupéré une nouvelle clé privée de certification KPR 233 associée à la dernière version à jour de son firmware, il peut à nouveau s'authentifier avec succès auprès du serveur DHCP 20, qui le classe à nouveau dans la catégorie des objets communicants de confiance, et lui réalloue la totalité des droits d'accès accordés à ces objets de confiance. A chaque expiration du bail alloué aux adresses IP, les objets communicants du réseau local doivent relancer une demande d'adresse IP auprès du serveur DHCP 20, et réussir à s'authentifier avec succès auprès de ce dernier, comme décrit ci-dessus. A cette occasion, les objets communicants peuvent changer de catégorie de confiance, et passer par exemple d'une catégorie d'objets communicants non fiables (« untrusted »), à une catégorie d'objets communicants de confiance (« trusted »), ou passer d'une catégorie d'objets communicants de confiance (« trusted »), à une catégorie d'objets communicants non suffisamment fiables (« need update » ou « need maintenance »).

On notera que dans l'exemple particulier de réalisation présenté en relation avec la figure 2, l'authentification des objets communicants repose sur l'utilisation de certificats, et sur un mécanisme de challenge cryptographique au moyen de clés privée et publique. Tout autre mécanisme d'authentification peut bien sûr être mis en oeuvre dans le cadre de la présente invention, tel qu'un simple échange de mot de passe par exemple.

On présente désormais, en relation avec la figure 3, la structure matérielle d'une passerelle résidentielle HGW 10 selon un mode de réalisation de l'invention, dans lequel le serveur DHCP 20, intégrant une unité d'authentification et de classification des objets communicants, est dans la passerelle 10.

Le terme « unité» 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 oeuvre une fonction ou un ensemble de fonctions.

Plus généralement, une telle passerelle résidentielle HGW 10 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, représentatif de l'unité d'authentification et de classification des objets communicants, stocké dans une mémoire morte 61 (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 63 contient notamment les clés publiques KPU des objets communicants décrites ci-avant en relation avec la figure 2, ainsi que, pour chaque objet communicant, une association identifiant de l'objet/catégorie de confiance. Le processeur de l'unité de traitement 32 pilote l'émission des datagrammes DHCP OFFER 26, la vérification de l'authentification (par exemple la vérification des résolutions de challenge RES (Chall., KPR) 28), ainsi que l'affectation des ressources réseau aux objets communicants, en fonction du résultat de l'authentification (émission du datagramme DHCP ACK 29) conformément au logigramme de la figure 2.

La figure 3 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser la passerelle résidentielle HGW, afin qu'elle effectue les étapes du procédé détaillé ci-dessus, en relation avec la figure 2. 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ù la passerelle résidentielle HGW 10 est réalisée 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 une passerelle résidentielle de type Livebox®, mais peuvent plus généralement être mis en oeuvre dans toutes les passerelles, routeurs, serveurs DHCP...

Claims (10)

1. REVENDICATIONS

   1. Procédé de gestion d'un réseau de communication local comprenant une pluralité d'objets communicants (11-17 ; 21) aptes à être connectés audit réseau et un serveur (10 ; 20) de configuration de paramètres d'accès desdits objets communicants audit réseau, caractérisé en ce qu'il met en oeuvre une authentification desdits objets communicants (11-17; 21) et une classification desdits objets communicants dans une catégorie de confiance en fonction d'un résultat de ladite authentification.
2. 2. Procédé de gestion d'un réseau de communication local selon la revendication 1, caractérisé en ce que ladite catégorie de confiance appartient à un ensemble d'au moins deux catégories de confiance, comprenant : une catégorie d'objets communicants de confiance ; une catégorie d'objets communicants non fiables.
3. 3. Procédé de gestion d'un réseau de communication local selon la revendication 2, caractérisé en ce que ledit ensemble d'au moins deux catégories de confiance comprend également au moins une catégorie d'objets communicants insuffisamment fiables.
4. 4. Procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 2 et 3, caractérisé en ce que, préalablement à ladite authentification, un desdits objets communicants est par défaut classé dans ladite catégorie d'objets communicants non fiables.
5. 5. Procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 2 à 4, caractérisé en ce qu'il comprend une adaptation d'une offre d'accès (29) audit réseau par lesdits objets communicants (11-17; 21), en fonction de ladite catégorie de confiance dans laquelle ils sont classés.
6. 6. Procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il met en oeuvre un protocole de configuration dynamique de type DHCP (« Dynamic Host Configuration Protocol », en français, protocole de configuration dynamique des hôtes) et en ce que, lors de ladite authentification, il comprend : une étape d'envoi (26) à un desdits objets communicants (21) à authentifier d'une offre DHCP comprenant un challenge d'authentification à résoudre ; une étape de vérification d'une résolution (28) dudit challenge d'authentification par ledit objet communicant.
7. 7. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté par un processeur.
8. 8. 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 gestion d'un réseau de communication local selon l'une quelconque des revendications 1 à 6.
9. 9. Serveur (10; 20) de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, caractérisé en ce qu'il comprend un processeur (32) apte à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 6.
10. 10. Passerelle (10) d'accès à un réseau de communication, caractérisée en ce qu'elle comprend un serveur (20) de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local selon la revendication 9.