FR 3064780 A1 20181005 FR 1752615 A 20170329 1 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 oeuvre 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 oeuvre 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 oeuvre 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 ; 3064780 2 - 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 5 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 oeuvre de l' authentification forte comprennent : affichage d'une première interface du serveur applicatif pour indiquer qu'une authentification est en cours ; 10 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 l'utilisateur : le dispositif utilisateur n'affiche que des interfaces du serveur applicatif pour l'authentification, sans intervention de l'utilisateur pour renseigner le code à usage unique. 15 Grâce à cette technique, le parcours d'authentification semble extrêmement simplifié à l'utilisateur. 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 20 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 25 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 à 30 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 35 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. 3064780 3 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. 5 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 10 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é 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 15 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 20 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, 25 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 : 30 - 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 oeuvre une application, dit serveur applicatif ; 35 - 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, 3064780 4 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 5 ê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 10 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 15 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 20 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 oeuvre par le dispositif utilisateur, 25 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. 30 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 oeuvre le procédé d'authentification d'un dispositif utilisateur dans un mode de réalisation particulier ; 35 les figures 2a, 2b et 2c illustrent des étapes d'un procédé d'authentification mises en oeuvre par un dispositif utilisateur selon des modes particuliers de réalisation ; 3064780 5 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. 5 La figure 1 représente un environnement dans lequel est mis en oeuvre le procédé d' authentification d'un dispositif utilisateur auprès d'un serveur mettant en oeuvre 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 10 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 15 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 20 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, 25 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. 30 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 35 l'utilisateur ayant souscrit à un abonnement. Cet identifiant est associé au dispositif par l'intermédiaire d'un module de sécurité. 3064780 6 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 5 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 oeuvre une application, dit serveur applicatif. L'application requiert une authentification de 10 l'utilisateur. L'application est par exemple un service accessible sur la toile d'araignée mondiale WVVW (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. 15 Par la suite, un premier mode de réalisation particulier correspond à la mise en oeuvre 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 oeuvre de la 20 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 oeuvre 25 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 ; 30 - une zone mémoire 112, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en oeuvre 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 oeuvre du procédé d'authentification ; - un premier module d'interface 113 avec un réseau de communication, agencé pour émettre et 35 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 ; 3064780 7 - 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 oeuvre les différentes fonctions 5 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 10 code pour mettre en oeuvre 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 oeuvre 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 ; 15 - 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 20 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 l'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 25 traitement, non représentés sur la figure 3b, agencés pour mettre en oeuvre 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 ; 30 - une zone mémoire 122, agencée pour mémoriser une application qui comprend des instructions de code pour mettre en oeuvre 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 35 mobile. - un module 125 de contrôle, noté TC par la suite. 3064780 8 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 oeuvre les différentes fonctions 5 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 oeuvre une application, dit serveur applicatif 30 selon un mode particulier de réalisation. 10 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 15 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 20 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 25 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 30 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 35 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. 3064780 9 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 5 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 10 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 15 mis en oeuvre. 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 oeuvre 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 20 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. 25 La figure 2b illustre des étapes du procédé d'authentification d'un dispositif utilisateur 10, 15 auprès d'un serveur mettant en oeuvre 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 oeuvre la fonction d'authentification forte assistée AFA. Dans une étape F10, le dispositif utilisateur 10, 15, plus précisément le module applicatif, 30 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 oeuvre et la donnée de supervision à l'aide 35 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 3064780 10 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 F11, le module applicatif transmet cette ou ces données de supervision au 5 module de contrôle MC, qui met alors en oeuvre 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 10 supervision et de contrôle peuvent être modifiées de manière dynamique à chaque échange nécessitant une authentification forte. Ces étapes F10 et Fil 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 F10, le module applicatif 158 MA 15 reçoit en provenance du serveur applicatif 30 la ou les données de supervision. L'étape Fil est mise en oeuvre 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 F10, le module applicatif 124 TA reçoit en provenance du serveur applicatif 30 la ou les données de supervision. A l'étape F11, le 20 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 2e illustre des étapes du procédé d'authentification d'un dispositif utilisateur 10, 15 auprès d'un serveur mettant en oeuvre une application, dit serveur applicatif 30, selon un 25 mode particulier de réalisation. Dans ce mode de réalisation particulier, la mise en oeuvre de l'authentification forte assistée est transparente pour le serveur applicatif 30. Dans une étape F20, 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 30 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 F21, 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 35 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 3064780 11 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 5 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 10 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. 15 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 l'utilisateur quant à la mise en oeuvre 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 20 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 oeuvre pour une 25 authentification à venir. Le dispositif utilisateur met alors en oeuvre 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 30 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 oeuvre l'étape F22. Dans le deuxième mode de réalisation, à l'étape F20, le module applicatif 124 TA envoie 35 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 3064780 12 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 oeuvre l'étape F22. 5 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 oeuvre. 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 10 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 oeuvre. Au contraire, dans le deuxième mode de réalisation, cette technique d'authentification peut être mise en oeuvre grâce à la copie des requêtes qui est fournie par le module applicatif du 15 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 oeuvre l'application. Le processus de vérification du code à usage unique est ainsi transparent du 20 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 : 25 - 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 oeuvre une application, dit serveur applicatif ; 30 - 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 35 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 3064780 13 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 5 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. 10 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 15 au dispositif utilisateur lors d'une session applicative. La technique d'authentification est mise en oeuvre 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 oeuvre une fonction ou un ensemble de fonctions, selon ce 20 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 25 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 30 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 oeuvre 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 35 procédé d'authentification précédemment décrit, mis en oeuvre par un dispositif utilisateur. L'invention concerne donc aussi : 3064780 14 - 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. 10 REVENDICATIONS1. Procédé d'authentification d'un dispositif utilisateur (10, 15) auprès d'un serveur mettant en oeuvre 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 (F10) 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 oeuvre 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. 3064780 16 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 mobile 15 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 oeuvre 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. 20 25