FR2980063A1 - Procede d'authentification - Google Patents

Procede d'authentification Download PDF

Info

Publication number
FR2980063A1
FR2980063A1 FR1157973A FR1157973A FR2980063A1 FR 2980063 A1 FR2980063 A1 FR 2980063A1 FR 1157973 A FR1157973 A FR 1157973A FR 1157973 A FR1157973 A FR 1157973A FR 2980063 A1 FR2980063 A1 FR 2980063A1
Authority
FR
France
Prior art keywords
authentication
user
entity
data
request
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
Application number
FR1157973A
Other languages
English (en)
Inventor
Jean-Jacques Schwartzmann
Celia Schutz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Priority to FR1157973A priority Critical patent/FR2980063A1/fr
Priority to PCT/FR2012/052009 priority patent/WO2013034865A1/fr
Priority to EP12767048.7A priority patent/EP2754262A1/fr
Publication of FR2980063A1 publication Critical patent/FR2980063A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • 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/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

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)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé d'authentification entre un utilisateur disposant d'un premier et d'un deuxième dispositifs (20, 21) et une entité (22) d'authentification distante, le procédé comprenant : - une étape (E20) d'envoi depuis le premier dispositif d'au moins une première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - une étape (E22) de réception par le premier dispositif d'une requête d'une deuxième donnée d'authentification en provenance de l'entité d'authentification, - une étape (E25) de génération sur le deuxième dispositif de la deuxième donnée d'authentification, consécutive à l'étape de réception d'une requête, - une étape (E26) d'envoi à l'entité d'authentification par le deuxième dispositif de la deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire.

Description

Procédé d'authentification L'invention concerne un procédé d'authentification d'un utilisateur lors d'un accès à des données personnelles ou professionnelles à travers internet. Plus 5 précisément, l'invention concerne une authentification forte de l'utilisateur, ou authentification à deux facteurs. L'invention trouve une application particulièrement intéressante dans la sécurisation de l'accès à des systèmes informatiques basés sur une architecture d'informatique dans le nuage (le terme habituellement utilisé est le terme anglais 10 « cloud computing »). Une telle architecture repose sur des ressources informatiques dématérialisées, mises à disposition d'un grand nombre d'utilisateurs qui y accèdent à distance et de manière évolutive. De plus en plus d'entreprises migrent leurs applications vers de tels environnements en cloud computing. Cependant, ces approches en cloud computing ne sont pas sans risque, étant donné qu'elles reposent 15 majoritairement sur internet pour fonctionner. Il est donc nécessaire, dans les offres de cloud computing d'adresser correctement les problématiques de sécurité telles que l'accès, la protection des données, la sécurisation des transactions. Ainsi, l'usage de solutions d'authentification dites fortes tend à se développer dès lors que des ressources internes à l'entreprise, telles que des applications, des fichiers, ne sont plus 20 exclusivement détenues dans l'entreprise, mais stockées à l'extérieur et parfois même partagées. Une authentification forte consiste en une procédure d'identification qui requiert la concaténation d'au moins deux éléments ou facteurs d'authentification. L'objectif d'une authentification forte est de pallier les faiblesses de l'authentification unique par 25 mot de passe qui n'offre plus le niveau de sécurité requis pour assurer la protection de biens informatiques sensibles. La principale faiblesse d'un mot de passe réside dans la facilité avec laquelle il peut être trouvé, grâce à différentes techniques d'attaque, par exemple une attaque par force brute ou par dictionnaire. L'authentification forte consiste à mixer deux stratégies d'authentification différentes. Seule la combinaison de 30 ces éléments ou facteurs supposés inviolables est alors sensée assurer une réelle solidité pour une authentification. Pour réaliser une authentification forte, les facteurs utilisés doivent provenir de deux classes d'authentification différentes, parmi lesquelles : - ce que l'entité à authentifier connaît, un mot de passe par exemple, - ce que l'entité possède tel un élément physique appelé authentifieur (le terme utilisé habituellement est le terme anglais « token »), par exemple une carte à puce, ou un terminal mobile, ce que l'entité est, dans le cas d'un utilisateur, une empreinte digitale ou tout autre élément biométrique. Ainsi, pour assurer une authentification forte multi-facteurs, en plus du classique couple login/mot de passe qui représente ce que l'utilisateur connaît, l'authentification peut reposer également sur quelque chose que l'utilisateur détient, un élément physique appelé token. On s'intéresse ici plus particulièrement aux mots de passe à usage unique, ou « OTP » (pour « One Time Password »), ou mot de passe jetable générés sur un token détenu par l'utilisateur et utilisés en combinaison avec les login/mot de passe pour réaliser une authentification forte. En fournissant un mot de passe OTP valide généré par un token détenu par l'utilisateur, celui-ci prouve qu'il détient bien ledit token.
Un exemple connu d'un flux d'authentification forte est illustré par la solution « Google Authenticator » proposée par GoogleTM, et qui permet à un utilisateur préalablement enregistré d'accéder à des services proposés par Google à l'aide d'une authentification à deux facteurs. Cette solution est présentée en relation avec la figure 1. Une procédure préalable d'enregistrement a permis de configurer un téléphone mobile 10 d'un utilisateur (non représenté) de manière à ce qu'il génère à la demande un mot de passe à usage unique, et de configurer un compte utilisateur au moyen d'un login et d'un mot de passe. Au cours de cette procédure d'enregistrement une clé secrète Ks, partagée avec un serveur 11 et une application de génération de mot de passe à usage unique ont été installées sur le téléphone mobile 10.
Ainsi, l'utilisateur dispose d'un téléphone mobile 10 adapté pour générer et transmettre au serveur 11 un code de validation, en l'espèce un mot de passe à usage unique, nécessaire à l'authentification de l'utilisateur, et d'un terminal 12 de type « PC » (de l'anglais « Personal Computer »), adapté pour accéder à des services internet tels qu'une messagerie, etc., et soumis à un contrôle d'accès. Le serveur 11 est adapté pour authentifier l'utilisateur selon la solution « Google Authenticator » et autoriser ainsi l'accès à un service requis lorsque l'authentification a réussi. Lors d'un accès de l'utilisateur à un service, au cours d'une première étape E10 de demande d'authentification, une requête d'authentification est transmise par l'utilisateur depuis son terminal 12 au serveur 11. Par exemple, cette requête comprend un login et un mot de passe propres à l'utilisateur. Le login et le mot de passe constituent le premier facteur de l'authentification. Ils correspondent à quelque chose que l'utilisateur connaît. Dans un cas où les données transmises par l'utilisateur dans la requête d'authentification sont correctes, c'est-à-dire dans un cas où le mot de passe est bien celui qui est associé au login saisi, alors dans une étape suivante El 1 de génération de mot de passe jetable, le serveur 11 génère un mot de passe à usage unique au moyen d'un algorithme cryptographique paramétré par la clé secrète KS propre au téléphone mobile 10. Dans une étape E12 de demande d'OTP, le serveur 11 envoie au terminal 12 une demande d'OTP. Dans une étape suivante E13 de génération, l'utilisateur déclenche la génération d'un mot de passe à usage unique sur son téléphone mobile 10. A cette fin, l'utilisateur déclenche l'application préalablement installée sur son téléphone 10 et destinée à calculer et afficher un mot de passe à usage unique sur l'écran de son téléphone 10. L'application de calcul de mots de passe à usage unique consiste en le même algorithme cryptographique que celui utilisé par le serveur 11 au cours de l'étape El 1, paramétré par la clé secrète Ks. Dans une étape E14 suivante de saisie d'OTP, l'utilisateur saisit sur le clavier de son terminal 12 le mot de passe généré et affiché sur l'écran de son téléphone mobile 10. Dans une étape E15 d'envoi d'OTP, le mot de passe à usage unique est envoyé au serveur 11 par le terminal 12. Dans une étape El 6 de vérification, le serveur 11 vérifie que le mot de passe à usage unique reçu du terminal 12 correspond au mot de passe qu'il a généré au cours de l'étape El 1 de génération. Si les mots de passe à usage unique reçus et générés sont identiques, alors l'authentification a réussi et le serveur 11 envoie au terminal 12 un message d'authentification réussie au cours d'une étape E17. Dans le cas où les mots de passe sont identiques, cela signifie que l'utilisateur est bien en possession du terminal mobile adapté pour générer des mots de passe à usage unique selon « Google Authenticator ». Le deuxième facteur d'authentification est ici la possession du terminal mobile 10 qui a été préalablement configuré pour générer le même mot de passe jetable que celui généré par le serveur 11. Ainsi, en vérifiant le mot de passe à usage unique généré depuis le téléphone mobile 10, le serveur vérifie que le téléphone mobile 10 est bien en possession de l'utilisateur.
Cependant, dans cet exemple, la preuve de possession du téléphone mobile 10 est contestable. En effet, la clé secrète KS utilisée par le téléphone mobile 10 lors de la génération du mot de passe à usage unique peut être volée par une personne malintentionnée et installée sur un autre téléphone mobile ou un autre équipement, de manière à générer un mot de passe à usage unique depuis cet autre téléphone ou cet autre équipement. Ainsi, si la personne malintentionnée réussit à obtenir le login et mot de passe de l'utilisateur légitime, elle peut accéder au compte de l'utilisateur légitime. Il n'est ainsi pas garanti avec cette méthode que le mot de passe a été généré par le téléphone mobile de l'utilisateur. Afin de pallier ce problème de sécurité, une amélioration évidente de ce procédé serait d'utiliser une carte « SIM » cryptographique (de l'anglais « Subscriber Identity Module ») sur le terminal mobile et d'installer la clé secrète KS partagée par le téléphone et le serveur et utilisée pour générer les mots de passe à usage unique dans une zone protégée de la carte SIM, non accessible en lecture. Les cartes SIM cryptographiques sont des cartes à crypto-processeur qui ont des capacités d'exécuter des algorithmes cryptographiques autres que les algorithmes de base définis pour accéder au réseau. Cependant, toutes les cartes SIM n'ont pas de telles capacités et la distribution de telles cartes à tous les utilisateurs serait onéreuse et prendrait en outre beaucoup de temps.
L'invention résout les inconvénients décrits ci-dessus en proposant un procédé d'authentification entre un utilisateur disposant d'un premier et d'un deuxième dispositifs et une entité d'authentification distante, le procédé comprenant : - une étape d'envoi depuis le premier dispositif d'au moins une première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - une étape de réception par le premier dispositif d'une requête d'une deuxième donnée d'authentification en provenance de l'entité d'authentification, - une étape de génération sur le deuxième dispositif de la deuxième donnée d'authentification, consécutive à l'étape de réception d'une requête, - une étape d'envoi à l'entité d'authentification par le deuxième dispositif de la deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire. Le procédé d'authentification selon l'invention est une authentification forte au cours de laquelle l'utilisateur prouve avec une première donnée d'authentification qu'il connaît quelque chose, en l'espèce un login et un mot de passe et qu'il détient quelque chose, en l'espèce un terminal mobile. Ici, la preuve de possession du terminal mobile est difficilement contestable dans le sens où, la deuxième donnée d'authentification étant transmise depuis le téléphone sur un canal de signalisation du réseau mobile, cette transmission implique une authentification préalable de la carte SIM par le réseau et la transmission dans la signalisation d'un identifiant du téléphone mobile, le numéro MSISDN. Ainsi, même si une personne malintentionnée volait la clé secrète installée sur le téléphone mobile de l'utilisateur, elle ne pourrait pas faire la preuve qu'une donnée d'authentification générée sur son propre téléphone provient du téléphone de l'utilisateur. Le procédé offre ainsi un avantage que n'offrent pas des solutions connues.
Par ailleurs, le procédé d'authentification offre une solution plus sécurisée que des solutions connues, qui proposent de transmettre la deuxième donnée d'authentification par le même canal que celui utilisé pour transmettre la première donnée d'authentification. En effet, la deuxième donnée est transmise sur un canal du réseau mobile, différent du canal utilisé pour transmettre la première donnée. Par ailleurs l'accès à ce canal est soumis à authentification du réseau. Par ailleurs, la mise en oeuvre du procédé d'authentification ne nécessite pas une infrastructure lourde. En effet, lorsque le procédé est opéré par l'opérateur internet mobile, celui-ci dispose de l'infrastructure réseau et des informations qui permettent une mise en oeuvre aisée du procédé. Ces informations sont par exemple les données d'abonnement mobile et les données d'abonnement Internet. Par ailleurs, l'infrastructure de transmission de la deuxième donnée d'authentification, un canal de signalisation du réseau mobile est elle aussi déjà existante. Le procédé d'authentification selon l'invention est particulièrement adapté à des offres d'architectures en cloud computing. En effet, de telles architectures permettent à des utilisateurs d'accéder à des ressources, parfois sensibles, via Internet. Afin d'obtenir la confiance des utilisateurs en de telles offres, il est important d'afficher un bon niveau de sécurité. L'authentification forte du procédé objet de la présente invention répond à ce besoin. Selon un exemple de réalisation, le canal de communication est conforme à la 25 norme USSD. Le canal USSD ne nécessite qu'un accès GSM de base et les services qui empruntent ce canal sont accessibles à partir de n'importe quel terminal mobile, sans adjonction de code spécifique sur le terminal. L'avantage de ce canal est d'être toujours disponible et très réactif. Il est d'ailleurs généralement associé aux services de 30 téléphonie de type temps réel ou de messagerie instantanée. Dans un exemple de réalisation, la deuxième donnée d'authentification est un mot de passe à usage unique. Il est connu que les mots de passe à usage unique ne sont valables qu'une fois et ne sont valables que pendant une courte durée. Cela fait de ce type de donnée une donnée non critique qui peut être transmise sur un canal non sécurisé, tel que le canal USSD. Dans un exemple de réalisation, la requête d'une deuxième donnée d'authentification comprend un challenge.
Cet exemple de réalisation correspond aux mots de passe à usage unique asynchrones. Dans un autre exemple de réalisation, la requête d'une deuxième donnée d'authentification reçue de l'entité d'authentification comprend une demande de mot de passe à usage unique.
Cet exemple de réalisation correspond aux mots de passe à usage unique synchrones. Avantageusement, le procédé d'authentification selon l'invention comprend, préalablement à l'étape de génération, une étape de lecture au cours de laquelle le challenge affiché sur le premier dispositif est scanné par le deuxième dispositif..
Le mode de réalisation qui consiste à scanner le challenge affiché sur l'écran du terminal avec le téléphone mobile évite à l'utilisateur une saisie manuelle, ce qui simplifie l'usage du service d'authentification. Ainsi, l'utilisateur n'a plus qu'à lancer l'application de génération sur son téléphone, une fois le challenge scanné. Par ailleurs, cela évite d'éventuelles erreurs de saisie.
Le procédé selon l'invention comprend les étapes préalables d'enregistrement suivantes : - une étape d'envoi depuis le premier dispositif de la première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - une étape de réception de l'entité d'authentification d'une clé secrète générée à partir d'au moins des données d'identification de l'utilisateur, et d'installation de ladite clé sur le deuxième dispositif, - une étape de réception par le premier dispositif d'une requête d'une nouvelle deuxième donnée d'authentification, en provenance de l'entité d'authentification, - une étape de génération sur le deuxième dispositif de la nouvelle deuxième donnée d'authentification, consécutive à l'étape de réception de la requête, - une étape d'envoi à l'entité d'authentification par le deuxième dispositif de la nouvelle deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire.. La phase d'enregistrement est assez similaire au procédé d'authentification et donc, simple pour l'utilisateur. Cette phase permet de distribuer à l'utilisateur la clé secrète nécessaire à la génération des deuxièmes données d'authentification et cette distribution est confirmée pendant la phase d'enregistrement par l'envoi d'une nouvelle deuxième donnée d'authentification qui utilise, pour sa génération la clé secrète nouvellement transmise.
Dans un exemple de réalisation, le procédé d'authentification selon l'invention comprend en outre : - une étape de réception de la deuxième donnée d'authentification envoyée via le canal de communication du réseau cellulaire par un portail de l'entité d'authentification, et - une étape d'envoi par le portail à un serveur d'un message comprenant ladite deuxième donnée d'authentification et un identifiant de l'utilisateur obtenu de la signalisation du réseau cellulaire. L'invention concerne aussi une entité utilisateur comprenant un premier et un deuxième dispositifs utilisateur, le premier dispositif comprenant : - des moyens d'envoi, agencés pour envoyer au moins une première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - des moyens de réception, agencés pour recevoir de l'entité d'authentification une requête d'une deuxième donnée d'authentification, le deuxième dispositif comprenant : - des moyens de génération, agencés pour générer sur le deuxième dispositif de la deuxième donnée d'authentification, consécutive à l'étape de réception d'une requête, - des moyens d'envoi, agencés pour envoyer à l'entité d'authentification la deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire. Selon un exemple de réalisation de l'entité utilisateur, le deuxième dispositif comprend en outre des moyens de lecture, agencés pour scanner un challenge affiché sur le premier dispositif. L'invention concerne aussi une entité d'authentification comprenant un serveur et un portail, le serveur comprenant : - des premiers moyens de réception, agencés pour recevoir d'un premier dispositif utilisateur une première donnée d'authentification, - des moyens d'envoi d'une requête, agencés pour envoyer une requête d'une deuxième donnée d'authentification, - des deuxièmes moyens de réception, agencés pour recevoir un message comprenant la deuxième donnée d'authentification et un identifiant de l'utilisateur, le portail comprenant : - des moyens de réception de la deuxième donnée d'authentification, agencés pour recevoir la deuxième donnée d'authentification d'un deuxième dispositif utilisateur via un canal de communication d'un réseau cellulaire, - des moyens d'envoi de messages, agencés pour construire et envoyer un message au serveur, ledit message comprenant la deuxième donnée d'authentification reçue et un identifiant de l'utilisateur.
L'invention concerne également un système d'authentification comprenant : - au moins une entité utilisateur selon l'invention, et - une entité d'authentification selon l'invention. D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description détaillée ci-après, et des dessins annexés parmi lesquels : - la figure 1, déjà commentée, décrit les étapes d'un procédé d'authentification forte connu, appelé « Google Authenticator » ; - la figure 2 décrit les étapes d'un procédé d'authentification forte selon un exemple de réalisation de l'invention ; - la figure 3 décrit les étapes d'un procédé d'enregistrement selon un exemple de réalisation de l'invention ; - la figure 4 représente un dispositif utilisateur mettant en oeuvre les étapes du procédé, selon un exemple de réalisation ; - la figure 5 représente une entité d'authentification mettant en oeuvre les étapes du procédé d'authentification, selon un exemple de réalisation. Un procédé d'authentification selon l'invention va maintenant être décrit en relation avec la figure 2. Le procédé d'authentification selon l'invention décrit ici est un procédé d'authentification forte. Une authentification forte est une procédure qui requiert la combinaison d'au moins deux facteurs d'authentification, ici quelque chose qu'un utilisateur connaît, en l'espèce un login et un mot de passe, et quelque chose que l'utilisateur détient, un authentifieur (le terme anglais « token » est habituellement utilisé), ici un téléphone mobile. L'utilisateur va ainsi devoir prouver à un serveur qu'il connaît son login et son mot de passe, et qu'il détient le téléphone mobile qu'il a préalablement déclaré comme lui appartenant et configuré pour mettre en oeuvre la procédure d'authentification. Cette configuration est réalisée au cours d'une procédure préalable d'enregistrement décrite de manière détaillée en relation avec la figure 3. L'utilisateur (non représenté) possède un terminal 20, par exemple un terminal de type « PC » (de l'anglais « Personal Computer ») et un téléphone mobile 21. Une entité d'authentification 22 comprend au moins un serveur 22-1 et un portail « USSD » 22-2 (de l'anglais « Unstructured Supplementary Service Data ») apte à mettre en oeuvre le protocole USSD. Le serveur 22-1 est destiné à authentifier l'utilisateur lorsque celui-ci souhaite accéder depuis son terminal 20, via un réseau (non représenté), par exemple Internet, à un service auquel il a préalablement souscrit. Un service auquel l'utilisateur souscrit est par exemple un service de messagerie, ou un service de paris en ligne. Le téléphone mobile 21 et le serveur 22-1 partagent une clé secrète Ks, propre au téléphone mobile 21. Dans cet exemple de réalisation, la clé KS est installée sur le terminal mobile 21. Le portail USSD 22-2 est adapté pour recevoir du téléphone 21, via un canal d'un réseau de télécommunications mobiles (non représenté), par exemple le réseau « GSM » (pour « Global System for Mobile Communications »), un code USSD comprenant un mot de passe à usage unique généré par le téléphone mobile 21, et pour retransmettre au serveur 22-1 le mot de passe à usage unique dans un langage compréhensible par le serveur 22-1 ainsi qu'un identifiant associé au téléphone mobile 21 qui a envoyé le code USSD. Le canal USSD est une fonctionnalité de base du standard GSM ; il permet de véhiculer des informations au-dessus des canaux de signalisation du réseau GSM, sous forme de codes USSD. Le canal USSD ne nécessite qu'un accès GSM de base et les services qui empruntent ce canal sont accessibles à partir de n'importe quel terminal mobile, sans adjonction de code spécifique sur le terminal. Un service USSD se présente sous la forme d'un code USSD. Par exemple, on connaît le service USSD « #123# », offert par plusieurs opérateurs de téléphonie mobile pour permettre d'accéder au suivi de sa consommation, sur compte prépayé ou non. Lorsqu'un utilisateur saisit et envoie sur le réseau le code #123# depuis son téléphone mobile, les informations de suivi de consommation s'affichent en retour sur l'écran de son téléphone. Dans une étape initiale E20 de demande d'accès, l'utilisateur envoie au serveur 22-1 depuis son terminal 20 une requête d'authentification qui comprend au moins une première donnée d'authentification. Par exemple, la requête d'authentification comprend un nom de connexion de l'utilisateur (le terme couramment utilisé est le terme anglais « login ») et un mot de passe, propres à l'utilisateur. Cette première donnée d'authentification, en l'espèce le couple login, mot de passe, constitue le premier facteur du procédé d'authentification selon l'invention. Ce facteur représente quelque chose que l'utilisateur connaît. Bien sûr, on suppose ici que la première donnée d'authentification est correcte, c'est-à-dire que le login correspond à un compte de connexion de l'utilisateur préalablement créé, et que le mot de passe est bien celui qui valide l'accès à ce compte. Ainsi, on suppose qu'une vérification de cette première donnée effectuée par le serveur 22-1 en fin d'étape E20 est positive. Dans une étape E21 de génération d'un challenge, le serveur 22-1 génère et mémorise un challenge en association avec un identifiant de l'utilisateur. Le challenge est une suite aléatoire de chiffres, destinée à être utilisée lors de la génération d'un mot de passe à usage unique, ou « OTP » (de l'anglais « One Time Password »), ou mot de passe jetable. Pour des raisons de sécurité, et notamment pour garantir l'unicité des challenges, la taille du challenge est de préférence supérieure à 8 caractères. L'identifiant de l'utilisateur est par exemple un numéro « MSISDN » (pour « Mobile Station ISDN Number ») qui est le numéro du téléphone 21 « connu du public » grâce auquel on peut joindre l'utilisateur sur son téléphone mobile 21, ou/et un numéro « IMEI » (de l'anglais « International Mobile Equipment Identity ») qui permet d'identifier de manière unique chacun des terminaux de téléphonie mobile associé au téléphone 21. Les numéros MSISDN et IMEI peuvent être obtenus par le serveur 22-1 durant la procédure d'enregistrement. Dans une étape E22 de demande de mot de passe, le serveur 22-1 envoie au terminal 20 une requête de mot de passe à usage unique. Dans cet exemple de réalisation, la requête comprend le challenge généré par le serveur 22-1 au cours de l'étape précédente E21. Ainsi, en fin d'étape E22, le challenge est affiché sur l'écran du terminal 20. Dans une étape E23 de déclenchement d'application, l'utilisateur déclenche l'exécution d'une application préalablement installée sur le téléphone 21 et destinée à générer le mot de passe à usage unique. Dans une étape suivante E24 de récupération du challenge, exécutée dans le cadre de l'application déclenchée au cours de l'étape précédente, l'utilisateur scanne le challenge affiché sur l'écran de son terminal 20 au moyen de son téléphone mobile 21. Dans un autre exemple de réalisation, l'utilisateur saisit manuellement le challenge affiché sur l'écran de son terminal sur le clavier de son téléphone 21. Cette étape E24 de récupération du challenge est destinée à disposer du challenge reçu par le terminal 20 sur le téléphone mobile 21.
Dans une étape E25 de génération de mot de passe côté téléphone, consécutive aux étapes E23 et E24, un mot de passe à usage unique est généré sur le téléphone mobile 21. L'étape E25 de génération de mot de passe est exécutée dans le cadre de l'application déclenchée au cours de l'étape E23. Dans un exemple de réalisation, l'étape de génération est exécutée automatiquement après avoir scanné le challenge durant l'étape E24. Dans un autre exemple de réalisation, elle est exécutée sur commande de l'utilisateur, après avoir scanné le challenge. La génération du mot de passe consiste à appliquer un algorithme de chiffrement, paramétré par la clé secrète KS partagée avec le serveur 22-1, au challenge récupéré au cours de l'étape précédente E24. Un exemple d'algorithme utilisé pour la génération d'OTP est l'algorithme HMAC-SHA1 (pour « Hash-based Message Authentication Code - Secure Hash Algorithm »). Dans cet exemple de réalisation, les mots de passe à usage unique générés ont une taille d'au moins 6 caractères. Dans une étape E26 d'envoi du mot de passe, le mot de passe à usage unique généré sur le téléphone 21 au cours de l'étape précédente E25 est envoyé à l'entité d'authentification 22 sur le canal USSD. Plus précisément, un code USSD est envoyé depuis le téléphone 21 sur le canal USSD. Le code précise le service USSD concerné, en l'espèce l'envoi d'un mot de passe et il comprend le mot de passe à envoyer. Par exemple le code USSD est de la forme « *#151#981256# », où la valeur « 151 » représente le service d'envoi d'un mot de passe, et « 981256 » le mot de passe à usage unique généré au cours de l'étape E25. Le canal USSD étant une fonctionnalité de base du réseau GSM, l'envoi du code USSD sur ce canal bénéficie de l'authentification inhérente à l'accès au réseau GSM. Ainsi, en transmettant le code sur le canal USSD on a la garantie que celui-ci est envoyé depuis un téléphone mobile dont la carte SIM a été authentifiée. Dans une étape E27 de réception et de retransmission, le code USSD est reçu sur le canal de signalisation USSD par le portail USSD 22-2 de l'entité d'authentification 22. Le portail 22-2 extrait du message de signalisation le mot de passe, et construit un nouveau message comprenant le mot de passe extrait et un identifiant de l'utilisateur du téléphone 21 qu'il a obtenu dans la signalisation USSD. Le portail USSD 22-2 transmet ce nouveau message au serveur 22-1. Ce nouveau message est par exemple transmis au moyen du protocole HTTPS (de l'anglais « HyperText Transfer Protocol Secured ») ; il est par exemple encodé au format « XML» (de l'anglais « eXtensible Markup Language »), selon une interface définie préalablement entre le portail USSD 22-2 et le serveur 22-1. L'identifiant du téléphone 21 est par exemple le numéro « MSISDN », complété éventuellement du numéro « IMEI », transportés dans la signalisation. Dans une étape E28 de génération de mot de passe côté serveur, le serveur 22-1 génère le mot de passe à usage unique à partir du challenge qu'il a lui-même généré et mémorisé au cours de l'étape E21 de génération du challenge. Bien sûr, le serveur 22-1 utilise le même algorithme de génération de mot de passe que celui utilisé par le téléphone 21 au cours de l'étape E25, paramétré par la clé secrète KS qu'il partage avec le téléphone 21. Dans une étape E29 de vérification, le serveur 22-1 vérifie que le mot de passe à usage unique reçu du téléphone 21 via le portail USSD 22-2 est bien égal au mot de passe qu'il a généré au cours de l'étape précédente E28. Si c'est le cas, l'authentification de l'utilisateur a réussi. Le mot de passe à usage unique constitue le deuxième facteur de l'authentification selon l'invention. Ainsi, le procédé selon l'invention réalise une authentification forte de l'utilisateur, basée sur la vérification de deux facteurs combinés : la connaissance par l'utilisateur d'un login et d'un mot de passe, et la preuve de possession du téléphone 21. En effet, s'agissant de cette dernière, le code USSD qui contient le mot de passe à usage unique attendu, est transmis depuis le téléphone 21 via un canal du réseau GSM et le mot de passe est ainsi associé à un identifiant de l'utilisateur par une entité indépendante de l'utilisateur, en l'espèce le portail USSD. Cela apporte une sécurité accrue puisqu'une personne malintentionnée ne peut pas modifier elle-même cette information pour se faire passer pour l'utilisateur légitime. Si la vérification effectuée au cours de l'étape E29 est positive, le serveur 22-1 envoie au terminal 20 un message indiquant que l'authentification a réussi au cours d'une étape E30 de confirmation. L'utilisateur peut ensuite accéder au service pour lequel il requérait un accès. Ici, la preuve de possession du téléphone est moins contestable que si le mot de passe, une fois généré sur le téléphone mobile avait été saisi sur le clavier du terminal 20 de l'utilisateur. En effet, l'envoi du mot de passe par le canal USSD suppose une authentification GSM entre la carte SIM insérée dans le terminal et le réseau, ainsi que la transmission via la signalisation d'au moins un identifiant du téléphone de l'utilisateur. Ainsi, le portail USSD 22-2 qui reçoit l'OTP est sûr que celui-ci a été généré sur un terminal qui comprend la carte SIM de l'utilisateur. A priori il s'agit donc bien du terminal de l'utilisateur. Avec l'envoi de cet OTP par le téléphone, il est prouvé que l'utilisateur est en possession du téléphone.
L'exemple de réalisation décrit la génération d'un mot de passe à usage unique asynchrone, c'est-à-dire basé sur un challenge qui est transmis du serveur au téléphone 21, via le terminal 20. Bien sûr l'invention n'est pas limitée à la génération d'OTP asynchrones et dans un autre exemple de réalisation un mot de passe est généré de façon synchrone. Il est connu que dans le cas d'OTP synchrones, le serveur et le téléphone sont synchronisés grâce à la date courante ou à un compteur, ou par une combinaison de la date courante et d'un compteur. Dans cet exemple de réalisation, la requête d'authentification transmise du serveur au terminal 20 au cours de l'étape E22 est une requête de mot de passe à usage unique prédéfinie qui ne comprend pas de challenge. L'étape de récupération du challenge E24 n'est donc pas exécutée, de même que l'étape E21 de génération du challenge par le serveur 22-1. Dans ce cas, le mot de passe est généré lors du déclenchement de l'application de génération sur le téléphone 21 au cours de l'étape E23 de déclenchement. Dans l'exemple de réalisation décrit ici, on suppose que le service est accessible depuis le serveur 22-1. Bien sûr, l'invention n'est pas limitée à cet exemple et dans un autre exemple de réalisation, le serveur 22-1 est dédié à l'authentification de l'utilisateur, le service en tant que tel étant offert par un autre serveur (non représenté) dédié au service. L'invention est décrite ici avec un accès via le réseau GSM. L'invention n'est pas limitée à ce réseau puisque le canal USSD est également accessible depuis les réseaux « GPRS » (pour « General Packet Radio Service ») ou « UMTS » (pour « Universal Mobile Telecommunications System »). Ainsi, l'invention s'applique également à ces réseaux. Dans l'exemple de réalisation décrit ici, la clé secrète KS partagée avec le serveur 22-1 est installée sur le téléphone mobile 21. Dans un autre exemple de réalisation, la clé secrète est installée sur la carte SIM du téléphone 21, dans une zone non accessible en lecture. Dans ce cas, la sécurité du procédé est accrue puisqu'il devient alors impossible à une personne malintentionnée de voler la clé secrète Ks. Dans un exemple de réalisation, les instructions de code qui mettent en oeuvre le procédé d'authentification selon l'invention sur le téléphone 21 sont sous forme d'une applet installée dans la carte SIM et exécutée par la carte SIM. On comprend que ce mode de réalisation est plus avantageux en termes de sécurité. Dans l'exemple de réalisation décrit ici, le challenge est saisi sur le téléphone 21 au cours de l'étape E24 de récupération en scannant la valeur affichée sur le terminal 20 au moyen du téléphone 21. L'invention n'est pas limitée à cet exemple.
Dans un deuxième exemple de réalisation, l'utilisateur saisit la valeur du challenge sur le clavier de son téléphone 21. Dans un troisième exemple de réalisation, une liaison Bluetooth est établie entre le terminal 20 et le téléphone 21, et le challenge est transmis du terminal 20 au téléphone 21 via cette liaison. L'utilisation d'une liaison Bluetooth augmente la sécurité du procédé d'authentification car elle garantit que le terminal 20 est toujours utilisé en association avec le téléphone 21 de l'utilisateur. Un procédé d'enregistrement de l'utilisateur va maintenant être décrit en relation avec la figure 3. Un tel enregistrement est nécessaire pour une mise en oeuvre ultérieure du procédé d'authentification selon l'invention. En effet, un tel enregistrement est destiné à distribuer un matériel à l'utilisateur, nécessaire à la génération des mots de passe à usage unique qui vont être utilisés pour accéder à un/aux services auquel/auxquels l'utilisateur a souscrit. Plus précisément cette étape d'enregistrement permet d'installer sur le téléphone 21 de l'utilisateur la clé secrète KS partagée avec le serveur 22-1, qui va être utilisée lors de la génération de mots de passe à usage unique. On suppose que l'application de génération de mot de passe est déjà installée sur le téléphone. Une telle installation peut se faire par téléchargement sur le téléphone 21, par envoi de « SMS » (de l'anglais « Short Message Service ») contenant l'application, ou lorsque l'application est destinée à être installée sur la SIM, selon une procédure « OTA » (de l'anglais « Over The Air »). Dans cet exemple de réalisation, on suppose que l'utilisateur possède un abonnement auprès d'un opérateur de réseau mobile (non représenté) pour ses accès mobile et Internet. L'opérateur dispose donc de données d'abonnement à un compte mobile de l'utilisateur, telles qu'un numéro MSISDN et un numéro IMEI. Il dispose également comme données d'accès à Internet d'un login/mot de passe qui permettent à l'utilisateur d'accéder également à son compte mobile depuis internet. Ces données sont gérées par l'opérateur pour l'ensemble des utilisateurs abonnés au moyen d'un serveur d'identités 23. Bien sûr, si l'utilisateur possède plusieurs terminaux mobiles, il accède à plusieurs comptes mobiles et a pour chacun un login/mot de passe et des identifiants MSISDN et IMEI associés. On suppose ici que l'opérateur gère également l'entité d'authentification 22. Lorsqu'un utilisateur souscrit au service d'authentification selon l'invention, il envoie dans une étape E300 de demande de souscription, une requête de souscription depuis son terminal 20 vers le serveur 22-1.
Dans une étape E301 de demande d'authentification, le serveur 22-1 envoie au terminal 20 une requête d'authentification. De manière classique, la requête comprend une demande de login et de mot de passe. Dans une étape E302 de saisie, l'utilisateur saisit son login et son mot de passe sur son terminal 20 et envoie ces deux données au serveur 22-1. Le login et le mot de passe correspondent à des données d'abonnement du compte mobile internet de l'utilisateur associées à son téléphone 21. Dans une étape E303 de demande de vérification, le serveur 22-1 transmet au serveur d'identités 23 les deux données. Le serveur d'identités 23 vérifie le login et le mot de passe de l'utilisateur et en cas de succès, transmet au serveur 22-1 dans une étape E304 de résultat de la vérification un message de succès de l'authentification. Dans une étape E305 de demande de données, le serveur 22-1 demande au serveur d'identités 23 le numéro de téléphone MSISDN associé au compte de l'utilisateur, et éventuellement le numéro d'identification IMEI associé.
Dans une étape E306 de réponse, le serveur d'identités 23 envoie au serveur 22-1 le numéro MSISDN et éventuellement le numéro IMEI de l'utilisateur. Dans une étape E307 de génération d'une clé, le serveur 22-1 génère une clé secrète KS pour le compte de l'utilisateur, plus précisément pour le téléphone mobile 21 de l'utilisateur. Cette clé secrète est obtenue par dérivation d'une clé maîtresse KM au moyen d'un algorithme de dérivation de clés. Cet algorithme, paramétré par la clé maîtresse KM, est appliqué à au moins un identifiant du téléphone 21 de l'utilisateur, par exemple le numéro MSISDN, et éventuellement au numéro IMEI. La dérivation de clés est supposée connue de l'homme du métier et ne sera pas détaillée ici. Le serveur 22-1 mémorise la clé secrète dérivée KS en association avec le numéro MSISDN et éventuellement le numéro IMEI propres au téléphone 21 de l'utilisateur. Utiliser le numéro IMEI pour la dérivation de clés permet d'associer la clé secrète KS également au téléphone 21 en tant que dispositif. Dans une étape E308 de génération d'un challenge, le serveur 22-1 génère un challenge pour la procédure courante d'enregistrement de l'utilisateur. Ce challenge est mémorisé en association avec le numéro MSISDN du téléphone 21 de l'utilisateur. Dans une étape E309 d'envoi de la clé secrète, le serveur 22-1 envoie la clé dérivée KS au terminal 20. La clé secrète est transmise de façon sécurisée au terminal 20. Dans un exemple de réalisation, la clé est transmise chiffrée au terminal 20 au moyen d'une clé de session négociée préalablement à l'envoi. Par exemple, la clé secrète est transmise dans une session HTTPS. Dans un autre exemple de réalisation, la clé secrète KS est transmise à l'utilisateur par courrier. Dans une étape E310 d'envoi du challenge, le serveur 22-1 envoie au terminal 20 le challenge généré au cours de l'étape E308 de génération d'un challenge.
Dans une étape E311 d'installation, l'utilisateur installe la clé secrète KS sur le téléphone 21. Dans un exemple de réalisation, l'utilisateur scanne la valeur de la clé secrète KS affichée sur l'écran du terminal 20 par exemple sous forme d'un flashcode et l'enregistre sur le téléphone 21. Dans un exemple de réalisation, l'accès à la clé KS est protégée, par exemple au moyen d'un code « PIN » de déblocage (pour « Personal Identification Number »). Dans une étape E312 de déclenchement d'application, l'utilisateur déclenche l'exécution d'une application préalablement installée sur le téléphone 21 et destinée à générer un mot de passe à usage unique. Cette application peut être téléchargée à partir du téléphone 21. Dans une variante de réalisation, elle peut être envoyée au téléphone par exemple sous forme d'un ou plusieurs messages courts (le terme « SMS est habituellement utilisé). Dans une étape suivante E313 de saisie du challenge, l'utilisateur scanne la valeur du challenge affichée sur l'écran du terminal 20, par exemple sous forme d'un flashcode, au moyen de son téléphone 21. Dans un autre exemple de réalisation, il saisit la valeur du challenge sur le clavier de son téléphone 21. Cette étape E313 de saisie est exécutée dans le cadre de l'application déclenchée au cours de l'étape précédente E312. Dans une étape E314 de génération de mot de passe par le téléphone, consécutive aux étapes E312 et E313, un mot de passe à usage unique est généré sur le téléphone 21. L'étape E314 de génération est exécutée dans le cadre de l'application déclenchée au cours de l'étape E312. La génération consiste à appliquer au challenge obtenu au cours de l'étape E313 de saisie un algorithme de chiffrement paramétré par la clé secrète Ks. Dans une étape E315 d'envoi, le terminal 21 envoie à l'entité d'authentification 22 un code USSD comprenant le mot de passe généré au cours de l'étape E314. Plus précisément, le code USSD est envoyé sur le canal USSD. Dans une étape E316 de réception et de retransmission, le code USSD est reçu par le portail USSD 22-2. Le mot de passe à usage unique est extrait du code USSD puis envoyé au serveur 22-1 par le portail USSD 22-2, en association avec un identifiant du téléphone 21, par exemple le numéro MSISDN et éventuellement le numéro IMEI. Le numéro MSISDN est récupéré par le portail USSD 22-1 dans la signalisation USSD. Le message est par exemple une requête HTTPS. Dans une étape E317 de génération d'un mot de passe par le serveur, le serveur 22-1 génère un mot de passe à usage unique à partir du challenge qu'il a généré au cours de l'étape E308. A cette fin, le serveur applique le même algorithme de chiffrement que celui appliqué par le téléphone 21 au cours de l'étape E314, paramétré par la clé secrète Ks. Dans une étape E318 de vérification, le mot de passe généré au cours de l'étape E316 est comparé au mot de passe reçu par le serveur 22-1 au cours de l'étape E315. Si les mots de passe sont identiques, alors cela signifie que la procédure d'enregistrement s'est effectuée correctement. Cela signifie que la clé secrète KS a été correctement installée sur le téléphone 22 et que la génération de mot de passe s'est faite correctement. Dans ce cas, le serveur 22-1 envoie au terminal 20 dans une étape E319 de confirmation un message indiquant que la souscription au service d'authentification a réussi. Une fois la procédure d'enregistrement au service d'authentification réalisée, l'utilisateur qui souhaite accéder à un service dont l'accès est conditionné par une authentification forte selon l'invention réalise les étapes du procédé d'authentification décrit en relation avec la figure 2. Dans l'exemple décrit ici, la clé secrète KS est installée sur le téléphone au cours de l'étape E311 en scannant la clé affichée avec le téléphone 21. L'invention n'est pas limitée à cet exemple. Dans un deuxième exemple de réalisation, l'utilisateur saisit la valeur de la clé secrète KS sur le clavier de son téléphone 21 et l'enregistre sur le téléphone 21. Dans un troisième exemple de réalisation, une liaison Bluetooth est établie entre le terminal 20 et le téléphone 21, et la clé secrète est transmise du terminal 20 au téléphone 21 via cette liaison. Le challenge transmis au cours de l'étape E310 peut également être transmis du terminal 20 au téléphone 21 via cette liaison. Dans un autre exemple de réalisation, la clé secrète KS et l'application de génération de mots de passe à usage unique sont installées sur la carte SIM pendant la phase d'enregistrement. Une telle installation peut être réalisée selon une procédure OTA, mise en oeuvre par l'opérateur de téléphonie mobile. Une entité utilisateur selon l'invention va maintenant être décrite en relation avec la figure 4.
L'entité utilisateur 40 comprend deux dispositifs : un ordinateur 20 de type PC en tant que premier dispositif et un téléphone mobile 21 en tant que deuxième dispositif. Ces deux dispositifs sont utilisés conjointement pour mettre en oeuvre, côté utilisateur, les procédés d'authentification et d'enregistrement décrits précédemment.
De manière classique, l'ordinateur 20 comprend : une unité de traitement 200, un ensemble de mémoire, dont une mémoire volatile 201, ou « RAM » (pour « Random Access Memory ») utilisée pour exécuter des instructions de code, stocker des variables, etc., un écran 202, adapté pour afficher des données, par exemple une requête d'authentification et un challenge reçus de l'entité d'authentification distante 22 (non représentée sur la figure 4). Le challenge est reçu dans une requête d'une deuxième donnée d'authentification, un clavier 203, adapté pour saisir des données, par exemple une première donnée d'authentification comprenant par exemple un login et un mot de passe. Le premier dispositif 20 comprend également : des moyens d'envoi 204, agencés pour envoyer au moins la première donnée d'authentification de l'utilisateur à l'entité d'authentification 22. Les moyens d'envoi 204 sont agencés pour mettre en oeuvre l'étape E20 de demande d'accès du procédé d'authentification décrit précédemment, et les étapes E300 de demande de souscription et E302 de saisie du procédé d'enregistrement précédemment décrit, des moyens de réception 205, agencés pour recevoir de l'entité d'authentification 22 une requête d'une deuxième donnée d'authentification et un message indiquant que l'authentification a réussi. Les moyens de réception 205 sont agencés également pour recevoir la clé secrète K. envoyée par l'entité d'authentification durant la procédure d'enregistrement, ainsi qu'un message indiquant que la souscription s'est correctement déroulée. De manière classique, le téléphone mobile 21, en tant que deuxième dispositif comprend une unité de traitement 210, un ensemble de mémoire, dont une mémoire volatile 211, ou RAM utilisée pour exécuter des instructions de code, stocker des variables, etc., Le deuxième dispositif 21 comprend également : des moyens de saisie 212, agencés pour récupérer le challenge affiché sur l'écran du terminal 20. Dans un exemple de réalisation, les moyens de saisie comprennent une application permettant de scanner le challenge affiché sur l'écran. Dans un autre exemple de réalisation dans lequel le challenge est saisi manuellement par l'utilisateur, les moyens de saisie consistent en le clavier du téléphone 21, des moyens de génération 213, agencés pour générer la deuxième donnée d'authentification. Les moyens de génération 213 sont agencés pour mettre en oeuvre l'étape E25 de génération de mot de passe du procédé d'authentification précédemment décrit, ainsi que l'étape E314 de génération de mot de passe du procédé d'enregistrement précédemment décrit, des moyens d'envoi 214, agencés pour envoyer à l'entité d'authentification 22 via le canal USSD d'un réseau cellulaire la deuxième donnée d'authentification générée. Les moyens d'envoi 214 sont agencés pour mettre en oeuvre l'étape E26 d'envoi du mot de passe du procédé d'authentification précédemment décrit, ainsi que l'étape E315 d'envoi du procédé d'enregistrement précédemment décrit.
Les moyens d'envoi 204 et les moyens de réception 205 du premier dispositif 20, et les moyens de saisie 212, de génération 213 et d'envoi 214 du deuxième dispositif 21 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter certaines des étapes des procédés d'authentification et d'enregistrement précédemment décrits.
Une entité d'authentification selon l'invention va maintenant être décrite en relation avec la figure 5. L'entité d'authentification 22 comprend un serveur 22-1, et un portail USSD 222. Ces deux entités coopèrent pour mettre en oeuvre, côté réseau, les procédés d'authentification et d'enregistrement décrits précédemment. Le serveur 22-1 comprend de manière classique : une unité de traitement 22-10, un ensemble de mémoire, dont une mémoire volatile 22-11, ou RAM utilisée pour exécutée des instructions de code, stocker des variables, etc., Le serveur comprend également : des premiers moyens de réception 22-12, agencés pour recevoir une première donnée d'authentification du premier dispositif utilisateur 20 (non représenté sur la figure 5), des moyens 22-13 d'envoi, agencés pour envoyer au premier dispositif utilisateur 20 une requête d'une deuxième donnée d'authentification, des deuxièmes moyens 22-14 de réception, agencés pour recevoir la deuxième donnée d'authentification, ainsi qu'un identifiant de l'utilisateur. Le portail 22-2 comprend de manière classique : une unité de traitement 22-20, un ensemble de mémoire, dont une mémoire volatile 22-21, ou RAM utilisée pour exécutée des instructions de code, stocker des variables, etc. Le portail 22-2 comprend également : des moyens de réception 22-22, agencés pour recevoir du deuxième dispositif utilisateur 21 (non représenté figure 5) via un canal de communication du réseau cellulaire la deuxième donnée d'authentification d'un message. Le canal est par exemple le canal USSD, des moyens d'envoi 22-23, agencés pour construire et envoyer au serveur 22-1 un message comprenant la deuxième donnée d'authentification reçue via le canal de communication du réseau cellulaire, ainsi qu'un identifiant de l'utilisateur, tel que le numéro MSISDN. Les premiers et deuxièmes moyens de réception 22-12, 22-14, les moyens d'envoi 22-13 du serveur 22-1, et les moyens de réception 22-22, les moyens d'envoi 22-23 du portail 22-2 sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter certaines des étapes des procédés d'authentification et d'enregistrement précédemment décrits.30

Claims (12)

  1. REVENDICATIONS1. Procédé d'authentification entre un utilisateur disposant d'un premier et d'un deuxième dispositifs (20, 21) et une entité (22) d'authentification distante, le procédé comprenant : - une étape (E20) d'envoi depuis le premier dispositif d'au moins une première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - une étape (E22) de réception par le premier dispositif d'une requête d'une deuxième donnée d'authentification en provenance de l'entité d'authentification, - une étape (E25) de génération sur le deuxième dispositif de la deuxième donnée d'authentification, consécutive à l'étape de réception d'une requête, - une étape (E26) d'envoi à l'entité d'authentification par le deuxième dispositif de la deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire.
  2. 2. Procédé d'authentification selon la revendication 1, dans lequel le canal de communication est conforme à la norme USSD.
  3. 3. Procédé d'authentification selon la revendication 1, dans lequel la deuxième donnée d'authentification est un mot de passe à usage unique.
  4. 4. Procédé d'authentification selon la revendication 1, dans lequel la requête d'une deuxième donnée d'authentification comprend un challenge.
  5. 5. Procédé d'authentification selon la revendication 1, dans lequel la requête d'une deuxième donnée d'authentification reçue de l'entité d'authentification comprend une demande de mot de passe à usage unique.
  6. 6. Procédé d'authentification selon la revendication 4, comprenant, préalablement à l'étape de génération, une étape de lecture (E24) au cours de laquelle le challenge affiché sur le premier dispositif est scanné par le deuxième dispositif.
  7. 7. Procédé d'authentification selon la revendication 1, comprenant les étapes préalables d'enregistrement suivantes :- une étape d'envoi (E302) depuis le premier dispositif de la première donnée d'authentification de l'utilisateur auprès de l'entité d'authentification, - une étape de réception (E309) de l'entité d'authentification d'une clé secrète (Kg) générée à partir d'au moins des données d'identification de l'utilisateur, et d'installation de ladite clé sur le deuxième dispositif, - une étape de réception (E310) par le premier dispositif d'une requête d'une nouvelle deuxième donnée d'authentification, en provenance de l'entité d'authentification, - une étape de génération (E314) sur le deuxième dispositif de la nouvelle deuxième donnée d'authentification, consécutive à l'étape de réception de la requête, - une étape d'envoi (E315) à l'entité d'authentification par le deuxième dispositif de la nouvelle deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire.
  8. 8. Procédé d'authentification selon la revendication 1, comprenant en outre : - une étape de réception de la deuxième donnée d'authentification envoyée via le canal de communication du réseau cellulaire par un portail (22-1) de l'entité d'authentification (22), - une étape d'envoi par le portail à un serveur d'un message comprenant ladite deuxième donnée d'authentification et un identifiant de l'utilisateur obtenu de la signalisation du réseau cellulaire.
  9. 9. Entité utilisateur (40) comprenant un premier et un deuxième dispositifs utilisateur (20, 21), le premier dispositif (20) comprenant : - des moyens d'envoi (204), agencés pour envoyer au moins une première donnée d'authentification de l'utilisateur à une entité d'authentification, - des moyens de réception (205), agencés pour recevoir de l'entité d'authentification une requête d'une deuxième donnée d'authentification, le deuxième dispositif (21) comprenant : - des moyens de génération (213), agencés pour générer sur le deuxième dispositif de la deuxième donnée d'authentification, consécutive à l'étape de réception d'une requête,- des moyens d'envoi (214), agencés pour envoyer à l'entité d'authentification la deuxième donnée d'authentification générée, via un canal de communication d'un réseau cellulaire.
  10. 10. Entité utilisateur selon la revendication 9, dans lequel le deuxième dispositif comprend en outre des moyens de lecture (212), agencés pour scanner un challenge affiché sur le premier dispositif.
  11. 11. Entité d'authentification (22) comprenant un serveur (22-1) et un portail (22- 2), le serveur (22-1) comprenant : - des premiers moyens de réception (22-12), agencés pour recevoir d'un premier dispositif utilisateur une première donnée d'authentification, - des moyens (22-13) d'envoi d'une requête, agencés pour envoyer une requête d'une deuxième donnée d'authentification, - des deuxièmes moyens de réception (22-14), agencés pour recevoir un message comprenant la deuxième donnée d'authentification et un identifiant de l'utilisateur, le portail (22-2) comprenant : - des moyens (22-22) de réception de la deuxième donnée d'authentification, agencés pour recevoir la deuxième donnée d'authentification d'un deuxième dispositif utilisateur via un canal de communication d'un réseau cellulaire, - des moyens (22-23) d'envoi de messages, agencés pour construire et envoyer 25 un message au serveur, ledit message comprenant la deuxième donnée d'authentification reçue et un identifiant de l'utilisateur.
  12. 12. Système d'authentification comprenant : - au moins une entité utilisateur selon la revendication 9 ou la revendication 10, 30 et - une entité d'authentification selon la revendication 11. 35
FR1157973A 2011-09-08 2011-09-08 Procede d'authentification Withdrawn FR2980063A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR1157973A FR2980063A1 (fr) 2011-09-08 2011-09-08 Procede d'authentification
PCT/FR2012/052009 WO2013034865A1 (fr) 2011-09-08 2012-09-07 Procede d'authentification
EP12767048.7A EP2754262A1 (fr) 2011-09-08 2012-09-07 Procede d'authentification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1157973A FR2980063A1 (fr) 2011-09-08 2011-09-08 Procede d'authentification

Publications (1)

Publication Number Publication Date
FR2980063A1 true FR2980063A1 (fr) 2013-03-15

Family

ID=46968277

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1157973A Withdrawn FR2980063A1 (fr) 2011-09-08 2011-09-08 Procede d'authentification

Country Status (3)

Country Link
EP (1) EP2754262A1 (fr)
FR (1) FR2980063A1 (fr)
WO (1) WO2013034865A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9038195B2 (en) * 2013-03-15 2015-05-19 Google Technology Holdings LLC Accessing a cloud-based service using a communication device linked to another communication device via a peer-to-peer ad hoc communication link
FR3013475B1 (fr) * 2013-11-19 2017-05-19 Oberthur Technologies Procede et dispositifs d'authentification pour acceder a un compte utilisateur d'un service sur un reseau de donnees
US11627463B2 (en) * 2019-08-09 2023-04-11 Critical Ideas, Inc. Authentication via unstructured supplementary service data
US20220166769A1 (en) * 2020-11-25 2022-05-26 Samsung Electronics Co., Ltd. Electronic device for verifying a user's identity

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020177433A1 (en) * 2001-05-24 2002-11-28 International Business Machines Corporation Methods and apparatus for restricting access of a user using a cellular telephone
US20080318548A1 (en) * 2007-06-19 2008-12-25 Jose Bravo Method of and system for strong authentication and defense against man-in-the-middle attacks

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020177433A1 (en) * 2001-05-24 2002-11-28 International Business Machines Corporation Methods and apparatus for restricting access of a user using a cellular telephone
US20080318548A1 (en) * 2007-06-19 2008-12-25 Jose Bravo Method of and system for strong authentication and defense against man-in-the-middle attacks

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Unstructured Supplementary Service Data (USSD); Stage 3 (3GPP TS 24.090 version 10.0.0 Release 10)", TECHNICAL SPECIFICATION, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE (ETSI), 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS ; FRANCE, vol. 3GPP CT 4, no. V10.0.0, 1 May 2011 (2011-05-01), XP014065880 *
MENEZES A ET AL: "Handbook of Applied Cryptography , IDENTIFICATION AND ENTITY AUTHENTICATION", 1 January 1997, HANDBOOK OF APPLIED CRYPTOGRAPHY; [CRC PRESS SERIES ON DISCRETE MATHEMATICES AND ITS APPLICATIONS], CRC PRESS SERIES ON DISCRETE MATHEMATICS AND ITS APPLICATIONS, BOCA RATON, FL, US, PAGE(S) 385 - 424, ISBN: 978-0-8493-8523-0, XP002262234 *

Also Published As

Publication number Publication date
EP2754262A1 (fr) 2014-07-16
WO2013034865A1 (fr) 2013-03-14

Similar Documents

Publication Publication Date Title
US20180295121A1 (en) Secure element authentication
US8543091B2 (en) Secure short message service (SMS) communications
EP3065435A1 (fr) Procédé de génération d'une identité numérique d'un utilisateur d'un dispositif mobile, identité numérique d'utilisateur, et procédé d'authentification utilisant ladite identité numérique de l'utilisateur
US20050144439A1 (en) System and method of managing encryption key management system for mobile terminals
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
WO2011138558A2 (fr) Procede d'authentification d'un utilisateur requerant une transaction avec un fournisseur de service
WO2003096615A1 (fr) Procede d'autentification et de verification de communications par sms
CN109145628B (zh) 一种基于可信执行环境的数据采集方法及系统
US11777743B2 (en) Method for securely providing a personalized electronic identity on a terminal
EP3375133B1 (fr) Procede de securisation et d'authentification d'une telecommunication
FR3030831A1 (fr) Entite electronique securisee, appareil electronique et procede de verification de l’integrite de donnees memorisees dans une telle entite electronique securisee
EP2932429B1 (fr) Procédé de sécurisation d'une demande d'exécution d'une première application par une deuxième application
CN112020716A (zh) 远程生物特征识别
CN114390524B (zh) 一键登录业务的实现方法和装置
EP2754262A1 (fr) Procede d'authentification
WO2016089303A1 (fr) Procédé d'authentification
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
CN112995204A (zh) ProtonMail加密邮件的安全读取方法、装置、设备及存储介质
WO2019038323A1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
EP2115657A2 (fr) Procede et systeme d'autorisation d'acces a un serveur
Suganya et al. Secure user authentication using biometrics in mobile banking
EP2630746B1 (fr) Procede et systeme d'authentification
WO2012022856A1 (fr) Procédé d'authentification d' un utilisateur du réseau internet

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140530