FR3086807A1 - Traitement perfectionne d'une requete d'acces a un reseau wifi selon le protocle wps-pbc - Google Patents

Abstract

La présente invention concerne le traitement d'une demande d'accès à un réseau Wi-Fi, reçue d'un terminal nomade (TN) auprès d'un point d'accès (AP), dans lequel la réception de la demande d'accès déclenche une session de contrôle d'accès selon le protocole WPS-PBC. En particulier, le point d'accès (AP) met en œuvre : - une vérification de données récupérées du terminal nomade, - une interruption d'une temporisation habituelle selon le protocole WPS-PBC, et - une autorisation d'accès au réseau Wi-Fi si les données récupérées du terminal nomade vérifient un critère choisi. Ainsi, l'utilisateur du terminal nomade peut accéder directement au réseau sans attendre la temporisation habituelle précitée.

Description

Traitement perfectionné d’une requête d’accès à un réseau Wi-Fi selon le protocole WPS-PB C

La présente invention concerne la connexion d’un terminal nomade à un réseau sans fil, par exemple de type WiFi, via un point d’accès de type routeur ou passerelle.

La gestion des connexions à un réseau WiFi, notamment, pose le problème de la saisie de la clé du réseau (dite WPA pour « Wi-Fi Protected Access »). Une telle saisie est souvent fastidieuse. En outre, il n’est pas proposé en pratique un mécanisme de révocation des accès WiFi suite à la connexion puis à la déconnexion du terminal nomade.

La norme WPS (pour « Wi-Fi Protected Setup »), proposée par l’organisme WiFi Alliance, vise à faciliter l’accès aux réseaux WiFi (sans toutefois traiter la révocation), en proposant plusieurs modes :

WPS PIN (proposant la saisie d’un code PIN sur le terminal nomade) et,

WPS PBC (appui d’un bouton prévu sur le point d’accès).

ce qui simplifie la connexion d'un terminal nomade au réseau WiFi.

Le mode WPS PIN est fortement déconseillé, sujet à un grand nombre d’attaques possibles.

Par ailleurs, la simplicité d’utilisation de WPS PBC par un appui de bouton améliore grandement l’expérience utilisateur. Néanmoins, ce protocole souffre de faiblesses de conception cruciales pouvant entraîner des failles de sécurité.

En effet, lors d’un appui de bouton WPS PBC, une « fenêtre temporelle » de cent-vingt secondes s’ouvre, pendant laquelle le point d’accès écoute les demandes de connexion. Si une seule connexion est demandée, alors celle-ci est acceptée.

En référence à la figure 1, la procédure classique WPS PBC s’enclenche par l’appui d’un bouton BT sur le point d’accès AP et si le terminal nomade TN se connecte à la session en cours d’établissement dans les 120 secondes (flèche OK), le terminal TN est alors connecté au réseau WiFi. Il convient de noter que le terminal TN peut alors récupérer en clair notamment les clés de sécurité du réseau WiFi. En effet, dans les messages échangés ensuite entre le terminal nomade et le point d’accès, il peut apparaître, en clair, l’identifiant de session « SSID » et surtout la clé WPA du réseau.

Ainsi, si un attaquant envoie des requêtes WPS en boucle (en zone urbaine notamment) :

- aucun utilisateur ne peut parvenir à se connecter au réseau WiFi,

- l’attaquant peut récupérer, en clair, toutes les clés WiFi de son voisinage.

Le protocole WPS PBC est réputé « non sûr » de l’avis de l’organisme WiFi Alliance, lui-même, mais reste largement utilisé, notamment pour connecter les objets connectés (loT) ne possédant pas d’interface homme machine de pilotage pour l’accès au WiFi.

Même si ce protocole est très avantageux du fait de la simplicité de sa mise en œuvre, il présente des failles de sécurité sévères.

Par ailleurs, quand bien même le terminal nomade cherchant à se connecter serait de confiance, son utilisateur doit attendre 120 secondes avant de pouvoir accéder au réseau, rendant trop longue la demande de connexion.

La présente invention vient améliorer la situation.

Elle propose à cet effet un procédé de traitement d’une demande d’accès à un réseau sans fil, reçue d’un terminal nomade auprès d’un point d’accès, dans lequel la réception de la demande d’accès déclenche une session de contrôle d’accès selon un protocole mettant en œuvre une temporisation habituelle à l’issue de laquelle il n’est donné accès à un terminal nomade que si ce terminal nomade a été le seul à requérir l’accès pendant ladite temporisation.

En particulier, le procédé, mis en œuvre par le point d’accès, comporte :

- une vérification de données récupérées du terminal nomade,

- une interruption de la temporisation habituelle précitée, et

- une autorisation d’accès au réseau sans fil si les données récupérées du terminal nomade vérifient un critère choisi.

Typiquement, comme indiqué précédemment, le réseau sans fil précité peut être un réseau de type Wi-Fi et le protocole, un protocole de type WPS-PBC. Toutefois, l’invention peut s’appliquer d’une manière équivalente pour des protocoles similaires (implémentant aussi une temporisation) dans d’autres technologies sans fil (NFC, Bluetooth, ou autres).

Ainsi, la vérification des données récupérées du terminal nomade vient remplacer la vérification d’une demande de connexion unique pendant la temporisation habituelle de 120 secondes, laquelle temporisation peut alors être supprimée sans faire attendre inutilement l’utilisateur du terminal nomade.

Plusieurs modes de réalisation peuvent être prévus pour mener cette vérification (pris individuellement ou même en combinaison).

Dans un premier mode de réalisation, les données récupérées du terminal nomade comportent un secret stocké au moins temporairement en mémoire du point d’accès, et le critère choisi consiste en une vérification de correspondance entre :

- le secret stocké en mémoire, et

- une valeur de secret, reçue d’une interface homme/machine connectée au point d’accès et à disposition d’un utilisateur.

On demande ainsi à Γ utilisateur de saisir un « challenge » qui lui est proposé.

Par exemple, le secret précité peut être un aléa généré par le point d’accès et joué sur une première interface homme/machine reliée au point d’accès et à disposition de l’utilisateur, tandis que la valeur de secret est saisie par cet utilisateur via une deuxième interface homme/machine à disposition de l’utilisateur et connectée au point d’accès.

Cette deuxième interface homme/machine peut être par exemple une interface de saisie que comporte le terminal nomade, et ainsi l’utilisateur précité est l’utilisateur du terminal nomade, invité, et cherchant à se connecter à un réseau sans fil d’un ami par exemple.

En variante, il peut s’agir de l’administrateur du point d’accès qui voit un utilisateur, tiers, tenter de se connecter avec son terminal nomade au réseau, et l’administrateur peut saisir alors un secret ou un aléa si ce tiers est de confiance.

L’aléa peut comporter typiquement une chaîne de caractères (par exemple une suite de 4 chiffres tirés aléatoirement entre 0 et 9) et la première interface homme/machine est un écran apte à afficher cette chaîne de caractères.

Alternativement, il peut s’agir d’un secret tel qu’une information propre à l’administrateur (son prénom, sa date de naissance ou autre).

Dans un deuxième mode de réalisation, les données récupérées du terminal comportent des informations propres au terminal nomade, ces informations étant récupérées du terminal nomade pendant le déroulement de la session selon le protocole précité.

En particulier, les informations propres au terminal nomade peuvent comporter au moins une adresse réseau du terminal nomade (par exemple une adresse MAC dans le cas où le protocole est de type WPS-PBC pour l’accès à un réseau de type Wi-Fi), qui est récupérée suite à la réception d’un message d’une requête de connexion (par exemple un message de type « Probe Request » selon le protocole WPS-PBC, comme on le verra plus loin en référence à la figure 2).

Plus particulièrement, les informations propres au terminal nomade peuvent comporter au moins un élément parmi :

- une adresse (MAC par exemple) du terminal nomade,

- une information d’entité ayant fabriqué le terminal nomade,

- un nom de modèle du terminal nomade,

- un numéro de modèle du terminal nomade,

- un nom de terminal nomade.

Dans l’exemple du protocole WPS-PBC, l’un quelconque de ces éléments ci-dessus peut être récupéré typiquement suite à la réception par le point d’accès d’un message de type « EAPResponse {Ml} » issu du terminal nomade, dans un état plus avancé dans la session comme on le verra plus loin en référence à la figure 2.

Dans ce deuxième mode de réalisation, le procédé peut comporter ensuite :

- jouer les données récupérées du terminal nomade sur une première interface homme/machine, connectée au point d’accès et à disposition d’un utilisateur administrateur du point d’accès, et

- vérifier la réception auprès d’une deuxième interface homme/machine, connectée au point d’accès et à disposition de l’utilisateur administrateur, d’un message d’autorisation de connexion du terminal dont les données sont jouées par la première interface.

Dans ce deuxième mode de réalisation, le critère choisi consiste alors en une vérification de cohérence par Tutilisateur administrateur entre le terminal nomade requérant un accès au réseau et les données de ce terminal nomade telles que jouées par la première interface.

Là encore, la première interface peut être un écran affichant ces données propres au terminal nomade.

Dans un troisième mode de réalisation, où le terminal requiert une connexion à un premier réseau sans fil, privé, le procédé peut comporter:

- prévoir un deuxième réseau sans fil, public, accessible via le point d’accès,

- dérouler une session selon le protocole précité mais sans la temporisation habituelle, pour connecter directement le terminal nomade au réseau sans fil public,

- récupérer des données propres au terminal nomade depuis le réseau sans fil public et vérifier une cohérence de ces données récupérées pour, le cas échéant, accorder au terminal nomade l’accès au réseau sans fil privé.

Ces données peuvent comporter au moins une référence de version de logiciel, tel que le système d’exploitation du terminal nomade par exemple.

La présente invention vise aussi un programme informatique comportant des instructions pour la mise en œuvre du procédé ci-avant, lorsque ces instructions sont exécutées par un processeur d’un circuit de traitement. Les figures 3B, 4B et 5 commentées ci-après peuvent constituer des formes d’algorithme général d’un tel programme.

Elle vise aussi un point d’accès comportant un circuit de traitement pour la mise en œuvre du procédé ci-avant. La figure 6 illustre un exemple de réalisation d’un tel circuit de traitement.

D’ailleurs, d’autres avantages et caractéristiques de l’invention apparaîtront à la lecture de la description détaillée ci-après d’exemples de réalisation aucunement limitatifs, et à l’examen des dessins annexés sur lesquels :

La figure 1 illustre très schématiquement un protocole de connexion d’un terminal nomade TN à un point d’accès AP à un réseau sans fil, par exemple de type Wi-Fi, ce protocole étant alors de type WPS-PBC,

La figure 2 illustre de façon plus détaillée le protocole de connexion WPS-PBC, issue d’une publication de l’organisme Wi-Fi Alliance,

La figure 3A illustre un système comportant un point d’accès AP et des interfaces hommes/machines connectées au point d’accès pour la mise en œuvre d’un procédé selon un premier mode de réalisation,

La figure 3B illustre les étapes du procédé selon ce premier mode de réalisation,

La figure 4A illustre un système comportant un point d’accès AP et notamment des interfaces hommes/machines connectées au point d’accès pour la mise en œuvre d’un procédé selon un deuxième mode de réalisation,

La figure 4B illustre les étapes du procédé selon ce deuxième mode de réalisation,

La figure 5 illustre les étapes d’un procédé selon un troisième mode de réalisation,

La figure 6 illustre schématiquement un circuit de traitement CT d’un point d’accès selon un exemple de réalisation de l’invention.

L’invention vise à sécuriser un protocole par exemple de type WPS-PBC présenté ci-avant. Davantage d’explications sur ce protocole sont données ci-après, en référence à la figure 2, sur laquelle :

- le terme « Enrollee » fait référence au terminal nomade cherchant à « s’enrôler » sur le réseau WiFi (correspondant à la référence TN de la figure 1),

- AP désigne le point d’accès (comme sur la figure 1),

- le terme « Registrar » fait référence à une entité « administrateur » vérifiant notamment les requêtes de connexion demandées auprès d’un ou plusieurs points d’accès AP auxquels elle est connectée.

Le point d’accès AP peut être une passerelle domestique (ou « box ») entre un réseau Wi-Fi local et un réseau étendu (type Internet), l’entité « Registrar » étant alors souvent confondue avec un point d’accès tel qu’une passerelle de ce type. Dans ce cas, le terminal nomade TN (« enrollee ») peut chercher à accéder temporairement au réseau Wi-Fi en tant qu’invité par exemple. En variante, le point d’accès AP peut être un « hotspot » de réseau Wi-Fi public, et le terminal TN étant itinérant et se connectant temporairement à une succession de hotspots.

Une session classique selon le protocole de gestion de demande d’accès WPS-PBC peut se résumer comme suit, en référence à la figure 2. La demande d’accès au réseau commence par une requête de «pré-connexion» ou «Probe Request» du terminal nomade au point d’accès, et le point d’accès AP répond à cette requête de pré-connexion par un message « Probe Response ». Par ailleurs, cette demande de connexion est transférée à l’entité « registrar » et il est amorcé ainsi une session selon le protocole WPS-PBC dans laquelle le point d’accès AP (ou plus précisément le point d’accès AP combinée à l’entité «registrar») vérifie, dans une fenêtre temporelle de durée habituelle de 120 secondes, si plusieurs terminaux nomades ont tenté de se connecter au réseau WiFi via ce point d’accès.

Si plusieurs terminaux nomades TN ont cherché à se connecter pendant cette fenêtre temporelle, alors la session est fermée et aucun des terminaux n’accède au réseau. En revanche, si un seul terminal nomade TN a essayé de se connecter, alors le point d’accès AP lui accorde l’accès au réseau Wi-Fi.

Une telle mise en œuvre oblige ainsi le seul terminal cherchant à se connecter à patienter 120 secondes avant d’avoir accès au réseau, ce qui n’est pas ergonomique pour un terminal de confiance.

L’invention consiste à inclure une étape supplémentaire de vérification du terminal nomade dans le protocole WPS-PBC en vue de mettre fin prématurément à cette fenêtre temporelle.

Cette étape est menée par le point d’accès. Plus précisément, elle est menée par la combinaison point d’accès et entité « registrar », mais dans la présente description, on assimile le point d’accès et l’entité « registrar » comme une entité unique correspondant au point d’accès, pour la simplicité de l’exposé.

Dans un premier mode de réalisation de cette étape, le flot des échanges de messages pendant la session WPS peut être interrompu momentanément afin de proposer un « challenge » au terminal nomade cherchant à s’enrôler.

Dans un exemple de réalisation illustré sur la figure 3A, le point d’accès AP peut générer une chaîne de caractères aléatoires XYT qui s’affichent sur un écran ECR connecté au point d’accès de manière visible par un utilisateur du point d’accès et/ou par un utilisateur du terminal nomade TN.

Plus généralement, cet aléa peut être une chaîne de caractères ou autre, et est joué par une première interface homme /machine (un écran ECR ou un système de restitution sonore, ou autre) à disposition d’un utilisateur, et cet utilisateur doit saisir le même aléa sur une deuxième interface homme/machine (référencée IHM sur la figure 3A) pour que le protocole de connexion WPS puisse se poursuivre. Cette deuxième interface IHM est reliée au point d’accès AP qui peut donc vérifier la correspondance entre l’aléa XYT joué par la première interface ECR et le code XYT saisi par l’utilisateur via la deuxième interface IHM.

Dans une réalisation particulière, cet utilisateur est le propriétaire de la passerelle AP et il sait qu’un terminal nomade d’un invité cherche à se connecter à son réseau Wi-Fi. Il peut saisir l’aléa XYT sur une interface IHM connectée à sa passerelle (un clavier de télécommande de la passerelle, ou encore un clavier tactile de son propre terminal déjà appairé avec la passerelle, ou autres).

Dans une réalisation alternative ou complémentaire, cet utilisateur est le propriétaire du terminal nomade, invité, et physiquement à proximité de l’écran ECR et de la passerelle AP. Il peut donc visualiser l’écran ECR et saisir l’aléa XYT sur son terminal nomade (via un clavier tactile par exemple). Dans ce cas, la passerelle AP attend du terminal « enrollee » une réponse comportant l’aléa XYT généré, selon une modification possible du protocole WPS-PBC. En pratique, même si la connexion Wi-Fi n’est pas encore complètement établie à ce stade (la négociation selon le protocole WPS-PBC n’étant pas terminée), le terminal enrollee a néanmoins déjà envoyé des trames au point d’accès AP pour se déclarer. Le même type de trame peut alors être utilisé (par exemple en mode diffusion ou « broadcast ») pour répondre au challenge et envoyer donc dans ces trames l’aléa saisi XYT. Sachant qu’un seul terminal a le droit de répondre au challenge dans cette phase, tout rejeu de l’aléa est en principe ignoré.

Ainsi, selon une modification générale de ce protocole, comme illustré sur la figure 3B (où la génération de l’aléa par le point d’accès est référencée SI et son affichage sur écran est référencé S2), si l’aléa reçu de la deuxième interface IHM ne correspond pas à l’aléa attendu à l’étape S3 (flèche KO), alors la session de connexion s’arrête à l’étape S4 et l’accès au réseau est refusé. Sinon, à l’étape S5, le déroulement du protocole de connexion WPS-PBC peut se poursuivre mais sans la mise en œuvre de la temporisation de 120 secondes à l’étape S6 de sorte que l’utilisateur du terminal nomade n’a pas à attendre cette temporisation pour accéder au réseau.

Une variante de la génération d’un aléa peut consister plus généralement à demander à l’utilisateur de la deuxième interface IHM de saisir un secret : il peut s’agir effectivement d’un aléa, mais alternativement d’une information telle que le prénom de l’utilisateur habituel du point d’accès, ou son numéro de téléphone, ou autre, stockée en mémoire du point d’accès AP.

D’autres réalisations sont encore possibles : par exemple, il peut s’agir de demander un mot affiché à l’écran (mini-écran) d’une passerelle point d’accès AP ou sur l’écran d’une télévision connectée à la passerelle AP et qui doit être recopié sur le terminal nomade via l’interface IHM, ou encore d’un code barre ou QR-code affiché à l’écran de la passerelle ou de la télévision, et qui déclenche l’envoi d’un message correspondant du terminal TN vers la passerelle AP.

Bien entendu, ce secret ou « challenge » n’est pas rejouable et préférablement tiré aléatoirement à chaque demande de connexion.

Ainsi, la temporisation habituelle n’est pas mise en œuvre et en cas de réponse valide de la deuxième interface IHM, le terminal nomade accès directement au réseau à l’étape S6. L’étape de challenge/réponse peut alors intervenir dès le début du protocole WPS-PBC. Par exemple, il est possible d’interrompre la session WPS à la réception de la requête « probe request » par le point d’accès AP.

On présente en référence aux figures 4A et 4B un deuxième mode de réalisation selon lequel la saisie d’un secret (ou « challenge ») n’est plus nécessaire et dans lequel le point d’accès récupère des informations qui sont propres au terminal nomade TN et commande leur affichage (sur un écran ECR de passerelle ou de téléviseur), ou plus généralement leur jeu sur une première interface connectée à la passerelle AP. Ainsi, un utilisateur de la passerelle AP peut vérifier ces données du terminal nomade (par exemple son adresse MAC, son fabricant MANUFAC, ou son modèle (MODEL#) comme décrit plus loin) et interrompre la session en cours si ces informations ne correspondent pas à celles du terminal nomade TN invité par l’utilisateur de la passerelle. Plus particulièrement, l’utilisateur de la passerelle peut disposer d’une seconde interface IHM pour saisir une validation de ces informations du terminal nomade TN.

Par exemple, cette seconde interface IHM peut être la même que la première interface et correspondre à un terminal propre de l’utilisateur de la passerelle AP, déjà appairé précédemment avec la passerelle. L’utilisateur reçoit alors sur son terminal (un smartphone par exemple) les informations relatives au terminal nomade TN et les valide ou non à l’aide d’un clavier tactile par exemple. En variante, il peut visualiser ces informations sur un écran ECR relié à la passerelle et valider la demande de connexion sur son propre terminal.

En variante encore, l’utilisateur peut appuyer une deuxième fois sur le bouton de la passerelle pour poursuivre la session WPS jusqu’à l’accord d’accès au réseau. En revanche, en l’absence de cet appui sur le bouton et passé un délai de cinq secondes par exemple, la passerelle interprète cette absence comme un refus de donner accès au terminal dont les informations sont affichées.

En référence maintenant à la figure 4B, le lancement du protocole WPS-PBC à l’étape S41 implique l’obtention d’informations relatives au terminal nomade TN auprès du point d’accès AP.

Une fois ces informations obtenues, la session selon le protocole WPS-PBC peut être interrompue (pour vérifier alors auprès de l’utilisateur si ce terminal nomade peut être autorisé). En référence à la figure 2, une première interruption de la session peut être effectuée dès la réception de la requête « Probe Request » par le point d’accès AP. On ne dispose alors à cette étape que de l’adresse MAC du terminal nomade « enrollee ». Une autre interruption envisageable peut être effectuée après réception d’un message de type « EAP-Response {Ml} » (figure 2). On dispose alors à cette étape de l’adresse MAC comme précédemment, mais aussi d’informations complémentaires éventuellement plus faciles à vérifier que l’adresse MAC et notamment:

- l’information du fabricant du terminal nomade TN (« manufacturer ») ;

- le nom du modèle du terminal TN (« model name ») ;

- le numéro de modèle (« model number ») ;

- le nom du terminal TN, donné habituellement par son utilisateur (« device name »).

Ainsi, le flot des échanges de messages selon le protocole WPS-PBC peut être momentanément interrompu après l’étape S42 d’obtention de ces informations auprès du point d’accès AP, en vue d’entamer une étape de validation par l’administrateur du réseau, utilisateur de la passerelle AP, en lui présentant à l’étape S43 le profil du ou des terminaux nomades tentant de se connecter à son réseau Wi-Fi, ce profil contenant ces informations précitées sur le ou les terminaux TN.

A l’étape S44, le point d’accès se met en attente d’un message de validation reçu depuis l’interface IHM. En l’absence d’un tel message de validation (flèche KO en sortie du test S44), la session est définitivement interrompue et l’accès est refusé à ce terminal TN.

Sinon (flèche OK), à l’étape S5 comme précédemment décrite, le déroulement du protocole de connexion WPS-PBC peut se poursuivre mais sans la mise en œuvre de la temporisation de 120 secondes à l’étape S6 de sorte que Futilisateur du terminal nomade n’a pas à attendre cette temporisation pour accéder au réseau.

L’étape de validation S44 par l’administrateur peut être effectuée de plusieurs manières, comme décrit plus haut :

- validation par un bouton de la passerelle suite à l’affichage des données du terminal TN sur un écran ECR relié à la passerelle,

- ou encore envoi d’un message SMS sur le terminal de l’utilisateur et validation par lien URL sur ce terminal,

- ou autres.

Dans un troisième mode de réalisation de l’invention, on prévoit, à la fin de la session selon protocole WPS-PBC de ne pas mettre en œuvre la temporisation habituelle de 120 secondes, mais d’orienter le terminal nomade temporairement vers un réseau Wi-Fi public, afin d’obtenir des informations sur le terminal nomade TN, avant de lui accorder l’accès à un réseau Wi-Fi privé.

Ainsi, ce troisième mode de réalisation vise à pallier les faiblesses du protocole WPS-PBC en termes de sécurité par l’ajout d’un réseau Wi-Fi public formant « sas de quarantaine » pour analyser les données du terminal nomade. Par exemple, au lieu de donner accès au réseau Wi-Fi domestique, une telle réalisation ne vise qu’à connecter le terminal nomade TN à un sas à clé de sécurité unique, sans possibilité de se connecter au réseau local privé (ni à un réseau étendu par ailleurs, via la passerelle AP). Ce sas de sécurité permet à la passerelle AP de scanner le terminal TN, de l’identifier, puis de proposer à I’utilisateur de la passerelle de lui donner ou non le droit de rejoindre le réseau Wi-Fi privé ou son réseau Wi-Fi invité (avec par exemple un accès interdit à certains fichiers partagés sur le réseau privé).

En référence à la figure 5, à l’étape S51, le terminal nomade TN (« enrollee ») active le protocole WPS-PBC par sa demande d’accès au réseau. Le point d’accès AP (et l’entité « registrar ») termine le protocole habituel de connexion sans mettre en œuvre l’étape de temporisation (arrêtée à l’étape S6) et lui accorde directement un accès mais à un réseau Wi-Fi public formant sas de quarantaine. Ainsi, la connexion WPS PBC est activée sur ce « sas WiFi », préférentiellement avec une nouvelle clé de session, à l’étape S52.

Ainsi, le terminal nomade est connecté au « sas WiFi ». Le point d’accès AP peut profiter de cette connexion pour lire des données (ou « scanner ») le terminal TN à l’étape S53, pour en établir un profil. Le point d’accès AP peut ensuite à l’étape S54 envoyer une notification au terminal de l’administrateur de la passerelle (par exemple un message SMS) ou vers un écran connecté à la passerelle (écran OLED de la passerelle ou écran TV relié à la passerelle). L’administrateur peut, au choix, refuser la connexion au terminal nomade (étape S56), ou encore le rediriger vers le réseau Wi-Fi privé (étape S55), ou alternativement encore vers un réseau Wi-Fi invité (accès restreint à certains fichiers du réseau privé).

Ainsi, ce troisième mode de réalisation permet d’administrer de manière simple la ségrégation entre le réseau WiFi invité et le réseau WiFi privé.

Les informations qu’il est possible de récupérer du terminal nomade pendant sa mise en quarantaine dans le sas Wi-Fi (étape S53) sont multiples. Il peut s’agir par exemple de chercher à la fois à identifier le terminal qui cherche à se connecter, et d’évaluer la sécurité de ce terminal. Pour l’identification du terminal, on peut typiquement :

- récupérer le nom du terminal (« friendly name ») déclaré par le terminal à un serveur DHCP relié au point d’accès AP,

- et/ou récupérer l’adresse MAC et en déduire des données comme le fabricant, etc.,

- et/ou réaliser un scan de type « OS guessing » et en déduire le système d’exploitation du terminal TN, etc.

Pour la sécurité de la connexion de ce terminal au réseau privé ou invité, on peut typiquement :

- réaliser un scan réseau de type « version guessing », et en déduire les services du réseau utilisés et si ces services sont à jour,

- réaliser un scan de type « OS guessing » et en déduire si le système d’exploitation est à jour, etc.

Les possibilités sont ainsi multiples.

On a représenté sur la figure 6 un point d’accès AP comportant un circuit de traitement CT pour la mise en œuvre de l’un ou l’autre des modes de réalisation de l’invention présentés ci-dessus. A titre d’exemple, le circuit de traitement CT du point d’accès peut comporter typiquement :

une interface INI de communication radiofréquence (reliée à une antenne ANT dans l’exemple illustré) selon le protocole Wi-Fi, une mémoire MEM propre à stocker des instructions d’un programme informatique pour mettre en œuvre le procédé selon l’invention, ainsi que des données temporaires (par exemple des données de scan ou des informations propres au terminal TN) ou des données permanentes (comme un secret propre à l’administrateur dans le premier mode de réalisation), un processeur PROC relié à la mémoire MEM pour lire les instructions du programme informatique et mettre en œuvre le procédé ci-avant, une interface IN2 (par exemple une interface graphique) pour piloter l’affichage d’un message sur écran (aléa ou données sur le terminal nomade TN), une interface IN3 pour recevoir un signal de validation par l’administrateur (par exemple un bouton de validation sur la passerelle ou encore une interface de communication qui peut correspondre à la première interface IN 1 afin de recevoir ce message de validation du terminal de l’administrateur, ou du terminal nomade dans le cas d’un challenge).

Claims (16)

1. REVENDICATIONS

   1. Procédé de traitement d’une demande d’accès à un réseau sans fil, reçue d’un terminal nomade (TN) auprès d’un point d’accès (AP), dans lequel la réception de la demande d’accès déclenche une session de contrôle d’accès selon un protocole mettant en œuvre une temporisation habituelle à l’issue de laquelle il n’est donné accès à un terminal nomade que si ce terminal nomade a été le seul à requérir Γ accès pendant ladite temporisation, caractérisé en ce que le procédé, mis en œuvre par le point d’accès (AP), comporte :

   - une vérification de données récupérées du terminal nomade (S3 ; S42,S44 ; S53,S54),

   - une interruption (S6) de la temporisation habituelle, et

   - une autorisation d’accès au réseau sans fil si les données récupérées du terminal nomade vérifient un critère choisi.
2. 2. Procédé selon la revendication 1, caractérisé en ce que le réseau sans fil est de type Wi-Fi et ledit protocole est de type WPS-PBC.
3. 3. Procédé selon l’une des revendications 1 et 2, caractérisé en ce que les données récupérées du terminal nomade comportent un secret (SI) stocké au moins temporairement en mémoire (MEM) du point d’accès, et le critère choisi consiste en une vérification de correspondance (S3) entre :

   - le secret stocké en mémoire, et

   - une valeur de secret, reçue d’une interface homme/machine (IHM) connectée au point d’accès et à disposition d’un utilisateur.
4. 4. Procédé selon la revendication 3, caractérisé en ce que le secret est un aléa généré par le point d’accès (AP) et joué sur une première interface homme/machine (ECR) reliée au point d’accès et à disposition de l’utilisateur, tandis que la valeur de secret est saisie par l’utilisateur via une deuxième interface homme/machine (IHM) à disposition de Futilisateur et connectée au point d’accès.
5. 5. Procédé selon la revendication 4, caractérisé en ce que la deuxième interface homme/machine est une interface de saisie que comporte le terminal nomade, ledit utilisateur étant un utilisateur du terminal nomade.
6. 6. Procédé selon l'une des revendications 4 et 5, caractérisé en ce que l’aléa comporte une chaîne de caractères et la première interface homme/machine est un écran apte à afficher ladite chaîne de caractères.
7. 7. Procédé selon la revendication 1, caractérisé en ce que les données récupérées du terminal comportent des informations propres au terminal nomade, ces informations étant récupérées (S42) du terminal nomade pendant le déroulement (S41) de ladite session de contrôle d’accès.
8. 8. Procédé selon la revendication 7, caractérisé en ce que les informations propres au terminal nomade comportent au moins une adresse réseau du terminal nomade, récupérée par le point d’accès suite à la réception d’un message d’une requête de connexion du terminal nomade pendant le déroulement de la session de contrôle d’accès.
9. 9. Procédé selon la revendication 8, prise en combinaison avec la revendication 2, caractérisé en ce que l’adresse réseau est une adresse MAC du terminal nomade, récupérée suite à la réception d’un message de requête de connexion de type « Probe Request » selon le protocole WPS-PBC.
10. 10. Procédé selon l’une des revendications 7 à 9, caractérisé en ce que les informations propres au terminal nomade comportent au moins un élément parmi :

    - une adresse réseau du terminal nomade,

    - une information d’entité ayant fabriqué le terminal nomade,

    - un nom de modèle du terminal nomade,

    - un numéro de modèle du terminal nomade,

    - un nom de terminal nomade.
11. 11. Procédé selon la revendication 10, combinée à la revendication 2, caractérisé en ce que ledit élément est récupéré suite à la réception par le point d’accès d’un message de type « EAPResponse {Ml} » issu du terminal nomade, selon le protocole WPS-PBC.
12. 12. Procédé selon l'une des revendications 7 à 11, caractérisé en ce qu’il comporte :

    - jouer (S43) les données récupérées du terminal nomade sur une première interface homme/machine (ECR), connectée au point d’accès et à disposition d’un utilisateur administrateur du point d’accès, et

    - vérifier (S44) la réception auprès d’une deuxième interface homme/machine (IHM), connectée au point d’accès et à disposition de l’utilisateur administrateur, d’un message d’autorisation de connexion du terminal dont les données sont jouées par la première interface, le critère choisi consistant ainsi en une vérification de cohérence par l’utilisateur administrateur entre le terminal nomade requérant un accès au réseau et les données de ce terminal nomade telles que jouées par la première interface.
13. 13. Procédé selon la revendication 1, dans lequel le terminal requiert une connexion à un premier réseau sans fil, privé, caractérisé en ce qu’il comporte :

    - prévoir un deuxième réseau sans fil, public, accessible via ledit point d’accès,

    - dérouler une session selon ledit protocole (S51), mais sans ladite temporisation habituelle (S6), pour connecter le terminal nomade au réseau sans fil public (S52),

    - récupérer des données propres au terminal nomade depuis le réseau sans fil public (S53), et vérifier une cohérence desdites données (S54) pour, le cas échéant, accorder au terminal nomade l’accès au réseau sans fil privé.
14. 14. Procédé selon la revendication 13, caractérisé en ce que lesdites données comportent au moins une référence de version de logiciel.
15. 15. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque lesdites instructions sont exécutées par un processeur d’un circuit de traitement.
16. 16. Point d’accès comportant un circuit de traitement pour la mise en œuvre du procédé selon l’une des revendications 1 à 14.