Domaine technique

L'invention se rapporte à un procédé d'authentification d'un utilisateur d'un dispositif appartenant à un groupe de dispositifs auprès d'un service rendu par un fournisseur de service.

L'invention trouve une application particulièrement avantageuse dans le domaine des systèmes à authentification unique permettant à un utilisateur disposant de plusieurs dispositifs de s'authentifier un nombre limité de fois.

Etat de la technique

L'accès d'un client à un service offert par un fournisseur de service est généralement précédé d'une étape préalable d'enregistrement de l'utilisateur auprès du service. Cette étape préalable est suivie d'une étape de délivrance d'informations secrètes, telles qu'un nom d'utilisateur (ou identifiant) et d'un mot de passe, partagées entre le client et le service. Ensuite, lors d'un accès au service, lorsque le client est un utilisateur, ce dernier saisi ses données personnelles sur un dispositif via, par exemple, une interface graphique ; après saisie, les données personnelles sont transmises au fournisseur, qui les vérifie et autorise l'accès lorsque ces données correspondent aux informations secrètes fournies lors de l'étape de délivrance. Une fois l'accès autorisé, l'utilisateur accède au service. A l'inverse, le fournisseur refuse l'accès lorsque ces données ne correspondent à aucune donnée enregistrée.

Aujourd'hui, un même utilisateur (ou groupe d'utilisateurs), peut posséder plusieurs dispositifs, en particulier dans un réseau domestique. Il est désormais courant de trouver plusieurs dispositifs connectés à un même réseau domestique. Les dispositifs visés sont par exemple des télévisions, des ordinateurs (fixes ou portables), des ordiphones (traduction du terminal anglo- saxon de « smartphones »).

Dans ce réseau, l'accès à un service depuis deux dispositifs nécessite deux authentifications distinctes. Par exemple, cela peut se traduire par une phase de saisie, sur chaque dispositif, d'un identifiant et d'un mot de passe, ce qui n'est pas souhaitable car les utilisateurs des deux dispositifs souhaitant un accès au service peuvent appartenir à un même groupe d'utilisateurs, voire être les mêmes utilisateurs.

L'invention

L'invention vient améliorer la situation.

A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé d'authentification d'un utilisateur d'un premier dispositif lors d'un accès à un service offert par un fournisseur de service, le premier dispositif appartenant à un groupe de dispositifs d'un réseau local incluant un second dispositif d'un utilisateur disposant d'un module d'identification pour s'identifier et s'authentifier auprès du service, caractérisé en ce qu'il comprend

- une étape de diffusion préalable au cours de laquelle le deuxième dispositif diffuse au premier dispositif une possibilité de fourniture, d'une preuve d'une authentification,

et en ce que lorsque le premier dispositif souhaite s'authentifier

- une étape de demande (ET14,ET22), par le premier dispositif au second dispositif, d'une preuve d'une authentification réussie vis-à- vis du service, la preuve incluant l'identité de l'utilisateur du second dispositif,

- une étape de transmission (ET16,ET23) depuis le second dispositif à destination du premier dispositif de la preuve,

- une étape d'authentification (ET18,ET25) de l'utilisateur du premier dispositif à la base de la preuve reçue.

L'invention propose ainsi de partager des preuves d'authentifications réussies entre dispositifs d'un même groupe de dispositifs. On verra dans la suite qu'un même groupe de dispositifs peut être des dispositifs d'un réseau local.

L'étape préalable est une étape de proposition spontanée, par le deuxième dispositif, d'au moins une preuve. Cette étape de proposition spontanée évite au premier dispositif d'interroger le ou les deuxièmes dispositifs, s'ils sont plusieurs, pour savoir s'ils peuvent fournir une preuve. De cette façon, lorsqu'un dispositif possède une preuve d'authentification réussie vis-à-vis du service, l'invention évite une nouvelle authentification si un dispositif du même groupe souhaite un accès au même service.

Selon un mode de réalisation, le procédé comprend une étape préalable d'identification d'au moins un dispositif du groupe apte à fournir une preuve. Grâce à cette caractéristique, optionnelle, on connaît préalablement à une demande d'accès à un service, le ou les dispositifs aptes à fournir un service d'identité et donc apte à fournir une preuve ; le gain en temps est donc non négligeable surtout si le nombre de dispositifs aptes à fournir une preuve est important.

Selon un aspect matériel, l'invention a trait à un programme informatique comportant des instructions pour la mise en œuvre du procédé défini ci-dessus, lorsque ce programme est exécuté par un processeur. Un tel programme peut utiliser n'importe quel langage de programmation. Il peut être téléchargé depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur.

Selon un autre aspect matériel, l'invention a trait à un dispositif, dit second dispositif, comprenant un module de communication pour communiquer avec un réseau de communication et accéder à un service apte à être délivré par un fournisseur de services et dont l'accès est précédé d'une d'authentification, caractérisé en ce qu'il comprend

un module de diffusion apte à diffuser, à d'autres dispositifs, une possibilité de fourniture d'une preuve d'une authentification,

- un module de transmission de preuve (MOD-TRS) apte à transmettre, sur demande, une preuve d'authentification réussie relative à un service à destination d'un premier dispositif à des fins d'authentification d'un utilisateur (UT) du premier dispositif pour l'accès au service.Selon un autre aspect matériel, l'invention a trait à un dispositif, dit premier dispositif, comprenant un module de communication pour communiquer avec un réseau de communication et accéder à un service apte à être délivré par un fournisseur de services et dont l'accès est précédé d'une d'authentification, caractérisé en ce qu'il comprend un module de traitement apte à recevoir depuis un deuxième dispositif un message indiquant une possibilité de fourniture d'une preuve d'une authentification, - apte à requérir une preuve au deuxième dispositif, apte à recevoir depuis le deuxième dispositif une preuve d'authentification réussie relative à un service,

Le module est également apte à transmettre la preuve reçue sur le réseau à des fins d'authentification d'un utilisateur du premier dispositif pour l'accès au service.

Enfin, selon un dernier aspect matériel, l'invention a trait à un système informatique comprenant un premier dispositif tel défini ci-dessus et un second dispositif tel que défini ci-dessus.

Bien entendu, chacun de ces dispositif comporte des moyens logiciels tels que des instructions du programme informatique précité, ces instructions étant exécutées par des moyens physiques tels qu'au moins un processeur et une mémoire de travail.

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 sur lesquels : La figure 1 représente un système informatique sur lequel est illustré un exemple de réalisation de l'invention.

Les figures 2 et 3 représentent schématiquement les circuits inclus dans le premier et le deuxième dispositif, respectivement.

Les figures 4 et 5 illustrent des échanges de données entre l'ordinateur, l'ordiphone, la passerelle et un serveur hébergeant un service de type WEB ou http, selon deux modes de réalisation, respectivement.

Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 représente un système SYS comprenant un réseau local incluant deux dispositifs illustrés au moyen d'un ordinateur PC et d'un ordiphone SP. L'ordinateur est un ordinateur fixe ou portable telle qu'une tablette.

Les dispositifs sont équipés de ressources physiques et logicielles. En l'espèce, en référence à la figure 2, l'ordinateur comprend

- un processeur CPU1, dit premier processeur,

- un module de stockage MEM1, dit premier module de stockage,

- un module de communication COM1, dit premier module de communication, pour établir une connexion avec l'extérieur en particulier avec une passerelle GTW.

Un utilisateur UT utilise cet ordinateur en vue d'accéder à un service SI. En référence à la figure 2, l'ordiphone SP inclut

- un processeur CPU2, dit deuxième processeur,

- un module de stockage MEM2, dit deuxième module de stockage, - un module de communication COM2, dit deuxième module de communication d'un premier type, pour établir une connexion avec l'extérieur, en particulier avec la passerelle GTW.

La passerelle GTW assure une interconnexion entre un réseau local et un réseau d'accès RES tel que le réseau ADSL (de l'anglais Asymmetric Digital Subscriber Line), le réseau 3G, etc.

Dans notre exemple, la passerelle GTW communique avec l'ordinateur et l'ordiphone par le biais d'un réseau Wifi. Rappelons que l'appellation Wifi (pour « Wireless Fidelity ») rassemble des technologies de transmission sans fil permettant de créer des réseaux informatiques sans fil basés sur les normes de la famille IEEE 802.11. L'invention ne se limite pas à un réseau WIFI mais s'étend à d'autres types de réseaux, par exemple Bluetooth, NFC, Ethernet, etc.

Dans notre exemple, la passerelle GTW comprend des ressources physiques et logicielles. Une passerelle purement logicielle aurait pu aussi être utilisée pour la mise en œuvre du procédé. Cette passerelle de type logicielle aurait été par exemple stockée dans la deuxième mémoire MEM2 de la tablette TB et exécutée par le deuxième processeur.

Dans l'ordinateur et dans l'ordiphone, les différents modules sont reliés au processeur par l'intermédiaire d'un premier bus BUSl et d'un deuxième bus BUS2, respectivement. Rappelons qu'un bus a pour fonction d'assurer le transfert de données numériques entre les différents circuits d'un ordinateur. Dans notre exemple, le bus en question inclut un bus de données et un bus de contrôle.

A noter aussi que, dans notre exemple, les modules de stockage décrits ci-dessus sont des mémoires permanentes, par exemple de type ROM (acronyme anglo-saxon de Read Only Memory) et que l'ordinateur et l'ordiphone incluent également une mémoire vive respective (non représentée) servant à stocker de manière non durable des données de calcul utilisées notamment lors de la mise en œuvre du procédé.

Le système comprend en outre un serveur connecté au réseau ADSL. Ce serveur stocke le service SI accessible depuis l'ordinateur ou l'ordiphone au travers de la passerelle.

Dans la suite, deux modes de réalisation vont être décrits ; ces modes incluent des étapes (ETn,k) ; « n » désignant le mode de réalisation 1 ou 2 ; et « k » la référence d'une étape particulière.

Les deux modes de réalisation tirent profit de fonctions offertes par le protocole UPnP, notamment d'une fonctionnalité d'auto découverte décrite dans la norme UPnP incorporée par référence dans la présente demande. Le texte de la norme est intitulé « UPnP™ Device Architecture 1.1 , Document Revision Date: October 15, 2008 » accessible à l'adresse suivante http://upnp.Org/specs/arch/UPnP-arch-DeviceArchitecture-yl.l .pdf - Chapitre 1 Discovery - 1.1 SSDP (Simple Service Discovery Protocol) et au chapitre 2 Description (Devices + Services).

Un premier mode de réalisation est décrit en référence à la figure 4.

Lors d'une première étape ET11, grâce au protocole UPnP et à la fonctionnalité d'auto-découverte décrite dans la norme UPnP (sigle anglo-saxon de Universal Plug and Play), l'ordiphone SP expose à l'ordinateur PC un service Identité S-ID aptes à fournir une ou plusieurs preuves d'authentification réussies.

Lors d'une deuxième étape ET12, une requête d'accès au service SI est émise par l'ordinateur PC à destination du serveur SRV. La requête d'accès est par exemple une URL (sigle de Uniform Resource Locator) du type http://mail.orange.fr/android-app saisie dans un navigateur WEB.

Lors d'une troisième étape ET13, le service SI répond qu'une authentification est requise. La réponse est par exemple une réponse de type http affichant le texte « 401 Authentication required » signifiant qu'un accès au service requiert une authentification.

Lors d'une quatrième étape ET14, l'ordinateur PC ayant connaissance de l'existence du service identité S-ID sur l'ordiphone requiert auprès de l'ordiphone SP une preuve d'authentification réussie. Cette requête « getAuth»peut être la requête « SOAP ACTION » décrite dans la norme UPNP à l'adresse suivante : http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture- yl. l.pdf - Chapitre 3 Control - cf Figure 3-1 (Soap Action).

Lors d'une cinquième étape ET15, accessoirement, un programme CTRL requiert l'autorisation d'un utilisateur de l'ordiphone. A cet effet, dans notre exemple, un message s'affiche sur un écran ECR de l'ordiphone.

On fait l'hypothèse ici que l'utilisateur de l'ordiphone (non représenté) accepte de fournir une preuve d'authentification.

Lors d'une sixième étape ET16, la preuve d'authentification demandée PRV(Sl), et éventuellement choisie par l'utilisateur, est fournie par l'ordiphone SP. Le message en question est par exemple le message SOAP RESP défini dans la norme UPNP à l'adresse suivante http://upnp.org/specs/arch/UPnP-arch- DeviœArchitecture-yl .1. pdf - Chapitre 3 Control - cf. Figure 3-1 (Soap Resp).

Lors d'une septième étape ET17, l'ordiphone SP accède au service SI au travers de la passerelle GTW en fournissant la preuve d'authentification reçue à la cinquième étape ET5.

Lors d'une huitième étape ET18, le service SI reçoit la preuve d'authentification PRV(Sl) et vérifie que cette preuve est valide. Dans l'affirmative, le service SI donne accès au service ; dans la négative, l'accès au service n'est pas autorisé.

Notons ici que l'ordre d'exécution des étapes peut varier. Par exemple, la première étape peut être exécutée à tout moment avant la quatrième étape ET4.

Aussi, selon un deuxième mode de réalisation, la preuve PRV(Sl) peut être transmise de l'ordiphone SP à l'ordinateur PC avant l'accès au service. Ce deuxième mode de réalisation est décrit en référence à la figure 5. Les étapes sont les suivantes.

La première étape ET21 est la même que la première étape ET11 décrite en référence au premier mode.

Lors d'une deuxième étape ET22, équivalente à la quatrième étape ET14 décrite en référence au premier mode, l'ordinateur ayant connaissance de l'existence du service identité S-ID sur l'ordiphone requiert auprès de l'ordiphone une preuve d'authentification. Cette requête « getAuth» peut être la requête « SOAP ACTION »décrite dans la norme UPNP à l'adresse suivante : http://upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-yl.L pdf - Chapitre 3 Control - cf. Figure 3-1 (Soap Action).

Lors d'une troisième étape ET23, équivalente à la sixième étape ET16 décrite en référence au premier mode, la preuve d'authentification demandée PRV(Sl) et éventuellement choisie par l'utilisateur est fournie par l'ordiphone. Le message en question est par exemple le message SOAP RESP défini dans la norme UPNP à l'adresse suivante http://upnp.org/specs/arch/UPnP-arch- DeviceArchitecture-yl .1. pdf - Chapitre 3 Control - cf. Figure 3-1 (Soap Resp).

Lors d'une quatrième étape ET24, équivalente à la deuxième étape

ET12 décrite en référence au premier mode, une requête d'accès au service SI est émise par l'ordinateur PC à destination du serveur SRV. La requête d'accès est par exemple une URL du type http://maiLoranqe.fr/android-app saisie dans un navigateur WEB. Ici, l'ordiphone accède au service SI au travers de la passerelle GTW en fournissant la preuve d'authentification reçue à la cinquième étape ET5. La cinquième étape ET25 est la même que la huitième étape ET18 décrite en référence au premier mode de réalisation.

Ce deuxième mode évite, entre autres, la réception d'un message d'erreur visé à la troisième étape ET13 décrite en référence au premier mode. Ces deux modes de réalisation peuvent faire l'objet de variantes.

Selon une première variante, l'ordiphone peut être équipé d'une carte à puce de type carte SIM (Subscriber Identity Module) gérée par exemple par un opérateur de télécommunication. La preuve d'authentification peut être stockée dans la carte SIM. Dans cette configuration, la preuve est une preuve d'authentification relative à l'opérateur gestionnaire de la carte SIM. Cette preuve est par exemple une preuve d'authentification réussie vis-à-vis d'un réseau RES de type 3G. L'invention permet donc un accès depuis un ordinateur dépourvu de carte SIM à un service nécessitant une carte SIM.

Lors de la première étape ET11 ou ET21 est mise en œuvre une fonctionnalité d'auto découverte. L'invention ne se limite pas à cet exemple. La recherche de la présence d'un service d'identité S-Id peut être réalisée par le biais d'une transmission d'une requête de recherche à destination de dispositifs cibles du réseau domestique. Dans cette configuration, dans notre exemple, l'ordinateur interroge l'ordiphone afin de savoir si ce dernier possède un service d'identité apte à fournir une ou plusieurs preuves. Si le réseau domestique avait été constitué d'autres dispositifs, par exemple un téléphone mobile, une télévision IP, l'ordinateur aurait transmis une requête à ces autres dispositifs ou qu'à une partie d'entre eux.

Notons enfin qu'une preuve peut être valide pour plusieurs services et non un seul service. Notons aussi qu'une preuve authentification réussie peut concerner une authentification réussie vis-à-vis d'un opérateur de télécommunication ; l'authentification concernée est par une authentification liée à un réseau de type 2G, 3G, 4G, ou autres. La preuve d'authentification réussie résultant peut alors permettre un accès à plusieurs services offerts par l'opérateur comme un accès un service de courrier électronique, à un service de télévision, à un service de vidéo à la demande, etc. Aussi, l'ordiphone peut stocker plusieurs preuves d'authentification réussie relativement à plusieurs services différents et également relatives à plusieurs identités. Dans cette configuration,

- soit les différentes preuves sont transmises depuis l'ordiphone à l'ordinateur. A réception, une preuve est sélectionnée sur l'ordinateur.

- soit la sélection de la preuve est faite sur l'ordiphone, la sélection étant suivie d'un envoi de la preuve à l'ordinateur,

- soit l'ordinateur transmet à l'ordiphone un identifiant du service ; l'ordiphone fournissant en retour la preuve d'authentification associée à ce service,

- etc.

A noter aussi qu'une preuve peut être un cookie dans le cas d'une communication http. Rappelons ici que le sigle http désigne l'expression anglo- saxonne « HyperText Transfer Protocol » connue de l'homme du métier.

A noter aussi qu'un fournisseur de service correspond à un serveur dans lequel est stocké un ou plusieurs services.

La réalisation du procédé décrit ci-dessus s'effectue grâce à des modules installés sur l'ordinateur et l'ordiphone. En particulier, l'ordiphone SP comprend un module de transmission de preuve (MOD-TRS) apte à transmettre une preuve d'authentification réussie relative à un service, à destination de l'ordinateur à des fins d'authentification d'un utilisateur de l'ordinateur pour l'accès au service.

De la même manière, l'ordinateur PC comprend un module de traitement (MOD-TRT) apte à recevoir une preuve d'authentification réussie relative à un service, et à transmettre la preuve reçue sur le réseau à des fins d'authentification d'un utilisateur de l'ordinateur pour l'accès au service.

L'invention qui vient d'être décrite ci-dessus, peut être mise en œuvre au moyen de modules logiciels et/ou matériels. Dans la suite, le terme «module» peut correspondre soit à un composant logiciel, soit à un composant matériel, soit encore à un ensemble de composants matériels et/ou logiciels, aptes à mettre en œuvre la ou les fonctions décrites ci-dessus.