FR3061385A1 - Dispositif d'acces securise - Google Patents

Abstract

L'invention concerne un procédé de gestion, sur un serveur (6) d'un réseau étendu (3), d'un service de communication à distance entre un terminal (7) et un objet d'un réseau local (1). Le terminal et l'objet sont aptes à communiquer via une passerelle (2) du réseau local. Le procédé comporte les étapes suivantes sur le serveur : - réception (E28), en provenance du terminal, d'un message de requête (GETCAM@) d'accès au service ; - génération (E29) d'une adresse du service (@CAM) ; - envoi vers la passerelle (E29) d'une commande de redirection (SPF) de l'adresse générée du service, ladite commande comprenant au moins une durée de validité (LT) à l'issue de laquelle l'adresse générée devient invalide ; - envoi vers le terminal (E30) de l'adresse générée du service (@CAM).

Description

Titulaire(s) :

Demandeur(s) : ORANGE Société anonyme — FR.

Inventeur(s) : HERVE.

FONTAINE FABRICE et MARCHAND

ORANGE Société anonyme.

(® Mandataire(s) : ORANGE.

FR 3 061 385 - A1 ® DISPOSITIF D'ACCES SECURISE.

(® L'invention concerne un procédé de gestion, sur un serveur (6) d'un réseau étendu (3), d'un service de communication à distance entre un terminal (7) et un objet d'un réseau local (1). Le terminal et l'objet sont aptes à communiquer via une passerelle (2) du réseau local. Le procédé comporte les étapes suivantes sur le serveur:

- réception (E28), en provenance du terminal, d'un message de requête (GETCAM@) d'accès au service;

- génération (E29) d'une adresse du service (@CAM);

- envoi vers la passerelle (E29) d'une commande de redirection (SPF) de l'adresse générée du service, ladite commande comprenant au moins une durée de validité (LT) à l'issue de laquelle l'adresse générée devient invalide;

- envoi vers le terminal (E30) de l'adresse générée du service (@CAM).

I I I

I I

I I

I	Ez3 |------------------| E40 | ! OK ί
I	F24 « E41
	SPF —. i =251 I
i Gt- -L-η UPDATE |	UPDATE φ -F i I I
I I	p'7|NTF2(@PS_^|E'?|
I I I I	getcau® [SS]
! k t	SPF |
	T=3. frp= 50000) i 1 I
!	=30 >| E44
!	STREAM(@CAM) 1 — , 1 lyl
	| ; NTF3(@) 1 E3i F.-ie |

Dispositif d'accès sécurisé

Domaine technique

L'invention se rapporte au domaine général des réseaux de télécommunication et plus particulièrement aux communications entre un objet connecté d'un réseau local et un terminal.

De manière générale, l'invention s'applique aux équipements d'un tel réseau.

Etat de la technique

Un réseau local, aussi appelé dans la suite réseau domestique, est un réseau informatique qui relie ensemble, avec ou sans fils, les équipements terminaux, ou plus simplement terminaux, d'une maison (ordinateurs, périphériques d'impression, de stockage, objets connectés, etc.), aptes à communiquer ensemble. Un réseau domestique comporte un équipement routeur, aussi communément appelé passerelle, élément intermédiaire assurant la redirection, ou routage, des paquets de données entre les différents terminaux et réseaux qui lui sont connectés. L'utilisateur d'un tel réseau peut exécuter un service donné sur un terminal donné disposant de caractéristiques propres (par exemple, commander une caméra, ouvrir une porte, etc.), depuis son réseau local ou depuis un réseau large bande via la passerelle.

Un tel terminal est appelé dans la suite un objet connecté (en anglais : IoT pour

Internet of Things).

Au nombre de ces objets connectés, les dispositifs de prise d'images, ou caméras, prennent une importance considérable. Pour accéder au flux de données multimédia (images, son, vidéo) d'une caméra connectée depuis l'extérieur de son domicile, l'utilisateur doit aujourd'hui configurer la passerelle. Cette configuration permet d'accéder au flux via la passerelle, en se connectant à cette dernière sur une sous-adresse particulière, aussi appelée « port », affectée au flux, depuis l'extérieur du réseau. Or actuellement, la plupart des caméras connectées du marché fournissent un flux de données non chiffrées. Le flux est donc accessible pour quiconque connaît l'adresse de la passerelle et le numéro de port du flux. Or de nombreuses applications, malveillantes ou non, sont aujourd'hui capables de réaliser un tel accès.

Pour sécuriser le flux, et éviter qu'une personne autre que le propriétaire de la caméra s'y connecte, il serait possible de chiffrer le flux, soit au niveau de la caméra, soit au niveau de la passerelle. Cependant ces solutions ne sont pas envisageables car elles sont trop coûteuses en termes de ressources (CPU, mémoire, etc.) et imposent un partage de la clé de chiffrement/déchiffrement entre les entités de chiffrement et de déchiffrement.

L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.

L'invention

A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé de gestion, sur un serveur d'un réseau étendu, d'un service de communication à distance entre un terminal et un objet d'un réseau local, le terminal et l'objet étant aptes à communiquer via une passerelle du réseau local, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes sur le serveur :

réception, en provenance du terminal, d'un message de requête d'accès au service ;

génération d'une adresse du service ;

envoi vers la passerelle d'une commande de redirection de l'adresse générée du service, ladite commande comprenant au moins une durée de validité à l'issue de laquelle l'adresse générée devient invalide ;

envoi vers le terminal de l'adresse générée du service.

Par « service de communication », on entend ici un service offert par l'objet du réseau local associé à la passerelle, par exemple la mise à disposition d'un flux vidéo par une caméra, ou de fichiers par un disque réseau, etc.

Par « service de communication à distance », on entend que ce service peut être accédé de l'extérieur du réseau local de l'objet connecté, notamment depuis un réseau étendu, ou large bande, aussi appelé WAN (pour Wide Area Network).

Par « adresse du service », on entend l'adresse, par exemple une URL, à laquelle le service souhaité est accessible (par exemple, l'adresse pour obtenir le flux vidéo streamé de la caméra).

Par « serveur », on entend un dispositif situé dans le réseau étendu, apte à offrir de tels services à des terminaux.

Ainsi, l'invention permet au terminal, situé de préférence dans le réseau étendu, de demander au serveur une adresse pour accéder au service de l'objet connecté (par exemple le flux vidéo). Le serveur construit l'adresse extérieure d'accès au service (typiquement, une URL comportant un numéro de port et l'adresse extérieure de la passerelle). La passerelle reçoit un ordre de redirection et assure classiquement (au moyen d'un NAT) la redirection d'adresses, c'est-à-dire l'établissement d'une « route » permettant d'accéder depuis l'extérieur du réseau local (sur l'adresse extérieure) au service de l'objet connecté (sur une adresse locale). Selon l'invention, cette route n'est ouverte que pendant une période de temps déterminée, appelée ici « durée de validité », ce qui permet d'accéder au service de l'objet seulement pendant une certaine période de temps, de préférence courte (par exemple moins de cinq minutes), évitant ainsi les intrusions de dispositifs pirates qui auraient acquis l'adresse extérieure. Ce mécanisme offre donc une protection contre les intrusions, malveillantes ou non, venant de l'extérieur du réseau local, tout en évitant une mise en œuvre coûteuse et complexe de cryptage des données du service.

Selon un mode de mise en œuvre particulier, l'invention est en outre caractérisée en ce que l'adresse générée du service comporte un numéro de port aléatoire.

Avantageusement selon ce mode, le numéro de port étant aléatoire, l'adresse générée pour le service est également aléatoire, c'est-à-dire impossible à deviner pour un dispositif intrus, et de surcroît modifiée à chaque itération du procédé, c'est-à-dire à chaque fois qu'un terminal demande une nouvelle adresse du service. Ceci renforce encore la sécurité liée à la durée de validité de l'adresse.

Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec le précédent, le procédé est caractérisé en ce que l'étape de réception d'un message de requête en provenance du terminal est précédée d'une étape d'envoi d'un message de notification vers le terminal.

Ainsi, l'invention permet de prévenir le terminal que le service à distance est disponible (par exemple l'accès au flux « streamé » de la caméra). Ceci évite au terminal d'avoir à interroger le serveur pour savoir si un service donné est disponible à distance.

Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, le procédé est caractérisé en ce que l'étape de réception d'un message de requête du terminal est précédée d'une étape d'établissement d'une session de communication avec la passerelle.

Avantageusement, l'étape d'établissement d'une session de communication entre le serveur et la passerelle permet de bénéficier d'un protocole standard (par exemple, comme il sera décrit plus tard, MQTT) pour échanger les messages enter le serveur et la passerelle.

Selon un autre mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, le procédé est caractérisé en ce qu'il comporte aussi une étape de découverte de l'objet connecté.

Avantageusement selon ce mode, l'objet connecté et les services qu'il met à disposition sont découverts automatiquement par la passerelle et/ou le serveur, afin de les mettre facilement sur le serveur à disposition du terminal.

Selon une variante, le procédé est caractérisé en ce que l'étape de découverte précède l'étape d'établissement d'une session de communication avec la passerelle.

Avantageusement selon ce mode, l'objet connecté et les services qu'il met à disposition sont découverts avant d'établir la session de communication. Ainsi, si les services proposés par l'objet ne sont pas intéressants (parce que mal adaptés à la demande des terminaux clients, ou non permis par le serveur, etc.), la session pourra ne pas être mise en œuvre.

Selon un autre aspect fonctionnel, l'invention a pour objet un procédé de détection et mise à disposition, sur une passerelle de service, d'un service de communication à distance entre un terminal et un objet d'un réseau local, le terminal et l'objet étant aptes à communiquer via une passerelle du réseau local, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes :

- réception, en provenance du serveur, d'une commande de redirection d'une adresse du service, ladite commande comportant au moins une durée de validité à l'issue de laquelle l'adresse du service devient invalide ;

- établissement d'une redirection d'adresse entre l'adresse du service dans le réseau local et l'adresse indiquée par la commande de redirection ;

- lorsque la durée de validité est écoulée, annulation de la redirection.

Les objets selon cet aspect fonctionnel de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect fonctionnel, notamment la redirection des adresses (route) pendant une période de temps déterminée, ce qui permet d'accéder au service de l'objet seulement pendant une courte période de temps. Les caractéristiques optionnelles évoquées pour le premier aspect peuvent s'appliquer ici.

Selon un aspect matériel, l'invention concerne également un serveur de gestion d'un service de communication à distance entre un terminal et un objet d'un réseau local, le terminal et l'objet étant aptes à communiquer via une passerelle du réseau local, ledit serveur comportant les modules suivants :

- un module de réception d'un message de requête d'accès au service ;

- un module de génération d'une adresse du service ;

un module d'envoi vers la passerelle d'une commande de redirection de l'adresse générée du service, ladite commande comprenant au moins une durée de validité à l'issue de laquelle l'adresse générée devient invalide ;

un module d'envoi, vers le terminal, de l'adresse générée du service.

Le terme module utilisé dans la présente description 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 telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.)

Selon un autre aspect matériel, l'invention concerne également une passerelle d'un réseau local apte à assurer la détection et la mise à disposition d'un service de communication à distance entre un terminal et un objet du réseau local, le terminal et l'objet étant aptes à communiquer via la passerelle, ladite passerelle comportant les modules suivants :

un module de réception d'une commande de redirection d'une adresse du service, ladite commande comportant au moins une durée de validité à l'issue de laquelle l'adresse de l'objet devient invalide ;

- un module d'établissement d'une redirection d'adresse entre l'objet connecté dans le réseau local et l'adresse indiquée par la commande en provenance du serveur ;

- un module d'annulation de la redirection lorsque la durée de validité est écoulée

Selon un autre aspect matériel, l'invention concerne aussi un système pour l'accès à un service de communication à distance entre un terminal et un objet du réseau local, le système comprenant un serveur de gestion du service de communication à distance tel que décrit précédemment et une passerelle d'un réseau local apte à assurer la détection et la mise à disposition du service de communication à distance tel que décrite précédemment

Selon un autre aspect matériel, l'invention concerne encore un programme d'ordinateur apte à être mis en œuvre sur un serveur tel que décrit ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de gestion d'un service de communication à distance entre un terminal et un objet d'un réseau local défini au-dessus.

Selon un autre aspect matériel, l'invention concerne encore un programme d'ordinateur apte à être mis en œuvre sur une passerelle de service tel que décrite ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé de détection et mise à disposition d'un service de communication à distance entre un terminal et un objet d'un réseau local, défini au-dessus.

Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes de l'un quelconque des procédés définis ci-dessus.

Les objets selon les aspects matériels de l'invention procurent au moins les mêmes avantages que ceux procurés par le procédé selon le premier aspect fonctionnel. Les caractéristiques optionnelles évoquées pour le premier aspect peuvent s'appliquer aux aspects matériels.

L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.

Les figures:

La figure 1 représente le contexte général de l'invention.

La figure 2 représente une architecture d'une passerelle domestique implémentant un mode de réalisation de l'invention.

La figure 3 représente un chronogramme des échanges entre les différents équipements lors d'une mise en œuvre de l'invention.

Description détaillée d'un exemple de réalisation illustrant l'invention

La figure 1 représente le contexte général de l'invention selon l'état de l'art, dans lequel un réseau de télécommunication comporte un réseau local ou LAN (Local Area Network) 1, aussi appelé réseau domestique, et un réseau de type étendu, ou WAN (Wide Area Network), 3. Selon cet exemple, le réseau WAN est un réseau Internet. Plus largement, le réseau 3 pourrait être de n'importe quel type (cellulaire, GSM - Global System for Mobile Communications, UMTS Universal Mobile Télécommunications System, Wifi - Wireless, etc.) sans sortir du cadre de l'invention. Le réseau local 1 comprend une passerelle 2, par exemple de type Livebox, connectée au réseau Internet 3. Le réseau local 1 comprend également un ensemble de terminaux, selon l'exemple une caméra 4 et un disque dur de type NAS (pour « Network Access Storage ») 5. Les équipements 4, 5 sont connectés à la passerelle 2, avec ou sans fils.

La passerelle 2 comporte un routeur NAT (Network Address Translation), qui a pour fonction de faire correspondre les adresses IP internes du réseau local 1 à un ensemble d'adresses utilisables sur le réseau Internet 3. Pour gérer la traversée du routeur NAT, on peut utiliser divers protocoles, par exemple SNMP (Simple Network Management Protocol), ou STUN (Simple Traversai of UDP through NATs, avec UDP pour « User Datagram Protocol »), ou encore UPnP IGD (Universal Plug and Play - Internet Gateway Device). La configuration peut être faite manuellement (via une interface Web par exemple) ou automatiquement.

Le serveur 6 est un équipement du réseau étendu, proposant une offre de services d'accès à distance à un ensemble de clients comme par exemple l'utilisateur du terminal 7.

Le terminal client 7 est dans cet exemple un téléphone mobile de type smartphone auquel sont associées des fonctions informatiques et de navigation Internet, apte à communiquer sur le réseau Internet, ou sur le réseau local, avec les équipements 2,4,5, mais pourrait être également un ordinateur portable, une tablette informatique, etc. Dans la suite, on entend par terminal client tout dispositif apte à se connecter au réseau Internet et à accéder au réseau local via la passerelle de service 2. Dans cet exemple le terminal client souhaite accéder au flux de la caméra 4, c'est-à-dire au service à distance proposé par la caméra 4. Le terminal client 7 dispose par exemple d'un client Web ; une page applicative du service à distance est typiquement présentée sur le terminal 7 au moyen d'un navigateur Web.

En se référant à la figure 1, on décrit un procédé d'initialisation d'un objet du réseau local en vue de son accès depuis l'extérieur du réseau local, par exemple la caméra 4, selon l'état de l'art UPnP IGD. Le procédé d'initialisation d'un autre objet du réseau local 1 (par exemple le NAS 5) serait similaire. Le procédé d'initialisation est de préférence mis en œuvre automatiquement lors de chaque initialisation du réseau, c'est-à-dire à chaque démarrage de l'objet 4, ou à chaque fois que l'équipement 4 et/ou la passerelle 2 changent d'adresse IP. Lors d'une première étape, la caméra 4 émet à destination de la passerelle 2 une requête de configuration du routeur NAT et de détermination d'une adresse IP publique (par exemple via un message « UPnP AddPortMapping »). Cette étape est symbolisée par la flèche Fl sur la figure 1. La passerelle 2 répond à la requête en transmettant à l'équipement 4 un message contenant une adresse IP publique et un numéro de port qu'elle a choisi (par exemple, 50000). Cette étape est symbolisée par la flèche F2 sur la figure 3. La caméra 4 mémorise l'adresse IP publique et le numéro de port, pour permettre la mise en œuvre ultérieure d'un service, par exemple l'accès au flux de la caméra 4 depuis le terminal 7 de l'utilisateur, connecté au réseau Internet 3. Le port attribué peut être visualisé via l'interface Web de la caméra, ou transmis par exemple à une application du fabricant. Le terminal 7 en prend connaissance. Lorsque l'utilisateur du terminal 7 veut accéder au flux vidéo de la caméra, il se connecte via son navigateur Internet à l'adresse IP publique de sa passerelle sur le port associé à la caméra (en utilisant typiquement le protocole HTTP/HTTPS OU RTSP).

Selon un autre état de l'art, on peut utiliser le protocole STUN. Ceci suppose que l'on ait au préalable installé une application cliente de ce type dans la caméra. L'application cliente de la caméra dialogue avec un serveur STUN, qui se trouve à l'extérieur du réseau local. A l'initiative de la caméra, un canal de communication permanent est ouvert via la passerelle entre le client et le serveur STUN. Le serveur STUN découvre l'adresse IP publique de la passerelle et la renvoie au mobile 7. Un serveur dédié est nécessaire dans le réseau et une application cliente doit être installée sur l'objet connecté, ce qui augmente sa complexité.

On note dans les deux cas (qu'il s'agisse d'UPnP IGD ou de STUN) les inconvénients suivants :

• L'initialisation est à l'initiative de l'objet connecté, ce qui n'est pas forcément souhaitable. L'utilisateur en mobilité, une fois qu'il est sorti du réseau local avec son terminal 7, ne peut plus commander l'objet connecté.

• Puisque la caméra 4 ne peut pas savoir à quel moment le client aura besoin d'accéder au flux, la traversée du routeur NAT de la passerelle est réalisée de manière permanente. Ce type de procédé n'est donc pas sécurisé car n'importe qui connaissant l'adresse IP et le numéro de port peut accéder au flux de la caméra, qui n'est généralement pas chiffré ; or il existe aujourd'hui des applications qui permettent de se procurer aisément l'adresse et le numéro de port d'un objet connecté.

L'invention propose donc d'utiliser un serveur (aussi appelé « Backend ») du réseau, noté 6 sur la figure, et un module de type proxy, situé à la fois sur le serveur et sur la passerelle, qui permette d'ouvrir de manière intelligente la traversée du NAT (et/ou du pare-feu) de la passerelle, à l'initiative du terminal client et pour une durée très limitée, de manière à ce que uniquement le terminal client concerné puisse accéder au flux de la caméra.

On va maintenant décrire l'invention à l'appui des figures 2 et 3.

La figure 2 représente l'architecture d'un équipement qui implémente un mode de réalisation de l'invention. Selon ce mode de réalisation, le module proxy (PROX) du réseau local est situé dans la passerelle, mais il pourrait sans perte de généralité être situé sur n'importe quel équipement du réseau local. Le module proxy du réseau local, noté dans la suite PP, dialogue avec le module proxy du serveur 6, noté dans la suite PS, pour offrir l'accès à un service à distance de l'objet connecté selon un mode de réalisation de l'invention.

La passerelle 2 comprend, classiquement, des mémoires (M) associées à un processeur (CPU). Les mémoires peuvent être de type ROM (de l'anglais Read On/y Memorÿ) ou RAM (de l'anglais Random Access Memorÿ) ou encore Flash. Une partie de la mémoire M contient notamment, selon l'invention, la partie logicielle du dispositif (proxy, noté PP) de l'invention. Elle comprend aussi un module de routage NAT pour assurer la redirection, ou routage, des paquets de données entre les différents terminaux et réseaux qui lui sont connectés

La passerelle 2 comporte encore un certain nombre de modules qui lui permettent de communiquer avec les réseaux 1, 3 via différents protocoles sur différents liens physiques ; sur la figure 2, on a ainsi schématisé un module Ethernet (ETH) permettant des communications filaires avec le réseau internet et le réseau local 1, et un module Wi-Fi (WIFI) pour les communications sans fils. Un module MQTT permet plus spécifiquement de dialoguer avec les objets du réseau local et le serveur 6 en utilisant le protocole du même nom. Un module RTSP (Real Time Streaming Protocol)/http permet de contrôler la distribution de flux multimédias (streaming) sur un réseau IP en utilisant l'un ou l'autre de ces protocoles.

La figure 3 représente les échanges entre le terminal client 7, le serveur 6 (ou backend), la passerelle 2, et l'objet connecté 4, ou caméra selon cet exemple.

Ce mode de réalisation de l'invention est basé sur un certain nombre de mécanismes de normes connues :

UPnP, pour Universal Plug and Play, est un ensemble de protocoles ayant pour but de permettre à des terminaux de se connecter aisément et de communiquer simplement au sein d'un réseau local. Elle constitue un ensemble de protocoles de communication basés sur le protocole IP et promulgué par le forum de normalisation UPnP (« UPnP Forum »). Pour contrôler les terminaux du réseau, UPnP utilise des points de contrôle, émettant classiquement vers les différents terminaux du réseau des messages dits de découverte, afin de récupérer en retour une description des terminaux correspondant à la requête. Ces messages de découverte sont émis le plus souvent en mode de communication point vers multipoint, mode aussi appelé multicast, du point de contrôle vers les terminaux. Un équipement terminal compatible avec la norme UPnP répond à ces messages de requête en fournissant ses caractéristiques (type de terminal, capacités matérielles et logicielles, etc.). Tout autre protocole offrant les mêmes capacités de communication dans le réseau local pourrait être utilisé alternativement, comme par exemple « Apple mDNS ».

RTSP (Real Time Streaming Protocol) permet de contrôler la distribution de flux multimédias (streaming) sur un réseau IP. C'est un protocole de niveau applicatif prévu pour fonctionner sur des protocoles tels que RTP/RTCP et RSVP. De nombreuses caméra IP du marché utilisent le protocole RTSP (Real Time Streaming

Protocol) pour diffuser le flux vidéo sur le réseau. Alternativement on peut utiliser le protocole http, qui est également pris en charge pour la plupart des objets connectés de type caméra, ou encore un protocole de téléchargement progressif comme Apple HLS, MPEG-DASH, etc.

MQTT est un service de messagerie TCP/IP simple et léger permettant de transmettre des messages de petite taille (inférieure à 256Mo) dans un réseau local. Les messages sont envoyés par des publieurs (les publishers) sur un canal (une chaîne d'information) appelé Topic. Ces messages peuvent être lus par les abonnés (les subscribers). MQTT est utilisé dans ce mode de réalisation à titre d'exemple. Tout autre protocole offrant les mêmes capacités de communication entre deux objets connectés du réseau local, ou une passerelle et un serveur, pourrait être utilisé alternativement, comme par exemple la norme TR-69, quoique plus complexe à mettre en œuvre.

On va maintenant décrire un mode de réalisation de l'invention, selon les étapes suivantes.

Lors des étapes E0 et E20 préliminaires, la passerelle 2 et le serveur 6 établissent (via leurs modules proxys PP et PS respectifs) une connexion bidirectionnelle de type MQTT. A l'issue de cette étape, une connexion sécurisée est établie de manière permanente entre les deux entités.

On rappelle que la passerelle est selon cet exemple une passerelle standard de type Livebox équipée notamment d'un routeur NAT et de différents modules de communication, dont un module dédié, dit « Proxy Passerelle », noté PP dans la suite. Le serveur est un serveur du réseau étendu proposant un certain nombre de services, notamment d'accès à distance. Il comporte à cet effet un module de communication dédié, dit « Proxy Serveur », noté PS dans la suite.

Lors d'une étape El qui la suit, le serveur 6 s'abonne au service à distance (en l'occurrence, un service de streaming vidéo sur la caméra) proposé par la passerelle ; ce message, noté SUBS peut prendre la forme suivante si l'on utilise le protocole MQTT:

MQTT: Subscribe to the « gateway» topic

Les étapes E2 et E10 correspondent à des étapes de découverte de la caméra par la passerelle, en utilisant selon cet exemple le protocole UPnP. Ce message, noté DISC peut prendre la forme suivante :

UPnP : discovery

Lorsqu'elle a récupéré les informations de description de la caméra, la passerelle transmet ces informations au module approprié PS sur le serveur 6, en utilisant la connexion établie préalablement via le protocole MQTT, au cours d'une étape E3 ; ce message, noté PUB, reçu par le serveur lors d'une étape E22, peut prendre la forme suivante :

MQTT : pubiish gateway topic with ail caméra info inciuding @MAC, model name, manufacturer,...

Ce qui signifie que la passerelle transmet toutes les informations pertinentes relatives à l'objet connecté :

- @MAC, correspondant à l'adresse MAC de la caméra visée, une adresse unique («Media Access Control ») du terminal permettant de l'identifier sans ambiguïté ; Nom de la caméra, modèle, fabricant, etc.

Cet ensemble d'étapes optionnelles, encadrées en pointillé sur la figure et notées « DEC », permet au serveur de récupérer toutes les informations utiles concernant l'objet.

Lors d'une étape E23 sur le serveur, le proxy PS analyse si ce type de caméra est compatible avec son offre de services à distance. Si c'est le cas, il en avertit l'utilisateur du terminal 7 et lui demande s'il veut rajouter cette caméra à son offre de services d'accès à distance. Ce message, noté NTF1, peut prendre la forme d'un simple SMS (Short Message Service) adressé au terminal 7 :

SMS/... : Customernotification

L'utilisateur reçoit la notification au cours d'une étape E40, et s'il l'accepte, un message d'acquittement est renvoyé lors d'une étape E41 au proxy PS sur le serveur, qui reçoit la réponse lors d'une étape E24 (notée OK).

Si l'utilisateur a accepté la notification, le proxy PS sur le serveur 6 peut envoyer, de manière optionnelle, une commande à la passerelle pour ouvrir le NAT (ou pare-feu) pour son adresse IP (@PS) afin de pouvoir configurer celle-ci ; ce message, noté SPF sur la figure, peut prendre la forme suivante :

PCB through MQTT : SetPortForwarding (@MAC Caméra, Caméra API port, @PS backend, iease time... )* ce qui signifie que le serveur transmet à la passerelle toutes les informations pertinentes relatives à la configuration souhaitée :

@MAC Caméra correspond à l'adresse MAC de la caméra visée ;

Caméra API porter, le port de ΓΑΡΙ (Application Programming Interface) permettant de configurer la caméra (par exemple 80 si celle-ci à une interface normalisée de type HTTP CGI sur ce numéro de port) ;

@PSbackendest l'adresse IP du proxy serveur PS,

- iease time est le temps de réponse autorisé, aussi dit « durée de validité » (pour l'accès au service à distance)

Cette étape est suivie optionnellement d'étapes de configuration de la caméra. L'ordre de mise à jour de la configuration (UPDATE) est transmis du serveur à la passerelle (E26) puis relayée (E5) par la passerelle à la caméra. Cet ensemble d'étapes optionnelles, encadrées en pointillé sur la figure et notées « CONF », permet par exemple de changer le mot de passe pour accéder au serveur Web, définir le profil vidéo en fonction du débit remontant de la ligne Internet (la plupart des clients Internet ayant un débit remontant limité, il est judicieux de choisir un débit pour la caméra qui soit en adéquation avec les possibilités de la ligne), etc.

Lors d'une étape E27, le proxy PS transmet à l'application mobile une notification avec une adresse (URL) distante (@PS_D).

- L'URL distante ne pointe pas sur la passerelle mais sur le proxy PS du serveur 6.

Ce message, noté sur la figure NTF2(@PS_D), peut prendre la forme suivante :

App notification (Google Fi rebase... ) : Send Caméra streaming URL (with backend IP)

Lors d'une étape E43, si le mobile est en accès distant et qu'il souhaite accéder au flux de la caméra, il se connecte donc au proxy PS du serveur 6 en HTTP ou RTSP (les caméras sachant généralement gérer ces deux protocoles) pour lui demander l'adresse (URL) distante de la caméra; ce message, noté GETCAM@, peut prendre la forme d'un message http :

HTTP/RTSP : Get Caméra streaming URL with backend IP

Le proxy PS reçoit cette demande lors d'une étape E28, puis réalise lors de l'étape E29 une configuration dynamique du serveur NAT de la passerelle. On notera que la passerelle ne peut pas restreindre l'accès au service à l'adresse IP du terminal mobile 7, car celle-ci est une adresse distante (attribuée par le routeur NAT). En conséquence, la passerelle spécifie uniquement un temps de validité de la connexion (en anglais, iease) relativement faible (par exemple de 3 minutes) et un numéro de port aléatoire. Ce message, noté SPF (LT=3, ERP = 50000), peut prendre la forme suivante :

SetPortForwarding (©MAC Caméra, Caméra video port (in HTTP and/or RTSP), externatrandom port, iowiease time (3min)...), où ©MAC Caméra correspond à l'adresse MAC de la caméra visée ;

Caméra video port : est l'un des ports vidéo disponibles sur la caméra, choisi par le serveur en fonction du protocole qu'il souhaite utiliser pour accéder au flux, dépendant du lecteur vidéo (le choix du port est donc essentiellement dépendant du protocole utilisé, habituellement 80 ou 8080 en HTTP, 554 en RTSP, etc.) externat random port (ERP) est le port externe de la passerelle, choisi de préférence de manière aléatoire par le serveur ;

«low lease time » (LT) est le temps de validité autorisé pour la réponse, de préférence assez long pour que l'utilisateur puisse se connecter mais pas davantage pour limiter les intrusions (3 minutes est une durée correcte).

En réponse à ce message, la passerelle ouvre le NAT (ou pare-feu) lors d'une étape E6, c'est-à-dire qu'elle établit une ouverture, ou route, entre la caméra (spécifiée par son adresse IP privée - @PS_L - et son numéro de port privé) et l'adresse externe de la passerelle, formée de son adresse IP et du port aléatoire (ERP) fourni par le serveur (50000 selon l'exemple de la figure 3). La passerelle refermera le NAT lorsque le temps spécifié (LT) sera écoulé.

Lors d'une étape E30, le Proxy PS peut utiliser une commandes « http redirect » (ou « RTSP redirect ») pour donner la bonne adresse URL à l'application sur le terminal 7, c'est-à-dire l'adresse formée du numéro de port (ERP) et de l'adresse IP externe de la passerelle. Ce message, noté en abrégé @CAM, peut prendre la forme suivante :

HTTP / R TSP redirect

Lors d'une étape E45, l'application sur le terminal 7 de l'utilisateur accède au flux. Le temps maximal de validité pour la connexion (lease time, LT) faible qui a été spécifié laisse juste le temps au mobile de lancer la lecture du flux. Au bout des 3 minutes, si le flux est déjà établi (streamé) il ne sera plus interrompu. Il sera juste impossible de le relancer. Ce message, noté STREAM(@CAM), peut prendre la forme suivante :

HTTP/RTSP : Get Caméra streaming URL with Livebox IP and Livebox externat port

Lors d'une étape E31, lorsque le temps spécifié (LT) est écoulé, le proxy PS du serveur 6 avertit l'application du terminal que l'accès n'est plus possible ; il faut alors, pour recevoir le flux de la caméra, réitérer les étapes E42 et suivantes, dans le but d'obtenir une nouvelle adresse distante de la caméra. On notera que dans ce cas, l'adresse de la passerelle peut changer ou non, mais le numéro de port changera systématiquement puisqu'il est choisi de manière aléatoire à chaque itération de l'étape E29, pour des raisons de sécurité, car il est plus sûr que le port soit choisi de manière aléatoire. Ce message, noté NTF3(@), peut prendre la forme suivante :

App notification (Google Fi rebase... ) : Notify app that caméra streaming URL with Livebox IP is no more vaiid

Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.

Notamment, selon une variante, l'établissement de la communication MQTT bidirectionnelle de l'étape E0/E20 peut être conditionnel à la découverte du terminal, c'est-à-dire que les étapes de découverte (E10, E2) peuvent précéder cette étape initiale d'établissement, qui n'est effectuée que si la caméra découverte est compatible avec le service d'accès à distance 5 proposé. En effet on peut imaginer découvrir une caméra dont le modèle, les performances, etc. ne sont pas tolérées par le service, auquel cas il est inutile d'enchaîner les autres étapes du procédé.

Claims (12)

1. Revendications

   1. Procédé de gestion, sur un serveur (6) d'un réseau étendu (3), d'un service de communication à distance entre un terminal (7) et un objet d'un réseau local (1), le terminal et l'objet étant aptes à communiquer via une passerelle (2) du réseau local, ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes sur le serveur :

   - réception (E28), en provenance du terminal, d'un message de requête (GETCAM@) d'accès au service ;

   - génération (E29) d'une adresse du service (@CAM) ;

   envoi vers la passerelle (E29) d'une commande de redirection (SPF) de l'adresse générée du service, ladite commande comprenant au moins une durée de validité (LT) à l'issue de laquelle l'adresse générée devient invalide ;

   envoi vers le terminal (E30) de l'adresse générée du service (@CAM).
2. 2. Procédé selon la revendication 1, caractérisé en ce que l'adresse générée du service (CAM@) comporte un numéro de port aléatoire (ERP).
3. 3. Procédé selon la revendication 1, caractérisé en ce que l'étape de réception (E28) d'un message de requête en provenance du terminal est précédée d'une étape d'envoi (E27) d'un message de notification (NTF2) vers le terminal.
4. 4. Procédé selon la revendication 1, caractérisé en ce que l'étape de réception (E28) d'un message de requête du terminal est précédée d'une étape d'établissement (E20) d'une session de communication (MQTT) avec la passerelle (2).
5. 5. Procédé selon la revendication 1, caractérisé en ce qu'il comporte aussi une étape de découverte (E22) de l'objet connecté.
6. 6. Procédé selon les revendications 5 et 6, caractérisé en ce que l'étape (E22) de découverte précède l'étape d'établissement (E20) d'une session de communication (MQTT) avec la passerelle (2).
7. 7. Procédé de détection et mise à disposition, sur une passerelle de service (2), d'un service de communication à distance entre un terminal (7) et un objet d'un réseau local (1), le terminal et l'objet étant aptes à communiquer via une passerelle du réseau local (2), ledit procédé étant caractérisé en ce qu'il comporte les étapes suivantes :

   - réception (E6), en provenance du serveur, d'une commande de redirection (SPF) d'une adresse du service, ladite commande comportant au moins une durée de validité (LT) à l'issue de laquelle l'adresse du service devient invalide ;

   - établissement (E6) d'une redirection d'adresse entre l'adresse du service dans le réseau local (@PS_L) et l'adresse indiquée par la commande de redirection.

   - lorsque la durée de validité (LT) est écoulée, annulation (E6) de la redirection.
8. 8. Serveur de gestion d'un service de communication à distance entre un terminal (7) et un objet d'un réseau local (1), le terminal et l'objet étant aptes à communiquer via une passerelle (2) du réseau local, ledit serveur (6) comportant les modules suivants :

   - un module de réception (E28) d'un message de requête d'accès au service (GETCAM@) ;

   un module de génération d'une adresse du service (@CAM);

   un module d'envoi vers la passerelle (E29) d'une commande de redirection (SPF) de l'adresse générée du service, ladite commande comprenant au moins une durée de validité (LT) à l'issue de laquelle l'adresse générée devient invalide ;

   un module d'envoi, vers le terminal (E30), de l'adresse générée du service (@CAM).
9. 9. Passerelle d'un réseau local (1) apte à assurer la détection et la mise à disposition d'un service de communication à distance entre un terminal (7) et un objet du réseau local (1), le terminal et l'objet étant aptes à communiquer via la passerelle, ladite passerelle comportant les modules suivants:

   - un module de réception (E6) d'une commande de redirection (SPF) d'une adresse du service, ladite commande comportant au moins une durée de validité (LT) à l'issue de laquelle l'adresse de l'objet devient invalide ;

   - un module d'établissement d'une redirection d'adresse entre l'objet connecté dans le réseau local et l'adresse indiquée par la commande en provenance du serveur.

   - un module d'annulation de la redirection lorsque la durée de validité (LT) est écoulée.
10. 10. Système d'accès à un service de communication à distance entre un terminal (7) et un objet du réseau local (1), le système comprenant :

    un serveur de gestion d'un service de communication à distance selon la revendication 8 ;

    - une passerelle d'un réseau local (1) apte à assurer la détection et la mise à disposition du service de communication à distance selon la revendication 9 ;
11. 11. Programme d'ordinateur apte à être mis en œuvre sur un serveur tel que défini dans la revendication 8, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini selon la revendication 1.
12. 12. Programme d'ordinateur apte à être mis en œuvre sur une passerelle de service telle que définie dans la revendication 9, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé défini selon la revendication 7.

    1/2

    Μ WIFI RTSP/http MQTT CPU ΕΤΗ NAT PP

    _

    1, 3