FR3064780A1 - Technique d'authentification d'un dispositif utilisateur - Google Patents
Technique d'authentification d'un dispositif utilisateur Download PDFInfo
- Publication number
- FR3064780A1 FR3064780A1 FR1752615A FR1752615A FR3064780A1 FR 3064780 A1 FR3064780 A1 FR 3064780A1 FR 1752615 A FR1752615 A FR 1752615A FR 1752615 A FR1752615 A FR 1752615A FR 3064780 A1 FR3064780 A1 FR 3064780A1
- Authority
- FR
- France
- Prior art keywords
- user device
- application
- short message
- mobile terminal
- application server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
- H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
- H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Telephonic Communication Services (AREA)
Abstract
L'invention concerne une technique d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en œuvre une application, dit serveur applicatif. Un code à usage unique est extrait (EI) par le dispositif utilisateur d'un message court reçu en fonction d'au moins une donnée de supervision associée à ce serveur applicatif. Un formulaire de vérification est alors envoyé (E2 au serveur applicatif, ce formulaire comprenant le code à usage unique extrait. Le dispositif utilisateur est authentifié lorsque le code à usage unique est vérifié conforme.
Description
® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication : 3 064 780 (à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national : 17 52615
COURBEVOIE
©) Int Cl8 : G 06 F21/46 (2017.01), G 06 F21/35, H 04 L 29/06
DEMANDE DE BREVET D'INVENTION A1
| ©) Date de dépôt : 29.03.17. | ©) Demandeur(s) : ORANGE Société anonyme — FR. |
| (30) Priorité : | |
| ©) Inventeur(s) : CARBOU ROMAIN et BELLARDIE | |
| NICOLAS. | |
| (43) Date de mise à la disposition du public de la | |
| demande : 05.10.18 Bulletin 18/40. | |
| ©) Liste des documents cités dans le rapport de | |
| recherche préliminaire : Se reporter à la fin du | |
| présent fascicule | |
| (© Références à d’autres documents nationaux | ©) Titulaire(s) : ORANGE Société anonyme. |
| apparentés : | |
| ©) Demande(s) d’extension : | @) Mandataire(s) : ORANGE/IMT/OLPS/IPL/PAT. |
TECHNIQUE D'AUTHENTIFICATION D'UN DISPOSITIF UTILISATEUR.
FR 3 064 780 - A1
L'invention concerne une technique d'authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif. Un code à usage unique est extrait (El) par le dispositif utilisateur d'un message court reçu en fonction d'au moins une donnée de supervision associée à ce serveur applicatif. Un formulaire de vérification est alors envoyé (E2 au serveur applicatif, ce formulaire comprenant le code à usage unique extrait. Le dispositif utilisateur est authentifié lorsque le code à usage unique est vérifié conforme.
E1
E2
i
Technique d’authentification d’un dispositif utilisateur
L’invention se rapporte au domaine général des télécommunications.
L’invention concerne plus particulièrement une technique d’authentification d’un dispositif utilisateur auprès d’un serveur mettant en œuvre une application. Plus précisément, on se place dans le domaine d’une authentification dite « forte », s’appuyant sur un envoi d’un code à usage unique en complément ou remplacement d’une authentification par couple identifiant, mot de passe.
Une telle authentification forte est par exemple mise en œuvre pour un paiement en ligne avec envoi d’un code à usage unique par message court pour valider la transaction. Dans un autre exemple, l’authentification par identifiant, mot de passe est complétée par un envoi d’un code à usage unique par message court pour renforcer la sécurité.
Pour renforcer la sécurité lors d’une interaction entre un terminal client et un serveur applicatif, il est connu d’authentifier un utilisateur en lui envoyant un code à usage unique ou OTP (pour « One Time Password » en anglais) et en lui demandant de le saisir dans un formulaire de vérification à destination du serveur applicatif. Par exemple, un utilisateur souhaitant payer en ligne une commande à un site marchand doit entrer ce code à usage unique pour confirmer une transaction de paiement. Généralement, de tels codes à usage unique ont une durée de validité limitée, de l’ordre de quelques minutes, et deviennent obsolètes après une seule utilisation. Les codes à usage unique sont transmis par un intermédiaire, souvent l’organisme bancaire du client, au moyen d’un message court ou SMS (pour « Short Message Service » en anglais) sur un terminal mobile associé au client.
L’utilisation d’un code à usage unique permet d’éviter un éventuel rejeu d’une transaction ou d’une authentification.
Toutefois, lorsque ce code à usage unique est transmis sous la forme d’un message court, l’utilisateur doit généralement mettre en suspens son interface d’interaction avec le serveur applicatif, lire le code à usage unique dans l’application de gestion des messages courts puis saisir le code lu au moyen de l’interface d’interaction avec le serveur applicatif. Lorsque l’utilisateur interagit avec le serveur applicatif au moyen de son terminal mobile, ces différentes manipulations peuvent se révéler complexes.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention a pour objet un procédé d’authentification d’un dispositif utilisateur auprès d’un serveur mettant en œuvre une application, dit serveur applicatif. Ce procédé comprend :
- une extraction d’un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée audit serveur applicatif ;
- un envoi d’un formulaire de vérification au serveur applicatif, ledit formulaire comprenant le code à usage unique extrait, le dispositif utilisateur étant authentifié lorsque le code à usage unique est vérifié conforme.
L’interaction de l’utilisateur avec son dispositif utilisateur est ainsi simplifiée. Il ne lui est plus nécessaire de manipuler différentes applications en parallèle.
Ainsi, du point de vue de l'utilisateur, les interactions liées à la mise en œuvre de Γ authentification forte comprennent :
affichage d’une première interface du serveur applicatif pour indiquer qu’une authentification est en cours ;
prise de connaissance du résultat de l’authentification sur une deuxième interface du serveur applicatif.
Le processus de vérification du code à usage unique est transparent du point de vue de rutilisateur : le dispositif utilisateur n'affiche que des interfaces du serveur applicatif pour l’authentification, sans intervention de rutilisateur pour renseigner le code à usage unique.
Grâce à cette technique, le parcours d’authentification semble extrêmement simplifié à rutilisateur.
La donnée de supervision correspond par exemple à un numéro de l’émetteur du message court. Elle peut être complétée par d’autres données de supervision, telles qu’une description du format du message court, permettant d’identifier où est localisé l’élément de contenu utile dans le message court.
Elle peut également être complétée par une donnée de contrôle comprenant une adresse de localisation de ressource ou URL (pour « Uniform Resource Locator » en anglais) et un nom identifiant un champ du formulaire de vérification.
Les différents modes ou caractéristiques de réalisation mentionnés ci-après peuvent être ajoutés indépendamment ou en combinaison les uns avec les autres, au procédé d’authentification tel que défini précédemment.
Dans un mode de réalisation particulier, le procédé d’authentification comprend une réception en provenance du serveur applicatif de ladite au moins une donnée de supervision.
La donnée de supervision est ainsi disponible pour le dispositif utilisateur et permet à celui-ci d’identifier facilement le message court contenant le code à usage unique afin de l’extraire.
A titre d’exemple illustratif, lorsque l’application est un navigateur web, la donnée de supervision est transmise du serveur applicatif vers le dispositif utilisateur sous la forme de balises HTML (pour « HyperText Markup Language ») ou bien encore à l’aide de code Javascript.
La fourniture par le serveur applicatif de ces données de supervision et de contrôle permet de fiabiliser le résultat pour extraire le code à usage unique. De plus, ces données de supervision et de contrôle peuvent être modifiées de manière dynamique à chaque échange nécessitant une authentification forte.
Dans un mode de réalisation particulier, le procédé d’authentification comprend une identification d’un message court antérieur reçu présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur, pour obtenir ladite au moins une donnée de supervision.
Dans ce mode de réalisation particulier, le dispositif utilisateur obtient la donnée de supervision en analysant un échange antérieur avec le serveur applicatif et des messages courts reçus dans une période temporelle précédant cet échange. La donnée de supervision peut ainsi être utilisée pour une authentification forte ultérieure.
Dans un mode de réalisation particulier, dans lequel, le dispositif utilisateur comprenant un terminal mobile, apte à recevoir des messages courts, et un terminal client accédant à un réseau de communication étendu par Γintermédiaire du terminal mobile, le procédé d’authentification comprend en outre un envoi du terminal mobile vers le terminal client du code à usage unique extrait.
Dans ce mode de réalisation particulier, le terminal mobile qui est destinataire du message court comprenant le code de sécurité à usage unique joue un rôle de point d’accès au réseau de communication étendu pour le terminal client. Une liaison peut alors être établie entre le terminal mobile et le terminal client. Le terminal client reçoit ainsi du terminal mobile le code à usage unique extrait pour l’insérer dans le formulaire de vérification.
Selon une caractéristique particulière du procédé d’authentification, le terminal client transmet à destination du terminal mobile une copie des requêtes envoyées au serveur applicatif, permettant au terminal mobile d’identifier ledit message court antérieur.
Dans ce mode de réalisation particulier, la liaison établie est bidirectionnelle et permet au terminal client de transmettre au terminal mobile une copie des requêtes envoyées au serveur applicatif. En effet, ces requêtes sont acheminées par l’intermédiaire du terminal mobile, généralement de manière protégée, et ce dernier n’a pas accès à ces requêtes. La copie des requêtes reçue par le terminal mobile permet à celui-ci d’identifier le message court antérieur présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur.
Selon un deuxième aspect, l'invention concerne également un dispositif utilisateur comprenant :
- un module de gestion de messages courts, agencé pour recevoir un message court en provenance d’un serveur de messagerie ;
- un module de contrôle, agencé pour extraire un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée à un serveur mettant en œuvre une application, dit serveur applicatif ;
- un module applicatif, agencé pour établir une session applicative avec un serveur applicatif et pour envoyer un formulaire de vérification au serveur applicatif afin de s’authentifier, ledit formulaire comprenant le code à usage unique extrait, le dispositif utilisateur étant authentifié lorsque le code à usage unique est vérifié conforme.
Ce dispositif utilisateur peut bien sûr comporter en termes structurels les différentes caractéristiques relatives au procédé d’authentification tel que décrit précédemment, qui peuvent être combinées ou prises isolément.
Dans un mode de réalisation particulier, le module applicatif est en outre agencé pour recevoir au moins une donnée de supervision en provenance du serveur applicatif.
Dans un mode de réalisation particulier, le module de contrôle est en outre agencé pour obtenir ladite au moins une donnée de supervision en identifiant un message court antérieur reçu présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur.
Selon une caractéristique particulière, le dispositif utilisateur étant formé d’un terminal mobile comprenant le module de gestion de messages courts et le module de contrôle et d’un terminal client comprenant le module applicatif, ledit terminal client étant agencé pour accéder au réseau de communication étendu par l’intermédiaire du terminal mobile, le terminal client comprend en outre un deuxième module de contrôle, agencé pour envoyer une copie de requêtes envoyées au serveur applicatif, permettant au terminal mobile d’identifier ledit message court antérieur.
Les avantages énoncés pour le procédé d’authentification selon le premier aspect sont transposables directement au dispositif utilisateur. Par conséquent, ils ne sont pas détaillés plus amplement.
Selon un troisième aspect, l'invention concerne un programme pour un dispositif utilisateur, comprenant des instructions de code de programme destinées à commander l’exécution du procédé d’authentification précédemment décrit mis en œuvre par le dispositif utilisateur, lorsque ce programme est exécuté par ce dispositif et un support d’enregistrement lisible par un dispositif sur lequel est enregistré un programme pour un dispositif.
Les avantages énoncés pour le procédé d’authentification selon le premier aspect sont transposables directement au programme pour un dispositif utilisateur et au support d’enregistrement.
La technique d’authentification d’un dispositif utilisateur sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
la figure 1 représente un environnement dans lequel est mis en œuvre le procédé d’authentification d’un dispositif utilisateur dans un mode de réalisation particulier ; les figures 2a, 2b et 2c illustrent des étapes d’un procédé d’authentification mises en œuvre par un dispositif utilisateur selon des modes particuliers de réalisation ;
les figures 3a et 3b représentent un terminal mobile selon un mode particulier de réalisation ;
la figure 4 représente un terminal client selon un mode particulier de réalisation.
La figure 1 représente un environnement dans lequel est mis en œuvre le procédé d’authentification d’un dispositif utilisateur auprès d’un serveur mettant en œuvre une application dans un mode de réalisation particulier.
Sur la figure 1 sont représentés deux dispositifs utilisateur 10, 15 accédant à une application par l’intermédiaire d’un réseau de communication étendu 2. Le premier dispositif utilisateur 10 comprend un terminal mobile 11 et un terminal client 12 accédant au réseau de communication étendu 2 par l’intermédiaire du terminal mobile. Le terminal client est par exemple un ordinateur, une tablette ou un autre terminal mobile. Le terminal mobile 11 est connecté au réseau de communication 2 par l’intermédiaire d’un réseau d’accès sans fil, tel qu’un réseau mobile GSM, UMTS, LTE, ... Le terminal client 12 et le terminal mobile 11 s’échangent des données au moyen d’un réseau d’accès local sans fil, par l’intermédiaire de canaux de communication radio, en utilisant notamment la technologie de transmission sans fil basée sur la norme de réseau radioélectrique IEEE 802.11 et ses évolutions communément regroupées sous l'appellation Wi-Fi (pour « Wireless Fidelity »). Plus précisément, le terminal mobile 11 joue le rôle d’un point d’accès, permettant à des terminaux d’accéder au réseau de communication 2. Le terminal mobile 11 achemine ainsi des données reçues du terminal client 12 au moyen du réseau d’accès local sans fil vers le réseau de communication 2 et achemine des données reçues du réseau de communication 2 à destination du terminal client 12 vers ce dernier au moyen du réseau d’accès local sans fil.
Le deuxième dispositif utilisateur 15 est un terminal mobile accédant au réseau de communication 2 par l’intermédiaire d’un réseau d’accès sans fil, tel qu’un réseau mobile GSM, UMTS, LTE, ....
Les terminaux mobiles 11, 15 sont aptes à recevoir des messages courts ou SMS par l’intermédiaire du réseau mobile et à les restituer à leur utilisateur par l’intermédiaire d’une application de gestion des messages courts. Aucune limitation n’est attachée au nombre de dispositifs utilisateur.
Chaque terminal mobile 11, 15, plus précisément chaque utilisateur de ce terminal mobile, est identifié par un identifiant d’un abonnement auprès d’un opérateur, typiquement le MSISDN (pour « Mobile Station Integrated Services Digital Network Number »). Cet identifiant est le numéro connu du public d'identification de l’utilisateur dans le réseau de son opérateur. C'est cet identifiant, couramment appelé numéro de téléphone, qui doit être composé afin de joindre l’utilisateur ayant souscrit à un abonnement. Cet identifiant est associé au dispositif par l’intermédiaire d’un module de sécurité.
Un serveur de messagerie 20 transmet à destination des terminaux mobiles des messages courts, envoyés par d’autres terminaux ou bien par des serveurs lors de l’exécution d’une application. Un message court comprend notamment un numéro identifiant l’émetteur du message court, un numéro identifiant le destinataire du message court et des éléments de contenu. Un message court peut également prendre la forme d’un message MMS (pour « Multimedia Message Service » en anglais). Un message court peut encore prendre la forme d’une donnée USSD (pour « Unstructured Supplementary Service Data »)
Le réseau de communication 2 permet notamment d’accéder à un serveur 30 mettant en œuvre une application, dit serveur applicatif. L’application requiert une authentification de rutilisateur. L’application est par exemple un service accessible sur la toile d’araignée mondiale WWW (pour « World Wide Web »), communément appelée le Web ou la Toile, via des échanges hypertexte. L’application cliente est pilotée par l’utilisateur par l’intermédiaire d’une interface homme-machine du terminal client 12 ou du terminal mobile 15. A titre d’exemple illustratif, cette application cliente est un navigateur web.
Par la suite, un premier mode de réalisation particulier correspond à la mise en œuvre de la technique d’authentification sur le dispositif utilisateur 15, c’est-à-dire le terminal mobile 15, l’application cliente et l’application de gestion de messages courts s’exécutant sur le terminal mobile 15.
Un deuxième mode de réalisation particulier correspond à la mise en œuvre de la technique d’authentification sur le dispositif utilisateur 10, l’application cliente s’exécutant sur le terminal client 12 et l’application de gestion de messages courts s’exécutant sur le terminal mobile
11. Dans ce deuxième mode de réalisation particulier, le terminal client 12 et le terminal mobile 11 sont déjà appariés, c’est-à-dire le terminal client 12 est client du terminal mobile 11 jouant le rôle d’un point d’accès. Le terminal client 12 et le terminal mobile 11 coopèrent pour la mise en œuvre du procédé d’authentification.
La figure 3a représente un terminal mobile 11 dans un mode particulier de réalisation. Le terminal mobile 11 comprend notamment :
- un processeur 111 pour exécuter des instructions de code de modules logiciels ;
- une zone mémoire 112, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé d’authentification ;
- une mémoire de stockage 117, agencée pour stocker des données utilisées lors de la mise en œuvre du procédé d’authentification ;
- un premier module d’interface 113 avec un réseau de communication, agencé pour émettre et recevoir des données par l’intermédiaire d’un réseau mobile ;
- un deuxième module d’interface 114, agencé pour émettre et recevoir des données par l’intermédiaire d’un réseau d’accès local sans fil ;
- un module 115 de gestion des messages courts, noté MR par la suite ;
- un module 116 de contrôle, noté MC par la suite.
Il est ici souligné que le terminal mobile 11 comprend également d’autres modules de traitement, non représentés sur la figure 3a, agencés pour mettre en œuvre les différentes fonctions de terminal mobile.
La figure 3b représente un terminal mobile 15 dans un mode particulier de réalisation. Le terminal mobile 15 comprend notamment :
- un processeur 151 pour exécuter des instructions de code de modules logiciels ;
- une zone mémoire 152, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé d’authentification ;
- une mémoire de stockage 157, agencée pour stocker des données utilisées lors de la mise en œuvre du procédé d’authentification ;
- un premier module d’interface 153 avec un réseau de communication, agencé pour émettre et recevoir des données par l’intermédiaire d’un réseau mobile ;
- un module 155 de gestion des messages courts, noté MR par la suite ;
- un module 156 de contrôle, noté MC par la suite ;
- un module 158 applicatif, noté MA par la suite, agencé pour exécuter l’application sur le terminal mobile.
Le module 156 de contrôle est connecté au module 158 applicatif par un protocole connu de l’homme de métier, par exemple une « websocket ».
Dans un mode de réalisation particulier, le terminal mobile 15 comprend en outre un deuxième module d’interface 154, agencé pour émettre et recevoir des données par Γintermédiaire d’un réseau d’accès local sans fil.
Il est ici souligné que le terminal mobile 15 comprend également d’autres modules de traitement, non représentés sur la figure 3b, agencés pour mettre en œuvre les différentes fonctions de terminal mobile.
La figure 4 représente un terminal client 12 dans un mode particulier de réalisation. Le terminal client 12 comprend notamment :
- un processeur 121 pour exécuter des instructions de code de modules logiciels ;
- une zone mémoire 122, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en œuvre les étapes du procédé d’authentification ;
- un module d’interface 123, agencé pour émettre et recevoir des données par l’intermédiaire d’un réseau d’accès local sans fil ;
- un module 124 applicatif, noté TA par la suite, agencé pour exécuter l’application sur le terminal mobile.
- un module 125 de contrôle, noté TC par la suite.
Le module 125 de contrôle est connecté au module 124 applicatif par un protocole connu de l’homme de métier, par exemple une « websocket ».
Il est ici souligné que le terminal client 12 comprend également d’autres modules de traitement, non représentés sur la figure 4, agencés pour mettre en œuvre les différentes fonctions de terminal client.
La figure 2a illustre des étapes d’un procédé d’authentification d’un dispositif utilisateur 10, 15 auprès d’un serveur mettant en œuvre une application, dit serveur applicatif 30 selon un mode particulier de réalisation.
A l’état initial, une session est établie entre le dispositif utilisateur 10, 15 et le serveur applicatif 30.
Dans une étape El, le dispositif utilisateur extrait un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée au serveur applicatif. La donnée de supervision correspond au numéro d’émetteur du serveur de messagerie 20. L’utilisation de cette donnée de supervision permet notamment d’identifier un message court reçu qui a été émis en relation avec l’exécution de l’application. Elle peut être complétée par une deuxième donnée de supervision correspondant à une description du format du message court, permettant de localiser le code à usage unique dans le message court. Dans une variante de réalisation, lorsque cette deuxième donnée de supervision n’est pas disponible, le code à usage unique est localisé en effectuant une opération de séparation dans la chaîne de caractères ou de recherche de délimiteurs ou bien encore de recherche de suite de caractères numériques.
Dans une étape E2, le dispositif utilisateur 10, 15 insère le code à usage unique dans un formulaire de vérification et l’envoie au serveur applicatif 30.
Le serveur applicatif 30 vérifie alors si le code à usage unique présent dans le formulaire de vérification correspond à celui qui est attendu, le code à usage unique étant alors vérifié conforme. Le dispositif utilisateur 10, 15 est alors authentifié auprès du serveur applicatif 30. Lorsque le code à usage unique n’est pas vérifié conforme, le dispositif utilisateur 10, 15 n’est pas authentifié auprès du serveur applicatif 30.
Ces étapes El et E2 vont être décrites de manière plus précise pour les premier et deuxième modes de réalisation définis précédemment.
On rappelle que dans le premier mode de réalisation, le dispositif utilisateur correspond au terminal mobile 15.
Lors de l’étape El, le module 155 MR reçoit un message court et le transmet au module 156 de contrôle MC. Ce dernier extrait alors le code à usage unique et le transmet au module 158 applicatif MA.
Lors de l’étape E2, le module 158 applicatif MA insère le code à usage unique dans le formulaire de vérification et l’envoie au serveur applicatif 30.
Dans le deuxième mode de réalisation, le dispositif utilisateur correspond au terminal mobile 11 et au terminal client 12.
Dans une étape initiale, non représentée sur la figure 2a, le terminal mobile 11 et le terminal client 12 échangent leurs capacités afin de déterminer s’ils supportent tous deux la fonction d’authentification forte assistée AFA. A titre d’exemple illustratif, cet échange de capacités s’effectue en utilisant un protocole UPnP (pour « Universal Plug and Play ») - DLNA (pour « Digital Living Network Alliance »). De manière optionnelle, le choix d’activer ou non cette fonction AFA est proposé à l’utilisateur par l’intermédiaire de l’interface homme-machine d’un des deux terminaux. En fonction de ce choix, la fonction est activée sur les deux terminaux. Ce choix peut être permanent ou temporaire. Suite à cette activation, les modules de contrôle, TC 125 pour le terminal client 12, et MC 116 pour le terminal mobile 11 sont initialisés. Toujours dans cette étape initiale, les deux modules de contrôle TC et MC procèdent à un échange de clés publiques de chiffrement asymétrique, leur permettant par la suite d’échanger des données de façon sécurisée à travers le réseau d’accès local sans fil. Aucune limitation n’est attachée au procédé de chiffrement mis en œuvre. Il est bien entendu que le chiffrement de cette liaison entre les deux modules de contrôle TC et MC est optionnel et sa mise en œuvre dépend d’un niveau de confiance associé au réseau d’accès local sans fil. Une liaison bidirectionnelle entre les deux modules de contrôle TC et MC est ainsi établie.
Lors de l’étape El, le module 115 MR reçoit un message court et le transmet au module 116 de contrôle MC. Ce dernier extrait alors le code à usage unique et le transmet au module 125 de contrôle TC au moyen de la liaison bidirectionnelle établie.
Lors de l’étape E2, le module 125 de contrôle TC transfère au module 124 applicatif TA le code à usage unique extrait. Le module TA insère alors le code à usage unique dans le formulaire de vérification et l’envoie au serveur applicatif 30.
La figure 2b illustre des étapes du procédé d’authentification d’un dispositif utilisateur 10, 15 auprès d’un serveur mettant en œuvre une application, dit serveur applicatif 30 selon un mode particulier de réalisation. Dans ce mode de réalisation particulier, le serveur applicatif 30 est adapté pour mettre en œuvre la fonction d’authentification forte assistée AFA.
Dans une étape F10, le dispositif utilisateur 10, 15, plus précisément le module applicatif, reçoit en provenance du serveur applicatif 30 au moins une donnée de supervision, destinée à être utilisée à l’étape El pour extraire le code à usage unique d’un message court reçu. A titre d’exemple illustratif, si le serveur applicatif 30 est un serveur web et le module applicatif est un navigateur web, le serveur applicatif 30 envoie dans un message HTTP une indication que l’authentification forte assistée peut être mise en œuvre et la donnée de supervision à l’aide d’attributs de balises HTML, ou encore à l’aide de code Javascript. On rappelle ici que la donnée de supervision correspond au numéro d’émetteur du serveur de messagerie 20. Elle peut être complétée par une deuxième donnée de supervision correspondant à une description du format du ίο message court, permettant de localiser le code à usage unique dans le message court. Elle peut également être complétée par une donnée de contrôle comprenant une adresse de localisation de ressource ou URL et un nom identifiant un champ du formulaire de vérification.
Dans une étape Lll, le module applicatif transmet cette ou ces données de supervision au module de contrôle MC, qui met alors en œuvre les étapes El et E2 décrites en relation avec la figure 2a.
La fourniture par le serveur applicatif de cette ou de ces données de supervision et de contrôle permet de fiabiliser l’extraction du code à usage unique.
On constate également que dans ce mode de réalisation particulier, les données de supervision et de contrôle peuvent être modifiées de manière dynamique à chaque échange nécessitant une authentification forte.
Ces étapes L10 et Lll vont être décrites de manière plus précise pour les premier et deuxième modes de réalisation définis précédemment.
Dans le premier mode de réalisation, lors de l’étape L10, le module applicatif 158 MA reçoit en provenance du serveur applicatif 30 la ou les données de supervision. L’étape Lll est mise en œuvre en interne au terminal mobile 15. Ainsi, le module applicatif 158 MA envoie la ou les données de supervision reçues au module 156 MC de contrôle.
Dans le deuxième mode de réalisation, lors de l’étape L10, le module applicatif 124 TA reçoit en provenance du serveur applicatif 30 la ou les données de supervision. A l’étape Lll, le module applicatif 124 TA transmet la ou les données de supervision reçues au module 125 de contrôle. Ce dernier les transmet au moyen de la liaison bidirectionnelle au module 116 de contrôle.
La figure 2c illustre des étapes du procédé d’authentification d’un dispositif utilisateur 10, 15 auprès d’un serveur mettant en œuvre une application, dit serveur applicatif 30, selon un mode particulier de réalisation. Dans ce mode de réalisation particulier, la mise en œuvre de l’authentification forte assistée est transparente pour le serveur applicatif 30.
Dans une étape L20, le module de contrôle MC obtient une copie des requêtes envoyées par le module applicatif au serveur applicatif 30. A titre d’exemple illustratif, il s’agit d’une requête HTTP émise par le module applicatif. Dans un mode de réalisation particulier, cette requête HTTP contient un lien HTML donné ou correspond à un envoi de formulaire. Le module de contrôle MC horodate et enregistre ces copies de requête dans une zone mémoire cache. Cette zone mémoire est de taille limitée afin de conserver uniquement les requêtes les plus récentes.
Dans une étape L21, lorsqu’un message court est reçu, le module de gestion des messages courts MR transmet le numéro émetteur du message court et le contenu de celui-ci au module de contrôle MC. Ce dernier filtre éventuellement les contenus non significatifs, par exemple ceux qui sont notamment émis depuis des numéros privés, puis il horodate et enregistre ces messages courts dans la zone mémoire cache. Cette zone mémoire est de taille limitée afin de conserver uniquement les messages courts les plus récents.
Dans une étape F22, le module de contrôle identifie un message court mémorisé dans la zone mémoire cache présentant un élément de contenu identique à un élément de contenu d’une requête mémorisée, plus précisément un formulaire de vérification. Les horodatages doivent être bien entendu cohérents. Cet élément de contenu identique correspond au code à usage unique utilisée dans une authentification forte antérieure. Le code à usage unique est localisé en effectuant une opération de séparation dans la chaîne de caractères ou de recherche de délimiteurs ou bien encore de recherche de suite de caractères numériques. Le module de contrôle obtient alors la donnée de supervision correspondant au numéro émetteur. Le module de contrôle peut également obtenir la deuxième donnée de supervision correspondant à la localisation du code à usage unique dans le contenu du message court et la donnée de contrôle comprenant une adresse de localisation de ressource ou URL et un nom identifiant un champ du formulaire de vérification. Le module de contrôle peut également mémoriser le format du contenu du message court.
Dans un mode de réalisation particulier, une notification est alors déclenchée sur le dispositif utilisateur 10, 15 par un module de contrôle. Cette notification permet d’obtenir une confirmation de rutilisateur quant à la mise en œuvre ultérieure de l’authentification forte assistée (étapes El et E2). A titre d’exemple illustratif, cette confirmation peut prendre la forme de la question suivante : « Une donnée que vous avez saisie semble avoir été reçue précédemment par message court. Voulez-vous automatiser les saisies ultérieures ? ». Si l’utilisateur répond positivement, les données de supervision et de contrôle sont enregistrées. On constate que dans ce mode de réalisation particulier, la ou les données de supervision (et de contrôle le cas échéant) sont obtenues par apprentissage sur un échange antérieur.
La fonction d’authentification forte assistée est alors mise en œuvre pour une authentification à venir. Le dispositif utilisateur met alors en œuvre les étapes El et E2 décrites en relation avec la figure 2a.
Ces étapes F20, F21 et F22 vont être décrites de manière plus précise pour les premier et deuxième modes de réalisation définis précédemment.
Dans le premier mode de réalisation, à l’étape F20, le module applicatif 158 MA envoie au module de contrôle 156 MC une copie des requêtes envoyées au serveur applicatif. A l’étape F21, le module 155 MR transmet le numéro émetteur du message court et le contenu de celui-ci au module de contrôle 156 MC. La zone mémoire cache correspond alors à la mémoire de stockage 157. Le module de contrôle 156 MC met alors en œuvre l’étape F22.
Dans le deuxième mode de réalisation, à l’étape F20, le module applicatif 124 TA envoie au module de contrôle 125 TC en clair la copie des requêtes envoyées. Le module de contrôle 125 TC les transmet alors au module de contrôle 116 MC au moyen de la liaison bidirectionnelle. Les copies des requêtes sont par exemple transmises sous un format tel que JSON (pour « JavaScript
Object Notation », XML (pour « extensible Markup Language »), ... A l’étape F21, le module 115 MR transmet le numéro émetteur du message court et le contenu de celui-ci au module de contrôle 116 MC. La zone mémoire cache correspond alors à la mémoire de stockage 117 du terminal mobile 11. Le module de contrôle 116 MC met alors en œuvre l’étape F22.
Pour ce deuxième mode de réalisation, on souligne ici que les requêtes entre l’application cliente et le serveur applicatif sont de manière générale cryptées afin de protéger les échanges au niveau applicatif. Des protocoles tels que TLS (pour « Transport Layer Security ») et SSL (pour « Secure Sockets Layer ») sont par exemple mis en œuvre. Le terminal mobile 11, bien que jouant le rôle du point d’accès pour le terminal client 12, ne peut pas accéder aux requêtes envoyées. Une technique permettant au terminal mobile d’exploiter directement certains éléments des requêtes, par exemple par reconnaissance de couples (clé,valeur) dans le champ « query string » d’une requête « http GET », ne peut donc pas être mis en œuvre.
Au contraire, dans le deuxième mode de réalisation, cette technique d’authentification peut être mise en œuvre grâce à la copie des requêtes qui est fournie par le module applicatif du terminal client 12 au terminal mobile 11.
Aucune limitation n’est attachée à ces différents modes de réalisation et l’homme du métier est à même d’en définir d’autres permettant d’extraire le code à usage unique d’un message court reçu afin de l’insérer dans le formulaire de vérification à destination du serveur mettant en œuvre l’application. Le processus de vérification du code à usage unique est ainsi transparent du point de vue de l'utilisateur : le dispositif utilisateur affiche uniquement des interfaces du serveur applicatif pour une authentification forte, sans intervention de l’utilisateur pour renseigner un code à usage unique reçu dans un message court.
Pour résumer les modes de réalisation précédemment décrits, le dispositif utilisateur 10, 15 comprend :
- un module 115, 155 de gestion de messages courts, agencé pour recevoir un message court en provenance d’un serveur de messagerie 20 ;
- un module de contrôle 116, 156, agencé pour extraire un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée à un serveur 30 mettant en œuvre une application, dit serveur applicatif ;
- un module applicatif 124, 158, agencé pour établir une session applicative avec un serveur applicatif et pour envoyer un formulaire de vérification au serveur applicatif afin de s’authentifier, ledit formulaire comprenant le code à usage unique extrait, le dispositif utilisateur étant authentifié lorsque le code à usage unique est vérifié conforme.
Dans un mode de réalisation particulier, le module applicatif est en outre agencé pour recevoir au moins une donnée de supervision en provenance du serveur applicatif.
Dans un mode de réalisation particulier, le module de contrôle est en outre agencé pour obtenir ladite au moins une donnée de supervision en identifiant un message court antérieur reçu présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur.
Dans un mode de réalisation particulier, le dispositif utilisateur est formé d’un terminal mobile 11 comprenant le module de gestion de messages courts et le module de contrôle et d’un terminal client 12 comprenant le module applicatif, le terminal client étant agencé pour accéder au réseau de communication étendu par l’intermédiaire du terminal mobile, le terminal client comprend en outre un deuxième module de contrôle 125, agencé pour envoyer une copie de requêtes envoyées au serveur applicatif, permettant au terminal mobile d’identifier ledit message court antérieur.
L’invention concerne également un système comprenant :
- un dispositif utilisateur tel que décrit précédemment et dans lequel le module applicatif est en outre agencé pour recevoir au moins une donnée de supervision en provenance du serveur applicatif, et
- un serveur applicatif 30, agencé pour envoyer cette au moins une donnée de supervision au dispositif utilisateur lors d’une session applicative.
La technique d’authentification est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme « module » peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s’agit par exemple d’un circuit intégré, d’une carte à puce, d’une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 115, 116 du terminal mobile 11, les modules 124, 125 du terminal client 12, les modules 155, 156, 158 du terminal mobile 15 sont agencés pour mettre en œuvre le procédé d’authentification précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter le procédé d’authentification précédemment décrit, mis en œuvre par un dispositif utilisateur. L'invention concerne donc aussi :
- un programme pour un dispositif utilisateur, comprenant des instructions de code de programme destinées à commander l’exécution du procédé d’authentification précédemment décrit, lorsque ledit programme est exécuté par ce dispositif utilisateur ;
- un support d’enregistrement lisible par un dispositif utilisateur sur lequel est enregistré le 5 programme pour un dispositif.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.
Claims (11)
- REVENDICATIONS1. Procédé d’authentification d’un dispositif utilisateur (10, 15) auprès d’un serveur mettant en œuvre une application, dit serveur applicatif (30), ledit procédé comprenant :- extraction (El) d’un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée audit serveur applicatif ;- envoi (E2) d’un formulaire de vérification au serveur applicatif, ledit formulaire comprenant le code à usage unique extrait, le dispositif utilisateur étant authentifié lorsque le code à usage unique est vérifié conforme.
- 2. Procédé d’authentification selon la revendication 1, comprenant une réception (F 10) en provenance du serveur applicatif de ladite au moins une donnée de supervision.
- 3. Procédé d’authentification selon la revendication 1, comprenant, pour obtenir ladite au moins une donnée de supervision, une identification (F22) d’un message court antérieur reçu présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur.
- 4. Procédé d’authentification selon la revendication 1, dans lequel, le dispositif utilisateur comprenant un terminal mobile, apte à recevoir des messages courts, et un terminal client accédant à un réseau de communication étendu par l’intermédiaire du terminal mobile, le procédé comprend en outre un envoi du terminal mobile vers le terminal client du code à usage unique extrait.
- 5. Procédé d’authentification selon les revendications 3 et 4, dans lequel le terminal client transmet (F20) à destination du terminal mobile une copie des requêtes envoyées au serveur applicatif, permettant au terminal mobile d’identifier ledit message court antérieur.
- 6. Dispositif utilisateur (10, 15) comprenant :- un module (115, 155) de gestion de messages courts, agencé pour recevoir un message court en provenance d’un serveur de messagerie (20) ;- un module de contrôle (116, 156), agencé pour extraire un code à usage unique d’un message court reçu en fonction d’au moins une donnée de supervision associée à un serveur (30) mettant en œuvre une application, dit serveur applicatif ;- un module applicatif (124, 158), agencé pour établir une session applicative avec un serveur applicatif et pour envoyer un formulaire de vérification au serveur applicatif afin de s’authentifier, ledit formulaire comprenant le code à usage unique extrait, le dispositif utilisateur étant authentifié lorsque le code à usage unique est vérifié conforme.
- 7. Dispositif utilisateur selon la revendication 6, dans lequel le module applicatif est en outre agencé pour recevoir au moins une donnée de supervision en provenance du serveur applicatif.
- 8. Dispositif utilisateur selon la revendication 6, dans lequel le module de contrôle est en outre 5 agencé pour obtenir ladite au moins une donnée de supervision en identifiant un message court antérieur reçu présentant un élément de contenu identique à un élément de contenu d’un formulaire de vérification antérieur.
- 9. Dispositif utilisateur selon la revendication 8, formé d’un terminal mobile (11) comprenant le 10 module de gestion de messages courts et le module de contrôle et d’un terminal client (12) comprenant le module applicatif, ledit terminal client étant agencé pour accéder au réseau de communication étendu par l’intermédiaire du terminal mobile, dans lequel ledit terminal client comprend en outre un deuxième module de contrôle (125), agencé pour envoyer une copie de requêtes envoyées au serveur applicatif, permettant au terminal mobile15 d’identifier ledit message court antérieur.
- 10. Programme pour un dispositif utilisateur, comprenant des instructions de code de programme destinées à commander l’exécution du procédé d’authentification selon l'une des revendications 1 à 5 mis en œuvre par le dispositif, lorsque ledit programme est exécuté par ledit dispositif.
- 11. Support d’enregistrement lisible par un dispositif utilisateur sur lequel est enregistré le programme selon la revendication 10.1/2
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1752615A FR3064780A1 (fr) | 2017-03-29 | 2017-03-29 | Technique d'authentification d'un dispositif utilisateur |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR1752615A FR3064780A1 (fr) | 2017-03-29 | 2017-03-29 | Technique d'authentification d'un dispositif utilisateur |
| FR1752615 | 2017-03-29 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3064780A1 true FR3064780A1 (fr) | 2018-10-05 |
Family
ID=59649794
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR1752615A Withdrawn FR3064780A1 (fr) | 2017-03-29 | 2017-03-29 | Technique d'authentification d'un dispositif utilisateur |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3064780A1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090282467A1 (en) * | 2006-06-19 | 2009-11-12 | Nederlandse Organisatie Voor Toegepast-Natuurweten | Method and system for controlling access to networks |
| US20150088760A1 (en) * | 2013-09-20 | 2015-03-26 | Nuance Communications, Inc. | Automatic injection of security confirmation |
| US20150334564A1 (en) * | 2014-05-15 | 2015-11-19 | Microsoft Corporation | Transparent two-factor authentication via mobile communication device |
| US20160286393A1 (en) * | 2015-03-26 | 2016-09-29 | Yasser Rasheed | Method and apparatus for seamless out-of-band authentication |
-
2017
- 2017-03-29 FR FR1752615A patent/FR3064780A1/fr not_active Withdrawn
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090282467A1 (en) * | 2006-06-19 | 2009-11-12 | Nederlandse Organisatie Voor Toegepast-Natuurweten | Method and system for controlling access to networks |
| US20150088760A1 (en) * | 2013-09-20 | 2015-03-26 | Nuance Communications, Inc. | Automatic injection of security confirmation |
| US20150334564A1 (en) * | 2014-05-15 | 2015-11-19 | Microsoft Corporation | Transparent two-factor authentication via mobile communication device |
| US20160286393A1 (en) * | 2015-03-26 | 2016-09-29 | Yasser Rasheed | Method and apparatus for seamless out-of-band authentication |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9485146B1 (en) | Providing services using a device capabilities service | |
| US9419969B2 (en) | Method and system for granting access to a secured website | |
| US20180063115A1 (en) | Access to documents in a document management and collaboration system | |
| US9565190B1 (en) | Domain join and managed directory support for virtual computing environments | |
| US20130124606A1 (en) | Automatic personalization of downloadable mobile apps | |
| EP3257224B1 (fr) | Technique de connexion à un service | |
| US8544072B1 (en) | Single sign-on service | |
| US11244074B2 (en) | Security systems and methods for social networking | |
| WO2019110574A1 (fr) | Procédés de communication sécurisée | |
| US20170371625A1 (en) | Content delivery method | |
| US10044710B2 (en) | Device and method for validating a user using an intelligent voice print | |
| US10476856B2 (en) | Method for authenticating a device | |
| FR2978891A1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
| TW201909072A (zh) | 電子帳戶的掛失、解掛、業務管理方法、裝置及設備 | |
| Salamh et al. | What’s on the horizon? An in-depth forensic analysis of android and iOS applications | |
| FR3008837A1 (fr) | Procede d'authentification forte | |
| EP3568965A1 (fr) | Procédé d'authentification en deux étapes, dispositif et programme d'ordinateur correspondant | |
| EP3456025B1 (fr) | Technique d'authentification d'un dispositif utilisateur | |
| FR3064780A1 (fr) | Technique d'authentification d'un dispositif utilisateur | |
| JP2017523702A (ja) | ローカル情報を取得するための方法、機器、及びシステム | |
| FR3083356A1 (fr) | Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant | |
| EP3136354A1 (fr) | Méthode de sécurisation et de vérifiabilité d'un vote électronique | |
| US20170163430A1 (en) | Tracking data usage in a secure session | |
| EP3021273A1 (fr) | Procédé de sécurisation d'une transaction entre un terminal mobile et un serveur d'un fournisseur de service par l'intermédiaire d'une plateforme | |
| FR3041787A1 (fr) | Procede de transfert d'informations de configuration d'un objet connecte |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20181005 |
|
| ST | Notification of lapse |
Effective date: 20191106 |